ついに登場！ 究極の見積もり技法（その1：解説編）：山浦恒央の“くみこみ”な話（38）
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。
見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は、積み上げ法の代表である「FP（Function Point）」の超簡易版として、「FP試算法」を解説しました。これは、計算手順が30分で理解できて、システムの分析やFP計算も1、2時間程度で可能な見積もり法です。
今回は、パラメトリックス法の1つとして、「SLIM（Software Life Cycle Management）」を取り上げます。「ソフトウェアの規模」をFP試算法で見積もり、その見積もり値にSLIMを適用すると、「工数（コスト）」「開発期間（月）」「機能総量（規模）」「（プロセス）生産性」「品質」の5つの関係を分析できます（例えば、規模が20％増えたり、開発期間を18カ月から14カ月に短縮したりした場合、スケジュールや人月にどう影響するかを簡単に計算できます）。また、「最短開発期間（技術者を何人投入しても、これより早くは開発できないという時間）」も算出可能です。
「18カ月かかるところを14カ月でやれ！」と言われて、「それは無理です」と答えると、必ず「何の工夫もしないでできない何て言うな!!」と上層部から叱責を受けます。
その場合の究極の反撃法が、このSLIMで算出した最短開発期間です。
最短開発期間を計算したところ15カ月半となりました。ですので、14カ月では絶対にできません。出荷日を最優先にし、14カ月で出荷したければ、開発規模を縮小する必要がありますし（どれだけ縮小すればよいかもSLIMで計算できます）、フルスペックでリリースするのであれば、開発期間を延長しなければなりません（開発期間も算出可能です）
と根拠のある反撃、解決策の提案ができます。
SLIMの概要
SLIMは、ソフトウェア開発における見積もり法の1つで、パラメトリックス法をベースにしています。
アメリカの陸軍で長年にわたり、ソフトウェア開発の管理を担当してきたローレンス・H・パトナムが、世界の6300以上のソフトウェア開発プロジェクト（もちろん、日本のプロジェクトも入っています）を分析し、「工数（コスト）」「開発期間（月）」「機能総量（規模）」「（プロセス）生産性」「品質」の5つの相互関係を表す式（ソフトウェア開発関係式）を求めました。
SLIMには、「5つの開発要素の相互関係が算出できる」「最短開発時間を計算できる」という大きな特徴があります。
今回は“5つの開発要素”を中心に話を進めていきます。
ソフトウェア開発関係式：5つの開発要素の相互関係を表す
ソフトウェアの開発において、工数（コスト）、開発期間（月）、機能総量（規模）、（プロセス）生産性、品質は、互いに複雑に関連しています。
これら5つの開発要素のうち、1つ以上が変化すると、他の要素にどんな影響が出るのか。これを分析するのは簡単なことではありません。例えば、6人×12カ月＝72人月だからといって、12人×6カ月＝72人月にはなりません。12カ月の工期を6カ月に短縮する場合、恐らくこんな極端な短縮は不可能でしょうが、もし、無理やりやるとしたら、ブルックスの法則により最低4倍の24人が必要となります。
フレデリック・ブルックスが、著書、『人月の神話』に書いた現象、傾向、教訓をまとめて「ブルックスの法則」と呼びます。人月計算に関し、「人数、期間、コストのいずれかが10％以上短縮された場合、残りのいずれかに『n2分の1の法則』を適用する必要がある」と述べています。すなわち、開発期間を半分に短縮するには、人数を4倍に増やさねばならないことになります。コストは24人×6カ月＝144人月で、当初の2倍掛かります。人数、期間、コストの関係だけではなく、開発規模や生産性も含めた複雑怪奇な関係をきちんと表したのが、以下の「ソフトウェア開発関係式」です。
以下、各変数、定数を解説します。「何だか複雑そうで読むのが面倒」と思う人は、品質とプロセス生産性の項を見るだけで構いません。もっと面倒な人は、各変数の単位だけを見ておいてください。
（1）工数（単位：人月）
工数とは、対象ソフトウェアを開発するのに必要な人月のことです（単位はそのまま「人月」です）。ソフトウェア開発のコストは、人件費がほぼ100％と見なしてよいため、工数がコストに直結しています（1人月を100万円、1万ドルと見積もることが多いようです）。
（2）β（単位：なし）
パトナムは、βを「システム統合、テスト、構成管理などの作業の能力を表すパラメータ」としています。いかにもそれらしい定義ですが、要は「6300のプロジェクトから採集したデータを1つの式で表現しようとすると、式とデータが符合しない箇所が出てくる。そのため、βはそれらをまとめて吸収する“緩衝領域”的な変数」といえます。一種の“苦し紛れ”定数といえますね。
パトナムによると、βはシステムの規模が大きくなり、複雑度が高くなると大きくなる性格があるそうです。ソフトウェア開発関係式では、表1のように、ソースコード行数と関連付けてβの値を定めています（中間値は案分計算で求めてください）。
| プログラムサイズ（KLOC） | 5〜15 | 20 | 30 | 40 | 50 | 70〜 |
|---|---|---|---|---|---|---|
| β | 0.16 | 0.18 | 0.28 | 0.34 | 0.37 | 0.39 |
| 表1 βの値の目安 | ||||||
（3）開発時間（単位：月）
開発時間とは、開発に必要な期間（通常は、要求仕様定義からテスト完了までの期間）のことで、単位は「月」です。
（4）機能の規模（単位：LOC）
機能の規模とは、プログラムのサイズのことで、単位は「LOC（Lines of Code：ソースコードの行数）」です。FP試算法でFPを求めた場合、ソースコードの行数に変換する必要があります。変換係数の目安として、1FPは、COBOLで記述すると100行、C++では50行、Visual Basicでは70行、Javaでは35行といわれています。
（5）ある品質レベルで（単位：なし）
このソフトウェア開発関係式で、一番苦しいのがこの要素です。ソフトウェア工学の最大のテーマが“品質”ですし、どんなソフトウェア開発でも、品質を無視することはできません。そんなわけで、ソフトウェア開発関係式に（無理やり）品質を含めてありますが、実際には無視して構いません。
SLIMでの品質の高低は、ソースコード行数を調整することで表現しています。すなわち、以下のような考え方をしています。
- 品質はタダではない（There is no free lunch）。高品質ソフトウェアを開発しようとすると、デバッグやテストなどを真面目に実施する必要がある
- 品質確保関連の作業が増えるため、高品質ソフトウェアを開発するには、その分、コストや工数が余分に掛かる
- かといって、コスト（あるいは工数）の中に品質を入れるのはしっくりこない（カッコ悪い？）
- バグはソースコードの中に存在し、品質も同様である。それならば、高品質ソフトウェアと低品質ソフトウェアの違いをソースコード行数の違いで表現するのが自然だろう
- 通常品質でソフトウェアを開発したら100KLOCになったとすると、同じ製品を高品質で開発するには、例えば、130KLOCのソフトウェアを開発するのと同じ工数がかかることにすればよいのではないか
以上から、SLIMでは、「品質の高低」は、ソースコード行数（生産量）を調整することで表現しています。そのため、ソフトウェア開発関係式は、正確には、“5つ”の開発要素の関係を表す式ではなく、品質以外の“4つ”の要素の関係を表す式といえます。
（6）プロセス生産性（単位：なし）
これも少し分かりにくい概念ですので細かく説明します。
通常の生産性は、個人や組織が単位時間当たりで、どのくらいの生産物を作ったかを表し、例えば、“1087行／人月”のように表現します。生産性は、開発対象ソフトウェアの規模、必要な工数、開発期間にかかわらず一定の値になります。
一方、SLIMで使用するプロセス生産性は、開発組織全体の生産性を示し、以下の式で算出します。つまり、工数や開発時間により、プロセス生産性の値は変化します。
この式から計算すると、プロセス生産性は指数関数的に増加するため、非常に大きな数になり扱うのが大変です。そこで、以下の近似式を適用し、線形増加する「生産性指標」に変換して数値を小さくします。実際の見積もり計算では、この近似式を使います。
プロセス生産性と生産性指標の関係を表2で表しました（強引に線形化したので、近似式の値とズレが出ています）。また、生産性指標と、CMM（Capability Maturity Model）のレベル（1〜5）の関係を図1に示します。
平均的な生産性指標は“13前後”といわれています（13なら、悪い数字ではありません）。そのため、過去の開発データがなくて生産性指標を計算できないときは、取りあえず、“13”を使ってください。プロセス生産性の値が“1”違うと、他の開発要素の大きな影響が出ますので、かなり慎重に算出する必要があります。
基本的に、SLIMの見積もりで必要なことは、全てここで解説しますが、各パラメータの詳細を知りたい方は、拙訳、「初めて学ぶソフトウエアメトリクス 〜プロジェクト見積もりのためのデータの導き方」（著：ローレンス・H・パトナム、ウエア・マイヤーズ／翻訳：山浦恒央、日経BP社,2005年）を参照ください。
今回は、SLIMの基本となるソフトウェア開発関係式に出てくる“5つのパラメータ”について解説しました。定義ばかりで少し退屈な説明が続いたかと思いますが、次回は、ソフトウェア開発関係式を実際に使用し、工数（コスト）、開発期間（月）、機能総量（規模）、プロセス生産性の具体的な算出法を解説します。ご期待ください！ （次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
関連キーワード
デスマーチ | 組み込み開発 | 組み込み開発プロセス改善 | 組み込み開発の混沌から抜け出そう | 現場の声からプロセス改善を深掘りする | 山浦恒央の“くみこみ”な話 | バグ | 開発プロセス | ソフトウェアテスト | システム開発
Copyright © ITmedia, Inc. All Rights Reserved.
デスマーチ・プロジェクトでの正しい手の抜き方