http://monoist.atmarkit.co.jp/mn/articles/1109/14/news011.html
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工學における最重要課題の1つでもあります。
今回お屆けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具體的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（狀況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具體的に解説していきます。
見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回、“勘・経験・度胸”のいわゆる「KKD」による類推法を解説しましたので、今回から世界のソフトウェア開発プロジェクトで最も頻繁に使われている積み上げ法による見積もりを紹介していきます。
積み上げ法
類推法は過去の経験を基に全體を一挙に見積もる方法ですが、今回から紹介する積み上げ法は、“部分”や“機能”に分解してそれぞれを見積もり、合計を出す方式です。類推法は“トップダウン式”、積み上げ法は“ボトムアップ方式”といえます。
例えば、新しく會社を創設する際、社員が何人必要かを見積もるとします。類推法では、同業他社の社員數をベースに、自社固有の事情を加味して、必要人員數を類推します。一方、積み上げ法では、會社組織を「人事部」「経理部」「営業部」「第1開発部」「第2開発部」「品質保証部」に分割し、さらに第1開発部を「エンジン設計課」「ボディ設計課」「電気系統設計課」「油圧系統設計課」に分け、エンジン設計課をさらに細分化して必要人員數を決める方式です。
積み上げ法による規模見積もりの王様と女王様が、「LOC（Lines of Code）見積もり」と「FP（Function Point）見積もり」です。
LOC見積もり
LOC見積もりは、開発対象のソフトウェアの規模をソースコードの行數（LOC）で見積もる方式です。見積もりの“王様”であり、恐らく人類初の見積もり法がこれでしょう。LOC見積もりは、以下の手順で進めます。
- 開発するソフトウェアを通常の設計時と同じ方法で機能の分解や詳細化を進め、小さいモジュールに分割（通常は、3、4段階まで詳細化する）
- 各モジュールのステップ數を合計
- その総LOC（あるいは、KLOC＝Kilo Line Of Code）を一人當たりの生産性（例えば、ステップ數／月）で割り算して人月を計算し、コスト・必要人數を出す
例えば、ソースコード行數が122KOLC、プロジェクトの平均生産性が1103LOC／月（注1）、1人月が98萬円とすると、開発コストは以下のようになります。
122KLOC ／ 1103LOC × 98萬円 ＝ 約1億840萬円
このように、LOC見積もりは通常の設計と同じ方法でアプローチするため、誰にでも可能で、特別な見積もり技術は不要です。また、見積もり値の単位（ステップ數）が明確なので、分かりやすくてカウントも簡単です。それ故、説得力もあります。ステップ・カウント用のツ－ルを使えば、自動計算できますし、工程管理ともよくなじみますので、例えば「5日遅れ」などを簡単に計算することが可能です。どんなに手抜きし放題のいいかげんなプロジェクトでも、さすがにソフトウェアのソースコード行數は計測しています。こうした理由から、LOCは「見積もり技法の王様」といわれるようになったのでしょう。
LOC見積もりの課題
世界中のソフトウェア開発プロジェクトで大人気のLOC見積もりですが、実は以下のような大きな欠點や課題があります。
- 何を・どのように、ソースコードとして數えるかで行數に5倍の違いが出る
- カウントが主観的であり、サバを読む餘地が多い
- 開発ライフサイクルの初期に予測するのが困難
- 「見積もり」と「実績」のズレが大きい
- 使用するプログラミング言語を意識する必要がある
以下、それぞれの課題を詳細に見ていきましょう。
1．何を・どのように、ソースコードとして數えるかで行數に5倍の違いが出る
単に、ソースコード行數のカウントといっても、“流儀”によって5倍の差が出ます。例えば、以下を考えてください。
- コメント行、空行、ヘッダ行の扱いは？
- 1行に複數命令を記述した場合のカウントは？
- 複數行で1命令を記述した場合のカウントは？
いろいろな流儀がありますが、最も多いのは以下のカウント法だと思われます。
- コメント行、空行は含まない
- ヘッダ行は展開してカウントする
- ステートメントが複數行にわたっても1行と見なす
- 1行に複數命令を記述しても1行と見なす
どんなカウント法を採用するにしても、同じ組織の中、少なくとも、同じプロジェクトの中では、カウント規則を統一しなければなりません。すなわち、同じステップ・カウントツールを使う必要があります（注2）。
餘談ですが、ISO（國際標準機構）では、ソフトウェアの規模を測定する尺度を「規模尺度法」として標準化していますが、LOCは、値が一意に決まらないので規模尺度法の要件を満たしていません。一方、LOCの永遠のライバルであるFPはそれを満足しているため、この點がLOCに比べて使用者の數で圧倒的に少ないFPの大きな自慢ポイントです。
2．カウントが主観的であり、サバを読む餘地が多い
例えば、「データベース初期化処理モジュール」のステップ數を、Aさんは80ステップと見積もり、Bさんは300ステップと見積もるなど、人によって大きな差があります。この差が、積もり積もって規模が數倍にも違ってきます。
これは、プロジェクトの中だけの問題にとどまりません。お金を払う発注側も、「なぜ、たかだかデータ受信バッファの初期設定に300ステップも掛かるのか？」と信用しない可能性が大で、「開発量を水増しするため、サバを読んでいるのでは？」との不信感につながりかねません。LOC見積もりでは、カウントの根拠になった數値やデータをきちんと提示できないのがツラいところです（提示しても、信用してくれない）。
一方、ライバルのFPは、客観的な根拠を示すことができ、誰がカウントしても同じ數値が出ます（というより、それを目指しているように思います）。
3．開発ライフサイクルの初期に予測するのが困難
規模見積もりにより、プロジェクトに何人の技術者が必要かが分かりますが、この時期はまだ要求仕様定義の段階であり、開発ライフサイクルの初期です。當然、処理方式、データ構造、アルゴリズムが見えていません。そんな狀態ではソースコード行數を正確に見積もることは不可能で、見積もり精度が低い最大の理由がこれです。桁違いの見積もりミスを起こす可能性が高く、細心の注意が必要です。
LOCによる規模見積もりは、理想をいえば「バージョン2」以降、すなわち、新規開発が終了して処理方式やデータ構造が完全に固まり、マイナーな機能を追加するフェーズ以降で適用すべきでしょう。新規開発の見積もりで適用する場合は、他の見積もり手法、例えば、類推法と併用する必要があります。
4．「見積もり」と「実績」のズレが大きい
上記の「3．開発ライフサイクルの初期に予測するのが困難」と関連した課題がこれで、±64％の差異があるといわれています。見積もりの場合、厳しい方にズレる見積もりミス（例えば、173KLOCと見積もったが、実際は96KLOCだった）は、狹義の観點では見積もりミスと見なしません。楽観的な見積もりミスが、「本當の見積もりミス」で、絶対に避けねばなりません。
楽観的な見積もりミスの怖さは、プロジェクト管理者なら誰でも認識していますので、勢い、多めに見積もって「保険を掛ける」ことになりますが、LOC見積もりの場合、その保険分をはるかに上回る壯大な見積もりミスが発生します。繰り返しになりますが、致命的な見積もりミスをなくすため、必ず、絶対に、何が何でも、死んだ気になって、他の見積もり手法を併用すべきです。
5．使用するプログラミング言語を意識する必要がある
當たり前ですが、ソースコードの行數をカウントする場合、具體的なプログラミング言語を想定します。アセンブリ言語と高級言語では、総行數は數倍の差が出ます。プログラミング言語の違いによって、生産性の數字を異なりますし、他のプロジェクトの數値をそのまま參考にできなくなりますので、注意が必要です。
LOC見積もりは、単純明快な技法なので、課題や欠點を認識しながら上手く使えば大きな効果を出せます。次回は、規模見積もり法の女王様「FP見積もり」について解説します。（次回に続く）