なぜ課題管理システムを使うのか？
ソフトウェア開発や Web サイト構築などのプロジェクト運用において Redmine や GitHub Issues などの課題管理システムを使う理由について書く。
TODO リストや Excel による課題管理
プロジェクトを達成するための課題を管理するだけなら単純な TODO リストや Excel だけでも十分である。例えば TODO リストなら課題を列挙してそれをチェックしてゆけばよい。
- 商品ページを実装する
- 運営用の管理ページを実装する
- アカウント登録機能を実装する
Excel や Google スプレッドシートのような表計算ソフトならば以下のように進捗や担当などの列を増やすなどして、
| 進捗 | 担当 | 課題 |
|---|---|---|
| 未着手 | アカベコ | 商品ページを実装する |
| 完了 | アオベコ | 運営用の管理ページを実装する |
| 作業中 | クロベコ | アカウント登録機能を実装する |
それらに連動して全体の傾向を集計するなどの運用も可能になる。実際、これまで経験した職場では Excel の作り込みによる課題管理を何度か目にした。
しかし問題がある。TODO リストや Excel では過程の記録が難しいのだ。
過程の記録と諸問題
課題が単純で粒度が十分に細ければ着手と終了だけ管理すればよい。例えば「コンビニで飲み物を購入する」という課題は明確で達成条件も単純だ。水なりジュースでも買えば終了できる。
しかしプロジェクトにおける課題はこんなに単純なものばかりではない。大抵は実作業だけでは済まずに考察、調査、議論などを経てようやく達成するものだろう。ではこうした「過程」はどのように管理すればよいのか。
Excel シートなら「質疑応答」のような列を用意するだろう。ソフトウェア開発のバグ管理表などでもよく見る形式だ。バグ報告者と開発担当がその欄でやりとりする。私も経験したことがあるのだけど、これは非常に管理しにくい。
やりとりが一往復ならまだしも、議論に発展すると手に負えなくなる。議論の進行に比例して質疑応答欄のセルはどんどん高くなる。やがて他の行がスクロールアウトして一覧性・可読性は低下してゆく。この問題の対策としては以下のような方法があるだろう。
- 終了した行を非表示にする
- 議論は別シートで管理して一覧表の当該業からリンクさせる
- 議論は外部システム (Slack、メール、...etc) で管理して一覧表の当該業からリンクさせる
過去の経験では 1 が多かった。質疑応答が伸びても議論が終了するまでは我慢しておく。しかしこれはかなり楽観的な方法である。現実には複数同時、しかも表上で微妙に隣接してるものが伸びてゆきがち。そうなるとストレスがたまって厳しい。
2 は RDB でいう正規化のようなものだから素性はよさそうに見える。しかし議論を単一シートで管理すれば 1 と同様の問題が起きるし、議論単位でシート分割すると増殖に耐えられず管理は破綻するだろう。
そもそも表計算とかスプレッドシートは可変長の文章管理に向いていない。というわけで 3 はどうか。Excel で課題管理しているプロジェクトでは、ここまで書いた過程を経ていなくても 3 で運用しているところは結構あるのではなかろうか。
とりあえず Slack としておこう。例えばこんな感じで議論したとする。
- A: 「〜表 N 番の件について相談したいです」
- B: 「なにか問題がありますか？」
- A: 「このままの仕様だと複雑すぎて期限までに終わらなそうです」
- B: 「それほど重要度の高い機能ではないから今回は見送りましょう」
- B: 「進捗は "将来対応" にしておいてください」
- A: 「承知しました」
実装予定だった機能を将来バージョンへ見送るという非常に重要な合意形成だ。こういう「明確な意思をもって却下したこと」は忘れられがちで、しかも後で揉めがちである。なのでぜひ記録したい。
ではこの議論を Excel シートへリンクするにはどうすればよいか。Slack のメッセージやスレッドは一意の URL を持つ。そのためこれをセルに貼れば議論へのリンクになる。ならば議論は Slack にして全体管理は Excel という補完はなかなかよい運用ではなかろうか。
しかし Slack のスレッドは課題と結びついておらず、議論の場として強制することもできない。そのため独自のルール構築と各人の善意に頼るしかなく、これらを徹底させるためのコストが高すぎる。
課題単位でチャンネルを作る手もあるだろう。しかしこの方法は前述の Excel に議論シートを追加してゆくのと同じ理由で破綻が見えている。Slack は大きく粒度の粗い課題をチャンネルにして運用するのに向く。この用途なら非常によくできたツールだ。一方で細かな課題管理には不向きである。
という長い枕からようやく本題。こうした問題を課題管理システムはどのように解決してくれるのか。
課題管理システム
本記事では Redmine や GitHub Issues のようなものを課題管理システムと定義しておく。英語圏だと ITS (Issue Tracking System) や BTS (Bug Tracking System) と呼ばれたりする。この分野は競合も多い。他に有名なものだと Jira、Bugzilla、Backlog など延々と列挙してゆける。
これらはその名のとおり課題の管理に特化している。「Excel = 表計算」、「Slack = 対話」だとしたら「課題管理システム = 課題」となるだろう。
では課題をどのように管理してゆくのか。どのシステムでも共通するだろう最小項目だと以下を入力して課題登録する。
| 項目 | 内容 |
|---|---|
| タイトル | 課題の簡潔な説明。達成したい目標やそのために必要な作業などを書く。なるべく単一の目的や作業となるようにするとよい。 |
| 説明 | 課題の達成条件や背景などを書く。なにを達成すれば課題は終了するのか？は必須。背景説明があると更によい。 |
ここまでなら TODO リストや Excel シートと変わらない。重要なのはここからである。
課題を登録することで、それらに対して過程を記録できるようになる。代表的なものは以下。
| 記録対象 | 内容 |
|---|---|
| コメント | 課題に対するコメントを記述可能。これを利用して調査、考察、議論 (対話) などを記録してゆく。Redmine や GitHub Issues はコメント記述に Markdown を使用できて表現力も高い。 |
| ファイル | 課題の説明をわかりやすくするために画像や資料のファイルを添付可能。添付した画像をコメントの文中に表示する機能もよく使われる。 |
| 状態変更 | 課題のタイトルや説明、進捗などの変更がが自動的に記録される。課題に対する操作そのものも過程なのだ。 |
いくつか実例を見てみよう。まずは私が開発している Redmine テーマへのバグ報告。
表示系バグということもあって現象が起きている状態のスクリーンショット付き。画像のおかげで簡単に原因となる箇所を特定できた。
GitHub Issues は Issue (課題) と Git リポジトリーの変更履歴を関連付けられる。そのため Issue に私の修正した内容が過程として表示されおり分かりやすい。
修正を受けて報告者にそれが反映されるバージョンと、リリース後の確認を依頼して終了。実際に確認していただいたようで報告者から感謝コメントもある。嬉しい。
次は OSS プロジェクト Vivliostyle 関連の GitHub Issues から引用。
これは VFM という Markdown 方言に対する画像サイズ指定構文を提案したもの。開発メンバーとの議論を経て却下されるまでの過程が記録されている。前述の「明確な意思をもって却下したこと」にあたるものだ。
この Issue を登録する際、私は属性構文で代替可能なことを思い出す。しかし Markdown における画像サイズ指定の話題を何度か見たことがあって、識者 = 開発メンバーと是非を議論して記録することは有益ではないか？と考えて Issue 化することにした。
結果として既にある属性構文で対応可能なため却下となったが、今後もし類似する提案があったなら本 Issue を引用できるだろう。また提案者が事前に検索するかもしれない。そうなれば議論の繰り返しを避けられる。
課題の着手から終了までの過程が記録されると、このように第三者へ公開もできる。資料性も高い。私は業務で長年 Redmine により課題管理をしているのだが、その蓄積によって何度も助けられた。これ前にやったことあるかも？と調べたら大抵は過程が記録されていて、そこに書かれた内容をトレースするだけで作業が済むことも多い。
Excel や Slack との連携
Excel や Slack による課題管理の問題を挙げ、それが課題管理システムにより解決されると書いた。しかし課題管理システムにも苦手な部分はある。そのためこれらとの連携 (棲み分け) についても書いておきたい。
Excel は表計算に徹する。課題管理システム上は添付ファイルとして扱うのがよいだろう。職場の Redmine ではチケット (課題) だけでなく Wiki に資料集ページを用意して Excel や Word などをまとめることもある。
Slack は課題管理システムと一般的な対話をつなぐ境界として利用する。連絡や通知は Slack のほうが圧倒的に向いているので、そこだけいただく感じ。Redmine や GitHub から Slack 通知する仕組みもあるが、それだけでなく対話の一部として課題の URL を貼り付けるのはよくやる。
例えば
- 即時に反応してほしい時
- Redmine や GitHub のメール通知が見落とされている可能性を考慮する
- メール通知より Slack メンション通知のほうが強い
- Slack メッセージには課題 URL を貼ったうえで「〜を検討したのでここ (URL) へ意見ください」という感じで一言そえる
- 対話の資料として
- 課題コメントに調査内容を記録、課題を資料として引用
- ある Slack 上の話題に沿った (もしくはより深い) 既存の議論として引用
- ↑これは著名 OSS プロジェクトの Issue をもって「優秀な開発者もこういう見解になる」という論拠にもよく使う
という感じ。
まとめ
最初に本記事を書きはじめた際は課題管理システムの多彩な機能を紹介する内容だった。もちろんそれらも大切だし、世界中の識者が選りすぐる機能に乗れるメリットもある。
しかし私が最も価値を感じているのは「過程の記録」だった。他の機能は別のツールでも工夫によって、そこそこに代替可能である。なのではじめに書いた内容を自分で否定してゆき、否定しきれないものとして残った「過程の記録」について書くように方針変更した。
読み返すとまだ書きたりず、表現もイマイチな箇所は目立つ。しかし推敲し過ぎるといつまで経っても終わらない。むしろ拙いところも残して公開するのも「過程の記録」として有益なのでは？ということでそうした。