HAROLABO Tech Blog

テクノロジーを使いやすく!ハロラボの技術情報発信メディアです。

見積もり

ソフトウェア開発において、見積りというのは面倒なものです。 要求は曖昧なのに正確な見積もりを求められ、納期とコストを決められるという、なんとも不合理なシステムです。 しかし、正しい見積もりこそがプロジェクト成功のカギであることは事実です。 見積りを制する者はプロジェクトを制す、ということで、見積もり精度を上げていきましょう。

なぜ見積もりをするのか?

どのくらいお金を使うかも、どのくらい期間がかかるかも分からないまま、どこかの誰かに家を建ててもらうことを想像してみてください。

普通は、使うお金は予算内で収めてほしいですし、10年も時間をかけてほしくはないはずです。 見積もりをすれば、建てたい家にどれくらいお金と期間がかかるか分かり、外装や内装や設備を変えたらお金と期間がどう変わるかが分かり、自分の予算と求める期間にちょうどあった家を建てることができます。 これが見積もりをする理由です。

見積もりの不確実性

見積もり、特に初期の見積もりというのは不確実なものです。 この現象を表した不確実性のコーンという図があります。 初期段階では、見積もりには4倍から0.25倍までの誤差があり、プロジェクトが進むにしたがって、1に収束していく実態を表した図です。

では、まず家を建て始めてしまって、見積もりの精度が上がってから見積もりをすればよいかというと、そういう訳にもいきません。 最初の見積もり作業をしていないだけで何をつくるかはすでに決まっているので、それにかかるコストと期間の予測値はすでに発生しているからです。 つまり、プロジェクトを成功に導くには、最初の見積もりの精度を上げることが必要なのです。

最初の見積もりの精度を上げるには?

先の工程まで事前に実施する

不確実性のコーンで分かる通り、なるべくプロジェクトが進んでいる状態であるのが望ましいと言えます。 工程でいえば、要件定義までは進んでおきたいところです。 そうはいっても、要件定義でやるべき内容をすべて実施するのは、コストも期間もかかり過ぎます。 見積もりがぶれそうな部分だけを見極めて実施する必要があります。

ソフトウェア開発プロセスのウォーターフォール開発の部分で述べた「プロジェクト設計を先に実施する」「2回開発する」というプラクティスも、不確実性のコーンの右側にできるだけ進めるための方法と言えると思います。

たくさんの人に見積もってもらう

特定の条件下では、多くの人がえいやで見積もった値の平均値が実測値とほぼ一致するという面白い話があります。 Wisdom of Crowds(群衆の英知)と呼ばれています。

そこで、経験のある人たちを集めて、同じ見積もりをしてもらい、その平均値を取ります。 これは、いわゆる相見積もりや、プランニングポーカーといったプラクティスとして実施していることも多いかと思います。

過去の経験を使う

なんとなく過去の実績はこんなものだったなといって見積もる方法はKKDと呼ばれています。 勘と経験と度胸で決める方法です。 群衆の英知の一人版といったところです。 当たり前ですが、経験がない場合や不足している場合には使えません。

過去の実績値を使う

過去に同じような作業を実施したときに、規模や所要時間を正しく記録していた場合に使える方法です。 スクラムのストーリーポイントとベロシティによる見積もりがこの方法です。 こちらも当たり前ですが、過去の実績値を正しく記録していない場合には使えません。 プロジェクト管理システムとセットで導入されることが多い手法だと思います。

標準的な見積手法を使う

FPとかLOCとかCOCOMOとかいった、要件数やソースコードステップ数をベースに見積もる方法です。 不確実性のコーンの右側にある程度進んだ状態での見積もりになるので確度が高くなりますが、当然、ある程度開発が進まないと使えません。

複数の手法を組み合わせる

群衆の英知の通り、ここに上げた(あるいはここにはない)複数の手法を組み合わせて見積もりをするのが、最も精度が高い方法だと言えます。

見積もり精度を上げるためのプロジェクト計画

WBSをつくる

作業を分解すると、見積もり精度が上がります。 家を建てるという作業の見積もりは分からなくても、レンガを1つ積むという作業の見積もりなら誰でもできるでしょう。 WBS(Work Breakdown Structure)を使って、プロジェクトの作業を分解していきます。

techblog.harolabo.com

工程ごとの作業工数比率

個々の作業の見積もりの精度を上げたとしても、想定した作業内容に不備があったとしたら、全体の見積もり精度は悪くなります。 作業内容が適切かの判断は難しいですが、1つの方法として、工程ごとの作業工数比率を成功プロジェクトの実績と比較する方法があります。

成功プロジェクトと失敗プロジェクトを比較すると、失敗プロジェクトでは実装工数が多くテスト工数が少ないことが分かります。 十分にテストされていないということは、市場に流出する不具合が見つけられないということでもあるので、直感と合っています。 それではどのくらいの工数比率にするかよいのかというと、成功プロジェクトの実績を見ると、各工程の作業工数が一番少ないものと多いものとで2倍以内に収まっていると良いようです。 上流工程では30%程度、下流工程では70%かける感じで、実装とテストを1:2くらいにする感じです。 私の経験としては設計:実装:テスト=1:1:1で見積もることが多かったですが、1:1:2の方が成功率が上がるかもしれません。

www.ipa.go.jp

要件定義への手戻りのリスク

見積もりと実績が乖離にする要因の筆頭は、要件定義への手戻りのリスクでしょう。 テスト段階で要件の抜け漏れに気づいて要件を追加・修正する必要が出るというリスクです。

このリスクは開発者なら誰もが分かっているリスクですが、このリスクに対応するのは容易ではありません。 なぜならどれだけモックアップを作りシミュレーションを行なっても要件定義時に完成状態を想像するのはとても困難であり、完成しないと分からないという現象はほぼ必ず発生するからです。 かといって、2回開発するというウォーターフォール開発プロセスで述べたプラクティスを実行しようとすると、コストと期間が膨れ上がります。 そのため、要件定義工数やテスト工数を多くとる軽減策しかとれないことが多いでしょう。 あるいはアジャイル開発手法が採用できればリスク対応策となりえます。

とにかく、コミュニケーション不足にならないことが最も重要なことです。モックアップや分かりやすいドキュメントの作成、密なコミュニケーションを怠らならいことが、要件定義への手戻りのリスクを抑えるカギだと言えると思います。

プロジェクトバッファを用意する

個別の精度を上げるのではなく、見積もり全体を一定工数内に収める方法として、プロジェクトバッファという余裕の時間を用意するという方法もあります。 プロジェクトの最後に付加するのがプロジェクトバッファですが、各作業の最後にバッファを付加する場合もあります。 CCPMなどを参考にするとよいでしょう。

クリティカルチェーン・プロジェクトマネジメント - Wikipedia

運用保守の見積もり

プロジェクトの見積もりをする際に、運用保守の概算見積もりをするケースもよくあります。 完成したソフトウェアはソフトウェア資産として計上することになり、運用保守も含めて投資対効果を見る必要があるからです。

以下の項目を考慮する必要があります。

  • インフラ費用
    • クラウドの場合は、仮想マシンのスケールやI/O・ストレージの増加量などを考慮する必要があります。
  • 監視体制
    • 24/365運用は当然ながら費用がかかります。
  • インシデント対応・改修対応
    • 不定期に発生する作業は、チケット制にしたり、個別対応にすることもあります。
  • EOL/EOS管理
    • 利用しているハードウェア/ソフトウェアの期限を迎えたときにアップデートする費用を考慮する必要があります。
  • 問い合わせ対応
    • 問い合わせに対応する作業です。
  • アカウント等のデータ管理
    • ユーザーの増減や、マスターデータの更新などの作業も考慮します。
  • ログ管理
    • ログの取得を依頼される場合もあります。
  • 定期レポート
    • 稼働状況を定期的にレポートとして作成する場合もあります。