ソフトウェア開発におけるパラダイムシフト自著書評『ソフトウェア最前線』 （2004年11月）
背景あるいは問題意識
我々の生活を支えている社会インフラの多くはコンピュータによって制御されている。たとえば、電話やインターネットなどの通信ネットワークはもちろん、金融システム、電力、ガス、公共交通機関などがコンピュータによって制御されている。また、マイクロエレクトロニクスの進歩によってコンピュータは小型化し、 身の回りのさまざまな機器に組み込まれるようになった。エアコン、炊飯器、洗濯機、ビデオから携帯電話、自動車に至るまで我々はコンピュータを内蔵した機器や装置に取り囲まれて生活している。さらに企業活動も製品の設計、製造、流通はもちろん、オフィス事務やさまざまなサービスの提供もコンピュータがなければ進まないような状況になっている。
間違いなく、我々の社会はコンピュータへの依存度を高めつつある。そして、これらのコンピュータの動作を決定しているものがソフトウェアであることを考えると、世界はソフトウェアに依存していると言っても過言ではない状況にある。
しかし、日本のソフトウェア産業の国際競争力は著しく低い。ソフトウェアの輸出額は輸入額の1%程度しかない。身の回りをみてもそれは実感できるだろう。パソコンのOS、アプリケーション・ソフトウェア、企業で利用されているDBMS、ERPなどの多くは外国製のソフトウェアである。また、最近、中国やインドなどがソフトウェア産業の育成に力を入れており、日本企業がソフトウェアの開発を海外に委託する事例が増えている。
おそらく、このままでは日本のソフトウェア産業はダメになっていく。高度な教育を受けた人材が主たる資源である日本にとってソフトウェア産業は重要な産業のはずである。日本のソフトウエアの競争力を高め、ソフトウエア産業を発展させるためにはどうすればよいのだろうか。生産性や質の向上を阻害している要因がどこにあり、どうすれば、阻害要因を取り除くことができるのだろうか。
それが、本書を書くことになった問題意識である。
本書の結論
本書の結論は次の5つである（結論に至る議論については是非、本書をご一読いただきたい）。
日本のソフトウェア産業が危機に瀕していることは、政府や学界、産業界も理解しており、ソフトウェア工学的見地から様々な取組みがなされている。しかし、ソフトウェア工学で問題がすべて解決するわけではない。特にプロセス成熟度モデル（CMM）の導入については、制度導入に要する全体コストと導入効果をきちんと評価すべきであり、拙速に進めるべきではない。（本書の第３章）
ソフトウェア開発で最も一般的に用いられているウォーターフォール・モデルは、スケジュールの遅延や予算超過のリスクが大きく、ソフトウェア開発には適していない。事前に綿密な計画を立て、決められたプロセスにしたがって包括的なドキュメントを作成して開発を進めるという事前合理性を重視した開発手法ではなく、変化への対応を優先し、個人の能力とチームワークを大切にしながら、動くソフトウェアによって進捗を管理するアジャイルな手法を採用すべきである。（本書の第4章）
ソフトウェア技術者の生産性は個人によって大きく異なる。したがって、優秀な人材を集めることこそがソフトウェア産業の生産性向上の近道である。しかし、ソフトウエア開発の現場は徹夜や休日出勤が日常化しており、ソフトウェア技術者はあまり魅力のない職業になっている。優秀な人材が集まらなければ、ソフトウェア産業の生産性はますます低下する。生産性の低下は、残業の恒常化と報酬水準の低下を招き、ますます優秀な人材は集まらなくなる。この悪循環をどこかで断ち切ることが必要である。（本書の第５章）
ソフトウェアの生産性と品質が悪化している原因の一つは、発注者（ユーザー）のソフトウェアに対する理解不足にある。特にカスタムメイドのソフトウェア開発プロジェクトが成功するかどうかは、ユーザーの強力がどれだけ得られたかに左右されることが多い。「店が客を育て、客が店を育てる」ように、よいユーザーがよいソフトウェア産業を育てるのである。（本書の第7章）
パッケージ・ソフトウェアの分野においては、真に創造的なソフトウェアを生み出す才能をもった天才を発掘することが重要である。歴史をみれば創造的なソフトウェアが成功したソフトウェアになっている事例は少ないが、ソフトウェアに内在するアイデアを特許によって保護することが可能になりつつあることを考えると、天才を発掘し、その能力をぞんぶんに発揮できる環境を整えることがソフトウェア産業の発展につながるだろう。そのために、まずは、千里の馬（名馬）を見抜く目を持った伯楽を探す必要がある。（本書の第6章）
この結論のうち、結論1から結論4までは強い関連がある（今から思えば、6章と7章は順序を逆にすべきだった）。それは、底流としてソフトウェア開発に大きなパラダイムシフトが起きつつあるからである。
従来型ソフトウェア開発手法の問題点
ウォーターフォール・モデルに代表される従来型のソフトウェア開発手法では、包括的なドキュメントが重視されてきた。これはソフトウェア開発に必要な知識や事柄は、形式知（文章や図面によって表現できる知識）で伝えることができるという前提に立っている。要求仕様書に基づいてソフトウェアの設計書が作られ、設計書に基づいてプログラムが作られる。従来型のソフトウェア開発手法では、それぞれのプロセスの主体は同一でなくてよい。一般的に、上流工程をSE（システム・エンジニア）が担当し、下流工程をプログラマが担当することが多い。これは、上流工程の成果を文書で下流工程に伝えることができるという前提に立っているからである。
しかし、この前提は間違っている。
要求仕様書や設計書を読み誤ったためにプロジェクトが大幅に遅延したり、予算超過を招いたケースはいくらでもある。重視すべきものは包括的なドキュメントではなく、実際に顧客が希望するとおり動くプログラムである。顧客から要求を聞き出して作成される要求仕様書は、100%顧客の要求を反映したものだと考えてはいけない。それは一つの「仮説」に過ぎない。その仮説を実証するには動くプログラムを作成して顧客の確認を行うことが必要になる。
また、従来型のソフトウェア開発手法では、欠陥のないソフトウェアを効率よく開発するために上流工程を重視する。それは欠陥を後で修復するより、最初から欠陥のないものを目指した方が合理的だという考えから来ている。実際、要求仕様に誤りがあった場合、要求定義段階で修正するコストを1とすると、設計段階での修正は3～6、コーディング段階では10と修正コストは増大し、受入テスト段階での修正コストは30～70にもなるという研究結果も報告されている。したがって、上流工程に優秀な人材をつぎ込み、綿密な計画と要求仕様書、設計書を作ることがプロジェクト成功の鍵だと信じられてきた。これは、ソフトウェア開発が事前合理性を追求できるものだという前提に立っているからである。
この前提も間違っている。
最近のソフトウェア開発では、事前に集めた情報や知識によってつくられた計画や設計が最善の解をもたらすことは少なくなっている。技術進歩や環境の変化によって顧客のニーズは絶えず動いているからである。特に最近は、定型化される前に業務のシステム化を進めるケースや、機器の最終仕様が決まらないまま組込ソフトの開発に着手するケースが増えている。こうしたケースでは、完全な計画を策定してから実行するのではなく、実行しつつ合理的な解を得るという事後合理性を追求すべきである。
「規律」から「アジャイル」へ
2001年2月、米国ユタ州スノーバードに集まったソフトウェア開発の専門家17名が「アジャイルソフトウェア宣言 (Manifesto for Agile Software Development) 」を発表した。
「アジャイル (agile)」とは「敏捷な、機敏な、機動的」といった意味をもつ単語であり、この宣言では「変化する要求に対し機敏に対応することによって定められた期間内に顧客が満足するソフトウェアを提供する」という意味が込められている。
このアジャイルソフトウェア宣言は、ドキュメントと事前合理性を重視する従来型のソフトウェア開発モデルとはまったく異なる価値観、世界観から生まれている。これは、アジャイルソフトウェア宣言の最初の数行を読めばすぐに理解できる。
我々は、自らソフトウェアを開発し、あるいはソフトウェア開発の支援を通じて、より優れたソフトウェア開発方法を見つけ出そうとしている。この研究を通じて、我々は次のようなものを重視するようになった。
プロセスとツールより、個人とその交流（対話）
広範囲にわたるドキュメントより、正常に動くソフトウェア
契約交渉より、顧客との協調
計画どおりに進めることより、変化に対応すること
誤解されると困るのだが、アジャイルだからプロセスやドキュメント、計画は不要だと言っているわけではない。引用したアジャイルソフトウェア宣言の最後の4行の左右に並べられたものはどちらも大切なのだが、右側に書かれたものをより重視するという意味である。
ある研究会でGLOCOMフェローの藤原洋氏（（株）インターネット総合研究所 代表取締役所長）から「アジャイルはインターネットと同じですね」との指摘を受けた。うかつにも気付かなかったが、まったくその通りである。ネットワーク・プロトコルの世界では、広範囲にわたるドキュメントとプロセスや計画を重視したOSIは姿を消し、ラフ・コンセンサスと動くソフトウェアによって変化に対応してきたTCP/IPが主流となった。
同じように、ソフトウェア開発の世界もアジャイルに変化していくのではないだろうか。ソフトウェア開発に関係する人々（特にソフトウェア企業の経営者）がこの変化に早く気付いて対応してくれれば、日本のソフトウェアの未来は明るくなるに違いない。
この記事が気に入ったらサポートをしてみませんか？