どうも、Tomatsuです。
COCOMO、CoBRA、ファンクションポイントなどのテキスト解説が不十分でシステム開発見積りのイメージが湧きません。。。
どうすればよいでしょう。。。？
このような疑問にお答えします。
COCOMO・CoBRA・ファンクションポイント法などのシステム開発見積り手法について分かりやすく解説します
記事を書いている私は、財務・会計関連の「知識ゼロの状態」から、中小企業診断士試験にストレート合格しました（情報は72点）。
現在は会社員をやりながら、診断士受験用のテキスト本の執筆や、受験生支援ブログにて執筆活動（一発合格道場）を行っています。
効率的な勉強法には自信がありますし、結果も出してきていると言えます。
システム開発見積り│COCOMO・CoBRA・ファンクションポイント法などの違い
見積り手法の分類を覚える
見積り手法を覚えられないという方は、各手法を闇雲に暗記しようとしてませんでしょうか？
システム開発見積り手法は大きく分けて下記の三つに分類されます。
- 類推法
- パラメトリック法
- 標準タスク法
まずは下図・表をつかって各手法の内容を把握すると良いでしょう。
これらの分類はPMBOKガイドでも紹介されております。
表からもわかる通り、三つの手法はプロジェクトのフェーズごとに使い分ける必要があります。
パラメトリック法に関しては、数多くの手法が考案されており、診断士試験で問われる論点としても下図の４つに分類されます。
ここからはパラメトリック法の各手法を一つずつみていきましょう。
LOC法（Line of Code法）
LOC法はパラメトリック法の中で最も古典的な見積り手法で、その名前のとおりソースコードの行数から開発規模を見積ります。
例えば、ソフトウェア規模が「100,000行」、生産性が「1000行/月」、プログラマー単価が「百万円/月」の場合、開発コストは下記の通りとなります。
この分かりやすさゆえ、システム開発の知見がない発注者側が直感的に分かりやすい見積手法として古くから採用されてきました。
ただし、同じソフトウェアでもプログラマレベルや選択されるアルゴリズムによって「総行数」は大きく変わりますので見積り手法としては未熟と言えます。
COCOMO法
COCOMO法もLOC法と同様に開発規模が総行数によって変わることを想定しております。
ただし、実際には総行数と開発工数（コストの直接因子）は比例関係ではありません。
システム開発では一般的に、総行数が増えるにつれて工数が指数関数的に増えていきます。
COCOMO法ではこの傾向を考慮し、以下の式を用いて工数を見積もります。
AとBはプロジェクトの種類によって変わる係数です。
プロジェクトの種類には下記がありますが、診断士試験では問われませんのでふ～ん程度に覚えておいていただければと思います。
- オーガニックタイプ：規模小さめ・リスク理解度高い
(A = 2.4, B = 1.05) - セミデタッチタイプ：規模・リスク理解度ともに中くらい
(A = 3.0, B = 1.12) - エンベデッドタイプ：規模・複雑さともに高い
(A = 3.6, B = 1.2)
COCOMO法ではLOC法と異なり、プロジェクトの種類による工数の変化も考慮するということを覚えておきましょう。
ファンクションポイント法
ファンクションポイント法はソフトウェアが保有する機能の数・難易度をもとに見積もる方法です。
見積り時に下表を埋めて総ファンクションポイント数を累計します。
複雑度はプログラムの機能の難易度を重みづけする係数であり、プログラマーのスキルではないことに注意しましょう（H30 第18問で引っ掛け問題が出題されました）
CoBRA法
CoBRA法では開発工数が規模に比例すると共に様々な変動要因（リスクファクター）によって工数が変わることを前提に見積もります。
式の形は下記のとおりです。
見積り業務の熟練者の知見をもとに「ΣCO」を抽出するのが最大の特徴となります。
COCOMOでは変動要因に対応するためのパラメターが予め設定されているのに対し、CoBRAではプロジェクト毎に熟練者がパラメターを調整します。
まとめ
本記事ではCOCOMO・CoBRA・ファンクションポイント法などの混同しがちな論点について解説してきましたが、いかがでしたでしょうか？
各手法の分類を知らずにやみくもに暗記をしていても知識として定着しづらいので、図解で意味をしっかり理解しながら勉強を進めてみてはいかがでしょうか。
それでは最後まで読んで頂きありがとうございました。
よくわかりました