アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

redmine.tokyo 16 感想

May 20, 2019イベントRedmine, redmine.tokyo

2019/5/18 (土) に開催された redmine.tokyo 第 16 回勉強会の感想。

講演 1. もうすぐリリース！ Redmine 4.1 新機能選抜総選挙

Redmine 主要コミッターの前田剛氏による Redmine 4.1 で有望な新機能の紹介。本バージョンは 2019/6/22 にリリース予定とのこと。

Redmine 4.1 （個人的）新機能選抜16件

  1. クリップボードからの画像ペースト
    • Feature #3816: Allow pasting screenshots from clipboard - Redmine
    • チケットや Wiki などの <textarea> でクリップボードの画像をペースト可能になる
    • GitHub では <textarea> に画像ファイルをドラッグ & ドロップするとアップロードと Markdown へ自動リンク生成する機能を提供している
    • Redmine は↑をクリップボードからのペーストで実現
    • バグ報告のスクリーンショット添付などがはかどりそう
    • ローカルに画像ファイルを出力しなくてよいというのが重要、Windows や macOS 標準のスクリーンショット取得操作はクリップボードに保存されるので
  2. 通知メールのFromに更新者名を表示
    • Feature #5913: Authors name in from address of email notifications - Redmine
    • Redmine からの通知メールの差出人がチケットの更新者になる
    • メーラーのリスト表示が見やすくなる
    • メール アドレスは従来どおり固定なのでメーラーのフィルターにおけるアドレスは維持で OK
    • 名前を固定したい場合はプロジェクト設定のメール通知で Redmine<redmine@example.net> のように差出人を含めた形式を指定する
  3. PDF形式添付ファイルのサムネイル表示
  4. ワイド表示カスタムフィールドのツールバー
  5. ガントチャートでの表示項目選択
  6. ガントチャートの折りたたみ
  7. 他のユーザーの作業時間の入力
  8. 作業時間のCSVインポート
  9. 同一チケット内のコメントへのリンク用簡略書式
  10. 新権限「自分が追加したチケットの編集」
    • Feature #1248: New Permission: Edit own issues - Redmine
    • この権限を有効にすると、そのユーザーが追加したチケットに限り他ユーザーへ題名や説明の変更を許可できる
    • Typo 修正や説明の補足追記に有用
    • 仮に他ユーザーが好ましくない編集をしたとしても編集履歴には残るだろうから問題もなさそう
  11. トラッカーの説明
    • Feature #442: Add a description for trackers - Redmine
    • トラッカーの横に情報アイコンが表示され、それをクリックすると対象トラッカーの説明を読める
    • 説明はポップアップ表示されるので邪魔にならない
    • 業界特有の工程や用語をトラッカーで再現している場合、それを周知するためにも有用だろう
  12. gitの日本語ブランチ名でリポジトリブラウザがクラッシュ
  13. 通知メールの件名へのステータス変更情報挿入を抑制するオプション
  14. 入力フィールドに対するスタイル設定
    • Patch #31147: Add custom styles for all fields - Redmine
    • 標準テーマにおいて <select> などの外観が OS 標準から独自スタイルに変更された
    • そのため全 OS で統一感のある外観となる
    • テーマ開発者として重要な変更、minimalflat2 でもこれを踏襲して独自スタイルを定義する予定
  15. ロードマップにバージョンのステータスを表示
  16. ユーザーのプロフィール画面の改善

最近の Redmine の開発体制

  • アクティブなコミッターは 3 人
    • 少なさにも驚くけどJPL 氏以外の 2 人が日本人というのもすごい
    • パッチとチケット作成者も日本人が多い
    • 過去の redmine.tokyo でも日本の Redmine 利用者は他の国と地域に比べて多いという話をしていたけど、開発体制にもそれがあらわれている
  • お願い
    • 1 チケットを作って欲しい
    • 2 パッチをレビューしてほしい
    • 3 フィードバックが欲しい
  • redmine.org へのアカウント登録と英語が壁
    • 英語については Google 翻訳でも OK
    • 過去チケットとの重複も気にしなくてよい
    • 総じて参加者を増やすことを重視している感じ、そのためのハードル下げ

講演 2. ある工場の Redmine バージョンアップ 4

工場の業務管理で利用している Redmine 環境の 4.0 更新について。今回はネタ成分少なめシリアス多め。

Redmine 4.0 への移行

  • Redmine 4.0 を利用している人？...少ない
  • 本日つたえたいことは「Redmine 4.0 は非常によいぞッ」
    • 職場環境は移行できてないのだがテーマ開発用 Docker イメージ経由で触ってみた限り、確かにッッ！
  • 以前はバージョン更新に消極的だったが redmine.tokyo へ参加するようになり、皆が積極的に最新版を使用しているのをみて考えを改めた
  • プラグイン作者のみんな！Redmine 4.0 対応してくれ！
    • 自身の作成しているテーマもだが、現在は Redmine 公式の Docker イメージがあるので開発環境を作りやすくなった
    • 私が akabekobeko/redmine-theme-starter を作ったようにプラグイン開発環境も Starter があれば開発だけでなくユーザーによる検証も実施しやすくなるのでは？
    • 壁としては Docker + docker-compose 環境を用意することだが、これは redmine.org や Redmine.JP に解説するのはどうだろうか？
    • Redmine 自身が公式 Docker イメージを提供しているので、これらのサイトに動作環境の構築手順が載っていてほしい
  • 環境移行の苦労話
    • プラグイン競合の問題によりプロジェクト設定画面を開けない
    • こんな時は Twitter や Slack へ助けを求めよう、ジェバンニが一晩でやってくれるかもしれない、今回はやってくれた
    • 以前も日本の Redmine 系な人たちは Twitter で Redmine 関連をエゴサしているという話をしていたので、これは有効そう

バージョン アップ後の評価

  • Wiki プレビューのタブ化
    • これは確かによい
    • 従来の上下に表示されるのだとかったるいので私はテキスト エディターで Markdown プレビューさせながら編集して Redmine にはコピペしてた
  • シンタックス ハイライト対象言語の大量追加
    • プログラマー的には強い移行動機になる
    • Wiki を Markdown にしていればこれで GitHub (GFM) の使い勝手にかなり近づいた
  • Clipboard paste image プラグインが利用できなくなった
    • Redmine 4.1 の画像ペースト機能で代替可能
    • ただしペーストのみなので画像トリミング機能が失われる
  • 4.0 にしてわかったこと
    • 入力が快適になるのでチケット書きがはかどる
    • こまめにバージョン更新するとユーザーへの影響 (負担) が少なくなる

講演 3. うちのRedmineの使い方（２）

これまで足掛け 10 年ほど Redmine を利用してきたが昨年入社した企業は非 IT 系だった。そこへ Redmine 導入した話。私がいま所属している企業もソフトウェアは利用しているものの開発系ではないため参考にしたい。

Redmine 導入の背景

  • 関東・関西にへ 20 店舗余りを展開する社員数 120 名ほどの企業
  • 全店アンケートにて本店と支店の関係に課題があると出た
    • IT の問題ではなさそうだが...
  • 課題解決のためコミュニケーション ツールとして Redmine を提案

オープンに耐えるコミュニケーションを身につける

  • 隠蔽体質は自覚症状のないまま組織を蝕むので怖い
    • わかる、公開されず記録もされないコミュニケーションは隠蔽体質の温床になりやすい
  • 信頼と言えば聞こえはよいが、PC を利用したデスクワークが主なら公開も記録もされないコミュニケーションで業務を回すのは放任だと認識している
    • 堀江貴文氏が逮捕された時、ライブドアをコミュニケーションがメール中止で会話のない冷たい企業、みたいに揶揄しているのを TV で見て呆れたのを思い出す、それは冷たいとか感情的なものでなく効率化の結果でしょうと
  • コミュニケーションを公開したり記録することについて忌避感を持つのはわかる、失敗が周知され残り続けるのだから
    • しかし失敗するのは前提であり、それにどれだけ耐えられるのかが組織の体力である
    • 失敗が可視化されないと対策を打てない、失敗を責める体質はそれを隠蔽して成功のみの大本営発表がまかり通る組織をつくる
  • 失敗を批評することに慣れる、というのが「オープンに耐えるコミュニケーションを身につける」ことにおいて重要だと考える

業務のステータスを見える化してやり切る習慣を身につける

  • 放置体質もやばい
    • これもわかる、Redmine 導入してもチケットを終了せず放置されることはよく起きる
    • これは「やり切る」ことに慣れていないから
  • 個人的には担当するチケット数の上限を決めて、既存のものが終了していないなら新しいものを受けないようにするのが効果的だと考えている
    • それをするために私は Web ブラウザーで担当チケットをすべてタブ化 (幅を取らないように表示はピン留め) して「終了 (やり切る) 圧力」を可視化するようにしている、それはそのまま「いま抱えている仕事」なので進捗と現状を質問された時に見せる資料にもなる
    • 直近 5 年ぐらいはこれで運用していて 10 タブを超えないようにできてる
    • 仕事が立て込んでくるとタブがガンガン増えてゆき見た目にもヤバさがわかるのでオススメ

AWS に環境構築する話

  • AWS EC2 を利用
  • 添付ファイルは S3 へ保存
  • 文字コードは utf8mb4
    • 絵文字などを考慮すると現状、これ一択
    • うちは utf8 なので、どこかで移行したい
    • チケットの簡易 Vote/Reaction 代わりに絵文字を使いたくなるかもしれないので
  • AWS のハマりどころとしてエンドポイントにリージョン指定が必要なので注意すること

運用

  • 使い方はシンプルに
    • 厳密なルールよりも「おおらか」さ
    • (ツールとして) トレーサビリティーは高いので自己改善できるはず
    • はじめから細かくルールなどを作り込むのはアンチパターン
    • これは 15 回のびくんびくん氏スライドでも言及されてた
  • わかりにくい文言を変更
    • 「トラッカー」を「チケット種別」とか「注記」を「コメント」とか
    • 「注記」については実質、こちらをチケットのコメントとして運用する派が多いだろうし標準でそうしてほしい
    • 「時間を記録」欄の「コメント」と「注記」欄について人に説明するのが難しいので「時間を記録」欄は時間以外は忘れてほしいと言っている
  • UI などのわかりにくい点はプラグインなどで緩和
  • プロジェクトは基本、ひとつ
    • Redmine 運用が崩壊する原因として無尽蔵にプロジェクトを作る問題があるので、こういう縛る方向の対応は重要
    • うちは Wiki を分けるためだけに子プロジェクトがどんどん増えていった
    • よほどの事がない限りプロジェクトは作らない、ぐらいで運用するほうがいい
    • Redmine 標準機能でチケットや Wiki を別プロジェクトに引っ越しできるので追加はプロジェクトが巨大化して困ってからでも遅くない
  • チケットは起票者しかクローズできないようにした
    • 投げっぱなしを防ぎ担当者の変更でキャッチボールする
    • ちゃんと結果を返して (コメントなど) 責任をもって閉じる
    • 私の場合は標準ステータスの「解決」で起票者に返して被レビュー、問題なければ起票者が「終了」するようにしてもらってる
    • 「終了」するまで前述のように Web ブラウザーのタブとしてチケットを残す
    • 「解決」のまま放置されていれば「タブが残る = うっとおしい」ので起票者にチケットのコメントなどでレビューを催促している、繰り返し放置されるようなら「〜の間、放置されているようですがもし成果物を確認済みであればチケットをこちらで閉じます。よろしいでしょうか？」とか書くことも
  • 会議録
    • チケットを利用するのは面白い
    • 会議そのものの進捗を管理可能な点からチケットは有用かもしれない
    • うちは私が主催のものは議事録ドリブンで運用、Wiki に議事録の雛形になる議題を書いて、それを事前に読んでもらって会議中にエディターで発言にあわせて Wiki を埋めてゆくスタイル
  • 人員名簿や店舗情報はプラグインを活用
    • この辺、プラグインなしでも Gravatar でいけそうな気がする
    • Redmine ユーザーはメールアドレスを持っているので、それを Gravatar で画像登録すれば標準で Redmine の随所にユーザー画像として表示できる
    • Redmine 標準のユーザー画像表示を活用するためにも Gravatar 前提で運用するほうが楽だと思う
    • うちはこれを説明して社員アドレスで Gravatar 登録してもらっている
    • 画像については任意で顔写真じゃなくてもいい、ユーザー名を実名にしてるので区別がつく
    • このスライドの例のように実店舗を管理するのなら顔写真のほうがよいのかもしれないが

講演 4. ユーザ要望に応える View customize 活用事例

ユーザーは自分が管理したいこを効率的におこなえればよい。Redmine であることは重要 (本質) ではないし、Redmine 特有の考え方を押し付けるのは難しい。というわけで View customize プラグインを利用したユーザー寄せな Redmine 管理を考える。

今回のユーザー要望

  • 仕様・設計変更書を Redmine で管理したい
  • Excel だと閲覧、検索、編集に難がある
  • 仕様・設計を変更した際に関連モジュールの影響を調査・連絡する
  • 調査対象は複数ある

Redmine をカスタマイズする

  • プロジェクト「仕様・設計変更管理」
  • カスタムフィールドを適宜、追加
  • ワークフローで使用するステータスを追加
  • 親チケットのワークフロー
    • トラッカー「変更依頼」
    • 変更の契機と調査が承認されたことを管理する
  • 子チケットのワークフロー
    • トラッカー「影響」
    • 調査状況、変更の着手、変更完了などを管理する
    • ...ここまでは Redmine 標準機能 (ワークフローなど) を利用
  • プラグイン導入
  • チケット一覧
    • あらかじめ検索条件を開いておく
    • デフォルトのカスタム クエリを指定
    • これらによりデフォルトで仕様設計変更一覧が表示され、活動中のものを確認できる
  • 親チケットの概観
    • 親チケットを見れば全体を鳥瞰できる
    • View customize により...
      • トラッカーなど Redmine 特有の項目を非表示
      • 「関連チケット」のら別を「仕様／設計変更票」に変更
      • Redmine 標準の子チケット一覧を非表示、子チケットは親チケット内へ一覧表示
  • 子チケットの概観
    • 子チケットを見れば変更内容がわかる
    • View customize によりチケット一覧の項目配置を変更、ステータス別にグループ化してラベル付け
  • 子チケットの編集画面
    • ステータスに応じて入力画面を変更
    • これは View customize 経由で jQuery による DOM 操作を利用
  • TODO
    • 子チケットがクローズしたら親チケットも連動してクローズ
    • REST-API でチケット情報を取得して排他制御

講演 5. LycheeカンバンとRedmine運用の事例紹介

Lychee の機能紹介とその実例。

  • 宣伝ではないとのことだが確実に宣伝だし、宣伝としてとてもよかった
  • Lychee の強力なガントチャート機能がひたすらいいなぁと感じたので
  • Redmine 4.0 からコンテキスト メニュー対応などガントチャートの機能強化が進むものの、Lychee ほどのものはなかなか実装できないだろう

大 LT 大会

今回は 5分 x 8 ～ 11 人枠となっておりボリューム満点。

Docker＠CloudGarageで Redmine.Osakaのサイト運用始めたかった

  • やっさん🍶(@yassan168) 氏
  • 資料
  • リモートで京都から音声参加、スライド進行と音声のズレはほとんどないため普通に聞ける
  • 私も VSP 上の素 Redmine on Middleware から Docker + docker-compose 移行したいので参考に
  • VPS などではなく CloudGarage 上へ環境構築するようだ
  • VPS だとホスト OS の Docker をどうするか？コンテナまでの HTTP は Reverse Proxy にする？などのミドルウェア管理が必要
  • Docker 導入の動機として素の yum や apt によるミドルウェア管理から逃れて連携などを Docker イメージに丸投げしたいというのがあるため、CloudGarage のほうがよさそう

Redmine を Docker で Raspberry に入れてみた

  • juno-nishizaki 氏
  • Raspberry Pi で Redmine を動作させる話
  • Raspberry Pi で〜、というのはハードウェアも含めて閉じた処理系という面白さもあってよく聞く
  • 自宅サーバーをこれで運用するのは Raspberry Pi 初期に流行った
  • 登壇では言及されなかったが SD カード運用だとデータが吹っ飛びやすい (自宅サーバー運用のよくある事故) から、もしそうなら外付け HDD マウントしてそれをストレージにしたほうがいい

redmine カスタムクエリーを使って状況を見やすく斬る

  • 門屋浩文＠redmineエバンジェリストの会(@MadoWindahead) 氏
  • 資料
  • カスタムクエリー ネタ
  • 運用解説としてカスタムクエリーがパラメーター込みの URL になるという点が出色
  • Redmine 上の GUI でカスタムクエリーをいじったり保存するのもよいが、いっそ URL をブックマークしてしまうのはどうか？
  • 今どきの Web ブラウザーはタブ機能が標準なのでクエリーを入力する代わりに、クエリーの指す URL をまとめてタブとして開き、それらを往復するほうが手っ取り早い、URL がそのまま目的のリソースを表す REST 的な発想

RedmineのView Customizeを用いたJavaScript OSSの組み込み

  • もりのあさ(@forenoonM) 氏
  • 資料
  • スライドはタイトルのみ 1 枚、続きは Qiita で
  • View customize を利用してチケットに添付した JavaScript を実行するハック
  • MikuMikuDance のモデリング データを利用してキャラクターを踊らせるデモ
  • セキュリティー的に問題がありそうではあるものの、そもそもこれをやるためには View customize をいじった上で実行する JavaScript や諸リソースを添付することになるから外部攻撃の耐性は Redmine 本体相当になるだろう
  • 実行する添付ファイルを外部から改ざん可能だとしたら View customize 経由で実行させずともウィルス仕込むとか本体システムいじるとかするだろうし
  • 前に Qiita のハックで文字を回すブームがあって QiitaにおいてHTML要素の属性指定ができなくなりました - Qiita Blog となったのを思い出すなど

チケット文化定着までに気をつけたこと

  • yuki476🌧️ 技術書BOOTHに出品中(@yuki476)さん氏
  • Redmine のチケットで作業をまわす文化を定着させるまでの施策について
  • 「この仕組みがないと仕事できない」ところまで定着させた
  • ちゃんとチケットで業務を回せていれば自然とこうなる
  • Git でこまめにコミットする感覚が近い、チケットは進捗管理だけでなく思考や調査のバックアップも兼ねる
  • 何年も前に書いたチケットのコメントに助けられた、などの経験の積み重ねが私にチケットを使わせる
  • Owl Eng. - BOOTH で技術書を公開 & 販売中、びくびくん氏の Redmine 本と共に懇親会で回覧されて大人気

毎月のTodoチケット作成を定期チケットプラグインでもっと簡単に！

  • hin-t 氏
  • Redmine にチケットを定期的に登録するプラグインの話
  • これは Redmine 標準機能としてほしい
  • マイルストーンやチケット期限などを提供しているなら、定期的なものを扱う機能があってもよいはず

管理画面から用語やメッセージを変更するプラグイン作りました

Redmine + GitBucketで実現する Redmineでプルリクエスト

  • kounoikeが取れなかったんです(@ko_noike) 氏
  • 資料
  • 前回のパネル ディスカッションにおける GitHub のようなプルリクエストがない問題を踏まえて開発した kounoike/gitbucket-redmine-plugin の話
  • Redmine は Git 連携可能だが GitHub のようなプルリクエスト機能をもっていない
  • 最近の GitHub を利用したソフトウェア開発はプルリクエストを活用するのが一般化しているので Redmine でも実現したい、というのを叶えるプラグイン
  • GitBucket と連携することで実現している
  • GitBucket 自体にも Issue tracker があるので目的が被る、という意味でこれも Redmine が対応してほしい
  • Git についてはそもそも bare リポジトリーでなく直に参照したいのと、GitHub のように Redmine 上からプロジェクトに紐付いて Hooks も設定した Git リポジトリーを生成してほしいものだ

GitHub連携プラグインを作った話 或いは、作りかけてる話 最悪、作りたかった話

  • アジャイルウェア堂端氏
  • さきほどの GitBucket 連携でプルリクエスト実現するプラグインに近い
  • こちらは GitHub と連携する
  • チケット一覧のタイトルに PR/merge がアイコンとして表示されるのが面白い
  • こちらも Redmine で対応してほしいという話になる
  • そういえば Redmine として Git や PR についてどう考えているのだろう？

TFSのチェックインをトリガーにRedmineのAPIを叩く

  • 手羽先(@miokakusu) 氏
  • 資料
  • Team Foundation Server へのチェックインを起点に Redmine API を実行する話
  • TFS は VSS の後継らしい、昔 VSS を使って開発していたので懐かしい
  • VSS 代替として SVN へ移行、更に Git というのが多かったろうし Visual Studio としても Git 連携が強力なので TFS 使っているというのは珍しいかも、というか初めてみた
  • TFS は OSS ではないので API が叩けない
  • TFS はチェックインの際にメール送信する機能がある
  • これを Redmine サーバーで受信してトリガーにすればいけるのでは？
  • そしてトリガーして Redmine チケットのステータスなどを自動更新する
  • この対応によりチームのチェックイン コメントの質が向上

技術書典 6 に参加してきた話

...というわけで以下に感想を

タイトルから Redmine 導入を検討している人や組織を対象としている印象を受けるかもしれない。しかし本書は既に Redmine 運用して問題に直面した場合の処方箋としても有用である。

成功体験よりも失敗や課題を分析してどのように解決すればよいか？という内容が多い。そして課題の大半は Redmine の機能的な部分ではなく人間的なもの。例えば「Redmine 嫌いおじさん」が最たるもので、保守的な人へ新しい管理手法をどのように浸透させてゆくのか？を取り上げている。

かくいう私も Redmine 管理者として同様の問題へ直面しており悩ましい。イマイチなじまない部署や人がいる。とはいえ Redmine のすべてが忌避されているわけではなく Wiki は受け入れられた。これまで属人的であった業務や顧客分析などの情報も積極的に Wiki へ書かれている。資料作成ツールとして文化は根ざしたといえるだろう。

あと一歩、タスク管理の可視化と進捗管理のためチケットを導入できてばというところまでは来ているのだが、この点に関して本書でも割り切りを提案している。Google Spread Sheet や Excel で運用できているのならば、それでいいじゃないか。Redmine は多機能ゆえに全てを使いたくなるけれど、便利な部分だけつまみ食いしてもいいじゃないか。

まるっきり管理されていないならまだしも、何らかのルールがあるなら必要に応じてチケットなりを採用すればいい。なにしろ私が redmine.tokyo 14 で登壇した時に自身でそう言っていたではないか。

感想を書くために改めて読みなおし、直近の悩みがひとつ解決した。本書は Redmine 運用の本であるだけでなく管理者としての悩みを打ち明ける相談役としてもよい。結局は自己解決するわけだが、やさしい文体と視点により、よき仲間との生産的な議論を経て対処したように感じられる。

グループ ディスカッション

私の参加した卓で出た話をまとめる。

チケット 100 万件ある Redmine でプラグインが激重

  • プラグイン名は失念
  • Redmine 本体としてはチケットが 100 万件あっても UI 上はページングされるし、内部も Cursor で部分取得してゆく方針だろうから問題ない
    • そのプラグインは SQL でチケット全件を走査、インデックス貼られていないカラムを見るから激重
    • プラグインが読み込まれる画面を開くと Redmine が固まるしサーバーの負荷もすごいことに
    • プラグインは長らく更新されていない、こういう場合、どうしたらよいか？
    • OSS で GitHub 公開されているなら Issue 登録する
    • しかしそういう開発停滞してるプロジェクトだと反応してもらえない可能性が高い
    • プラグインの利用目的が Redmine の外観変更っぽいので View customize はどうか？
    • Redmine の REST API として公開されている範疇の操作ならこれでいける
    • これで激重になるなら Redmine 本体 (として公開している REST API 内部) の SQL がよくないので、redmine.org に要望を出せる、これは個人プロジェクトよりも対応の確度は高いだろう
  • View customize で大抵のことは可能、ここで View customize の是非の話に
    • 大抵のことは可能というのが Redmine 運用上の治安を乱すのではないか？
    • 利用者の善意というか自己責任の話ではあるのだけど
    • プラグイン配布と互換保証のエコシステムを標準提供しないなら View customize を Redmine 本体へ取り込むのはどうか？
    • 雑な見立てだが Redmine プラグインの大半 (特に外観変更とか Wiki を拡張するなど) はこれで実現できそう
    • 「View customize の範疇 = REST API か Web ブラウザー機能」となるため Redmine 本体を壊す危険性も避けられるだろう
    • 要するに安全なプラグイン ランタイムとして View customize を据える
    • redmine.tokyo で毎回 View customize ネタがそれなりにあるのと、プラグイン互換で事故る話を聞いてると特にそう思う

大量の放置チケットを解決したい

  • Redmine を導入したもののチケットが終了されず大量に放置されて困っている
    • 今回の登壇だと「やり切る」話に通じる
    • これは 14 回の「なじむ Redmine」で取り上げた内容でもある
    • チケットの粒度が大きすぎるため終了条件も難しくなり、結果として放置される
    • ほぼ完了しているが厳密にはそうと言えない...みたいなのは粒度が大きい
    • 例えば「最高のソフトウェアを作る」というチケットは永遠に終わらないだろう
  • チケットは終了条件から考えて登録する
    • そしてなるべく粒度は小さくする
    • これには作業をどのように分割、階層化するか？というスキルがいる
    • 可視化することに慣れていないだけで生活でも日常的に実行しているはず
    • 例えばコンビニで買い物する場合でも漠然と「購入したいもの」があるはず、ならば「コンビニゆく」ではなく「パンを買う」のように粒度を下げて具体的にする
  • 放置を防ぐ仕組み
    • チケット警察は必要
    • チケット = 作業、が放置されているなら仕事をしていないわけなので上長がチェックすべき
    • チケットの期限は絶対に設定する、期限を過ぎたものはチケット上のコメントとして「放置されているが現状は？」と確認する
    • 口頭や Slack などチケット外で確認すると忘れられる、そうするとしてもその場でチケットを開かせて処遇を決めてコメントに書かせること
    • Redmine 導入しただけで治安よく運用されることはない、結局は治安を維持する存在が必要になる
    • メンバーが自走して分割統治が回るには時間がかかる、これは Redmine に限った話ではない
    • 自走するまでゆけば FAQ なり「隣の人に聞いてください。私ぐらい詳しいですよ」と言えるようになる
    • これを角を立たせず運用するには Redmine というよりファシリテーション系の本や講演が参考になる

懇親会

  • 今回も大いに盛り上がる
  • 今回は二次会にも参加した、三次会はラーメンなので胃腸的に厳しく辞退
  • Redmine の性質もあってだろう、だいたい組織論とか運用の話になる
  • 一次会では紙と電話で作業管理している職場へどうやって Redmine を導入するか？という話をした
  • 最後のほうで akipii(@akipii)氏が来られたので次回は私が Redmine テーマ作成で登壇希望と伝えた、もし決まったなら秋のお楽しみに
  • 前に書いた Redmine テーマのつくりかたをスライドにまとめて「できる Redmine テーマ」という題で発表したい、実際にテーマを書き換えて Redmine 本体に反映されるデモも実施予定
  • 一次会の終盤に JOJO とかクリント・イーストウッド映画の話をした流れもあり、二次会はサブカル話が多め
Copyright © 2009 - 2024 akabeko.me All Rights Reserved.