【システム開発】工数見積のポイント プロジェクトを成功に導く７つの観点

プロジェクトをマネジメントしている中で、「想定よりも工数がかかってしまって遅延してしまった」「適正な金額で受託したにもかかわらず計画した利益を下回ってしまった」ということはありませんでしょうか？

工数見積が不十分だったり抜け漏れがあったりすると、どんなにスケジュールを頑張って作成しても納期遅延が発生したり、赤字になったりする可能性があります。そのため、工数見積のポイントをおさえ、考慮漏れがない精度の高い見積をすることが重要です。

今回は工数見積の際に必ず抑えておきたいポイントを７つ紹介します。

ぜひ工数見積をする際の参考にしてみてください。

工数見積が失敗する理由

工数見積を間違えると、スケジュール遅延やコスト超過を招くだけではなく、それに伴ってプロジェクトメンバーの指揮も下がり、更なる悪循環となります。

誰も工数見積を失敗したいとは思っていません。

では、なぜ工数見積を失敗してしまうのでしょうか。

その最大の理由は「考慮できていない隠れた工数があるから」です。

プロジェクトがいざ始まって見たらあれもこれもやらないといけなかったと後から気づいて、なんとかその分リカバリーする羽目となります。

スポンサーリンク

工数見積を失敗しないための７つのポイント

工数見積もりの際に必ず抑えておきたいポイントであり、考慮漏れ、検討漏れになりがちなポイントは次の７つです。これらを工数見積もりの段階でしっかりと考慮、検討することでより正確な工数を見積もることができるようになります。

レビュー工数

1つ目はレビュー工数の考慮漏れです。

レビューというと顧客レビューを想像しやすいですが、通常は作業者の成果物を顧客に見せる前に社内レビューを通します。下手な成果物を見せたり、担当者によってバラつきが出たりすることを防ぐためには必須となるプロセスです。

さらに、レビューを受けるということはレビューに対する指摘対応があります。さらに言えば、指摘対応が正しく取り込まれたかどうか、レビューアの再チェックもあります。

このように細分化すると、”レビュー工数”といっても様々な側面があります。

レビュー工数は勿論、レビューの回数、レビュー指摘に対する対応、レビューに参加する人数、またそれに付随してかかる工数（事前の資料の準備、スケジュール調整、会議室の移動、アジェンダの作成など）についても見落としてはいけません。

スポンサーリンク

テストデータの作成工数

２つ目は、テストデータの作成工数です。

製造工程、テスト工程に特化した内容にはなりますが、この考慮が漏れていることで工数見積もりを誤っているプロジェクトをたくさんみてきました。

「テスト」というと製造したプログラムを動かしてテストすることを想像しますが、実際にはテストするためのデータを準備して初めてテストすることができます。

そして、炎上するプロジェクトに大半がテストデータの作成がうまくできていません。正しいテストデータを準備できていなかったり、準備するのに時間がかかったりしています。

これではスケジュール遅延を招くだけでなく、品質も確保することができません。

テスト工数を導く際は、テストデータを準備するための工数も確保しておくことが重要です。

スポンサーリンク

新規参画者の立ち上げ工数、教育期間

３つ目は、新規参画者の立ち上げ工数、教育期間の考慮漏れです。

どんなに優秀なエンジニアであっても参画したその日から活躍できる訳ではありません。そのプロジェクトの目的や背景、現在何をやっているのかを把握することから始まります。そもそも仕事ができるようにPCの設定や開発環境の構築、資料の把握などがあります。

特に炎上しているプロジェクトでは、新規参画者の立ち上げ工数を十分に持てないまますぐに作業を振るようなことになりがちですが、「急がば回れ」です。最初の立ち上げがうまくいけば、しっかりと戦力になってくれることを信じて、勇気をもって立ち上げ工数を持つようにすることが重要です。

スポンサーリンク

後続担当者への説明工数

続いて、後続担当者への説明工数です。

分かりやすいのが、設計工程と製造工程がラップしている場合に、１つの機能に対して設計者と実装者が異なる場合です。この時、設計書がどれほど優れていたとしても、設計者の意図まではなかなか実装者に伝えきれないことがほとんどですし、実装者が誤った解釈をしてしまうことも多いです。

そのため、設計者と実装者が分かれるような場合には、設計内容を説明するような時間を設けてタスクの引継ぎをした方が品質向上を見込むことができます。しかし、その分当然工数もかかります。説明を１時間するだけで、設計者と実装者の２名分、すなわち２人時間分の工数がかかります。

そもそも、設計者と実装者を分けなくて済む場合はそれに越したことはありませんが、担当者が分かれる場合には品質面も考え、引継ぎの工数も用意しておくことを強く推奨します。

スポンサーリンク

朝会、定例会などの打合せ工数

続いて、打合せ工数です。しかも、ここでいう打合せとは、顧客と要件打合せや設計打合せではなく、社内での朝会、社内外の定例会などのことです。要件打合せや設計打合せのようにシステム開発に直結する打合せについては打合せ回数を考えて、事前に工数に含めることがしやすいです。

しかし、たった30分の社内のプロジェクトメンバーの朝会や社内外の週次定例会などの工数は、システム開発に直結しない間接作業であることから軽視され、事前に工数試算から漏れることが多いです。さらに、打合せがあるということは当然、それに向けた資料作成など準備も必要となります。

小さな工数の積み重ねとはいえ、決して軽視してはいけません。

スポンサーリンク

有識者（レビューア）のタスクを整理しておく

６つ目は、レビューアのタスクを整理しておくことです。検討すべき工数の漏れという訳ではありませんが、スケジュール遅延が発生する理由の大きな１つに、有識者（レビューア）がボトルネックになることがよくあります。

多くのプロジェクトメンバーは定時で帰宅しているにもかかわらず、プロジェクトの中心になるような有識者（レビューア）だけがいつも残業しているような状態をよく見かけます。

ある程度は仕方ないとしても、その傾向があまりに強くなると、プロジェクトは遅延に向かっていきます。

事前に、プロジェクトの中心になるであろう有識者やレビューアとなるメンバのタスクを整理しておくことで、タスクが過剰にならないようにすることもプロジェクトマネージャーの仕事になります。

スポンサーリンク

類似作業を見つけても本当に工数削減になるか確認

最後は、工数見積もりをする際に陥りがちなミスになりますが、類似作業を見つけても簡単に工数削減ができると判断してはいけません。

例えば、よくある作業計画の失敗として、画面Ａと画面Ｂは類似機能であるため、画面Ａが作成できれば画面Ｂの実装工数は画面Ａの７割で済むと考えることがあります。確かに、画面Ａのプログラムを基にに画面Ｂを作成することで実装工数は削減できますが、テストは画面Ａと同様に実施しなければいけません。したがって、実装工数は削減できても、テスト工数は削減できないということになります。

類似作業を見つけて工数を削減すること、効率化を図ることは重要ですが、短絡的に実施してしまうと後から痛い目にあうことがあるので要注意です。

スポンサーリンク

まとめ

プロジェクトの成功の鍵は工数見積にあるといっても過言ではありません。正しい見積がされていれば、プロジェクトは余裕をもって進めることができます。しかし、逆に、工数に余裕のないプロジェクトは悲鳴を上げることになります。

”ありがちな”工数の検討漏れをまとめましたので、今回の内容が少しでも参考にしていただければと思います。