飯泉 純子　IIZUMI Junko
大槻　繁　OTSUKI Shigeru

本論文は、エンジニアリング・マインド誌Vol.5 特集「ソフトウェア経済学」に掲載されたものです。

人月からの脱却

　世の中の人々が、全て、独立事業者だとしましょう。全ての経済活動には「契約」が必要になるでしょう。それぞれの事業者の仕事の価値を測り、その価値に基づいて市場で価格が決まり、対価（報酬）が支払われます。

　そうすると、システムを開発する時に、人々が集まり、役割分担をし、仕事を定義し、それぞれの対価を契約として決めることになります。システムが完成した場合にのみ、その全ての対価を、成功報酬として受け取ることにすれば、「人月」の話はなくても済ませることができます。

　システム開発の受発注も契約ですが、それに関わる全ての人々との間にも契約があります。その全ての契約を毎回結んでいたら、世の中契約だらけで、本来の価値を生み出す活動ができなくなってしまいます。そこで、企業とか、団体にまとめて、組織間の契約を毎回結び、個人との間は、組織と個人との通常は雇用契約の形になってきました。サラリーマンというのが気楽な稼業かどうかはわかりませんが、組織に所属すると、毎月、給料が個人に支払われることになります。つまり、雇用契約が「人月」の原点なのです。これを、組織間の契約に持ち込むので、いろいろな問題がでてきてしまいます。

　極論すると、システム発注側が、システム開発企業の社員が怠けて月給泥棒するリスクを負ってしまう事態になっています。

契約と報酬の考え方

　システム開発に関わる調達側と開発側との契約はどのようにすべきなのでしょうか。原理原則からいうと、調達側は、そのシステムを活用したビジネスに関するリスクを負い、開発側はシステムの開発そのもののリスクを負うということになるでしょう。

　問題なのは、システムがものを買うような単純なものではなく、複雑で、時間とともに状況も変わり、目に見えず、予測も難しいので、単純にシステム開発のリスクを一方に押し付けるわけにもいかないことになります。

図１　契約と報酬の考え方

　契約に関する基本的な考え方を図１に示します。発注側は、あらかじめシステム開発の予算を決め、実際にかかった実績額との差を、つまり、うまくいった場合の余剰、あるいは、うまくいかない場合の不足の、全てを受注側が負う場合を完全定額契約(Firm Fixed Price)といいます。逆に、全てを発注者が負う場合を実費償還型契約(Cost Plus)といいます。それぞれにインセンティブや報償を付加する方式もあります。先進的、実験的なもの、単純なものといったシステム開発の種類によって適切な契約形態を選択していく必要があります。

アジャイルプロセスでの契約の改善

　発注者と受注者（開発者）との関係において、アジャイルな開発が目的とするのは、発注者が欲しいものを受注者がタイムリーに開発・提供することです。

　アジャイルプロセスの実開発への適用における障害の一つに契約書がありました。これまでウォーターフォール型の開発プロセスを前提とした契約書では、アジャイルプロセスで典型的に行われる繰り返し型の開発が難しかったのです。ウォータフォールプロセスが前提であることが明示的でなくても、例えば、成果物としてシステムやソフトウェア全体の要件定義書や機能仕様書といった「仕様書」の納品・検収がまずあり、それを満足するソフトウェアを開発（プログラミング、テスト）して納品すること、という内容が契約書に記載されているとしたら、その契約の元にアジャイルな（俊敏な）開発をすることは非常に難しいと思われます。

　もう一つ、従来の契約書には問題がありました。それは、契約書というのは概ねそういうものですが、基本的なスタンスが「性悪説」であるということです。発注者と受注者が対峙する関係にあることが前提となり、双方ともに事前にあらゆる事柄を約束しておくという、守りが中心の内容となっています。

　このような問題に対する議論がアジャイルプロセス協議会　見積・契約ワーキンググループにて行われ、アジャイルプロセスでの開発を可能とする契約に対する次のような提言をまとめました。

• 両者が運命協働体であることを宣言
• 仕様は（両者合意の上で）いつでも見直し可能
• 仕様の確定は迅速な承認を義務化
• 実装した成果物をショートリリース可能にする
• 相手方の問合せに迅速に応答することを義務化
• 納品物・中間提出物は開発プロセスを規定しないように考慮
• 開発プロセスなど、契約書本文に記述されていない開発条件を記載した「受注仕様書」を添付

見積り技術の体系

図２　見積り技術の種類

　ソフトウェア開発における見積り手法は、開発の初段、プロジェクトの遂行、開発後の評価等の局面で、さまざまなものが複合的に使われています。図２は、代表的な見積り技術を整理したものです。図の二つの軸は、見積り担当者の力量への依存度が高く属人性が高い「主観的」なもの、第三者の納得性の高い「客観的」なものという横軸と、開発の世界の外側から評価が可能な「外部的」なもの、開発の実装や体制といった情報に基づく「内部的」なものという縦軸になっています。調達側や第三者評価で使え、かつ、論拠がしっかりしたものという観点では、図の右上のもの程、望ましいということになります。

　今後、見積り手法に使用される機会が増えると思われるファンクションポイント法(Function Point Analysis)とCOCOMO(COnstructive COst MOdel) の概要を述べます。

ファンクションポイント法

図３　ファンクションポイント法の概念

　ファンクションポイント（以下、FP）はソフトウェアの機能規模を表す尺度です（図３）。FP法はFPを計測する手法で、ユーザが識別できる単位で当該システムの

• 入出力機能：外部入力、外部出力、外部照会
• 当該システムが維持管理するデータ：内部論理ファイル
• 当該システム内の機能が利用するが外部システムで維持管理されるデータ：外部インタフェースファイル

を識別し、それぞれに割り当てられたFP値を集計することによってシステム全体のFP値を算出します。

図４　ファンクションポイント法の利用局面

　FPに基づいて、ソフトウェア開発のさまざまな局面の見積りを行うことができます（図４）。ただし、そのためにはFPと見積りたい対象との関係を表すモデルが必要です。例えば、FPから工数を見積るためには、FPと工数の関係を表すモデルが必要です。線形式はモデルの一つで、FPと工数の関係が比例関係であると捉えたモデルです。その中でも最も単純なものが

工数 ＝ 生産性係数 × FP

です。生産性係数の単位は、求めたい工数の単位によって異なります（例：人月/FP、人時/FP）。また、生産性係数の値は、システムの規模レベルや対象業務などシステムやプロジェクトの特性によって異なります。

　FPに基づく見積りの利点の一つは、システムのユーザが識別できる機能やデータに基づいているため、ユーザの目に触れないプログラムソースコードの行数と比較すると、ユーザと開発者との間で合意がしやすいことです。

COCOMO

図５　XOXOMOの概念

　COCOMOは開発ソースコードの規模（SLOC：Source Lines of Code）に基づいて工数と期間を算出するモデルで、規模と工数の関係を線形モデルではなく、べき乗モデルで表しています。べき乗モデルであらわす利点には、規模が大きくなるほどに生産性が下がるという経験的な現象を一つのモデルで扱うことができることが挙げられます。

　COCOMOの基本モデルは

　　工数 ＝ A ×（規模）^B，期間 ＝ C ×（工数）^D

　【単位】工数：人月、規模：KSLOC、期間：月
　　A：生産性係数、B：規模指数、C：期間係数、D：期間指数

となります。

　COCOMOでは、基本モデルをベースとして、システムやプロジェクトの特性による変動を反映させるための変数を複数用意しています。COCOMOは最初1981年に発表されましたが、その後1997年にバージョン2（COCOMO 2.0、現在の表記はCOCOMO II）が発表されています。最初のバージョンでは工数を直接変動する要因となるコスト要因（Cost Driver）のみでしたが、バージョン2では規模を変動する要因となる規模要因（Scale Factor）も提案されています。規模要因としては5項目用意され、開発する組織の対象領域での経験度や開発プロセス成熟度、利害関係者の協力度合いなど、組織面が主に評価の対象とされています。コスト要因としては17項目用意され、プロダクト、プラットフォーム、人員、プロジェクトの側面から評価します。プロジェクトの側面の中には、開発期間に対する制約も含まれており、標準的な開発期間の75％よりも短縮することはできないことが仮定されています。

プロジェクトデータ蓄積の意義

　FPに基づく見積りや、COCOMOを利用した工数、期間の見積りを行うためには、それぞれのモデルに現れる係数や指数の値を定める必要があります。係数や指数の定め方としては統計解析の手法を利用することになりますが、そのためにはプロジェクトデータの蓄積が必要です。

　第三者の納得性の高い「客観的」な見積り手法とは、より多くの、そして対象プロジェクトと特性の似通ったプロジェクトデータに基づき、見積り時に必要となる判断の基準が明確である手法であると考えています。そのため、プロジェクトデータの蓄積が必要で、判断基準が示されているという点で、ファンクションポイントベース単純推論やCOCOMOを図２において他の見積り手法と比べて「客観的」なものとしてマッピングしています。

　ファンクションポイント法やCOCOMOは、提唱されたのが30年程前です。多くの人がデータを採取し、モデルを改善し、知見を積み重ねてきています。こういう地道な継続的な努力が少しずつ実ってきています。組織やチームにおいても、データを採取し、それを将来の予測のために生かすというのは、競争力を高めたり、交渉やマネジメントのためにも有効な方法です。

　インクリメンタル開発で、各段階での生産性を計測していけば、次の段階の予測精度を高めることにも活用することができます。

サービスや製造業への展開

図６　ソフトウェア経済学のサービス、ものづくりへの展開

　『ソフトウェア経済学』という名前がついていますが、研究対象は、図６に示すように、基本的に知識主導産業のいくつかに広げていく必要性を感じています。ソフトウェアの本質的困難として掲げられている複雑性、順応性、不可視性、変更可能性だけでも難しいのですが、今後出現してくる領域は、もっと難しい特性を備えていることでしょう。

　最近は、サービス産業の台頭もあってサービスエンジニアリングやサービスサイエンスというのも提唱されています。SOA(Service Oriented Architecture), SaaS(Software as a Service)と世の中「サービス」だらけです。サービスの本質的な特徴は、以下のように言われています。

• 同時性(simultaneous)：生産と消費とが同時に起こること
• 消滅性(perishable)：蓄積がきかないこと
• 無形性(intangible)：見えないこと
• 変動性(heterogeneous)：誰が、誰に、いつ、どこで提供されるかに左右されること

サービスを提供する手段としてソフトウェアも活用されることになりますから、ますます問題が難しくなると思われます。

　製造業についても、産業全体の中でものづくりという意味でソフトウェアは重要な位置を占めています。ハードウェア生産とソフトウェア生産との原理的な差異は、ソフトウェアには「製造」がないということです。「設計」が全てであり、それを量産することはクリック一つでコピーができあがることからも容易に想像がつくように、ほぼ無視できる事項です。しかし、ハードウェア製品の製造においても、ソフトウェアの占める量が急速に増えてきており、ものづくりの文化と、ソフトウェア開発との文化があまりに異なるがゆえに、いろいろな問題もでてきています。筆者は、未だその本質的特性が何というところまで見切れていませんが、おそらく、並行性(concurrency)、市場性(makete oriented)、有形性(tangible)、系列性(product line)といった特性がキーになると予測しています。

これからの検討課題

『ソフトウェア経済学』の構想を簡潔に述べました。まだ着手したばかりであり、今後の検討すべき事項も山積しています。いくつかの方向性を以下に掲げておきます。

• 産業論・組織論で提唱されている「モジュール化」は、この分野の検討に有効であると考えています。複合的企業間連携、アウトソーシング、組織統廃合、さらには社会制度との関連も分析を進める予定です。
• 企業価値算定、金融工学の知見の適用。特に、市場での価格決定の理論や、リスクの取り扱いについて整備していきます。
• バランススコアカード、企業戦略論は、ソフトウェアに関連した組織体では、経営層から実務層にいたる一貫した指針を与え、経済合理的な判断を促すという意味でも活用できると考えています。
• アジャイルプロセス、ソフトウェアセル生産、ソフトウェアプロダクトラインといった新しい開発パラダイムについても、費用対効果、コスト、市場価格等の観点でその有効性を説明できる論拠を『ソフトウェア経済学』が与えられるものと確信しています。

　『ソフトウェア経済学』は、まだまだこれからの研究領域です。おそらく数十年のレンジで取組んでいかなくてはならないものだと思います。大学の先生は開発の現場からは遠いですし、現場のエンジニアの方々は開発技術以外のところまで思いをめぐらせる余裕もありません。しかし、皆が何かおかしい、何とかしなくてはならないと感じていることを、素直にまとめてみて、方向性を示したものが『ソフトウェア経済学』なのです。

　これは一つのムーブメントです、この小論で取り上げたような話題に興味がある方々は、どんどん自由に探求をし、組織を超えたコミュニティに参加し、発表したり議論していくと、ほんものの成果が見えてくると思います。それこそが、エンジニアマインドともいうべきものではないでしょうか。

　経営論の祖であるピーター・ドラッカーがいうように、知識主導社会は既に始まっています、ビジネスもシステムも経済的、社会的な意義も変貌していきます。そして、「ソフトウェア経済学」そのものも、どのような名前が冠されようと、多層コミュニティで分散的に進められていくことでしょう。

■