ITシステム発注者から見たプロジェクトマネジメント

プロジェクト管理において、開発予算のことは避けて通れません。お金に関することは、やはり発注者と受注者の間での大きな争点の一つとなります。

発注者から受注者に対してシステム開発の見積もり依頼をした時の、受注者から提示される見積もりのサンプルを示します。



上記はサンプルですが、システム開発の見積もりを依頼すると、おおよそ上記のようにそれぞれの作業に対する工数（どれだけ作業時間がかかるか）に単価をかけて計算した費用で算出されています。（この人月で見積もる方法については賛否の議論がありますが、簡単に語れる話ではないのでここでは触れません。）

上記は、説明のために簡略化していることもありますが、発注者からすればこれが高いのか安いのかが判断つきません。

発注先を選定中であれば、複数の開発ベンダに見積もり依頼をして、それらを見比べることで多少は判断がつきやすくなります。ただし、ベンダによってそれぞれの作業の質が異なっていたりするので、単純に数値だけ比較しても意味がありません。

例えば、上記の例で単に「テスト」と書かれている作業項目についても、実際には
テスト仕様書を作成 → テスト仕様書のレビュー・修正 → テストデータ作成 → テスト実施／テスト結果記録 → テスト結果分析 → 出荷（品質）判定
といったような流れを踏んで行っていきますが、ベンダによって細かな流れが異なっていることもあるでしょうし、それぞれの作業をどこまで細かく（丁寧に）やるかどうかは違ってくるでしょう。
そうなると、見積もりの工数（費用）は少なかった（安かった）けれど、作業の質が荒くてシステムの品質も悪かったということもあり得るでしょう。
いわゆる、「安かろう悪かろう」です。

そうなると、冒頭に示した見積もりの妥当性を明確にしていくためには、各作業の詳細な内容を確認していくしかありません。
例えば、上記のテストの例でいえば、過去にシステム開発を行った事例での

• テスト仕様書
• テスト仕様書のレビュー結果（レビュー時間、指摘内容、件数など）
• テスト結果（エビデンス）
• 品質分析結果

といった資料を求め、これらの作業の質を確認していくのです。

もちろん、依頼するシステム開発の納品時にもこれらのドキュメントを求め、きちんと求めた質で作業が行われているかを確認します。（納品時の資料として求めておくことで、受注者に作業品質の担保を求めるということです。）

現状では、システム開発の見積もりが作業工数をベースとしている限り、それぞれの作業を可能な限り具体的に（詳細に）確認することで妥当性を見るしかないと思います。