新しい開発手法への期待 （2010年1月）
システム開発遅延の原因
現在、日本におけるソフトウェア開発プロジェクトの大半は、ウォーターフォール・モデルで行われている。ウォーターフォール・モデルとは、ソフトウェア開発の工程を(1) 要求定義、(2) 設計、(3) コーディング、(4) テスト、(5) 保守のように分けて、それらを順に実施していくという手法である。
最初にきちんとした計画や設計書をつくり、それに従って実行するという方法であり、作業は最初から正しく行った方が、後で修復するより効率的であるという考え方に基づいている。この手法を採用した場合、前の工程の成果物に従って後の工程を進めることになり、原則として前の工程の戻ることはない。「計画を立ててそのとおり実行する」。実にシンプルで美しい。
だが、それは理想的ではあっても、現実に実行可能なのだろうか。うまく行くケースもある。しかし、そうでないケースも少なくない。
ウォーターフォール・モデルでは、最初に要求定義を行う。この工程では、そのソフトウェアの利用者のニーズを把握し、必要な機能や最適なインタフェースを検討し、それをまとめて要求仕様を作成する。システムの設計は、顧客（発注者）が要求仕様書を承認してから始まる。ベンダーが要求仕様書を作成する場合であっても、顧客からニーズを聴取して仕様書を作成し、さらに顧客から承認を得ているのだから、普通に考えれば、要求仕様に問題があるはずがない。しかし、現実は理論どおりには進まない。要求仕様に間違いがあるケースもあるし、時間の経過によって顧客の要求そのものが変化するケースもある。
要求仕様に間違いがあった場合、納品直前の顧客による受入テスト段階まで発見されないことが多い。ソフトウェアが完成してから、顧客から「こんなソフトじゃ使えない」「こんなシステムを頼んだ覚えはない」などと言われてしまうのである。
こうした場合、プロジェクトは最初の工程からやり直しになる。バリー・ベームの研究によれば、要求定義の段階の誤りを修復するコストは、発見される工程が遅くなるほど大きくなる[1]。要求仕様の欠陥を要求定義段階で修復するコストを1とすれば、受入テスト段階で発見された場合には30～70に、稼動してから発見されると40～1000になる。
かくして要求仕様に問題があったソフトウェア開発プロジェクトは、スケジュールが大幅に遅延し、大赤字になる。
では、なぜ要求仕様がトラブルの原因になるのだろう。
顧客がシステムの仕様を確定できない段階でプロジェクトをスタートしてしまうケースや、一応仕様は確定しているのだが、途中で仕様変更や機能追加を強要するケースがかなりある。また、手順が固まっている業務のシステム化であっても、顧客が自分たちの望んでいることや知っていることを正しく伝えられないケースも少なくない。これらは顧客に重大な責任がある。しかし、原因は顧客だけにあるわけではない。環境や技術の変化によって顧客のニーズが変化するケースが増えている。こうした場合、最初に綿密な計画をたてる手法は通用しない。
「ウォーターフォールモデルは間違いだ！」
ウォーターフォール・モデルは、初期工程で混入した重大な問題の発見が遅れ、その結果、プロジェクトの大幅な遅延を招く危険性が高いという欠陥を持った開発モデルである。この事実は情報分野の専門家にとっては「常識」である。そして、何人かの専門家は、はっきりとウォーターフォール・モデルはソフトウェア開発に適していないと述べている。
たとえば、ソフトウェア開発プロジェクト管理に関するバイブル『人月の神話 狼人間を撃つ銀の銃弾はない』を書いたフレデリック・P・ブルックス Jr.は、その原著発行20周年記念増訂版で、はっきりと「ウォータフォールモデルは間違いだ！」と述べている[2]。
この分野で数多くの書籍を執筆しているエド・ヨードンも、『ピープル・ウェア』で有名なトム・デマルコも、前出のバリー・ベームもウォーターフォール・モデルに批判的である。
日本では、つくば国際大学の大野侚郎教授が「ソフトウェア工学発展史 ウォーターフォール（落水）モデルの錯覚・誤用・悪用の30年間」というコラムの中で、フィードバックなしのウォーターフォール・モデルによるソフトウェア開発がはびこったために「ほとんどの大規模プロジェクトで、納期の遅延、コストの高騰、機能の欠落、プロジェクトの崩壊をもたらした」と指摘している[3]。
このように多くの専門家が、ウォーターフォール・モデルの問題を指摘しているにもかかわらず、日本では依然としてソフトウェア開発と言えばウォーターフォール・モデルが一般的である。ソフトウェア開発の入門書に最初に出てくる開発モデルはウォーターフォール・モデルであるし、専門学校でも大学でもウォーターフォール・モデルを教えている。
これだけ問題が指摘され、実際に多くのトラブルを引き起こしているにもかかわらず、依然としてウォーターフォール・モデルが利用されている理由はどこにあるのだろうか。
それは、ウォーターフォール・モデルがとてもシンプルで分かりやすいからだろう。しかし、最初に述べたように「計画を立ててそのとおり実行する」という手法は、一見正しいように見えるが間違いである。「間違った方法はいつも、より合理的に見える」のである[4]。
「アジャイル」という新しいパラダイム
ウォーターフォール・モデルがこれほどまでに業界に浸透した理由の一つは、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”では、ソフトウェア開発はウォーターフォール・モデルで行うという先入観を取り除くように促している。
さらに、国防総省の調達手続きを定めたDoD 5000.2 で、ソフトウェア調達ではプロジェクト・マネージャは反復型開発プロセス（spiral development process）を採用することが義務化された[6]。
ここで注意しなければいけないことが一つある。それは、一般に反復型と言われている開発手法にはさまざまなものがあるという点である。トラブルの原因の多くが要求仕様にあることや、完璧な要求仕様をつくることができないプロジェクトが増えていることを考えると、ソフトウェア開発工程の最初（要求定義）から最後（ユーザによる受入テスト）までを繰り返す必要がある。要求定義を固めてから、設計、コーディング、テストの工程だけを繰り返したのでは、要求仕様の誤りによるトラブルを未然に防ぐことはできない。
こうした90年代におけるソフトウェア開発モデルの見直しや論争を背景に、この分野の専門家17名が2001年2月、米国ユタ州スノーバードで「アジャイルソフトウェア宣言」を発表した[7]。
アジャイルソフトウェア宣言
我々は、自らソフトウェアを開発し、あるいはソフトウェア開発の支援を通じて、より優れたソフトウェア開発方法を見つけ出そうとしている。この研究を通じて、我々は次のようなものを重視するようになった。
プロセスとツールより、個人とその交流（対話）
広範囲にわたるドキュメントより、正常に動くソフトウェア
契約交渉より、顧客との協調
計画どおりに進めることより、変化に対応すること
「アジャイル (agile)」とは「敏捷な、機敏な、機動的」といった意味をもつ単語であり、この宣言では「変化する要求に対し機敏に対応することによって定められた期間内に顧客が満足するソフトウェアを提供する」という意味が込められている。
このアジャイルソフトウェア宣言は、ウォーターフォール・モデルに代表される仕様書や設計書などのドキュメントを重視する従来型のソフトウェア開発モデルとはまったく異なる価値観、世界観から生まれている。これは、アジャイルソフトウェア宣言の最初の数行を読めばすぐに理解できる。
日本発の開発手法
アジャイルソフトウェア開発手法には、XP（エクストリーム・プログラミング）、ユーザー機能駆動型開発（FDD）、適応型ソフトウェア開発（ASD）、リーン・ソフトウェア開発（LD）、クリスタル、スクラムなどさまざまな手法がある。この中でリーン開発とスクラムはそのルーツが日本にあると言われている。
リーン・ソフトウェア開発のリーン（lean）とは「贅肉がとれた」とか「スリムな」という意味であり、リーン生産方式はトヨタ生産方式を意味する。つまりリーン・ソフトウェア開発とは、トヨタ生産方式をソフトウェア開発に適用したものなのである。
また、スクラムという名称と基本的な考え方は、野中郁次郎・竹内弘高氏共著による論文 “The New New Product Development Game”(Harvard Business Review, Jan 1986) に由来している。これは、コピー機、カメラ、自動車等の工業製品における新製品開発に関する論文なのだが、この考えをソフトウェア開発に取り入れたものがスクラムなのである。
ウォーターフォール・モデルに代表される従来のソフトウェア開発モデルでは、要求仕様書や設計書などのドキュメントを重視し、決められたプロセスどおりに作業を進めることを最優先する。それは、顧客のニーズは文字にすることができ、人と人とのコミュニケーションはドキュメントで可能であるという前提に立っている。また、システム化の対象はプロジェクトの初期に正確に把握でき、完全な計画を策定できるという考え方に基づいている。これは、形式知と事前合理性を重視する西洋的な考え方である。
一方、アジャイルソフトウェア開発は、きちんと動くソフトウェアを重視し、環境も顧客のニーズも変化していくものであるという前提に立ち、綿密な計画の策定より機動性を重視する。プロセスとツールより個人の能力とチームワークを大切にし、綿密なプランを立てるのではなく、変化にどう対応するのかに重点を置いている。これば暗黙知と事後合理性を重視する日本的な考え方だといえる。
たとえば、XPでは、2人のプログラマが1つのディスプレイを使って一緒にプログラムを作成する「ペア・プログラミング」を行う。これは、一緒に作業することによって、文字では伝えられないこと（暗黙知）を伝えることができるからである。この他、アジャイルソフトウェア開発では、知識の共有のために定期的なミーティングを行う。マニュアルやドキュメントに頼るのではなく、対面によるコミュニケーションを重視している。
どうみても、アジャイルは日本的な開発手法であり、米国ではその日本的開発手法がソフトウェア開発の世界にパラダイムシフトを起こしつつある。しかし、日本のソフトウェア産業は、依然として西洋的合理主義（事前合理性）一色に染まっている。実に不思議な現象である。
おそらく、日本で変化が生まれない最大の理由は、ウォーターフォール・モデルという開発モデルが、元請と下請けという企業間関係、職制やビジネスフローという安定的な仕組みの中に組み込まれてしまっていることにあるのだろう。
幸いなことに、日本でもパラダイムシフトが起きる兆候はあちこちにみることができる。たとえば、ユニバーサル・シェル・プログラミング研究所（USP研究所）が開発した「ユニケージ開発手法」である。プログラミング言語ではなく、OSのシェルコマンドを使ったシェルスクリプトによってシステムを構築するというユニークな手法である。
実際にユニケージ開発手法を使って、マーチャンダイジング・システムを刷新した良品計画の事例では、一つのスクリプトの大きさは100行～500行であり、大半は200行以下だと報告されており、極めて軽量な開発手法である。また、開発のプロセスは、1～3週間で完成度7割程度のシステムを開発し、修正を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
[6] DoD 5000.2-R ‘Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs’のC5.2.3.5.6.2 には” When acquiring software for a system, the PM shall plan a spiral development process for both evolutionary and single-step-to-full-capability acquisition strategies.”と定められている。
[7] ‘Manifesto for Agile Software Development ‘ (http://agilemanifesto.org/)