プロジェクトの計画で決めなかったことは、消えてなくなるわけではありません。実行段階で、毎日の判断として発生します。
これが私が失敗から学んだ一番大きなことです。計画を作るときは、決めるべき項目が多すぎて、どうしても「走りながら決めればいい」というものが出てきます。ところが実際に走り始めると、その一つひとつが誰かの手を止めます。しかも止まるのは私ではなく、実装しているメンバーの方です。
この記事では、計画段階で決め損ねやすい三つのことと、それが実行段階でどう跳ね返ってきたのかを書きます。実行が始まった後の進捗管理についてはITプロジェクトマネジメントの基本知識と実践方法に分けました。
目次
1. 「走りながら決める」の実際のコスト
まず、プロジェクトとは何かという定義から確認しておきます。特定の目的のために計画され、決まった期間で終わる一連の作業のことです。開始と終了があり、作り出すものが毎回違う。この「毎回違う」が計画を必要にします。定常業務のように決まった手順を繰り返すのであれば、そもそも計画は要りません。
そして計画の役割は、進んでいるかどうかを判断できるようにすることです。計画がなければ、遅れているかどうかすら分かりません。
ここまでは教科書通りの話ですが、実務で効いてくるのはもう一つの側面だと思っています。計画とは、判断を前倒しで済ませておく作業だということです。
計画段階で決めておけば、その判断は一度で済みます。決めずに走り出すと、同じ判断が実行中に何度も発生します。しかも実行中は全員が忙しいので、その場しのぎの答えになります。人によって答えが違うことも起きます。
私が具体的に痛い目を見たのは、次の三つでした。
2. 決め損ねその1：完了の定義
「実装は終わりました」という報告が上がってきたとき、それが何を意味するのかが人によって違いました。
ある人にとっては、コードを書き終えて手元で動いた状態でした。別の人にとっては、テストを書いてレビューも通った状態でした。同じ「終わりました」なのに、残っている作業量が数日単位で違います。
これが問題になったのは、進捗を集計したときです。全体の進捗が7割と出ていたのに、実際に納品できる状態のものは半分もありませんでした。集計自体は正しくて、入力されている「完了」の意味が揃っていなかっただけです。
以来、キックオフの時点で完了の条件を明文化するようにしました。私が使っているのは次のような形です。
- コードが書けている
- テストが書けていて、通っている
- 別の人のレビューを通っている
- 動作確認の手順が残っている
この四つを満たして初めて完了、と決めておきます。項目そのものは何でもよくて、全員が同じものを指している状態を作ることが目的です。
決めるのに要した時間は、キックオフの30分程度でした。決めなかったときに失った時間は、たぶんその何十倍かになります。
3. 決め損ねその2：レビューの担当者
次によくやったのが、レビューを誰がやるかを決めないまま始めることです。
計画段階では「レビューを実施する」という工程だけ書いてあって、担当は書いていない。実行段階になると、レビューを依頼したい人が、その都度手の空いていそうな人を探すことになります。
そして、探すのが面倒になった時点でレビューは省かれます。忙しい時期ほど省かれるので、一番レビューが必要なタイミングで一番機能しません。
もう一つ厄介なのは、詳しい人に依頼が集中することです。誰も決めていないと、結局は一番分かっている人のところに全部行きます。その人の作業が止まり、しかも本人からは断りにくい。私が気づいたときには、特定のメンバーがほぼレビューだけで一日を使っている状態になっていました。
対策としては、計画段階で担当を割り当てておくだけです。「この領域はこの人が見る」を先に決めておけば、探す手間も、断る気まずさもなくなります。負荷が偏っていることも、割り当ての時点で見えます。
4. 決め損ねその3：顧客に確認するタイミング
三つ目が、一番損失が大きいものです。
顧客への確認を「区切りのいいところで」と曖昧にしたまま進めると、区切りのいいところは実際にはかなり後になります。作っている側からすると、中途半端な状態で見せたくないという気持ちが働くからです。
その結果、まとまった量ができてから見せることになり、そこで認識のズレが判明します。ズレが小さければ修正で済みますが、前提が違っていた場合は作り直しになります。しかも、その時点では予算も日程もかなり消費しています。
私が経験した中で最悪だったのは、画面の項目構成が想定と違っていて、それが分かったのが結合テストの直前だったケースです。個々の機能は要件通りに動いていました。並べ方と操作の流れだけが違っていて、そこは仕様書に書かれていない部分でした。
以来、確認の場を日付で先に置くようにしています。「何ができたら見せる」ではなく「この日に、その時点のものを見せる」という決め方です。中途半端でも見せる、というのを事前に合意しておくと、出す側の心理的な抵抗も下がります。
このあたりの認識のズレがなぜ終盤に一気に出てくるのかは認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に、そもそも最初に納品物の形を確認しておく話は最後にやり直しになる人は、最初に納品物の形を見ていないに書きました。
5. 計画に時間をかけすぎない方法
ここまで書くと「では計画に時間をかけろ」という話に聞こえますが、そうではありません。計画を作り込みすぎると、今度は前提が変わったときに丸ごと無駄になります。ITの案件では前提はよく変わるので、精緻な計画ほど寿命が短いです。
私が使い分けの基準にしているのは、後から変えるコストが高いものを先に決めるということです。
完了の定義、レビューの担当、確認のタイミング。この三つは、決めるコストが低く、決めなかったときのコストが高い。だから先に決めます。
逆に、詳細なタスク分解や工数の見積もりは、後半になるほど精度が上がります。着手前に全工程を細かく積んでも、その通りにはなりません。ここは粗く置いて、フェーズが進んだ時点で作り直す方が現実的です。
つまり計画で先に決めるべきは、作業の中身より進め方のルールの方だと思っています。中身は変わりますが、ルールは変わりにくいからです。
6. まとめ
計画段階で決めなかったことは、実行段階で毎日の判断として発生します。しかも判断するのは、その場で一番忙しい人になります。
私が繰り返し失敗したのは、次の三つを曖昧にしたまま始めたときでした。
- 完了の定義：揃っていないと、進捗の集計そのものが意味を失う。
- レビューの担当者：決めないと省かれるか、詳しい人に集中する。
- 顧客に確認するタイミング：日付で置かないと、必ず後ろにずれて手戻りが大きくなる。
どれも決めるのに30分もかかりません。逆に、決めずに走ったときの損失は日数単位で返ってきます。計画に時間をかけるかどうかより、どの項目を先に決めるかの方が効くというのが、今のところの実感です。
実行が始まった後に進捗をどう把握するかはITプロジェクトマネジメントの基本知識と実践方法に、プロジェクトマネジメント全体の枠組みはITプロジェクトマネジメントの基礎とその重要性に書いています。計画に織り込むリスクの扱い方はプロジェクトのリスク管理：失敗を防ぐための戦略を、予算の配分はプロジェクトの予算管理の重要性を参照してください。