Hotwired 第2回　「ソフトウェア開発におけるパラダイムシフト」　（2004年11月）

「計画を立てそれを実行する」方式は正しいか

　現在、日本におけるソフトウェア開発プロジェクトの大半は、ウォーターフォール・モデルで行われている。ウォーターフォール・モデルとは、ソフトウェア開発の工程を(1) 要求定義、(2) 設計、(3) コーディング（プログラムの作成）、(4) テスト、(5) 保守の工程に分けて、それらを順に実施していくという手法である（図表1参照）。
　ソフトウェア開発に縁のない人にはピンとこないかもしれないが、簡単に言えば、最初にきちんとした計画や設計書をつくり、それに従って実行するという方法だと考えていただければよい。これは、作業は最初から正しく行った方が、後で修復するより効率的であるという考え方に基づいている。この手法を採用した場合、前の工程の成果物に従って後の工程を進めることになり、原則として前の工程の戻ることはない。
　計画をたてて実行する。実にシンプルで美しい。夏休み前に学校の先生から同じようなことを言われた記憶がある。
　たぶん、この方法が間違いだという人はほとんどいないだろう。
　しかし、本当に正しいのだろうか。たとえば、次の休暇旅行の計画を立てる場面を想像してほしい。厳密に「計画を立てそれを実行する」方式を実行すると、次のような手順になるだろう。休みを取る期間と旅行先を考え、利用する列車や飛行機の便を調べる。宿を決め、訪ねたい観光ポイントを選び、現地でやりたいこと、食事をする店をリストアップする。そして、分刻みの日程表を作成する。後はこの計画を逐次実行に移す。
　これはさすがに変だ。大雨や事故で交通機関ダイヤが乱れることもあるし、観光地が混雑していて予定どおり移動できないこともある。計画は必要だが、ほとんどの場合計画どおりに実施できるケースは少ない。計画というものは、実行しながら修正していくものではないだろうか。最初から詳細な計画を立てても無駄になることが多いような気がする。
　実際、現地に行かないと分からないことも多い。たとえば、地元の人に美味しい郷土料理のお店を教えてもらうこともあるし、思いもよらぬ観光イベントに出くわすこともある。それもまた、旅の醍醐味であり、充実した旅行をするコツでもある。
　旅行に限らず、仕事も人生も綿密な計画を立てて、それがそのまま実行できることはほとんどないのではないだろうか。計画を立ててそのまま実行できるほど、世の中は甘くない。

トラブルの原因は要求仕様にあることが多い

　ソフトウェア開発の世界も例外ではない。最初からきちんとした要求仕様を作成し、ソフトウェアの設計ができるものばかりではない。実際、予定どおり進まなかったソフトウェア開発プロジェクトの失敗の原因を探ると、要求仕様に問題があったという回答が最も多い。
　2004年8月に、ソフトウェア開発に関するウェブアンケート調査を行った。対象は、ソフトウェア開発に従事しており、この１年間にスケジュールの遅延や予算超過を経験したことのある技術者である。有効回答数は309件だった。このアンケートで、スケジュール遅延や予算超過を招いたトラブルの主たる原因の所在を尋ねたところ、４割強の回答者が原因は要求仕様にあったと答えている（図表2参照）。

　ウォーターフォール・モデルに代表される従来型のソフトウェア開発モデルでは、まず最初に要求定義を行う。この工程では、そのソフトウェアの利用者のニーズを把握し、必要な機能や最適なインタフェースを検討し、それをまとめて要求仕様を作成する（プロトタイピング方式では、この仕様をベースに試作品をつくることで要求仕様を確認する）。この作成された要求仕様は顧客（発注者）に渡され、その承認を得て設計が始まる。
　顧客からニーズを聴取して仕様書を作成し、さらに顧客から承認を得ているはずなのだから、普通に考えれば、要求仕様に問題があるはずがない。しかし、現実は理論どおりには進まない。

　コーディングのミスはプログラムの単体テストで発見されることが多く、設計上のミスは結合テストや機能テストで見つかることが多い。しかし、要求仕様に間違いがあった場合には、納品直前の顧客による受入テスト段階まで発見されないことが多いのである。つまり、要求定義段階で作業に問題があった場合、ソフトウェアが完成してから、顧客から「こんなソフトじゃ使えない」「こんなシステムを頼んだ覚えはない」などと言われてしまうケースが多いのである。
　こうした場合、プロジェクトは最初の工程からやり直しになる。バリー・ベームの研究によれば、要求定義の段階の誤りを修復するコストは、発見される工程が遅くなるほど大きくなる（1）。要求仕様の欠陥を要求定義段階で修復するコストを1とすれば、受入テスト段階で発見された場合には30〜70に、稼動してから発見されると40〜1000になる。
　かくして要求仕様に問題があったソフトウェア開発プロジェクトは、スケジュールが大幅に遅れたり、コストが予算を超過して大赤字になることが多くなる。

　では、なぜ要求仕様がトラブルの原因になるのだろう。
　関係者にヒアリングをすると、顧客がシステムの仕様を確定できない段階でプロジェクトをスタートしてしまうケースや、一応仕様は確定しているのだが、途中で仕様変更や機能追加を受け入れてしまっているケースがかなりあるという。また、手順が固まっている業務のシステム化であっても、顧客が自分たちの望んでいることや知っていることを正しく伝えられないケースも少なくないという。これは顧客に重大な責任がある（この顧客側の問題については第4回でとりあげる）。しかし、原因は顧客だけにあるわけではない。システム化の対象が十分に固まっていないケースや、環境や技術の変化によって顧客のニーズが変化するケースが増えているのである。このような場合、最初に綿密な計画をたてる手法は通用しない。

「ウォーターフォール・モデルは間違いだ！」

　ウォーターフォール・モデルは、初期工程で混入した重大な問題の発見が遅れ、その結果、プロジェクトの大幅な遅延を招く危険性が高いという欠陥を持った開発モデルである。この事実は情報分野の専門家にとっては常識である。そして、何人かの専門家は、はっきりとウォーターフォール・モデルはソフトウェア開発に適していないと述べている。
　たとえば、ソフトウェア開発プロジェクト管理に関するバイブル『人月の神話　狼人間を撃つ銀の銃弾はない』を書いたフレデリック・P・ブルックス Jr.は、その原著発行20周年記念増訂版で、はっきりと「ウォータフォールモデルは間違いだ！」と述べている（2）。
　この分野で数多くの書籍を執筆しているエド・ヨードンも、『ピープル・ウェア』で有名なトム・デマルコも、前出のバリー・ベームもウォーターフォール・モデルに批判的である。
　日本では、つくば国際大学の大野郎教授が「ソフトウェア工学発展史　ウォーターフォール（落水）モデルの錯覚・誤用・悪用の30年間」というコラムの中で、フィードバックなしのウォーターフォール・モデルによるソフトウェア開発がはびこったために「ほとんどの大規模プロジェクトで、納期の遅延、コストの高騰、機能の欠落、プロジェクトの崩壊をもたらした」と指摘している（3）。
　このように多くの専門家が、ウォーターフォール・モデルの問題を指摘しているにもかかわらず、日本では依然としてソフトウェア開発と言えばウォーターフォール・モデルが登場する。ソフトウェア開発の入門書で最初に出てくる開発モデルはウォータフォール・モデルであるし、専門学校でも大学でもウォーターフォール・モデルを教えている。

　これだけ問題が指摘され、実際に多くのトラブルを引き起こしているにもかかわらず、依然としてウォーターフォール・モデルが利用されている理由はどこにあるのだろうか。
　まず第一に、ウォーターフォール・モデルがとても理屈にあっているようにみえるからではないだろうか。しかし、最初に述べたように「計画を立てて実行する」という手法は、一見正しいように見えるが間違いであり、実際には実行しながら詳細を決めたり、計画を具体化していく手法の方が正しい｡「間違った方法はいつも、より理屈にあっているように見えるものである」ことに注意しなければいけない（4）。
　もう一つの理由は、日本特有の階層構造に起因しているように思える。日本のソフトウェア産業は、製造業や建設業と同じように階層構造になっている。一般的に、顧客からソフトウェア開発を受託した企業（元請）はその仕事の一部（場合によりほとんど全部）を一次下請企業に発注する。その一次下請企業は、さらにその一部を二次下請企業に発注する。ひどいケースでは5層、6層になるケースがあるという。この時、元請企業が上流工程を担当する。たとえば、概要設計までを自社で行い、詳細設計以下を下請企業に任せるのである。こうしたことが可能なのは、ソフトウェア開発の各工程を逆戻りすることなく逐次実行していくウォーターフォール・モデルを採用しているからである。つまり、ウォーターフォール・モデルは、階層化された業界構造にとって好都合な開発モデルになっているのである。

「アジャイル」という新しいパラダイム

　ウォーターフォール・モデルがこれほどまでに業界に浸透した理由の一つは、1980年代に米国の国防総省がDOD-STD-2167としてウォーターフォール・モデルとドキュメント重視のアプローチを標準としたからである。
　しかし、国防総省はウォーターフォール・モデルの問題点に気付き、90年代半ばにはソフトウェア開発工程を何度も繰り返してソフトウェアの完成度を高めていく反復型開発を推奨するようになっている（5）。
　たとえば、94年12月に新しいソフトウェア開発の標準として反復型の開発を推奨するMIL-STD-498が定められ、95年4月号のThe Journal of Defense Software Engineeringに掲載された"Changing from DOD-STD-2167A to MIL-STD-498"では、ソフトウェア開発はウォーターフォール・モデルで行うという先入観を取り除くように促している。
　ここで注意しなければいけないことが一つある。それは、一般に反復型と言われている開発手法にはさまざまなものがあるという点である。トラブルの原因の多くが要求仕様にあることや、完璧な要求仕様をつくることができないプロジェクトが増えていることを考えると、ソフトウェア開発工程の最初（要求定義）から最後（ユーザによる受入テスト）までを繰り返す必要がある。要求定義を固めてから、設計、コーディング、テストの工程だけを繰り返したのでは、要求仕様の誤りによるトラブルを未然に防ぐことはできない。

　こうした90年代におけるソフトウェア開発モデルの見直しや論争を背景に、この分野の専門家17名が2001年2月、米国ユタ州スノーバードで「アジャイルソフトウェア宣言 (Manifesto for Agile Software Development) 」を発表した（6）。
　「アジャイル (agile)」とは「敏捷な、機敏な、機動的」といった意味をもつ単語であり、この宣言では「変化する要求に対し機敏に対応することによって定められた期間内に顧客が満足するソフトウェアを提供する」という意味が込められている。
　このアジャイルソフトウェア宣言は、ウォーターフォール・モデルに代表される仕様書や設計書などのドキュメントを重視する従来型のソフトウェア開発モデルとはまったく異なる価値観、世界観から生まれている。これは、アジャイルソフトウェア宣言の最初の数行を読めばすぐに理解できる。

　我々は、自らソフトウェアを開発し、あるいはソフトウェア開発の支援を通じて、より優れたソフトウェア開発方法を見つけ出そうとしている。この研究を通じて、我々は次のようなものを重視するようになった。
プロセスとツールより、個人とその交流（対話）
広範囲にわたるドキュメントより、正常に動くソフトウェア
契約交渉より、顧客との協調
計画どおりに進めることより、変化に対応すること

アジャイルソフトウェア宣言 (Manifesto for Agile Software Development)

変化に取り残される日本

　アジャイルソフトウェア開発手法には、XP（エクストリーム・プログラミング）、ユーザ機能駆動型開発（FDD）、適応型ソフトウェア開発（ASD）、リーン・ソフトウェア開発（LD）、クリスタル、スクラムなどさまざまな手法がある。この中でリーン開発とスクラムはそのルーツが日本にあると言われている。
　リーン・ソフトウェア開発のリーン（lean）とは「贅肉がとれた」とか「スリムな」という意味であり、リーン生産方式はトヨタ生産方式を意味する。つまりリーン・ソフトウェア開発とは、トヨタ生産方式をソフトウェア開発に適用したものなのである。
　また、スクラムという名称と基本的な考え方は、野中郁次郎・竹内弘高氏共著による論文 “The New New Product Development Game”(Harvard Business Review, Jan 1986) に由来している。これは、コピー機、カメラ、自動車等の工業製品における新製品開発に関する論文なのだが、この考えをソフトウェア開発に取り入れたものがスクラムなのである。
　ウォーターフォール・モデルに代表される従来のソフトウェア開発モデルでは、要求仕様書や設計書などのドキュメントを重視し、決められたプロセスどおりに作業を進めることを最優先する。それは、顧客のニーズは文字にすることができ、人と人とのコミュニケーションはドキュメントで可能であるという前提に立っている。また、システム化の対象はプロジェクトの初期に正確に把握でき、完全な計画を策定できるという考え方に基づいている。これは、形式知と事前合理性を重視する西洋的な考え方である。

　一方、アジャイルソフトウェア開発は、きちんと動くソフトウェアを重視し、環境も顧客のニーズも変化していくものであるという前提に立ち、綿密な計画の策定より機動性を重視する。プロセスとツールより個人の能力とチームワークを大切にし、綿密なプランを立てるのではなく、変化にどう対応するのかに重点を置いている。これば暗黙知と事後合理性を重視する日本的な考え方だといえる。
　たとえば、XPでは、2人のプログラマが1つのディスプレイを使って一緒にプログラムを作成する「ペア・プログラミング」を行う。これは、一緒に作業することによって、文字では伝えられないこと（暗黙知）を伝えることができるからである。この他、アジャイルソフトウェア開発では、知識の共有のために定期的なミーティングを行う。マニュアルやドキュメントに頼るのではなく、対面によるコミュニケーションを重視している。

　どうみても、アジャイルは日本的な開発手法であり、米国ではその日本的開発手法がソフトウェア開発の世界にパラダイムシフトを起こしつつある。しかし、日本のソフトウェア産業は、依然として西洋的合理主義（事前合理性）一色に染まっている。実に不思議な現象である。
　おそらく、日本で変化が生まれない最大の理由は、ウォーターフォール・モデルという開発モデルが、元請と下請けという企業間関係、職制やビジネスフローという安定的な仕組みの中に組み込まれてしまっていることにあるのだろう。
　しかし、いずれ日本でもパラダイムシフトは間違いなく起きる。すでにその兆候はあちこちにみることができる。アジャイルを実践するソフトウェア開発企業も生まれているし、書店には「アジャイル」という文字を含む書籍が何冊も並ぶようになっている。
　問題は、何人の経営者がこの変化に気付いているかである。それが日本のソフトウェア産業の未来を決定することになるだろう。

（1）D.C.ゴーズ＆G.M.ワインバーグ『要求仕様の探検学』共立出版、p.20
（2）フレデリック・P・ブルックス，Jr.『人月の神話　狼人間を撃つ銀の銃弾はない』アジソン・ウェスレイ・パブリッシャーズ・ジャパン、1996年2月、p.256
（3）大野郎「ソフトウェア工学発展史　ウォーターフォール（落水）モデルの錯覚・誤用・悪用の30年間」http://www.ivis.co.jp/prof/07.html
（4）「間違った方法はいつも、より理屈にあっているように見えるものである（The wrong way always seems the more reasonable）」は、George Mooreの風刺喜劇“The Bending of the Bough"の中の科白である。
（5）クレーグ・ラーマン『初めてのアジャイル開発』日経BP社、2004年9月、pp.107-113