システム開発の見積もり
見積もりとは、ある開発について、どの程度の工数（人数×期間）で終わるのかを予想する作業である。
「どのようなスキルを持った人員をいつ何人入れれば予定した期日に開発が終わるのか」「今の人員で開発を行った場合にいつ開発が終わるのか」といったことを考え、QCD（品質・コスト・価値提供）を満たすことができる計画を立てる上で、欠かせない事前作業である。
この記事では、見積もりの難しさや手法、見積もりを行う際の注意点について述べる。
(1)見積もりの難しさ
システム開発には、要件の明確さや技術的な実現性といった点で不確実性を抱えやすいという特徴がある。
過去に開発したシステムと全く同じシステムを開発するということもなく、特に開発初期は不確実性が大きい状態となる。
この不確実性の大きさを示したものが、次に示す不確実性コーンと呼ばれる図である。
この図では、開発初期であればあるほど見積もりに差異が出やすいということを示しており、最も初期の段階では±4倍の範囲で見積もりと実際の規模に差異が出るとされている。
見積もりを行うにあたっては、「最大で±4倍の差異が出る」というイメージと、「初期の段階であればあるほど大きく差異が出る」ということを意識するべきである。
(2)見積もりの手法
見積もりの手法は「ボトムアップ見積もり」「類推見積もり」「三点見積もり」「直感による見積もり」「パラメトリック見積もり」に大別される。
これらの見積もりの中から、システムやチームの状況に応じて適した手法を用いるべきである。
それぞれの見積もりの手法についての説明は以下の通りである。
【ボトムアップ見積もり】
ソフトウェア開発を一つ一つの作業に分解し、一つ一つの作業の工数を見積もり、それを合算する手法である。
作業単位に分解する際にはWBSが用いられる。
最も標準的な見積もり手法だが、作業内容が具体的に見えるまでは見積もりの精度が低くなるという難点がある。
【類推見積もり】
類似する案件の規模を参考にして規模を見積もる手法である。
過去に似た案件を実施したことがある場合に有効な手法である。
【三点見積もり】
楽観値・悲観値・最可能値（最もそうなる確率が高い値）の三点を算出する見積もり手法である。
他の手法と組み合わせ、誤差の大きさを表現したい場合に用いられる手法である。
【直感による見積もり】
熟練度が高い複数人の有識者により、直感的に見積もりを行う手法群である。
新規性が高い案件においても初期段階から迅速に見積もりができる反面、正確性が熟練度に依存する難点がある。
直感による見積もりに分類される手法としては、以下のようなものがある。
ストーリーポイント
基準となる案件に対する見積もり対象の案件の規模を、各々の有識者が見積もるというものである。
案件の規模は原則としてフィボナッチ数列で表現する。
（…1,2,3,5,8,13,21,34…）
フィボナッチ数列が書かれたカードである「プランニングポーカー」と呼ばれる道具を用いて、「有識者がカードを出し合い、なぜそのカードを出したのかをお互いに認識共有する」という進め方をされることもある。
アジャイル開発で用いられることが多い見積もり手法である。フェルミ推定
実際に調査するのが難しい捉えどころのない規模を、いくつかの手がかりを元に論理的に推論し、短時間で概算する手法である。
「仮説を立てて問題を分解する」「分解した問題に対して参考になる数値を引用する」「引用した数値について補正をかけて統合する」という順序で推定を行う。
システム開発というよりは、コンサルティングの業界において一般的に用いられる手法ではあるが、その汎用性の高さからシステム開発の見積もりにも応用可能である。
【パラメトリック見積もり】
統計的な数値を用いて見積もりを行う手法群である。
数値さえ集まれば、有識者の熟練度に依存しない、客観的な基準による見積もりが可能である。
具体的には以下のような手法がある。
ファンクションポイント法
機能ごとに、項目数や難易度によって決まる複雑さに応じたポイントを与え、それを合算することで、規模を見積もる手法である。
機能やそれを構成する画面・バッチ処理が決まった段階での適用に向いている。ハルステッドモデル
プログラムのステップ数（正確に言えばプログラム中に出現する演算子と非演算子の数）によって規模を見積もる手法である。
見積もりのためにはプログラムを作成する必要があるため、かなり後の段階にならないと適用することができない。
(3)見積もりの際のポイント
見積もりやその後の作業計画の失敗から、デスマーチ（終わりの見えない高稼働）を招く典型的なパターンがいくつか存在する。
デスマーチが発生すると、担当者の離脱や労働者からの評判の低下を招き、作業品質の低下やコストの増加を招き、最悪の場合はリリースの延伸・中止に発展するため、管理する側としては何としても防ぎたいパターンである。
（そして、この記事の読者のほとんどは、長時間働きたくない・働かせたくないと本音では思っているだろう）
また、法令対応や経営上の都合でリリース日を動かすのが困難な案件でデスマーチに陥った場合は、十分な品質担保が行われていない状態での強引なリリースを行う事態に陥ることがある。
システムの提供はできるものの、リリース後の運用作業・バグ対応といったカバー工数（コスト）の増大は避けられず、バグの影響が及ぶ場合は、評判・信用の低下、最悪の場合は損害賠償ということにもつながりかねない。
バグ対応のコストは後の段階に行けば行くほど高まるという研究もあり、「バグ対応をリリース後に行うという決断」とも言うこともできるこの類の強行リリースは、コスト面で見れば最悪であり、やはり避けるべき事態である。
ここでは、見積もり担当者や計画担当者ができる範囲で、デスマーチを避けるための対策を紹介する。
【事前の不確実性の排除】
前述した通り、要件の明確さや技術的な実現性といった点で不確実性が残る場合、見積もりの誤差が大きくなる。
誤差を小さくするためには、要件調整や技術調査により不確実性を解決してから見積もりを行うことが望ましい。
また、後の段階になればなるほど見積もりの誤差は小さくなるため、段階がある程度進んでから再見積もりを行うのも有効である。
【「現行踏襲」から踏み込んだ検討】
たとえ、現行システムからの移植を行う案件であったとしても、要件が「現行踏襲」の一言で済まされている場合、その状態のまま見積もりを行うと過小見積もりにつながる。
「現行と同じように動くようにして欲しい」という要望があるにしても、現行システムの分析作業や、現行システム（現行運用）と整合を取った形での設計作業は発生するため、その状態のまま見積もりを行うことでこれらの作業の工数を過小評価してしまう。
「詳細は過去の○○案件を参照」「現行システムより画面イメージを作成（画面の機能・動作の詳細は割愛されている）」といった表現も、意味合いとしては「現行踏襲」と同じであるため、「現行踏襲」という言葉が使われていなかったとしても問題になることがある。
「現行踏襲」として省略された箇所を明確にしてから見積もりを行うのが理想であるが、少なくとも、現行システムの分析が不十分な状態で見積もりを行っているというのをリスクとして認識する必要はある。
【迅速な問題発見と対処】
段階が先に進めば進むほど取れる対策は減っていくため、見積もりやそれを元にした計画の通りに行かなくなるようなリスクの発見、そしてそのリスクへの対処は、迅速に行う必要がある。
迅速な問題発見と対処を実現するためには、管理者自身の力量の他、問題が即座に報告されるように良好な人間関係を築くこともポイントとなる。
初期段階であれば、スコープ見直し、（キャッチアップ期間を考慮した）人員投入、といった教科書通りの対処を行うことができる。
案件が進み始めてからは、（標準WBS通りではなくなる形での）作業の組み換え、社内プロセスの一部省略、といった属人的な対処とならざるを得ない。
それすらできない場合は、デスマーチや強行リリースに至るだろう。
この記事が気に入ったらサポートをしてみませんか？