進捗管理のためタスクのライフサイクルについて考えてみた
スケジュールをタスクにブレイクダウンしてWBSに。目標をセンターに入れてスイッチみたいに言われるんだけど、タスクの粒度を考えないとWBSって作成できない。かつ、タスクのステータスは管理する事でプロジェクトのボトルネックを把握する指標になる。では、「タスク」ってなんだろか、と思って自分の中のあるべき「タスク」のライフサイクルをダンプしてみました。
タスクの定義
何か次のタスクにつなげるアウトプットを作る行為の事。スケジュールには複数のゴールがあって、ゴール毎にワークフローがあります。ワークフローに沿ったタスクがあり、タスクが連なる事でゴールにたどり着きます。
背景
スケジュールは「システム開発」を想定。ゴールは「１機能の完成」。ワークフローとして「設計→実装→テスト」とします。（タスクについての考えをまとめるエントリなのでこのワークフローがゴールに対し妥当かは無視します）
- 管理者
- スケジュール全体を管理する人です。
- 作業者
- 作業をする人です。
- 評価者
- 作業者の成果物が完了基準を満たしているか、インプットと相違ないか評価（レビュー）する人です。
タスクのライフサイクル
赤字はステータスです。黒字はタスクの中の「やるべきこと」（なんて名前つければいいんだ..）です。以下で利用している「滞留」とはタスクが止まっている（誰もやってない）状態を指します。
Todo
管理者がボールを持っている状態からスタート。タスク発生時の最初のステータスです。
担当者決め(Assign)
誰が作業を行い、誰が評価するか確定します。
Assigned
誰がやるか決まっている状態です。滞留中。
Planning
作業者がボールを持ちます。
計画（Planning)
完了基準を満たす成果物を作成するためにインプットが揃っているか確認する。揃っていなければ要求し、不明点があればインプット作成者に問い合わせする。評価基準を満たす成果物の作成にどれぐらい時間がかかるか計画を立てる。作成のボリュームがどれぐらいか、どこでチェックポイントを設けるか。ここを終えてはじめて確度の高い見積もりが出る。予定されている規模との誤差を把握の上、管理者に報告。
Planed
計画が完了している状態。滞留中。
Doing
作業者がボールを持ちます。ここからは作業者に成果物の作成に責任が発生します。
作成(Making)
設計書書くなり、コーディングなりをする。
自己評価(SelfReview)
作業者自身が完了基準を確認する。
SelfDone
作業担当者での完了。滞留中。
Reviewing
評価者がボールを持ちます。
成果物の評価(Review)
成果物が完了基準とインプットを満たしているか評価する。
Reviewed
レビューでNGならこのステータス。滞留中。
Fixing
作業者がボールを持ちます。
成果物の修正（Fix）
Fixed
成果物を直した状態。滞留中。
ReReviewing
成果物の再評価(ReReview)
ReReviewed
再評価でNGならこのステータス。滞留中。Fixする必要あり。
Done
次タスクに入れる。
アウトプットして思った事
インプットの理解は前作業者と同一なら省ける
ただし、前提として評価者も同一であるという制約があります。評価者が異なった場合、作業の結果が妥当か判断できる人がいないはず。
こんなにステータス作ったらきつい
タスク内の「こと」をそれぞれのが完了した時点でステータスを変える必要がある。負荷が高そうなので仕組み、ツールを使う必要がありそう。
おわりに
もっと良い考え、シンプルな考えあるよ！とか誰かプロジェクトマネジメントな人からのマサカリが飛んでくるのを待ってます。
