ソフトウェア開発生産性のジレンマと，さらなる調達改革への期待

　ソフトウェア開発生産性の向上に資するイノベーションが、個々のプロジェクト単位でみると失敗リスクを増大させる懸念がある。そのことが、失敗を忌避しがちな政府のIT投資において、新技術導入の阻害要因となる懸念がある。

　本稿ではまず、ソフトウェア開発生産性の向上がプロジェクトの失敗リスクを増大させるメカニズムを説明し、イノベーションの導入によってIT投資の投資効果を最大化するために必要な政府の調達改革について、米国での実例も踏まえて展望する。

ソフトウェア開発は失敗の歴史

　ソフトウェア開発には失敗がつきものである。企業におけるソフトウェアの開発・導入を数百例調査した結果によると、ソフトウェアプロジェクトの6つの内5つは失敗と見なされており[Johnson 1995]また約1/3のプロジェクトが途中で中止されている。残る2/3のプロジェクトは、予算の倍の経費を投じ、予定の倍の時間を費やして、やっとのことでソフトウェアを完成させている[Brown他 1998]という。国防総省の報告書によれば、1999年の米国の官民合わせたソフトウェア開発プロジェクトのうち、31%が途中でキャンセル、51%において予算とスケジュールがオーバー、その上完成品の61%については顧客の初期要求を満たしていないという結果が出ている。[岸本 2003]ソフトウェア開発環境の生産性は向上し、ソフトウェア工学や品質管理手法が洗練された一方で、今なお多くのソフトウェア開発プロジェクトで失敗が続いている理由は多岐に渡るが、ここでは特にシステムのオープン化に伴う、継続的なイノベーションに起因する問題に着目したい。

ソフトウェア開発生産性のジレンマ

　システム開発の生産性や品質を上げるための技術革新は相次いでいる一方で、システムの複雑化、工期の短縮も急速に進んでいる。同じ技術を繰り返し用いれば失敗の回避、予測精度の向上を期待できるが、情報技術は急速に進歩しており、新技術を導入する度にプロジェクトのリスクは高まる。それでも新技術の採用が進むのは、新技術の導入によるリスクにも増して、生産性や品質の向上による工数の削減を期待でき、イノベーションによる新しい価値を享受できるからである。

　一般に工数が大きいほどプロジェクトのリスクが増すため、新技術の採用によって工数を削減できれば、総合的にみてリスクは軽減できるはずである。しかし競争市場の下では、新技術ですでに実績を積んだプレーヤーと、これから新技術にキャッチアップしようというプレーヤーが混在している。前者のプレーヤーが新技術による生産性・品質の向上によるリスク減少分を価格に織り込んでしまうと、後者のプレーヤーは新技術の採用に起因するリスクを価格に転嫁できず、個々のプロジェクトでは新技術の採用に伴うリスクだけが残る場合もある。結果として継続的なイノベーションによってソフトウェア開発の生産性が向上する過程で、ソフトウェア開発・導入に失敗するリスクはむしろ高まるのである。

生産性・品質格差の拡大と、入札時における情報の非対称性

　ソフトウェア開発の生産性向上は、単にソフトウェア開発・導入に失敗するリスクを増大させるだけでなく、組織間の生産性格差を拡大させる。これは、既存技術の蓄積と比べ、新技術への適応は、個人・組織の能力差が大きいからである。

　例えば、米国ではオープン化の進んだ1990年から1995年の間で、高生産性組織と低生産性組織の格差が4:1から600:1にまで増大し、品質の格差も10:1から100:1に拡大している[Yourdon 1996]。ソフトウェア開発では一般的に、バグの発見、修正にかかる工数が大きな割合を占めることから、品質の低下は生産性の低下に直結してしまう。

　技術サイクルの短いオープンシステムでは、レガシーシステム時代のような取引実績などの指標では、入札参加者の生産性を適切に評価できない可能性が高い。競争によって価格が一定の範囲に収束する場合、低生産性組織はコストを価格に転嫁できず、無謀なリスクを取って価格競争に参加する可能性がある。また、そもそもリスク評価のできない営業やマネージャが、無理な条件で案件を受注してしまうケースも少なくない。

　こういったリスクを軽減するためには、広く使われているパッケージ・ソフトウェア等、品質の実証されたソフトウェア部品の活用や、IT版コンストラクション・マネジメント[大和田 2003]等の導入を通じて、コストと品質の透明化を図る必要があろう。

EAは重要だが「銀の弾丸」ではない

　日本政府はEnterprise Architecture (以下、EA)の導入を通じて、ITシステムの全般的な見直しを進めている。EAの全体最適化計画では、これまで手付かずだったレガシーシステムの見直しや、業務プロセスの文書化など、非常に重要な試みが行われており、その動向を注視している。

　EAの導入によって要求仕様や設計段階のコミュニケーションが円滑になり、問題を早期に発見することでリスクを軽減できることは実証されている。しかし、EAはあくまでIT投資をマネジメントするための手法であって、システム開発の技法ではない。あらゆるプロジェクト失敗のリスクを回避できる訳ではないし、リスクを最大限排除するような選択は、投資対効果でみても合理的でない可能性が高い。

米国にみる包括的なIT調達改革

　デビッド.L.マクルーア氏(現 米国行政改革協議会（CEG）電子政府担当副理事長)によると、米国でEA導入が効果を上げた背景としては、 連邦調達合理化法や文書業務削減法、クリンガー・コーエン法といった法令整備の他、ITスタッフの大規模な入れ替え、パフォーマンスベースの請負契約や、調達サイクルの短縮といった包括的な調達改革の一環のなかで、EAをリスク軽減ツールとして用いたことが大きいという。

　パフォーマンスベースの請負契約では、作業指示書ではなく目標明細書を重視するため、政府のリスク性向と関係なく、請負業者の責任でイノベーションを導入できる。調達サイクルを短縮すれば、システム起案時には最新だった技術が予算執行時には陳腐化しているといった事態を防ぐことができる。いずれも、イノベーション活用に有用な施策といえる。

　これらの包括的な施策からEAだけを切り出して適用しても、米国のFEAと同様の効果が得られるかどうかには疑問が残る。我が国でも経済産業省主導で2001年から2002年にかけて「ソフトウェア開発・調達プロセス改善協議会」で政府の調達プロセス改革について議論され、複数年度調達など成果も上がりはじめている他、CIO、CIO補佐官の採用なども進んでいる。

　しかし米国が1993年から実施したIT調達改革は、よりドラスティックかつ包括的である。日本でもEA導入を一里塚に、調達サイクルの短縮や、パフォーマンスベースの請負契約の導入など、さらにIT調達改革が進むことを期待している。

リスクを伴うイノベーションの導入が円滑に進む制度設計を

　現状の調達改革やEAを巡る議論について、競争の導入によるコスト削減や、EA等の方法論の適用によってリスクを回避するといった論点こそみられるものの、リスクを伴うイノベーションの導入を促し、リスクを管理するという発想が乏しいことも課題といえよう。

　筆者も委員として参加した経済産業省「情報セキュリティ総合戦略策定研究会」では、情報セキュリティ対策について「事故前提社会システム」というコンセプトを打ち出した。事前に事故を予防することや、起きた事故に対症療法的に対応することばかりでなく、「情報セキュリティに絶対はなく、事故は起こりうるもの」との前提で、被害を最小化、局限化し、回復力の高い仕組みを構築する必要がある、という考えである。

　ソフトウェア・情報システムの調達においても同様に、「ソフトウェア開発・導入プロジェクトの失敗は起こりうるもの」という前提で、リスクを伴うイノベーションの導入を円滑に進め、プロジェクトの成否そのものよりも過程でのリスク管理に着目した行政評価制度や、プロジェクトの失敗から得られた知見を広く共有するなどの施策が必要ではないだろうか。

　例えば、リスク評価のできるITの専門家を政府内に持ち、調達プロセスに対して適切に関与することなどが考えられる。ここでは、プロジェクトが失敗した場合だけでなく、コスト削減や住民サービスの向上に資するイノベーションを導入しない場合にも、説明責任を求める必要があろう。

　また米国と同じように、政府のソフトウェア開発プロジェクトの失敗で得られた知見を広く公表し、ソフトウェア工学の進展に資することも重要である。失敗は失敗と認めなければ、ベンダーにモラルハザードを招くばかりでなく、同じ失敗を繰り返してしまう恐れもあるからだ。

　これは現行の調達制度や公務員人事制度だけでなく、そもそも失敗を忌避する国民性に深く根ざした問題であるため改革は容易ではないが、わが国が「世界最先端のIT国家」(e-Japan計画)を目指すのであれば、避けては通れない道のりではないだろうか。

　This work is licensed under a Creative Commons License.
RIETIサイト内の署名記事は執筆者個人の責任で発表するものであり、経済産業研究所としての見解を示すものではありません