システム開発工数見積りの１０個のチェックポイント

システム開発の工数見積りの結果をレビューする時に気をつけてみるべきポイント１０個をあげてみました。

工数見積りレビュー時のチェックポイント

システム開発の工数見積りの結果をレビューする時に気をつけてみるべきポイント１０個をあげてみました。

一口に「システム開発」と言っても様々なパターンが存在します。
「基本設計からシステムテストまで」作業したり「ＰＧ～結合テストまで」であったり。

極端な場合は「単体テストだけ」のテスターの役割だったり。
これが明確になっていないと正しい見積りは出てきません。

見積り時点で仕様が曖昧であったり、すべてを見通せない場合がたくさんあります。
このような場合、見えないものを数字にするのは難しいのですが、絶対に工数にはいくらか上乗せしておく必要があります。

プロジェクトを運営する上では必ず「プロジェクトを管理する為の工数」が必要です。

これがないと、プロジェクトマネージャが動いた分だけ「赤字」が発生してしまいます。
この工数、お客様からすると「間接的な工数」なので認めてもらえない場合があるので、注意が必要です。

システム開発を行う上では、当然、そのソフトウェアが使われるシーンや場所によっては、現在の運用フローを調査したり、担当者にヒアリングしたりする時間などが必要になります。

これが思ったより時間がかかり、開発に入るための条件がなかなか整わないことがよくあります。
このシステムにどんな人（部署）が関わって何をしているのかなどを調査・分析する工数は必ず取りましょう。

また、既知の技術ならば問題ないのかもしれませんが、始めて使う言語、開発環境、ツールがあるような場合は、そのことについて調査・分析をしたり習得する時間も必要になります。

簡単な機能が大きな工数になっていたり、逆に複雑な機能が少ない工数になっていないかなど、全体のバランスを見ながらその工数バランスを良く見ます。
また、各工数にはしっかりとした根拠があるかも確認します。

いつ、どの時点の仕様で見積りをしているのか、またはどんな制約事項を持って見積りをしているのかなどの前提条件を確認します。

必要であればその条件を見積り書に明記しておく必要があります。

投入予定の人数分パソコンが足りない、もしくはパッケージソフトなどのライセンスが足りていない場合は、それを購入する金額も含まれているか確認します。
パソコン無かったら仕事できません・・・。

発注元から借用できる物件（ハード、ソフト、資料、データの提供等）が明確になっているか確認します。
あとで「○○が無いのでできない」なんてことにならないように。

他のシステムと連携する場合などそのインターフェースの設計や、相手システムの改修等は誰がいつやるのか、ま受注側がやる時には既存の不具合等発生が発生した場合はどうするのかなど、お互いに齟齬が無いようにしておきます。

最終的に納品す場合の納品物件や、著作権などを明確にしておきます。

また、システムの開発を完了とする条件（検収条件）を明確にしておきます。

「システムテスト完了」だけではなく、「運用開始から１０日間トラブルなく稼働すること」なんて条件もあったりします。

必ず確認しておかないと、思ったタイミングでプロジェクトが完了できないことになります。

もっとあるのでしょうが、とりあえず今回はこれくらいで。
また、いづれの日にか追加していきます。