ソフトウェア開発の見積もり① 「見積もりの基礎知識」
はじめに
ソフトウェア開発の計画作りでは、各工程に要する時間を算出するために『見積もり』という行為が行われます。
見積もりが使われるのはソフトウェア開発だけではありませんが、ソフトウェア開発での見積もりは難易度が高く、たびたび問題が発生する工程の一つです。
この記事では、何回かに分けて、ソフトウェアにおける見積もりについて書きたいと思っています。
まず1回目は「見積もりがどんなものなのか？どういう特徴があるのか？」といった基本的な内容についてお伝えしていきます。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
ソフトウェア開発の見積もりとは
ソフトウェア開発における見積もりとは、主に開発に関わる作業の時間や期間を指します。
ソフトウェア開発の多くの作業は人間が行ないます。
そのため単純な計算をすると
『ある人がその作業に費やす時間 × 作業の数 = 開発に必要な総作業時間』
とすることができます。
このうちの「作業に費やす時間」と「必要な作業」を事前に洗い出し、予測するのが見積もりの工程です。
見積もりは、目的の一つとして「開発に必要な期間」と「開発に必要な費用」を算出することにも使われます。
こちらも単純な計算をすると
『総作業時間 ÷ 開発の人数 = 開発に必要な期間』
『総作業時間 × 時間辺りの単価 = 開発に必要な費用』
で算出することができます。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
ソフトウェア開発の見積もりの特徴
ソフトウェア開発における見積もりの特徴としては、次のようなものがあります。
・ほとんどの作業は人間が行なう
・事前に予測しにくい作業が多い
物理的な材料や機材を使うことが他業種よりも少なく、開発工程の多くを人人間が行なうことが、ソフトウェア開発の特徴の一つです。
またソフトウェア開発の見積もりは、
・求められる機能や要件によって必要な技術内容が大きく変わる
・プログラミングなど専門的な作業が多いことから、進捗が作業者の技量に依存する
などの理由から見積もりに乖離が起きやすい(事前に予測しにくい)のが現状です。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
代表的な見積もり手法
ここではソフトウェア開発で使われる代表的な見積もりいくつか手法を紹介します。
見積もり手法は、目的に応じて様々な種類があり、それぞれメリット/デメリットが存在します。現在の状況と目的に合わせて最適な見積もり手法を選択することが重要です。
① 積み上げ法
必要な作業を洗い出し、その作業に対して掛かる作業量(時間)を予測したのち、最後に各作業量を合計し総作業量とするという方法です。
■ メリット
計算方法がシンプルで分かりやすい(説明しやすい)
■ デメリット
・各作業で共通化できる内容も積み上げられてしまうため工数が膨らみやすい
・見積もる人によって作業量が変わってしまう可能性がある
② FP(ファンクションポイント)法
各機能の数や外部との接続機能の数などシステムの特徴を抽出し、その個数と機能の重み(難易度、複雑性を表す指標)をかけ合わせることで全体の開発規模を算出する方法です。
■ メリット
・見積もりの精度が作業者の技量で変わりにくい
■ デメリット
・システム固有の複雑性など詳細が把握しにくい
③ 相対見積もり
ある基準となる作業にたいして、規模が大きいか小さいかを比較して見積もっていく方法です。
例えば、作業の規模を(S, M, L, XL)の4段階のサイズとして、現在の作業がどのサイズにあたるかを相対的に見積もっていきます。
■ メリット
シンプルで早く見積もることができる
■ デメリット
規模のサイズが固定のため精度が高い見積もりにはならない
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
見積もりについての基本的な考え方
ここでは、ソフトウェア開発の見積もりにおいて基本的な考え方をいくつか紹介します。
見積もりの乖離が発生しスケジュールが遅延すると、チーム内で衝突が起きることがありますが、これは見積もりに対して認識がチーム内で統一されていないことが原因です。
このような事態を防ぐために、あらかじめ見積もりについての基本的な考え方をチーム内ですり合わせておくことが重要です。
① 見積もりは完了を約束するものではない
見積もりとは「見積もった時間内に作業が完了するか」を表す評価基準のひとつです。したがって見積もりの時間はその作業の完了を約束するものではありません。
見積もりの目的は、その時点での計画の妥当性を評価することにあります。計画と実績に乖離があることは普通であり、見積もり通りに100%完遂されると思って行動することは危険です。
② 見積もりは時間とともに変化する
見積もりは精度とともに評価しなければなりません。
プロジェクト開始直後の見積もりは、不確定事項が多く精度はあまり高くありません。現時点での見積もりがどの程度の精度なのかを、認識しておくことが重要です。
見積もりの精度は「不確実性の減少」「経験、実績による学習」により高くなり、基本的にはプロジェクトが進むにつれて高くなる傾向にあります。
精度が低い初期の見積もりについては、再度見積もりを行い計画を修正する判断も必要です。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
見積もりは目的によって複数存在する
開発プロジェクトの開始から終了までの間、様々なケースで見積もりは使われます。開発の状況によって見積もりの目的が変わることを理解しておいてください。異なる見積もりを共有することはプロジェクトのスケジュールに大きな影響を与える危険性があります。
▼ 例1: 開発会社が発注元に提示する見積もり
ソフトウェア開発企業が顧客である発注元の企業へ受注前に提示する見積もりは、多くの場合「概算見積もり」と呼ばれる精度が荒いものになります。
この見積もりの目的は、発注元企業が「費用感」「スケジュール感」を知ることが目的であり、あくまでざっくりとした感触を掴むためのものです。
このような見積もりは、調査が必要な不透明な内容や、洗い出されていない機能が存在するため、最終的には大きく乖離することも珍しくありません。
▼ 例2: 開発者の1日の作業の見積もり
開発者が一日に作業する単位での見積もりは、プロジェクトが正常に進行しているかを評価することが目的です。
実際に作業するタスクレベルで洗い出せているため、不確実な内容が少なく、作業の詳細まで時間単位で見積ることが可能です。
漏れや遅延は当然ありますが、見積もりと実績の乖離は比較的小さい見積もりと言えます。
上記の例でいうと、請負時に概算見積もりで3日掛かると見積もったものを、そのままの開発作業の見積もりに使ってしまうと、実績が大きく乖離する危険性があります。概算見積もりでは、開発者が詳細な設計や調査を行なっていないからです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
楽観的見積もり・悲観的見積もり
見積もりには、その作業が最も上手く進んだときの見積もり=『楽観的見積もり』とその作業が最も上手く行かなかった見積もり=『悲観的見積もり』というものがあります。
これは表現を変えるとその見積もりの「完了確率」でもあります。
楽観的な見積もりは「50%程度の確率で達成できる見積もり」。悲観的見積もりは「80%程度の確率で達成できる見積もり」といった表現になります。
この悲観的、楽観的見積もりは、バッファの設定と大きな関連があります。悲観的な見積もりに対して大きなバッファを設定すると、元々大きな期間の見積もりに対して、更に大きな余裕期間が取られてしまうからです。
現在見積もった内容が、悲観的なのか楽観的なのかを判断しておくことが重要です。
個人やチーム単位でも、悲観的(楽観的)な見積もりをしやすい人、悲観的(楽観的)な見積もりになりやすいチームなど傾向があります。今まで意識したことがなかった人は、自分がどういう傾向なのかを理解すると見積もりの精度向上に役立つと思います。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
複数人で行なう見積もり
見積もりの誤差を小さくするためには、個人で見積もるよりも複数人で見積もりをしたほうがよいでしょう。ポイントは次のとおりです。
▼ 個人の技量によって見積もりが変動する
ソフトウェア開発の作業は、熟練度や経験によって作業効率が変わるため、個人の見積もりだと担当者が変わった場合に誤差が生じやすい。
▼ 検討漏れや適切な解決方法を見つけやすい
個人で見積もりを行なうと作業内容に検討漏れが発生する可能性があります。また複数人で内容を議論することで一人では気づかなかった解決方法を見つけることができるなど、見積もりの不確実性を減らすことができます。
複数人での見積もりにも色々な方法が存在しますが、アジャイルソフトウェア開発で採用されている「プランニングポーカー」が有名です。
プランニングポーカーでは「1, 3, 5, 8, 13...」のようなポイントが書かれたカードをみんなで一斉に出し合い、妥当な見積もりを合意のもと決定する相対見積もりの方法のひとつです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
見積もりが乖離する原因
見積もりと実績と乖離を小さくし、見積もりの精度を上げるためには、正しく原因を分析することが重要です。
ここでは見積もりと実績の乖離の原因となりやすい状況の一部を紹介します。
■ 並行して複数のタスクを抱えている
複数のタスクを計画的に分割していたとしても、タスクを切り替えるコストは想像よりも大きいものです。特にプログラミングのような複雑性の高い作業であればあるほど、その切替には大きなコストがかかります。
このようなコストが積み重なることで見積もりと実績は乖離していきます。
■ タスクに多くの人が関連している
タスクに多くの人が関わっている場合、コミュニケーションに大きなコストが掛かります。承認や確認による待ち時間や、議論による手戻りなど事前には予測できないコストが掛かる場合があります。
多くの人が関わるタスクを見積もる際は、大きめのバッファを取るなどの対策が必要です。
■ 不確実性が高いタスク
作業するタスクに多くの不確実性が含まれている場合、見積もりと実績は大きく乖離する可能性があります。
例えば、未経験のタスク、技術的な調査が必要なタスクなどは、実際に実行するまで作業時間が予測しづらいものです。(場合によっては、数倍の時間が掛かることもありえます。)
■ 突発的な割り込み作業
企業で開発を行なう場合は特に、別の仕事の割り込み作業が発生することが考えられます。
突発的なミーティング、システム障害の発生、チームメンバーとの会話など一日の割り込み作業の時間は想像よりも多くを占めています。
こうした割り込み作業がプロジェクトの進捗にどのくらい影響しているのかを計測し、見積もりに組み込むことが必要です。
■ 作業者の問題(体調、モチベーションなど)
作業を行なうのはあくまで人間のため、体調不良による休暇やモチベーションの低下がタスクの進捗に影響を与えることがあります。このような場合も当然見積もりと実績は乖離します。
このようなケースを予測することは難しいため、事前に対策を練っておくことは現実的ではありません。また、個人的な意見にはなりますが、このようなケースが大きな遅延に繋がっていることも少ないように感じています。
これらのケースを対策するよりも、その他のケースに注力する方が効果が高いかもしれません。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
まとめ
読んでいただきありがとうございました。
今回は、ソフトウェア開発における見積もりの基礎的な内容について紹介しました。
今後も見積もりについて記事を追加していこうと思っていますので、興味がありましたら読んでいただければ幸いです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
アンケートのお願い
このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。
この記事が気に入ったらサポートをしてみませんか？