【システム開発プロジェクト炎上診断】　～　①見積り編

800mを全力疾走した直後にマラソンがスタートし、途中棄権したくてもさせてくれない状況は、想像するだけでも地獄です。
炎上するプロジェクトは、スタート時点から危うさがあり、その最大の要因が見積りの甘さです。
スタート直後の混乱を収めること、遅れを取り戻すことに注力するあまり、クライアントはもちろん開発マネジメントもプロジェクトマネージャー自身も、見積りの甘さに気が付かないままプロジェクトを前に進めることに躍起になってしまいます。その状況で突き進み、気が付いた時には挽回の余地はなく、離脱すらも認められない状況になってしまうのが恐ろしいところです。
まさに見積りの甘さは地獄への入り口なのです。
「システム開発プロジェクト炎上診断」シリーズの第1章は、この見積の甘さについて解説します。

１．反省会で必ずあがる「見積りが甘い」

反省会、振り返り、レッスン&ラーンドなど言い方は会社によって違うもののプロジェクトが終わった後には、今回学んだことを次に生かすための会が必ず催されます。
それなりに辛く過ごしたプロジェクトでは、必ずと言ってよいほど「見積りが甘かった」という反省の弁が登場します。
多くの反省会で挙がる「見積りが甘い」を単に過少見積りと考えている場合、その考えこそに甘さを感じます。
過少見積りであることは、その通りなのかもしれませんが、なぜ過少になったのかが重要です。
想定と違った、レビューが足りなかったなどの理由が上がるものの本質を突いていません。
「見積りが甘い」の根本理由は、想像が足りないことに尽きます。
想像というと漠然としていますが、実際にプロジェクトが始まった時に発生する作業や進め方の想像が足りなかった、つまりは考え尽くせなかったということです。
その原因は、時間がなかったのか、能力がなかったのか、経験が足りなかったのか、のいずれかです。
反省すべきは、見積り時点で、時間、能力、経験の何が不足しているか気が付けているかです。工数の過少見積りは、必ずと言ってよいほど起こりますが、見積り時に何が不足しているか気が付けていれば、それを補う手立てを施すことが出来ますし、プロジェクト開始後に問題が起きてもすぐに見積りの甘さに気が付くことができます。

２．見積りが甘いと、どう危険か

そもそも見積りが甘くなるようなプロジェクトは管理も甘くなるので、見積りの甘さに気が付くのは、開始後しばらく経ってからです。
見積りが甘くスタートしたプロジェクトの開始直後の流れは下記のようになり、甘さに気が付いた時にはもはや取返しの付かない状況に陥っています。

①出遅れ
　見積時に具体的な進め方が整理できていないため開始時点から出遅れる
②場当たり的に作業指示
 　WBS作成を急ぐもエンジニアを遊ばせるわけにはいかないので、場当たり的に作業を振る
③検討事項頻発
　こういう場合どうする？など検討事項が頻発しWBSがなかなか完成しない
④実績がでない
　進捗報告でWBS作成と検討事項の整理をしている状況と報告するも、実態としては、まったく実績が出ていない状況
⑤レビューで指摘続出
　実績が上がってくるもクライアントレビューで多くの指摘をもらい、指摘への検討タスクがWBSに考慮されていないことに気が付く
⑥残業で対応
　残業対応で挽回を試みるも、もはや計画は破綻気味
⑦リカバリ策を考える
 　なかなか実績が上がってこないことにクライアントから追求が入り、リカバリ策を真剣に考える
⑧WBS見直し
　リカバリ策を踏まえてWBSの見直しを検討する（③に戻る）
⇒この繰り返しを2～3週したところで、「この工数と期間では厳しいなぁ」と、やっと見積りの甘さに気が付く。

最初が肝心とは、まさにその通りで、計画的に進めることが求められるシステム開発プロジェクトにおいて、見積りの甘さは、スタートの出遅れを招きます。遅れを取り戻そうと一生懸命になることで見積りのことは忘れ去られ、気が付いた時には、もはやリカバリの余地はなく、その後の工程はよりごちゃごちゃした計画で進めざるを得ないのです。
マラソンのスタート直後にダメージを負ったものの、湿布を貼って傷みをごまかしながら42km先のゴールを目指すという過酷ロードの始まりです。

３．見積りで大事な４つのステップ

見積りは、プロジェクトのスタート地点であり、ベースラインです。プロジェクト開始後は、見積りを鏡として実績との乖離を把握していくことでコストを管理します。
コスト管理を行う責任者であるプロジェクトマネージャーは、見積根拠や算出方法、何が含まれて何が含まれていないかなど隅から隅まで把握して、見積りの全責任を持っていないといけません。
見積りには、次の4つのステップが必要です。
ひとつでも行っていないステップがあれば、そのプロジェクトは危険だと判断できます。

①根拠の整理
システム開発はモノ作りなので、簡単に言ってしまえば、何を幾つ作るかです。何をというのが機能であり、つまり機能数を洗い出せているかが最も重要です。
機能以外にも業務フロー数、関連システム数、ユーザー数、データエンティティ数など見積りに必要な要素とその数が根拠となります。数で根拠が定義されていれば1本当たりの工数が割り出せるので、経験に基づく勘が働きレビューの効果が出やすく、精度も上がります。

②工数の算出
開発工数に加えて、環境構築や移行などの作業に必要な工数の算出です。
ファンクションポイント法など昔から工数見積手法は世の中にいくつもあるものの、システムの仕組みや開発言語などによって変動するため、経験値に頼る部分が多いのが実情です。この経験値によるばらつきをなくすために、大手SIerでは独自の工数見積ツールを使って算出していますが、それよりも工数を算出した人の見積り実績と結果の評価が重要です。見積りした人のこれまでの見積り回数から結果が正しかった割合を導き出せたら、その割合が、今回の見積りの妥当性と言っても良いほどです。
技術力があるから見積りが正しいということではありません。重要なのはホームラン数ではなく、打率です。

③期間の算定
見積書に期間を明記することは当然ですが、各工程の期間をどのように算定したかは、とても重要です。
期間は、②で算出した工数をエンジニアの数で割って出せるものではありません。例えば、品質管理プロセスでレビューが3段階定義されている場合、3つのレビューを同日に行うことは不可能ですし、レビューで出た指摘を反映する期間も必要となります。
このような開発プロセスを考慮して期間を緻密に算出しなければ、納期に収まらない可能性が高く、ひいては過少見積りとなる可能性が高くなってしまいます。

④費用見積り
費用は、②の工数にエンジニアの単価をかけて算出してはいけません。正確には体制を考えますが、最低でも③で算定した期間に在籍するエンジニアの人数に単価をかけて算出する必要はあります。
プロジェクトの途中で参画するエンジニアがいる場合は、参画受け入れや戦力になるまでの習熟期間も必要なため、その期間の費用も考慮にいれるべきです。
さらにバッファとしてリスク費を乗せますが、その際、プロジェクトマネージャーの裁量で使えるリスク費用を積んでおくことも大切です。リスク費を使う時に、いちいちマネジメントの了解を取っていたらスピード感も落ちますし、手間もかかってしまいます。些細な問題の対応であれば、プロジェクトマネージャーの判断で対処できる方が早いし楽です。

４．なぜ、見積りが甘くなってしまうのか？

これまでに経験したプロジェクトで見積りが甘かったケースを4つ紹介します。見積りをした人の時間、能力、経験のどれかが不足しています。

①機能が洗い出せていない
見積根拠となる機能数が正確にあげられていないケースです。正しく言うと機能一覧はあるものの機能の粒度に統一性がなく網羅性の担保が出来ないものでした。
何を幾つ作るのかが不明確であれば、当然、タスクを漏らします。
見積りの経験も能力も乏しい人が根拠を整理してしまったことが、根本的な原因です。

②希望納期に合わせにいった
クライアントの希望納期に合わせてしまったケースです。
期間の算定を行わずに、算出した工数をクライアントの希望納期までの期間で按分してエンジニアの数を割り出して、見積りを作ってしまったのが原因です。プロジェクト開始後に、レビュープロセスやユーザーの検討リードタイムなどを考慮してタスクを洗い出しWBSを作ってみたら、期間的に無理が出てしまいました。工数見積りの後の期間算定が重要なことは、打率の高い見積り経験者なら当たり前に知っています。

③軽い気持ちの見積り
いわゆる概算見積りです。概算なので意図的に甘く、あるいは軽く見積ったものの、その金額のまま契約され実施することになってしまったケースです。
概算だとしても金額を提示するには、マネジメント承認が必要となる会社は多いと思いますが、概算見積では承認も甘くなりがちです。
「概算で良いからすぐに出してくれ」というクライアントの言葉を信じてはいけません。このリクエストには、出せない、出すには時間が必要、それでも出したいならクライアント側で出してくれ、という多少面倒や返しをしてしまった方が、後から痛い目に合わなくてすみます。
あるいは、概算見積りの後に必ず正式見積りを行い上振れの可能性があることをクライアントと握ることが大切になります。

④システム特性を考慮していない
システムの特性を考慮せずに、一般的な工程だけを考えてしまったケースです。
構築するシステムによって必要なタスクは変わってきます。例えば、会計システムでは値の重要性が高いため、現行システムと新システムで結果を比較をする現新一致テストを行うことが常識です。またクラウドサービスと連携する場合は、ネットワークボトルネックによってデータ移行の物理的な時間が必要です。オンラインショッピングサイトでは、性能が重要な要件になるため、一般的な性能検証だけでなく性能観点の設計レビューや単体機能の性能テストも盛り込むことが必要となります。
このようなシステムの特性を考慮しなければ、必要なタスクを漏らして過少見積りとなってしまいます。これには経験も必要となるため、見積り経験が豊富で、かつ打率の高い人によるレビューをして見積り精度を高める必要があります。

■炎上診断チェックリスト（①見積り）

①－1．見積根拠
・対象を本数で洗い出せているか
（機能分類毎の機能数、関連システム数、移行エンティティ数、業務フロー数）
①－2．工数妥当性
・誰が工数見積りをしたか（黒字実績のある人か）
・どのような手法を用いたか（黒字実績のある手法か）
①－3．期間算定
・工数・費用の見積りとは別に期間の算定をしたか
①－4．費用見積り
・期間×要員数の費用が確保されているか
・新規メンバーの立ち上がり期間の費用は含まれているか
・PM裁量で使えるバッファ費用を確保しているか
①－5．システム特性の考慮
・システム特性を考慮した工程や作業が盛り込まれているか
・仕様変更が頻発するプロジェクトの場合、各工程の終盤に変更に対応する期間を設定しているか

イラスト：見積りが甘いと、どう危険か