進捗管理をうまく行うために、いくつかの考え方を身に付けないといけません。今回提唱するマイルストーンを軸にした進捗管理も、誤った見方をしてしまえばガントチャートと同じような結果になりかねません。
予定通りかどうかは気にしない。予定が組めるかが重要
予定通りかどうかは、予想が当たったか外れたかにということです。当たったからといって正しい道を歩んでいることは保証されません。逆もまたしかりです。実績評価で重要なことは無駄なことをしなかったかどうか？です。時間が有効活用されているならば、予定との違いは、順序が変わったとか新たな状況が生まれたという解釈ができます。そして通常うまくいっている時も予定通りということはほぼありません。無駄な時間があったならば改善しなくてはいけませんが、認識すべきことは、時間が進み、予定を組んだ時と状況が変わっているということです。時間が進んでしまった今では、これからの日程を以前より正確に見通すことができます。なので、以前の予定（予想）に縛られた予定を組むことは間違っています。重要なことは今から予定が組めるかどうかです。常にオンスケ。ただしリスケできる時に限る
C/O日を無事迎えられると仮定すれば、常にオンスケジュールであると言えます。進捗状況とは予想とのギャップであってリスクを測る上での物差しと考えます。ただし、スケジュールがそのままであれば、管理上遅延は遅延であってこのままではC/O日をずらす必要が生じます。つまり再スケジュール（リスケジュール、リスケ）が必要であり、プロジェクトがうまくいっているのであれば、無理の無いリスケができるはずです。リスケできるという確信があれば、プロジェクトはいつでもオンスケです。リスケを日常業務に。ただし局所的に
予定は常に変わるのでリスケすることを日常業務化して、細かく実情を把握し、常に未来のことを考えるようにします。ただし、3/nの回でも書いているように過度に未来にわたってリスケするのは駄目です。よく見えるようになった部分を書き換えるだけにしておかないと、労力は無駄に、指示は遅くなります。プロジェクトはスピードが命なので、リスケによるオーバーヘッドはあってはいけません。実践するためのポイントは、管理表は極力シンプルかつ見易く、少なくすることが挙げられます。マイルストーンは単純な中間目標でリスケされない
常にリスケされるプロジェクト運営をすると、メンバーは何を基準に開発を進めてよいのか分かりにくくなります。そこでマイルストーンという中間目標を定めることが重要になります。この、マイルストーンこそが進捗管理の肝です。マイルストーンは、単純かつ検証可能である必要があります。メンバーは現在の作業を予定通り進めてもよいし、もっと良い方法や状況の変化に応じて別の作業をしても構いません。マイルストーンの実現に少しでも早く到達することに役立てばよいのです。ある作業は最後にはきっと必要だが、とりあえずマイルストーンの実現には関係がなければ、そこを省いても構いません。必要と思えるものでも今必要でなければ、それを止めることによって無駄を省く可能性があります。こうした役割からマイルストーンは勘違いや別解釈のできないほど単純かつ検証可能であることが求められます。そしてマイルストーンはリスケされません。なにがなんでもその時に通過しなければならない目標です。これをクリアできるリスケが不可能であれば、人員をつぎ込むなり要件を削減するなりしなくてはなりません。これほどマイルストーンは重要です。それでも中間地点で問題に気がつけるのであれば、これはまだ幸運です。多くのプロジェクトでは、この判断を最後までしないので最後になって火を噴いたりギブアップする目に会います。中間地点で要件削減を提案したり工数を積み増すには強い決断力・交渉力が必要ですが、C/O近くで実行する状況に比べれば選択の幅はずっと広いものです。賢いマイルストーンがプロジェクトの成功確率を高める
適切なマイルストーンが配置されていると、プロジェクトはその１つを乗り超える度に成功できるんだという確信を強くしていくことができます。そして中間時点の頑張りは終盤の追い込みより遥かに高い生産性を発揮します。プロジェクトの初期段階のマイルストーンは、緩みがちで無駄が出がちなスタート時の雰囲気を引き締めます。開発が広い範囲に拡大してくるとメンバー間で状態が分かりにくくなりますが、そのような場面にマイルストーン置くことで、プロジェクトの状態を再認識・共有できます。非常にタイトなプロジェクトであれば、中間の非常に高い目標となるマイルストーンをクリアさせることで、スケジュールが見通せるようになります。繰り返しますが、マイルストーンの重要な点は、「このプロジェクトは終わりそうだ、成功しそうだ」と思わせることにあります。その希望こそ、メンバーがプロジェクトを楽しく有意義に過ごせる何よりの精神的な支えとなります。どんなものがマイルストーンとなるか？
実際のマイルストーンにはどんなものがあるかを挙げてみます。- 4/20に全ての画面サンプルのリンクを完成させ顧客レビューを依頼する
- 5/7に既存画面の移植を終えて紙ベースの資料を破棄する
- 6/10に全テーブルに整合性のあるテストデータを100人分登録する
- 7/31に「会員登録～カートで買い物～振込み決済～出荷通知」までの正常系一連の流れのテストを行う
- 8/20に現在の機能内のバグ123個を10個以下にしてベータ版をユーザーに提供する
- 4/10に画面定義をFixする
- 7/10に外部インターフェースとの疎通確認をする
- 来週中にログイン機能のUTを終える
良いマイルストーンのさらに３つの条件
また、良いマイルストーンの条件は、単純・全員参加・検証可能に加え、①絶対通過点②実現限界点③最短設定の３点があります。- 絶対通過点はプロジェクトが必ず通過するポイントであることです。場合によっては通過する必要がないのであれば、多くの努力を払う力は湧いてきません。
- 実現限界点はギリギリ実現できそうな目標であることです。簡単に実現できそうならば目標にならず、できそうも無い時も最初から諦めムードなりとなり、できない時に言い訳が通じてしまいます。
- 最短設定とは、一番短い時間で実現できるものに設定するべきということです。高い生産性は短い時間しか持たないし、長くするほど状況の変化によって目標としての価値を損ないかねません。
例として挙げられている、4月末から8月末までにβ版を出すようなプロジェクトとなると、結構期間が長いプロジェクトだと思われますが、そうではなく２ヶ月間ぐらいの開発で、DBにテーブルを５０個以上作成し、結合試験を600ケースほど実施しなければならないほど要件が多く、尚且つ複数の開発会社が絡んだ案件の幅が広いプロジェクトで、さらに自分がプレイングマネージャーだと、マイルストーンをまず自分が管理することができないほど忙しくなったりすることがあります。
そして、上記に上げた粒度のマイルストーンを上げようとすると、莫大な量になってしまい、誰も管理しきれないものになってしまいます。ですので、マイルストーンの粒度をここで言われている大上段から見た「普通の目標」にまで粒度を荒くするのは、いた仕方のないことのように思われます。
そうなると、一機能の開発チームが一人体制か２人体制ぐらいのミニプロジェクトとして、仕事を開発・試験から案件削減も含めた交渉任せる以外に、仕事を進める方法がないように思われます。その中で、スキルもばらばらで仕事に対するモチベーションも様様な、開発者達への全体のチームビルディングや進捗管理をどのようにやっていったらよいのか、そして、プレイングマネージャーだけでなく、その元で働くごく普通の開発者一人一人がマイルストーンを正確にあげることができる見積もり力があるのかが問われてくるように思いますが、その辺の力はどのように伸ばせばよいのでしょうか。
個人の見積もり力やリスケを許容できる人員のスキルや日程の余裕、開発者一人一人のリスケや要件のスコープアウトが出来る交渉力があってこそ、ツールが役に立つと思われますがそういう、一人一人の力を伸ばすための方法の解説はなされないのでしょうか？プロジェクトリーダー論ではなく、プロジェクトフォロワー論、というか。
コメント by 戸田 — 2009年03月23日 月曜日 @ 4:18:10
コメントありがとうございます。
なるほど、例としては長すぎて悠長なプロジェクトを想定していると思われてしまったようですね。でも実はそうではなくて戸田さんの言われるようなプロジェクトこそマイルストーンでの管理を必要とします。
マイルストーン指向型のプロジェクト運営の大事な原点は、「無駄な作業、無駄な管理」を排除することで、その方法論は極力現場の判断に任せるということです。ご指摘のような事態（引用：ごく普通の開発者一人一人がマイルストーンを正確にあげることができる見積もり力があるのかが問われてくる）というのは、無理がありますよね。
現場はその与えられた範囲の中で最善の選択（仕事のトレードも含めて）ができる権限が与えられて、有意義な作業に専念できるのが一番です。そのような点において、現場と一体化しているプレイングマネージャーはマイルストーン指向をとることはごく自然な姿です。
ご指摘のような２ヶ月５０テーブルＩＴ６００ケースのプロジェクトであれば、この時２ヶ月は確定事項ですが、UT６００ケースは実際には大きな幅がある予想でしかないでしょう。その状況で複数のチーム（会社別など）に分かれて、その完成度やUT品質はバラバラである状況であると、短い中でスケジュールを細かく引いても現実役には立たないどころか、大きな弊害があります。といってスケジュールがないことも大問題です。
このようなプロジェクトであれば、「すべてのサブシステムを通過する結合テストの１ケース」をマイルストーンとすることがよくあります。
■4/20に以下のＩＴをマイルストーンとしてＩＴテスト環境で行います。
「新規ユーザー登録（4/30）～”クインテッド”のＣＤをカート投入～”ガンコちゃんの”ＤＶＤをカートに投入～クレジットで決済～課金完了メール～出荷通知メール１（”クインテッド”4/30即日配達）～出荷通知メール２（ガンコちゃん5/7配達）」
とこんな感じです。このＩＴ１ケースが成功するように4/20向けてがんばる事は、結構できます。そして、これに向けて、要件の確定やＤＢの過不足などの調整やサムシステム間でのミニマムな接続テストが自ずと進んでいきます。
この時ＷＢＳ上の作業項目は、
・チームＡ：ＩＴ（4/15-4/25）
・チームＢ：ＩＴ（4/10-4/22）
・チームＣ：ＩＴ（4/20-4/25）
・・・
みたいにバラバラでもＯＫです。テストケースの実数は別にあるのでしょうが、それをＷＢＳや進捗で管理する必要はありません。このようにＷＢＳを大雑把でよいのです。これがマイルストーン指向での進捗管理の特徴です。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
長くなってしまいましたが、ご意見あれば是非お聞かせください。現在の文書はプロジェクト管理のうち進捗管理だけなので、最後にご指摘の「一人一人の力を伸ばすための方法」には触れていません。進捗管理ほど確固たる手法はありませんが、うまくやる方法はなくはありません。ただし強いリーダーシップは必要です….いづれ機会があれば。
コメント by エラスモサウルス — 2009年03月24日 火曜日 @ 22:25:54
コメントに記載していただいた「すべてのサブシステムを通過する結合テストの１ケース」(というよりこの例ですと総合テスト)なり、もろもろのタスクの進捗を細かくWBSで管理するようになって、最終的にWBS管理コストでグダグダになり、遅れたWBSをみてリーダーが怒鳴り、現場が疲弊するパターンが多いですね。
私は線表かTracのようなバグ管理ツールでしかプロジェクトを管理したことがないので、コメントに書いていただいたような、ざっくりとしたマイルストーンの設定でプロジェクトを成功させることが本当に出来るよう、次回の、実際のツールを使ってマイルストーンを設定する記事を楽しみにしております。
ご教授、ありがとうございました。
コメント by 戸田 — 2009年04月15日 水曜日 @ 21:03:35
コメントありがとうございます。
この記事からちょっと時間が開いてしまっていますが、ちゃんと書きますので、もう少々お待ちください。
（現在、当社ソフトウェア開発環境展の準備でてんてこ舞いでして…）
コメント by エラスモサウルス — 2009年04月20日 月曜日 @ 11:52:46