はじめまして
セカンドセレクションのOkamizuです。
新卒でセカンドセレクションに入社してPCツールや制御機器のソフトウェアを開発する業務を7年間やってきました。最近では年単位での大規模プロジェクトのPLも担当させていただきました。
私自身SEとしてスキルアップするためにプロジェクトマネジメントを勉強することが多くなってきたので、勉強のためにも「ソフトウェア見積もり方法」を残したいと思います。
ソフトウェア開発見積もりの基本的な考え方
ソフトウェア見積もりの重要性
ソフトウェア開発を行うにあたって予算を取り、開発を立ち上げる時にはソフトウェア開発の見積もりを行う必要があります。見積もりはプロジェクト成功の鍵を握る非常に重要な要素です。
見積もりを誤ることでプロジェクトにおける工期遅れや品質低下などを引き起こしかねません。
プロジェクトを円滑に進めるうえで妥当な見積もりは欠かすことのできないものです。
見積もりの手順
※今回は1年以上の開発をする例を挙げて紹介します。
ソフトウェア開発の見積はどういう手順で、どういった見積書を出すのかと疑問を持たれる方が多いのではないでしょうか。
おおむね、見積もりを行う際には3つの見積もりを行うことになります。
● 超概算見積もり
超概算見積もりは、クライアントから「○○について実施した場合、どのぐらいかかる？」というお問い合わせの時にざっくりとした工数や工期を提示します。
私の経験上、長期で大型の開発の場合はここから始まることが多いです。
詳細な条件等は不明なため、本当に「超」概算であり、かなり多めの数値を提示させていただくことがほとんどです。
● 概算見積もり
要求仕様書、スケジュールや開発範囲、条件などを提示いただき、それに沿った見積もりを行います。ただし、要求仕様書の段階から、要件定義、仕様を固めた時にさらに変更になる可能性がある見積もりになります。
● 正式見積もり
要件定義・仕様策定、仕様に従った設計、開発、テストなど明示的な作業範囲や内容に基づいて行う見積もりです。制限事項や瑕疵対応範囲も明記します。
※開発規模により正式見積りのみの場合、概算見積もりと正式見積りを行う場合など異なります。
見積もりの対象
見積もりの対象には大きく以下の4点があります。
| コスト | ソフトウェア開発に必要な費用を指します。ここには工数だけでなく、必要なソフトウェア、ハードウェア等にかかる費用なども含まれます。 |
| 工数 | ソフトウェア開発に必要な作業工数を指します。 |
| 規模 | ソフトウェア開発作業にかかる量です。開発メンバの人数やソースコードの総量見積等で表します。 |
| 工期 | ソフトウェア開発の作業期間を指します。 例1：要求定義～リリース・例2：設計～機能テスト |
見積もりの課題、難しさ
なぜ、見積もりは難しいのでしょうか。
前提としてソフトウェアの見積もりはクライアントの何らかの目的に沿ったゴールを達成するための一つの要素です。
ゴールを達成するために「○○のようなことができるソフトウェアが必要だ。」と検討されるケースや「やりたいことは明確に決まっていないが、××という問題をソフトウェアで解決できないか」というケースで開発会社に見積もりを依頼されることがあります。
しかしこの場合、何がソフトウェア開発で実現できているべきかが見積もり時に明確ではない場合があります。こうした状況や不確定要素に対して、いきなり正確で詳細な見積もりを行うことは非常に難しいです。
また、改造・改修においては新規要素を追加する場合、既存の動作や機能を損なわずに品質を考慮した開発をする必要があります。こうした場合には事前に調査を行い、工数や規模を検討しなければ、見積もり対象が明確になりません。
ソフトウェア開発においては様々な不確定要素がありつつも、その開発はどれぐらいのコスト、工期で可能かを出さなければならないところに難しさがあると私は思います。
ソフトウェアを発注する方に知ってほしいこと
見積もりの目的ごとに金額が異なる
もちろんですが、新しい技術を用いた開発の場合には開発コストが高くなる傾向があります。これは技術を持っていると調査期間を短縮できる場合が多いからです。
また開発規模が大きいと複雑度が増し、開発を円滑に進めていくこと自体が難しくなるのでその面でもコストが高額になります。
見積もりの失敗談
見積もりは概算見積もり時点ではプロジェクト終了時結果と大きくかけ離れることが大いにありえます。
私が経験した見積もりの失敗は、仕様に従って再度見積もりを見直すタイミングをもたなかったために、概算見積もりから大幅にずれが発生した状態で開発を進めてしまったことです。
適切なタイミングで見積もりを見直ししなかったために、多大な調整が必要となってしまいました。
要件から詳細な仕様が定まった時に再度、仕様や条件に従って見積もりを見直しする必要があったのです。
見積もりを誤ることで関係者、多方面に不利益が生じることになります。
弊社の見積もり方法
ここからは弊社が実際に行っている見積もり手法を紹介します。
※工数の検討方法として例を2つ挙げますが、弊社では以下例を含んだ複数の方法で工数を見積もり、最終的な見積書を作成します。
- 見積もり依頼内容をブレイクダウンし、工数検討
要求仕様などから要素を分解し、それに必要な工数を算出。
例 プロジェクト開始から2か月で実施する場合。
AA:2人月
BB:1人月
計3人月
1か月目は1人で、2か月目は2人で開発。AAにあたる部分は機能や、画面など対象となるソフトウェアの性質によって異なります。改造の場合、改造元のソースコードから改造に必要なソースコードステップ数を検討し、ステップ数に応じた工数を算出。- 開発のために必要なソフト、ハードの検討
提供有無確認開発に必要なソフトウェアやハードを洗い出します。ソフトウェアのライセンス料やハードウェア購入費、クラウドサービス利用料などが必要になる場合があります。またクライアントから貸与いただける場合はその確認も随時行います。- スケジュール・リスク・体制を検討
工数や規模にそったスケジュールの検討、リスクやどのような開発体制を組むかを検討します。リスクを検討する場合はそれが実際に発生した場合の対応まで検討し、共有します。- 有識者による検討会を実施
複数のエンジニア、決裁権を持つ上長と、弊社がこの見積もり対象開発で遂げたい目的、目標を確認します。見積もり工数の妥当性や、リスク、依頼者への確認事項の漏れがないか、開発体制の検討も行います。
上記を実施していても、正確無比な見積もりを行うことは非常に難しいです。
ご依頼をくださったクライアントの希望を叶える提案内容を意識しつつも、弊社としての利益につながるような見積もりを心がけています。特に私が見積時に意識していることは、開発の目的や条件、実現したいことを共有することです。
クライアントが出す要求仕様書だけでなく、その目的や背景について理解することで必要な要素の追加や要件の変更を行うことができます。
それを見積もりに反映することでソフトウェア開発を実際に進めるときにクライアント、弊社ともに認識の齟齬が起きにくくなり、プロジェクトの成功につながると考えています。
まとめ
見積書を作成する際には最終的に以下3点について気をつけています。
- 見積もりの対象内容、工数、金額、開発範囲、開発条件等を詳細に明確に記載すること
- ソフトウェア開発において見積もり時にはわからなかったこと、不測の事態はつきものですが、およそ考えられうる内容についてどうするのかを明記しておくこと
- きちんと内容についてクライアントに説明、ご納得いただける形にすること
いかがだったでしょうか。今回はソフトウェアの見積もり方法について書いてみました。想定外の工数がかかってしまい、大炎上ということがないようにソフトウェア開発の見積もりについて見直してみることは大事ですね。この記事を書いたことで私自身、見積もりについて改めて考えを深めることができました。
長文読んでいただきありがとうございました。
2021年より、SSコラムに記事を投稿しております。
もしよろしければ、セカンドセレクションの事業内容もご確認ください。