プロジェクト管理でBacklogを使っています。
最初は、Backlogを使って
- 課題管理
- 進捗管理
- スケジュール管理
をすべて行おうとしていました。
ただ、しばらく運用していると、だんだん違和感を覚えるようになりました。
- チケットの粒度がバラバラ
- 進捗率が見えない
- 今どれくらい終わっているのか分からない
「Backlogって使いにくい・・・？」と思えてきました。
そこでチケットの粒度や管理方法を見直していたのですが、考えれば考えるほど別の疑問が出てきました。
そもそも何をもって「進捗」と呼ぶのか、ということです。
進捗率は本当に存在するのか
例えば「会員管理機能」を開発するとします。
最初は単純に考えていました。
- 設計
- 実装
- テスト
3工程あるので、
- 設計完了 = 33%
- 実装完了 = 66%
- テスト完了 = 100%
のように管理できそうです。
しかし実際の開発はそうなりません。
設計中に追加要件が見つかることがあります。
実装中に仕様変更が発生することもあります。
テスト中に設計の見直しが必要になることもあります。
つまり、作業の総量そのものが途中で変化します。
総量が変化する以上、「今70%です」という数字は思った以上に主観的です。
正確な進捗率を求めること自体が難しいのではないかと感じました。
ただ、進捗報告やリリース計画を考える上で、現在地を把握することは重要です。
そこで、進捗を見える化するためにチケットの粒度を揃える方法についても考えてみました。
チケットを細かく分割すれば解決するのか
次に考えたのは「チケットの細分化」です。
例えば、
- 会員管理機能
を
- 会員一覧
- 会員詳細
- 会員新規
- 会員編集
に分割します。これなら進捗が見えそうです。しかし、今度は別の問題が出てきます。
一覧画面の開発中に
- CSV出力
- 検索条件保存
といった機能が追加されることもあります。さらに、
- 一覧設計
- 一覧実装
- 一覧テスト
まで課題に細分化すると、管理する課題数が一気に増えます。
進捗を見える化するために、今度は管理コストが増えてしまいました。
チェックリストという案
そこで考えたのが、課題の中にチェックリストを持たせる方法です。
例えば、
- 会員一覧
□ 設計
□ 実装
□ テスト
です。
開発が進めば、
- 会員一覧
✓ 設計
✓ 実装
□ テスト
...
となります。
これなら、「今どこまで進んでいるの？」に答えられそうです。
しかし、ここでも疑問がでてきました。
チェックリストと「状態」は何が違うのか
例えば「状態」を
- 未着手
- 処理中
- 設計中
- 実装中
- テスト中
- 完了
で管理している場合、
- 状態：実装中
✓ 設計
□ 実装
はほぼ同じ情報を表しています。つまり、
- □ 設計
- □ 実装
- □ テスト
というチェックリストは、状態と役割が重複していることに気付きました。
最終的に整理した役割
考えた結果、役割は次のように分けることにしました。
状態
状態は、今何をしているのか を表します。
- 未対応
- 処理中
- 処理済み
- 完了
デフォルトで用意されている程度のシンプルな運用にします。
チェックリスト
チェックリストは、完了条件 を表します。
例えば、
- ■ 完了条件
□ 設計レビュー完了
□ 実装完了
□ テスト完了
です。
状態は「今」。
チェックリストは「完了判定」。
といった役割を分けることで混乱が減りそうです。
親課題・子課題
当初は、
- 会員管理機能
├ 会員一覧
├ 会員詳細
├ 会員新規
└ 会員編集
のような親子構造も考えました。
しかしBacklogは孫課題を持てません。プロジェクト進行中に、
- 会員一覧
└ CSV出力
…
のような構造が必要になった場合に困ります。
また、カテゴリで十分に分類できるケースもあります。
そのため、無理に親課題を増やすより、
- カテゴリ
└ 会員管理
で分類し、必要な単位で課題を作る方が柔軟だと感じました。
最終的にたどり着いた考え
ここまで考えていて気付いたのは、Backlogに求めていたものが多すぎたということです。
チケットの粒度や進捗率について考えていくうちに、Backlogで管理したかったのは進捗率そのものではなく、課題についての情報や判断の履歴だったことに気付きました。
例えば、
- 何を作るのか
- なぜ必要なのか
- 設計書はどこにあるのか
- 完了条件は何か
- 誰が担当するのか
- 今どの状態なのか
といった情報を整理し、作業に着手できる状態を作ることができます。
また、コメントや課題の履歴を通して
- なぜこの仕様になったのか
- どのような問題が発生したのか
- どのように解決したのか
といった経緯を後から追うこともできますし、さらに検索機能を使えば過去の課題や議論を簡単に探すことができます。
つまり、Backlogは単にタスクを並べるための場所ではなく、必要な情報や判断の履歴を蓄積し、活用するためのツール だと考えるようになりました。
もちろん、プロジェクトを進める上では、進捗をある程度見える化したい場面もあります。進捗報告やリリース計画を考える上で、現在地を把握することは欠かせません。
しかし今回感じたのは、Backlogの役割は進捗率を算出することではなく、課題とその履歴を管理することではないかということです。
そのため、進捗を把握する際も主観的な進捗率ではなく、
- 課題がどの状態にあるのか
- 完了条件のうち何が終わっているのか
を確認できる形の方が分かりやすいと感じました。
進捗を見える化するために課題管理を複雑にするのではなく、まずはBacklog本来の強みである課題管理や情報共有を活かしながら、状態やチェックリストを活用して現在地が分かる運用を目指していきたいと思います。
