Watcher_20060827_Win.pdf

　『ソフトウェア経済学』、どこかできいたような、でもなんか新しそうな響きの言葉でしょう。
　近年、産業パラダイムも、知識主導型へ急激に移行してきています。ものづくりからサービスへ、グローバル化・自由市場の浸透、ビジネスとシステムとの一体化もすすんでいる中で、社会/経済的な活動を説明する新しい理論が望まれています。
　ソフトウェアは知的活動の成果です。社会になくてはならない存在になっており、人間の経済活動の大きな部分を占めているにもかかわらず、それを支える理論が不十分なのです。
　本論文では『ソフトウェア経済学』という研究・技術領域を提唱し、その一つの説明事例として「コスト分析手法」と「ソフトウェア資産評価」をとりあげます。

　ソフトウェアに関わる経済活動は、ますます重要になってきています。家庭でもワープロ、表計算、メールソフトなどのパッケージ製品が日常的に使われています。実際に対価も払っているでしょうし、バージョンアップの知らせなんかもきて、ソフトウェアってお金がかかるという実感もあるでしょう。企業活動でも、いわゆるIT投資という名のもとに、ソフトウェア開発に莫大な資金が投入されていますし、ソフトウェアなしで企業活動そのものが存続できなくなっています。
　さほど重要な割に、ソフトウェアの値段が適正かどうか判断するよりどころはあまりに希薄です。企業が開発ベンダーやソフトハウスに開発を依頼する場合に、その契約額の妥当性の論拠はどこに求めればよいのでしょうか。
　冒頭の図は、『ソフトウェア経済学』の全体像を示しています。経済学は、近代資本主義における「富」に関する学問であり、ソフトウェアに関わる経済活動を説明する原理のよりどころとなり得る分野です。経営学の領域は、利益追求や社会貢献を目的とした企業・組織体に関する方法論を主として扱っています。そして、ソフトウェアエンジニアリングは、ソフトウェアの開発・保守、アーキテクチャ、プロセス、プロジェクトマネジメントに関する知識体系です。
　これ等三つの学問・技術領域を背景として、それ等を統合し、『ソフトウェア経済学』では、ソフトウェアに関わる以下の事項を明らかにしようと考えています。

• ソフトウェア、システム、サービス等の無形財の利用、開発、保守、運用、破棄の総合的な社会/経済的な振舞い
• 市場、組織、部門、プロジェクト、チーム、個人の一貫した社会/経済的な振舞い
• 価値、価格、費用（コスト）の定式化と、これ等の間の関係

　図は、近年の『ソフトウェア経済学』に影響があると思われる主要な理論提唱、出来事をまとめたものです。ソフトウェアエンジニアリングの発祥は、1968年のNATO会合といわれています。以降、さまざまな方法論や手法が提唱されています。70年代はプログラミングを系統的に行うことや、計算に関する基本的な原理が数多く生まれました。80年代は、方法論や開発プロセスに関心が寄せられるとともに、プロジェクトとして開発行為を捕らえ、データを収集・分析する定量化アプローチも出現しました。90年代には、知識体系を標準化し、経営的視点、運用といったより広範な取組みがなされました。90年代後半からインターネットが急速に普及したここともあいまって、今世紀に入り問題把握、要件定義、ビジネスプロセスと開発プロセスの統合等に関心が集まっています。
　IBMの巨大なオペレーティングシステムの開発に携わったF. P. Brooks Jr.は、1975年の著作『人月の神話』の中で、ソフトウェアに関する本質的困難として複雑性、同調性、不可性、可変性をあげています。次図にこれ等の説明と、各年代、社会的要請、視点を整理したものを示します。筆者の整理は、大局的には本質的困難をそれぞれの時代で一つ一つ解決してきたように見ることもできるということです。無論、2000年代に入ったからといって、複雑性、同調性等の観点が不要になったわけではなく前提となったと見るべきで、新規の主題が可変性への対応となっていることです。

　ソフトウェアの領域に、建築やハードウェア製造の技法・ツールやマネジメント手法を援用する場合には、上記のソフトウェアの本質的困難をどういう局面で解決しているかという視点で評価する必要があると考えています。
　技術開発は時間を要するものです。ファンクションポイント法やCOCOMOは、現在各方面のコスト分析や見積りの現場で使われていますが、これ等が提唱されたのは1980年前後です。その間、プロジェクトデータの収集・分析、モデル式の洗練化等の地道な努力の積み重ねがありました。90年代になり可視化の要請もあり、調達の透明性を確保したり、見積りの第三者評価等に両手法は有効と考えられています。最近の変化対応の要請という観点では、アジャイルプロセスやインクリメンタル（段階的拡充）開発といった新しい開発プロセスでの分析手法が要求されていますし、ユーザ企業と開発企業という調達プロセスの中でも、見積りの算出、説明、交渉といった場面に応じた手法の活用方法を開発していく必要があります。
　ビジネスプロセスと開発プロセスとの親密な連携もすすんできており、コスト分析手法も規模と工数・期間の関係分析だけでなく、その周辺の活動を統一的に扱える体系に発展させていく必要があります。次図は、ソフトウェアに関わる価値、価格、費用（コスト）に関する関係を端的に表したものです。

見積り技術の全体像

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

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

　近年、ファンクションポイント法（以降「FP法」と呼びます）の活用はいろいろな局面ですすんできています。FP法そのものは、システムの機能の大きさを表す尺度に過ぎませんが、開発世界の外部から観測可能である点で優れています。図６に示すように、システム全体の外部的な機能性に着目し、システムの規模を、データの集合（内部論理ファイル、外部インタフェースファイル）と、入出力（外部入力、外部出力、外部照会）によって表す方法です。近年、システムをゼロベースで開発することは希ですし、パッケージやコンポーネントを活用して実装していく場合に、規模を開発コード行数(LOC: Line Of Code)で把握するのは難しくなっていまから、FPで規模を把握するのは有効といえます。
　FPは、建築でいえば「坪単価」のような活用法が考えられます。システムのFP当たりの開発費、保守・運用費といったものは、経営指標としても有効なものです。次節で述べる不良資産の把握についても、ある企業の所有するIT資産が全体でどれだけのFP数で、不良資産化しているものがその内の何%であるといった表現も可能になります。

COCOMO

　見積り技法の全体像の図の一番右側に位置づけられるCOCOMO　(COnstructive COst MOdel)は、規模から工数や期間をモデル式によって算出できる方法です。1981年のB.Boehmの著作, ”Software Engineering Economics”によって提唱され、以降継続的に研究が進められてきています。上図は基本的な考え方の概要図を示しています。
　COCOMOの特長、および、優れている点は、以下の通りです。

• ソフトウェア開発が人間による「記述」の活動であるという普遍的な考え方に基づいている
• 記述の規模から、工数、および、開発期間を算出する関数（算術式）を提示している
• 規模が大きくなるとマネジメントオーバヘッドを生じ、コストが増大することを考慮している
• 開発に関する変動要因２２種（規模要因５種、コスト要因１７種）を定義しており、的確にコスト分析に反映できる

コスト算出の関数の概要は、以下の通りです。



今後のコストモデルを整備していく際に重要になるのが、母体の扱いと時間概念の導入と考えられます。これを以下に簡単に描写しておきます。



とした場合、COCOMOは、次のように定式化できます。



　これを母体がある場合に拡張すると、



とした場合、母体のある場合の定式化は以下のようになります。



　さらに、インクリメンタル開発プロセスへ拡張してみましょう。



　インクリメンタルの各段階がすすむというのを時間の推移をみなし、連続的な時間tを導入すると次のようになります。



このような定式化を通して、時間当たりの開発量（生産性）の扱いを、COCOMOの延長線上でとらえることが期待できます。

費用対効果

　費用対効果という視点でも、この時間の概念の導入は有効です。上図は、通常のウォータフォール型の開発の費用と効果の時間推移を表しています。開発に関する資本投下の判断には現在価値評価法(DCF: Discounted Cash Flow)を用いた手法を適用することもできます。一般的に運用フェーズに入ってから保守・改変の費用は初期段階では安定していますが、経年劣化がすすんだ場合や、ビジネス上の要求から改変の比率が増えて費用が増大し臨海点に達していくことが多いようです。
　下図は、アジャイル開発等で用いられているインクリメンタル開発を行った場合の時間推移です。小さく始めて、状況を見て、段階的に資本を投下していくことになります。ビジネス上の要求で撤退といった判断もしやすく、こういった判断にはオプション理論等の金融工学の分析手法が適用されることもあります。

　前節で述べたコストモデルは、個々のプロジェクトに関するもので、仕様が与えられた場合に、これを開発するための工数や期間を求めるものです。一方、組織や企業体という観点では、複数のプロジェクトがあり、定常的に開発活動が推進されています。製造業の工場でもソフトウェア開発は重要な活動で、組織全体での最適化がのぞまれています。特定の市場分野に対してあらかじめ用意された方法を用いて、共通のコア資産から開発される、共通し、管理されている機能を共有するソフトウェア集約型システムは「ソフトウェアプロダクトライン」と呼ばれています。
　近年の経営環境においても、ストック型からフロー型へ移行してきており、業務全体の中からボトルネックを見出し改善する制約条件理論(TOC: Theory Of Constraint)も注目を集めています。
　このような状況下でソフトウェア資産を把握し、管理することは経済的・経営的な視点でも重要です。衝撃的なデータですが、日本の企業のIT資産の内、約１／３が不良資産化しており、年間経費面でもその半分が無駄な費用であるという統計データも報告されています。さらに、いくつかの解析の結果、プログラムコードのクローン率（コピー/重複）は１／４程度に達していることが多いようです。

　不良資産を破棄し、保持しているソフトウェア資産を良構造に保っておくことは、基本的な対策の一つといえるでしょう。上図に、この対策の概要を示します。不良資産を特定し破棄するためには、システムやアーキテクチャを分析し、利用状況、活用状況を把握しておく必要があります。また、良資産に対しても、それをよりよい構造に変換するには、リファクタリング、部分的な再構成・再設計等の対策をとっていく必要があるでしょう。

　上図は、初期母体量に対して毎年20%の追加・改変を行う場合の工数を、そのまま放置して母体構造が劣化していく場合と、リファクタリングによって母体量も１割程度低減して全体構造を良構造に保ち続けた場合の比較をCOCOMO型のコストモデルでシミュレーションしたものです。初段ではリファクタリングの工数が上積みされますが、途中で逆転しますし、工数増大のカーブも前者が累乗的に増加するのに対し、逆のカーブで工数が爆発しないのが見てとれます。

　ソフトウェアの本質的困難の一つである「不可視性」は非常にやっかいな課題です。前節で述べたソフトウェア資産も、多くの企業では全貌を的確に把握をしていないようです。まして、その不良資産化状況や、構造の良し悪しを把握するのは困難を極めています。
　こういった課題解決のきっかけになるものとして、まずソースコードを対象とした解析が考えられます。次表に、標準的な品質指標の中からソースコード解析によって把握可能であるものの一覧を掲げています。実際に、モジュール性（結合度）、簡潔性（クローン率等）は、見積り分析手法の節で述べたコスト分析手法のコスト要因として活用することができます。

　こういった客観的な指標値は、リファクタリング（ソフトウェアの機能や振舞いを保持しながら良構造に変換すること）や再構成・再設計の効果を予測・評価するのに活用できるばかりでなく、組織外へのアウトソーシングの管理指標としても利用することができます。下図に、一連のソースコードクリーニングのプロセスを示します。

　ソフトウェア開発・保守・運用に対する施策は、上記のようなライフサイクル的な視点を含め、大きく以下の３点に集約されます。

• 良構造化：不良資産を破棄し、ソフトウェア資産（母体）を良構造に変換・保持すること
• 自動化：ツール活用やプロセスの最適化によって、誤りを減らし、作業を効率化すること
• 抽象化：人間の知的活動に使う言語や開発環境の抽象度を上げること

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

■