Comments
Description
Transcript
ソフト開発プロセスモデルと製品属性
オンライン ISSN 1347-4448 印刷版 ISSN 1348-5504 赤門マネジメント・レビュー 1 巻 4 号 (2002 年 7 月) ソフト開発プロセスモデルと製品属性 立本 博文 東京大学経済学研究科博士課程 E-mail: [email protected] 要約：ソフトウェアのプロセスモデルを再検討することで開発対象の製品と開発プロ セスの間の適合性の議論を考察する。具体的には、現実の企業で行われてきたことを 意識しながら、ソフトウェア工学のプロセスモデルに絞って流れを見ていく。また、 日本で国際競争力のあるパッケージソフトの例であるゲームソフトを対象に加えるこ とで、従来ビジネスソフトのみに限定されていた議論を再考察する。 キーワード：ソフトウェア開発、プロセスモデル、ゲームソフト 1. はじめに 本稿の目的は、ソフトウェア開発に関する論文を概観することによって、いままでどのよ うなことがソフトウェア開発に対して言われてきたのかを、経営の立場から見ることである。 具体的には、従来ソフトウェアの開発プロセスについて言われてきたことを整理し、それら の視点から、日本のパッケージソフトで国際競争力をもっているゲームソフトの開発を考察 する。 ソフトウェア工学における研究の焦点は、技術的な方法に当てられることが多く、ソフト ウェア企業が市場で競争するにあたって、どのように開発をしているのかといった問題意識 は欠落しているように思われる。いわば、純粋なソフトウェア工学の立場が理想的なゴール を語ることを目指しているのに対して、本論文では実際の企業での開発プロセスに注目して いる。そのため、ソフトウェア工学の細かい技法にまでは立ち入っていない。むしろ、本論 文では、市場環境、技術環境、開発対象の製品の特性によって、企業内での開発プロセスに どのような違いがあるのであろうかということに興味がある。 一概にソフトウェアと言っても、その範囲は非常に広い。対応するハードウェアでは汎用 コンピュータ用のものもあれば、PC 向けのものもあり、市販のパッケージ型のものもあれ 309 ©2002 Global Business Research Center www.gbrc.jp 立本 博文 ば顧客仕様にカスタマイズしたものもあり、また数値計算が主たる内容であるものからグラ フィック中心であるものもある。本論文では、筆者がゲームソフトの開発を研究しているた め、とくにパッケージソフトの開発を中心に取り上げる。 本論文では、まずソフトウェア産業の歴史を概観する。ソフトウェア産業は、非常に歴史 が浅く、およそ 50 年ほどの歴史しかない。その中で、著しい発展を遂げてきたことを確認 する。 つぎに、ソフトウェア工学の中でも、特にプロセスモデルについて概観する。プロセスモ デルは、工学的な文脈では、 「こうあるべきのもの」というノーマティブな意味合いがある。 しかし、本論文では、実際の企業で適応されている事例を見ることによって、実際にはどう だったのかを見ている。 最後に、プロセスモデルに関して、考察を加え、カテゴリー化を行う。このカテゴリー化 の際に各プロセスを比較することで、どこに特徴があり、何が利点で何が欠点であるのかを 整理する。 本論文の意義として、三つのことを目標としている。 ひとつめは、従来言われていたソフトウェア工学を経営の側から見ることによって、より 現場に近い考察が得られると考えられる。ソフトウェア工学は、工学という名前のとおりに、 理想的な解決方法を目指しているが、実際のソフトウェア開発の現場では、どうであったの かを見ることには意義があると思われる。 二つめは、経営の側から見て、ソフトウェアの開発プロセスをどのようにマネジメントす るかに対しての考察が得られると考えられる。ソフトウェア開発は、可変性が高く、人に依 存しやすい性格を持っているので、なかなか管理をうまくすることができない。このような 状況に対して、いくつかのヒントを得られると考える。 三つめは、経営学の立場からソフトウェア開発に対する蓄積をすることができると考える。 ソフトウェアの歴史が浅いこと、まだ産業自体が急発展の途中であることから、経営学の分 野ではソフトウェア開発に関する蓄積が少ない。しかしながら、ソフトウェアへのニーズは、 多様になり、ますます重要性が増してきている。このような中で、経営学の視点からソフト ウェア開発に対する蓄積は、重要であると思われる。 2. ソフトウェア産業の歴史 現在のコンピュータの原型ができたのが、20 世紀半ばである。初期のコンピュータは、 ON/OFF をあらわす真空管を物理的に配置した機械であった。この有名な例が、1946 年に米 陸軍弾道試験所で完成した ENIAC であった。この ENIAC の最大の問題点は、ケーブルの配 310 ソフト開発プロセスモデルと製品属性 線であった。現在のソフトウェアにあたるものは、ENIAC ではケーブルの配線で実現され ており、同じ処理をするためには、ケーブルを以前と同様に再配線することで実現していた。 当時 ENIAC の開発チームに参加していたフォン・ノイマンは、コンピュータの記憶領域 を増やし、プログラムを組込むことで、ケーブルの最配線をしなくてもよくなり、プログラ ムの再利用ができるようになると主張した。4 年後の 1950 年に、この構想は EDVAC が完成 することで実現した。この方式のことをプログラム内臓方式とよび、これを実現しているコ ンピュータのことをノイマン型コンピュータと呼ぶようになった。こうして、はじめてソフ トウェアが作られるようになっていった。この当時のコンピュータは、大型の汎用機（メイ ンフレーム）であった。これらの汎用機で、プログラムを開発するために、科学技術計算用 に FORTRAN、事務処理用に COBOL というソフトウェア開発言語が開発され、 広く普及し、 ソフトウェア開発の土台となっていった。1950 年代の主なユーザーは、軍であったが、そ の後、徐々に学術関係者に広がり、1960 年代に入ると、民間の一般事務処理に普及してい った。 1960 年半ばになると、半導体技術が向上して集積回路が普及し、コンピュータの小型化 に拍車がかかった。このころの有名なコンピュータは、1964 年に発売された IBM 社の System/360 と 1965 年に発売された DEC 社の PDP-8 である。特に DEC 社の PDP-8 は、小型･ 高性能を低価格で販売したために、非常に普及した。汎用機より小さいという意味で、ミニ･ コンピュータと呼ばれた。 System/360 シリーズのオペレーティングシステム（OS）の開発が 1964 年から 1965 年に かけて行われ、それまで単に制御プログラムの集まりだった OS に、体系的な機能が付加さ れ、汎用的な OS の概念が定着した。汎用 OS の登場、開発言語の普及により、大規模なソ フトウェアシステムの構築が実施されることとなった。OS/360 の開発経験を通じて、ソフ トウェア開発にかかわる品質の問題、コストの問題、スケジュール管理の問題など現在の問 題につながるような問題が認識され始めた。 このような背景の下に、1968 年開催された NATO の技術委員会で「ソフトウェア工学」 という言葉が提唱された。同時に、「ソフトウェア危機」という言葉も用いられた。この委 員会では、ソフトウェア開発における諸問題において、工学的なアプローチを用いて解決を 行っていこうということが確認された。 ソフトウェアの価値を決定的に認識させたのは、1969 年 IBM 社がとったアンバンドリン グ政策（価格分離政策）である。アンバンドリング政策は、ハードウェアとソフトウェアの 価格を別々に設定するということである。それまでは、ソフトウェアはすべて無償で提供さ れていた。この政策により、ソフトウェアでも利益があげられるようになり、ソフトウェア 311 立本 博文 だけでも企業が成り立っていくようになった。ここに、ソフトウェアが産業として成長する 要因がととのったと言える。 1970 年代になり、半導体の技術革新は進み、ますますダウンサイズの流れは強まった。 1976 年に Apple 社が Apple I を発売し、 “自分専用のコンピュータ”という概念が広がった。 いわゆるパソコン用のソフトウェア市場が開け、現在もっとも流通しているパソコン用のパ ッケージソフトが開発されるようになった。この流れは、1981 年に IBM 社が IBM PC (5010 Personal Computer) を発売することで、決定的となっていった。1980 年代は、パーソナルコ ンピュータの性能の向上が目覚しく、パソコン用のパッケージソフトウェアの市場が急激に 拡大していった。 1990 年代も、引き続き半導体の技術革新がすすみ、コンピュータの能力の向上が続いた。 Macintosh, Windows に代表されるような GUI を用いた OS が一般的になっていった。また、 1989 年に NFS（米国際科学財団）が ARPANET（インターネットの原型）を継承し、商用の 利用を認めたため、インターネットの一般開放が行われた。こうした新しい技術要素を背景 に、ソフトウェアへのニーズが多様になっていき、現在に続いている。 では、先にあげたソフトウェア工学はどうなっていったのであろうか。1970 年代には、 ソフトウェアの品質向上には、コーディング・デバッグという後の工程よりも、設計工程に おいての改善が必要であると認識されていった。それまでは、ソフトウェアの品質は、ソフ トウェア開発工程の下流部分であるデバッグで保たれると考えられていた。また、ただ作れ ばよいというものではなく、理論的な背景の元に作るべきだと主張され、モジュールに関す る議論が行われるようになっていった。モジュールの分割方法やモジュール内部の設計方法 が提言された。モジュール分割に関する方法論としては、構造化設計 (Stevens, Myers, & Constantine, 1974)、複合設計 (Myers, 1975) があげられる。モジュール内部の設計方法論と しては、構造化プログラミング (Dahl, Dijkstra, & Hoare, 1972)、ジャクソン法 (Jackson, 1975)、 ワーニエ法 (Warnier, 1974) があげられる。 1980 年代には、1970 年代の結果を受けて、数多くのツール類が開発、利用されていった。 また、このツールを統合化したワークベンチ（開発統合環境）が開発された。それとともに、 各メーカーではソフトウェア開発環境のアーキテクチャが示された。このようなソフトウェ ア工学の成果を利用したツールの利用による生産性の向上は、本家と言えるアメリカととも に日本でも行われ、成果をあげた (Cusumano, 1991)。例えば、日本国内のメーカーでは、日 立製作所が EACLE、NEC が SEA/1、富士通が SIA・SDAS といったものがあげられる。 1990 年代では、ターゲットとする開発環境が多種多様になっていった。プログラムの開 発は、それ以前と比べると 1980 年代の成果である各種ツールのおかげで効率的にはなって 312 ソフト開発プロセスモデルと製品属性 いた。各ソフトウェアベンダーから、CASE (Computer Aided Software Engineering) ツールが 発売され、生産性の向上に貢献した。 しかし、これらは、特に設計を含めた開発工程全般の効率化であり、実際のコーディング 自体は、ソースコードの記述が主であり、依然として高度な技術力と専門性が必要とされた。 アプリケーション開発の現場では、人材不足が深刻な問題となっていった。先にあげたよう に、GUI を持ったソフトウェアへのニーズ、ネットワークへの対応など幅広い分野への知識 がソフトウェア開発に必要となり、ソースコード記述が中心の開発では、とても対応ができ なくなっていった。このような中、1990 年代に普及した RAD (Rapid Application Development) ツールは、GUI を通してビジュアルなプログラミングを可能にした (Connell & Shafer, 1989)。 同時に、RAD のコンポーネント（ソフトウェア部品）として、各種の処理が開発者から扱 いやすい形で提供されていった。これは、オブジェクト指向型のプログラミングからの影響 を強く受けたものであった。 以上のように、ソフトウェア工学は、困難なソフトウェア開発に対して解決方法を提供し てきているが、ソフトウェアを利用するシーンが多様化し、またニーズが強くなっているた め、いまだに解決方法の精緻化と新しい解決方法を探ることが続いている。この流れをまと めたものが表 1 である。 3. ソフトウェア開発モデルの先行研究 ソフトウェア工学が扱う対象は、基本的にソフトウェア・プロダクトとソフトウェア・プ ロセスがある。ソフトウェア・プロダクトとは、開発の成果物のことであり、各種仕様書、 プログラムソース、テストデータなど、ソフトウェア開発で生成されるものである。これに は、各種の設計技法が深く関連する。一方、ソフトウェア・プロセスとは、ソフトウェア開 発工程そのものである。当然、ソフトウェア・プロダクトとソフトウェア・プロセスとは、 密接な関係にある。しかし、本論文では、実際の企業の活動の側からソフトウェア開発を眺 めていくため、ソフトウェア・プロセスに焦点をあてる。 本来、ソフトウェア開発というものは、可変性が高く、人に対する依存度が高い。「この ようにしなければプロジェクトはできない」というようなものではないかもしれない。潜在 的にはターゲットとしているソフトウェア製品と開発プロセスモデルの間で不適合を起こ しているにもかかわらず、開発者個人のスキルが高いので、たまたまうまくいってしまうケ ースもあるであろう。実際、ある程度規模の小さいプロジェクトは、スタープログラマーの 313 立本 表1 ソフトウェア設計技法 時代 ハードウェア ソフトウェア環境 1950 プログラム内蔵式 初期のアセンブリ言語 年代 計算機の完成 1949 年 英 EDSAC 1950 年 米 EDVAC 博文 ソフトウェア設計技法 特徴 弾道計算、物理現象の解析・制御に コンピュータが用いられた。使用者 開発言語の登場 は主に軍。MIT でこれらの研究をし 科学計算用言語 ていた研究者が、route 128 を中心に 「FORTRAN」 コンピュータ企業を起業。 事務処理用言語 「COBOL」 1960 汎用機の普及 ソフトウェアの価値 1968 年 NATO 会議で「ソフト ソフトウェアの巨大化・複雑化を受 年代 1964 年 の確立 ウェア工学」という言葉が使わ けて工学的なアプローチの必要性が IBM 社 System/360 1969 年 れた。 説かれた。 IBM 社 ミニコンの普及 アンバンドリング政策 アンバンドリング政策により、ソフ 1965 年 トウェアのみでも価格がつき、ソフ DEC 社 PDP-8 トウェア産業としての基盤ができ 1969 年 UNIX 開発 た。 1970 構造化の概念の普及 ソフトウェア設計工程の方法 ソフトウェア工学を受けて、ソフト 年代 1972 年 論の盛り上がり ウェア設計に対するさまざまな議論 汎用構造化言語 C 言語 が行われた。特に、モジュールの概 モジュール分割に関する議論 パソコンの登場 構造化設計 1976 年 Stevens et al. (1974) 念が設計方法に取り入れられる。 Apple 社 Apple I モジュール内部構造に関する 議論 構造化プログラミング Dahl et al. (1972) 1980 パソコンの普及 パソコン用 OS の普及 各社が toolbox やツールを発売。 70 年代考案されたツールの実用化が 年代 1981 年 1981 年 さらにこれらを統合化した統 行われた。これらツールを統合化し Microsoft 社 MS-DOS 合開発環境を発売 た開発環境とそのアーキテクチャの IBM 社 IBM PC 全体図が発表された。 オブジェクト指向の パソコンが普及したことによりパソ 普及 コン用パッケージソフトの市場が急 1983 年 速に拡大した。 オブジェクト指向言語 C++ 1990 インターネット ビジュアル開発環境 年代 普及 普及 1989 年 1991 年 RAD ツールとビジュアル開発 ARPANET の 商 用 Microsoft 社 Visual Basic 環境の融合 各種 CASE ツールの発表 CASE ツールを用いたソフトウェア の信頼性・生産性の向上が試みられ 利用許可 た。 オブジェクト指向を基盤にしたビジ GUI OS の普及 ュアルプログラミング環境・RAD ツ 1995 年 ールにより早期のプロトタイプ開 Microsoft 社 Windows95 発、ソフトウェアの部品化（コンポ ーネント化）が行われた。 出所）河村 (1995a,1995b)、長谷川 (2000) をもとに、筆者作成 表1 314 ソフト開発プロセスモデルと製品属性 力によるところが大きいと考えられる。 しかしながら、そのようなプロジェクトのやり方で、長期的に企業が成功するというのは 現実的ではないと考えられる。例えば、米マイクロソフト社では、会社設立から数年の間は、 スキルのある個人の技能にプロジェクトはまかされていた。初期のマイクロソフトでは、ス タープログラマーが 1 万行のアプリケーションを 2 日で書き上げ、もしそれがうまく動かな いとまたはじめから書き直すことが行われていた。 (Iansiti, 1998, p. 176)。 しかし、ソフトウェアマーケットが拡大し、ソフトウェア製品そのものが巨大化してくる にしたがって、このようなスタープログラマーに頼る方法ではなく、組織的にソフトウェア を開発するアプローチが取られるようになっていった。 前節で述べた System/360 の OS である OS/360 の開発者でもある Brooks は、自らの開発経 験を踏まえ、Brooks (1995) のなかで、開発者の質と組織形態と管理の重要性を主張してい る。後に、Boehm が行った調査においても、ソフトウェア開発のコスト増大要因として、開 発者・開発チームの能力の問題が一番であり、2 番目の要因である製品の複雑性の 2 倍も大 きいことが報告されている (Boehm, 1981; Boehm et al., 2000)。同様に、DeMarco and Lister (1999) でも、各種の技法よりも開発者チームの重要性を訴えている。つまり、ソフトウェア 開発の成功要因は、個々の技法の大切さもさることながら、開発プロセスをいかに管理する かということに大きく依存していると考えられる。では、ソフトウェアメーカー各社は、ど のようにソフトウェア開発を管理していたのだろうか。 1970 年代当時、もっとも有力であり、かつほぼ唯一であったソフトウェア開発の管理方 法は、ウォーターフォールモデルに従った管理方法であった。ウォーターフォールモデル1 (Boehm 1988; Brooks, 1995) とは、プロジェクトをいくつかのフェーズに分割し、各フェー ズに検査工程を設けることで、上流工程に戻ってのやり直しを最小化させ、プロジェクトの 混乱を防ぐ方法である。ウォーターフォールモデルは、現在でも影響力を持ちつづけている。 1970 年代という時代背景からわかるように、ウォーターフォールという考え方が始まった のは、汎用機での大型システム開発の経験からであった。ウォーターフォールの考え方は、 その後、さまざまなアイディアを加えられて、現場にあうように改良をされ続けている。 1980 年代になると、パーソナルコンピュータが普及し、PC 用パッケージソフトの市場が 急拡大した。これら PC 用パッケージソフトを供給した企業は、汎用機・ミニコンとは異な った背景・文化をもって出現した企業であった。これらの企業は、当初、管理方法と言える ものはほとんど持っていなかったと思われる。初期のパッケージソフトは規模が小さかった 1 ウォーターフォールモデルをはじめて示したのは、1970 年の WESCON での W. W. Royce の発表で あったと言われている (Boehm, 1981)。 315 立本 博文 ため、スタープログラマーが一人でプログラムを書くということが行われていたからである。 しかし、ソフトウェアの大規模化や、競争が厳しく変化の大きい製品市場に対応するために、 組織的な開発方法が必要となり、そのために管理方法が必要となった。 Cusumano and Selby (1995) は、マイクソフトの開発を観察することで開発プロセスにおけ る特徴的なプロセスを見つけ出した。このプロセスのことを「シンクアンドスタビライズ」 と呼んでいる。シンクアンドスタビライズでは、はじめに大まかなモジュールを設定し、モ ジュール間での調整を頻繁にすることでプロジェクトの安定化を図る方法である。従来でも、 1 ヶ月、1 週間程度のビルドを行うことで、各モジュールの結合テストが行われていたが、 マイクロソフトで観察されたのは毎日構築という頻度であり、それを徹底したことが特筆す べき点である。製品は、大まかなモジュールに分別して開発され、市場の変化をモジュール 単位で対処することができた。 Cusumano らは、このプロセス自体は、マイクロソフトだけが実行しているものではなく、 ほかのパッケージソフトメーカー、例えばボーランド社なども行っているとしている。しか しながら、それらの企業の中でも、マイクロソフトはシンクアンドスタビライズのやり方が 徹底していると主張している。 このシンクアンドスタビライズの方法は、ソフトウェア開発にインターネットが利用され るようになって、ますます加速されているように思われる。Cusumano and Yoffie (1998) のネ ットスケープの開発事例、Iansti (1998) のネットスケープ、マイヤフー・プロジェクト、ネ ットダイナミクスの開発事例で同様のことが報告されている。また、世界的に利用されてい る OS の Linux や WWW サーバーの Apache の開発でも、シンクアンドスタビライズと同様 のことが行われていると思われる。 現在では、大規模なシステム製品と相対的に小規模なパッケージ製品の開発プロジェクト モデルは異なると考えられている。大規模なシステム製品は、ウォーターフォール的な開発 プロセスモデルが適合的であり、パッケージソフトウェアのような相対的に小さなソフトウ ェア製品では、シンクアンドスタビライズ的なモデルが適合的であると考えられている。 なぜ、大規模システム製品にはウォーターフォール的な開発プロセスで、パッケージソフ トウェアにはシンクアンドスタビライズなのかという根拠が二つある。ひとつめの理由は、 システム製品とパッケージソフト製品での不確実性の違いである。この場合の不確実性とは、 テクノロジーとマーケットニーズの二つのポイントからである。 二つめの理由は、大きな問題を小さく分割して解決することが可能であるかどうかという ことである。システム製品では、依存関係が多く、一度にまとめて開発してしまわなくては いけない機能が多数存在する。大規模システム製品に関しては、事前に機能を詳細に調査し、 316 ソフト開発プロセスモデルと製品属性 設計を確定してしまわないと、ほかの依存関係部分に影響を及ぼしてしまう可能性が高い。 よって、コーディング以前に詳細設計をすることに合理的な理由がある。 一方、モジュール間の依存性がそれほど決定的にプロジェクトの成否に関係のないパッケ ージソフトでは、できるだけモジュールごとに作業を分割し、並行的に作業を繰り返したほ うが開発期間短縮に貢献できるとしている。 しかし、OS のような大規模で複雑な製品もシンクアンドスタビライズ方式で開発されて いるという報告もある。Zachary (1994) は、Windows NT の開発事例を記録しているが、そ の中で頻繁なビルドを行っていると報告している。Yourdon (1996, 1997) でも、Windows NT の開発事例で、毎日構築が行われたことで、「毎日の構築」という概念が非常にポピュラー になったとしている。Microsoft では、Windows95 の開発プロジェクトでも、毎日構築の概 念が用いられた。Microsoft 社の Visual C++ という開発環境製品のマネージャーであった McCarthy (1995) も毎日構築の重要性を訴えている。また、OS という例では、Linux は毎日 構築に非常に近いプロセスをとっているように思われる。 つまり、大規模なシステムがウォーターフォール的であり、小規模のパッケージソフトが シンクアンドスタビライズであるという図式は、この産業がたどってきた歴史的な産物であ り、現在では必ずしも成り立たない可能性がある。確かに、ウォーターフォール的な管理が 必要なソフトウェアの分野がシステムソフトウェアのプロジェクトに多いということは認 められる。しかし、その条件が規模のみであるというのは、違う可能性がある。この部分は、 まだ整理されていない分野である。 詳しい議論に入る前に、まず、基本的なソフトウェア開発工程を踏まえた上で、ウォータ ーフォールモデル、およびシンクアンドスタビライズモデルを説明する。 基本的なソフトウェア開発手順 ソフトウェア開発の基本工程は、 「目標設定（調査・分析） 」「概要設計（システム設計）」 「詳細設計（プログラム設計） 」 「コーディング（プログラム製造）」 「結合テスト」の段階に 分かれる｡2 以下、各工程についておよそどのようなことをするのかを説明する。 1. 目標設定（調査・分析） 調査・分析段階では、開発プロジェクトで解決しなければならない問題とは何かという ことを明確化し、開発目標を定める。製品に対してどのようなユーザーの要求があるの か、またその要求を実現したときに必要となる費用を概算する。 2 「ソフトウェア開発の手順と実際」『インターフェース』(1995 年 4 月号), p.80. CQ 出版. を参考に した。 317 立本 博文 2. 概要設計（システム設計） 製品をどのような構成で実現するのかを設計する。一例として、「インターフェース設 計」「ファイル設計3」「データ項目設計」「処理設計4」などを行う。特に、「処理設計」 では、「インターフェース設計」「ファイル設計」「データ項目設計」をもとに、プログ ラムをどのように部品化（モジュール化）するかを検討し、製品の構造の概要を設計す る。 3. 詳細設計（プログラム設計） プログラム個々に、どのような入力情報があり、それに対してのどのようなデータを出 力するのかを設計する。製品のそれぞれの機能を具体的に“どのように実現”するかを 設計する。処理結果データの出力先、出力方法を検討したり、共通モジュールは何を使 用するかなどを設計する。 4. コーディング（プログラム製造） 詳細設計にもとづき、実際にプログラムを製造する。製造されたプログラムは、部分ご とに単体テスト（モジュールテスト）を行い、詳細設計を満たしているかを確認する。 5. 結合テスト 単体テストの完了したプログラムについて、各プログラム間のインターフェースが相互 に正しいかを確認する。 次節では、本節で取り上げた基本的なソフトウェア開発プロセスを踏まえて、ウォーター フォールモデル、シンクアンドスタビライズモデルを説明する。 4. ウォーターフォールモデル 1970 年代にもっとも影響力があり、現在でも用いられることが多いのがウォーターフォ ールモデル (Boehm, 1988; Brooks, 1995) である。ウォーターフォールモデルのもっとも際立 っている特徴は、開発プロセスの各ステージを区切り、ステージごとに検証をおこない、上 流ステージへの逆流を防ぐことである。例えば、概要設計が終了すると、概要設計が十分で あるかを検証し、検証後、詳細設計へと移行する（図 1） 。 ウォーターフォールモデルは、詳細設計をコーディングの前に実施することにより、コー ディングを三つの意味で効果的に行うことができる。 ひとつめは、システムの全体構造を初期段階に検証することによって、システムが必要な 機能を備えているか、実現が可能なのかを検証することができる。特に、機能実現のために は、どこに困難があるのかを予め検証することによって、プロジェクトのリスクを小さくす ることができる。 3 4 システムが使用するデータを外部記憶媒体（ハードディスクやフロッピーディスク）に記憶する際 に、効率的利用になるように設計をする。 「インターフェース設計」「ファイル設計」「データ項目設計」をもとに、どのようなプロセスで 要求を処理するかを設計する。 318 ソフト開発プロセスモデルと製品属性 図1 ウォーターフォールモデル システム可能性 検証 検証 計画と要求分析 検証 製品設計 検証 詳細設計 検証 コーディング 単体 (モジュール)テスト 結合テスト 検証 実機でのシステム テスト 検証 運用・メンテナンス 検証 出典）Boehm (1988, p. 62). 二つめは、設計とコーディングのステージを分けることによって、モジュール単位の開発 の恩恵を得ることができる。恩恵のひとつは、複数のモジュールのコーディング期間をオー バーラップさせることで、全体のコーディング期間を短くさせることができる点である。ま 319 立本 表2 博文 6 分野における計画納期を守れる確率 6分野における計画納期を守れる確率（%） システム 軍需 情報システム アウトソース 市販 ユーザー開発 規模（FP) ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア ソフトウェア 平均 1 99 98 98 98 99 95 97.83 10 96 93 95 97 98 75 92.33 100 88 84 86 88 89 50 80.83 1,000 75 65 68 74 75 5 60.33 10,000 54 38 30 47 35 - 40.8 100,000 28 15 5 24 10 - 16.4 平均 73.33 65.5 63.67 71.33 67.67 56.25 66.88 出典）Jones (1996, 邦訳, p. 71). た、モジュールの設計を予め行い、各モジュール間のインターフェースを定めてあるので、 コーディングするものは、モジュール間の設計の理解に労力を割かなくて良い。このため、 それほど熟練していない技術者を使用したコーディングが可能になる。 三つめは、ステージの逆流を抑えることで、プロジェクトの進捗状態が把握できるように なる。ソフトウェアは、他の物理的な人工物と異なり、容易に変更できてしまうという性質 を持つ。このため、次々とソフトウェアの改善・修正が部分的に行われるという状況がおき やすい。このような場合、プロジェクトがゴールに近づいているのか、それとも改善・修正 のために工期が延びたのかがわからなくなり、混乱し、管理ができなくなることがある。フ ェーズごとに検査工程をおくことによって、プロジェクト進捗管理ができるようになった。 ウォーターフォールモデルは、特に大規模システムソフトウェアに対して適応されると言 われている。Brooks (1995) では、IBM のシステム 360 の開発事例を挙げ、コーディング前 に詳細設計を文章化することにより、コミュニケーションの問題を解決することができたと している。コミュニケーションの問題とは、プロジェクトの規模が大規模化すると、各作業 者の間のコミュニケーションコストが無視できないほどになることである。システム 360 の 開発事例では、手引書となるような目的、外部仕様書、インターフェース仕様書、内部仕様 書などの管理に注力したので、プロジェクトを成功させることができたとしている。 システムソフトでは、ウォーターフォールモデルの開発手法を取りいれることにより、特 に大規模なプロジェクトの成功率をあげることに成功しているとされている。Jones (1996) は、6700 のソフトウェアの開発プロジェクト調査し、六つの分野ごとのソフトウェアの成 320 ソフト開発プロセスモデルと製品属性 功率を測定している。それによれば、10000FP5以上の規模の開発プロジェクトの場合、シス テムソフトウェアがもっとも高い成功率を持っていることがわかった（表 2） 。 さまざまな利点を持つウォーターフォールモデルであるが、実際に運用してみると、いく つか不具合がでてきた。その主なものをあげると、 1． 結合（統合）テスト時に各モジュール間でインターフェースの解釈の違いにより、不 整合がおきる。 2． 必要な機能を定めてから（要求定義）、製品が完成するまで、期間が長いので、完成 する頃には、機能が時代遅れになっていたり、マーケットに受け入れられないことが ある。 3． 製品を作る際に、ユーザーとの距離が遠くなりがちなので、機能は十分だとしても、 使いづらいものになってしまうことがある。 このような、不具合を受けていくつかの新たなモデルが主張された。例えば、Boehm (1988) の主張するスパイラルモデルなどがこれにあたる。Boehm は、ウォーターフォールモデルで は、全体統合・評価が一度のチャンスのみであることが、弊害の原因であると考え、プロジ ェクトを小さなプロジェクトに分け、何回も全体統合・評価の機会を設けることを主張した。 しかし全体的に眺めるなら、Boehm の主張したことは、ウォーターフォールモデルの否定 ではなく、ウォーターフォールモデルに、反復的なプロトタイプサイクルを置くことによっ て、特に設計プロセスの情報の精緻化を狙った改良である。 現在でも、ウォーターフォール的なプロセス管理は、広く普及しており、もっとも影響力 の強いプロセスモデルであると言える。 5. シンクアンドスタビライズモデル 1980 年代になると、パーソナルコンピュータが爆発的に普及を始めた。この主な背景は、 パーソナルコンピュータを構成する部品、主に CPU やメモリなどが高機能、低価格化した ことである。ムーアの法則6が示すように CPU が高機能化・低価格化したために、コンピュ 5 6 ファンクションポイント。論理的にプログラムの規模を図るファンクショナルポイント法により試 算されたプログラム規模の単位。従来行われていた行数によるプロジェクト規模の推定（LOC: Lines Of Code）は、 「解決されたタスクの大きさ」を代表するには、不適当であるので、入出力などの論 理的な構造を検査することで、プロジェクトの大きさとする。IBM の開発者であった Albrecht and Gaffney (1983) によって、提唱された。 「同一面積のチップに埋め込まれる回路数は、18 ヶ月ごとに 2 倍になる」とする主張。ムーアの法 則のゴードン・ムーア氏は、米インテル社の設立者のひとりである (Groove, 1995)。 321 立本 博文 ータのダウンサイジングが起こり、パーソナルコンピュータが普及した。 マイクロコンピュータ革命ともよばれるこのようなパーソナルコンピュータ普及を背景 に台頭してきた製品分野が、パッケージソフト製品である。パッケージソフト製品は、特定 の顧客や少数の顧客の依頼によって作るものではなく、数百あるいは数百万の顧客への販売 を目的として開発するソフト製品である。 パッケージソフトの分野でベストプラクティスと考えられているソフトウェア開発プロ セスモデルが、Cusumano and Selby (1995) によって、紹介された「シンクアンドスタビライ ズ」モデルである。彼らは、マイクロソフト社のソフトウェア開発プロセスを調査し、そこ で特徴的に行われている開発プロセスを「シンクアンドスタビライズ」プロセスと名づけた。 このプロセスを「毎日構築プロセス」と呼ぶこともある。特にマイクロソフト社の製品の中 でも Microsoft Office シリーズにこの特徴は当てはまるとしている。 「シンクアンドスタビライズ」モデルは、必ずしもマイクロソフト社だけが行っているプ ロセスではない。むしろ、他のパッケージソフトメーカーでも同様のプロセスをとっている 可能性が高い。『マイクロソフトシークレット』の中で、インタビュー対象のマイクロソフ ト社のシルバーバーグは、彼がボーランドに在籍していたときに、「段階的な中間目標と毎 日構築プロセス」を用いてライバル製品であったマイクロソフト社のクイック・パスカルに 対応したことを述べている。また、Cusumano and Selby (1995) も、このようなプロセスは、 マイクロソフト社に独自のものではないとしている。マイクロソフト社で特徴的なのは、こ の毎日の構築の頻繁性が他社と比べたときに際立っていることだとしている。 以前、ボーランドでこのチーム（ターボ・パスカルのチーム）の責任者だったブラッド・シル バーバーグは、…「ビルドは定期的に行われる。ターボ・パスカルの場合は、だいたい毎日、ビ ルドを作った。…大手の中でおそらくマイクロソフトにいちばん似ているのがボーランドだろ う。」(Cusumano & Selby, 1995, 邦訳, 下巻, pp. 21-27). 「ウォーターフォールモデル」と比較した際の「シンクアンドスタビライズ」プロセスの主 な特徴は、次のとおりである。 「ウォーターフォールモデル」では、開発プロセスの中の各ステージは厳格に区別され、 各ステージごとに検査が存在した。しかし、「シンクアンドスタビライズ」モデルでは、大 まかに「計画段階」 「開発段階」 「安定段階」の 3 段階に区別されるが、各段階の区別はウォ ーターフォールと比べ、緩やかなものである。「開発段階」途中であっても、仕様変更が可 能である。この点は、ウォーターフォール的な開発とは、まったく異なっており、ウォータ ーフォール的な開発では、コーディング前に詳細設計を完了させており、どのような関数が 必要かまで特定されている。一方、 「シンクアンドスタビライズ」モデルでは、詳細設計と 322 ソフト開発プロセスモデルと製品属性 図2 シンクアンドスタビライズモデル マイクロソフトの典型的なプロジェクトのプロセス プログラム管理、開発、テストの同期安定化プロセス 段階 期間 計画 3～8ヶ月 中間目標 開発計画 仕様書（細部は決めない） スケジュールの完成 開発 6～12ヶ月 サブプロジェクト1 仕様決定とコーディングは同時的 サブプロジェクト2 何回かの中間目標を設定 サブプロジェクト3 画面の確定 機能の完成 安定化 コードの完成 3～8ヶ月 ゼロ・バグ版 製造開始（出荷日） 各サブプロジェクト 全体2～4ヶ月 コーディングと最適化 6～10週間 テストとデバッグ モジュールごとに独立作業 機能の安定化 統合を頻繁に繰り返す 統合 2～5週間 テストとデバッグ 予備期間 2～5週間 出典）Cusumano & Selby (1995, 邦訳, p. 273). 図2 323 立本 博文 コーディングは同時的に行われている。 ウォーターフォールモデルでは、進捗状況は、開発プロジェクトが、どのステージにいる かによって把握されている。例えば、プロジェクトが「詳細設計」ステージを終了したのか、 または、 「統合テスト」ステージを終了したのかといったような把握のされ方をする。一方、 「シンクアンドスタビライズモデル」では、プロジェクト中にいくつかの中間目標を設定し、 そのマイルストーンが達成されたかどうかで進捗管理をする。 「シンクアンドスタビライズ」モデルは、毎日構築モデルと呼ばれるように、頻繁な結合 テストを実施する。基本的な作業は、モジュールに別れての並行独立なコーディング作業と 成果物を頻繁に持ちよっての統合テストを繰り返す｡7 「段階的な中間目標と毎日構築プロセス」のもっとも大きな利点は、環境変化の大きいパ ッケージソフトウェアの分野において、理論的には、製品を常に出荷できる状態にしておく ことにより、ライバル他社に先駆けて迅速な行動をとることができる点である。 大きな環境変化に対して、製品をモジュールごとに構築することで、変化をモジュールご とに吸収することができる。これは、仕様が顧客とのやり取りの中で決定されるシステムソ フトを背景に構築されたウォーターフォールモデルとは、まったく異なる。ウォーターフォ ールモデルでは、基本的に「徐々に増加するユーザー要求」や「コーディング中の仕様変更」 などは、想定されていない。むしろ、そのような仕様変更は、悪いことだとされ、そのよう なことがないように十分にコーディング前の詳細設計をすることを求めている。 ウォーターフォールモデルとシンクアンドスタビライズモデルが背景とする条件は、次の 2 点においてまったく異なる。 ひとつは、「徐々に増加するユーザー要求」の問題があるかないかである。ウォーターフ ォールモデルが背景とするシステム製品は、基本的に顧客との間の要求分析から、基本仕様、 概要設計が作られるため、「徐々に増加するユーザー要求」の問題は起こりにくい。むしろ 追加要求が入ったときには、はじめからウォーターフォールのプロセスをやり直すことが考 えられる。そうでないと、コーディング中の混乱によりプロジェクトが失敗する確立が大き い。 それに対し、パッケージソフト製品では、ライバル他社よりもよい製品を作ることが目的 7 世界中でもっとも利用されている WWW サーバーとして有名な Apache も同様に頻繁なビルドを通 して、モジュール間の整合性を保つとともに、ソフトウェアの機能のチェックを行っている。ASF (Apache Software Foundation) では、Nightly ビルド、Milestone ビルド、Release ビルドという三つの 頻度でビルドを行っている。いちばん頻度が高いのが Nightly ビルドで、開発者が現在コミットし ているソースファイルを使用して、ビルドを行う。十分テストされ安定板とされるものが Release ビルドであり、その中間が Milestone ビルドである。 324 ソフト開発プロセスモデルと製品属性 である。たとえ、自社がよい製品であると思っていても、マーケットの中で相対的に品質が 悪いと消費者に判断されてしまえば、プロジェクトは失敗に終わってしまう。そのため、常 にマーケットの様子をうかがいながら、場合によってはプロジェクト途中に追加要求が入る ことが多々ある。そのため、製品をモジュールに分割し、仕様の変更をモジュールレベルで 吸収することに意味が出てくる。モジュールレベルで変化を吸収するために、頻繁な統合テ ストが必要となる。このことは、ウォーターフォールモデルよりも、非常に手間のかかるこ とであり、無駄な工数が生じやすい。リワーク（やり直し）も頻繁に生じる可能性がある。 しかしながら、製品のマーケットでの相対的な品質には、貢献するだろう。また、もし、ウ ォーターフォールモデル的に開発していたならば、かかっていたであろう開発期間を省くこ とができる。 二つめは、後工程にいくにしたがって増大する不確実性をどのように取り扱うかという問 題である。システムソフトでは、製品のシステム設計の段階で、そのシステムが動作するプ ラットフォームを決めてしまう場合が多い。そのため、後工程とりわけコーディング段階に おける、プラットフォームに対する不確実性はきわめて少ない。このため、コーディング前 に詳細設計を行うことが可能であり、無駄のないモジュール化を行うことができる。コーデ ィング期間中のモジュール間の調整、統合テストも、あらかじめ、概要設計、詳細設計の段 階で考慮されていたものであるのだから、頻繁に行う必要はない。むしろ、モジュールごと に独立して作業ができるので非常に効率のよいコーディングができる。 一方、パッケージソフトでは、前述のようにユーザーがパッケージソフトを使用する環境 は、変化しやすい。例えば、ハードウェアにマウスがつくという事態になれば、それまでの CUI ベース8のソフトウェアは、その構成をまったく変えなくてはならなくなるだろうし、 インターネットという安価な通信手段がプラットフォームに標準的であるならば、ソフトウ ェアを構成するコンセプト自体がまったく異なってくるだろう。 パッケージソフトの分野では、このようなユーザー環境変化が大きいために、必ずしも事 前に予測的なコーディングをすることができない。むしろ、やってみて初めてわかることも 多い。この時には、モジュールに別れて作業していたチームは、頻繁に統合テストを行い、 お互いが製品として整合性をもって作業をしているかを確認することが必要になる。 三つめとして、一般にウォータフォールモデルが想定しているシステム開発の規模とシン クアンドスタビライズモデルが想定しているパッケージ開発の規模とでは、システム開発の 規模の方が大きいという傾向がある。このため、システム開発では、インターフェースを早 8 キャラクター・ユーザー・インターフェース。文字ベースの画面で構成されたユーザーインターフ ェース。 325 立本 博文 期に定めることでプロジェクトの混乱要因となる不要なコミュニケーションコストを下げ ることを考えている。パッケージソフト開発は、比較的開発規模が小さいため、ビルドを頻 繁に繰り返すことにより、インターフェース間の整合が取れる。ただし、ここで注意しなく てはならないのは、シンクアンドスタビライズがパッケージソフトを背景にして生まれたモ デルであったとしても、それが大規模プロジェクトに適応できないという理由にはならない。 代表的な例は、Windows NT 開発プロジェクトである。このプロジェクトは、新しい OS 開 発という非常に大規模なプロジェクトであるにもかかわらず、はじめて毎日構築プロセスを 導入したプロジェクトとして有名である。大規模プロジェクトでのシンクアンドスタビライ ズモデルの適応性に関しては、まだ確定的ではない。 このように、ウォーターフォールモデルとシンクアンドスタビライズモデルでは、その背 景としている製品条件が異なり、それにより現在でもなお、二つのプロセスモデルが並存し ていると考えられる。 以上、二つのモデルは、製品レベルの環境相違と関連づけて議論することができたが、次 の節では同一製品セグメントの中で、プロジェクトの時系列に関連付けた議論をする。 6. 探索モデル 前節で、ウォーターフォールモデルとシンクアンドスタビライズモデルを説明した。両者 の背景となるのは、汎用機、ミニコン、パソコンというようなビジネス主体のコンピュータ であった。 しかし、日本のほぼ唯一の競争力のあるパッケージソフトであるゲームソフトに目を転じ てみるとどうであろうか。前述のソフトウェア産業の歴史で、コンピュータゲームについて は触れなかったので、ここで簡単に説明する。 コンピュータゲームは、もともとアメリカが唯一の生産国であった。1972 年に Atari 社が 業務用ゲーム「PONG」をヒットさせたことで、業務用の市場が立ち上がった。その後、1977 年に Atari 社は、Atari2600 というカートリッジ交換式の家庭用ゲーム機を発売し、家庭用ゲ ーム市場が形成され始めた。しかし、当時はソフトの違法なコピーが横行し、ゲームソフト の粗製乱造のため、アメリカ国内市場は 1983 年の末に一気に縮小してしまった。 ちょうどそのころ、日本でも、各メーカーから家庭用ゲーム機が発売されていた。その中 で 1983 年に「ファミリーコンピュータ」を発売した任天堂が、人気のあるソフトを発売す ることで市場を勝ち抜いていった。アメリカが本家であった家庭用ゲーム機の市場は、日本 が一方的に輸出する産業へとなっていった (平林, 赤尾, 1996)。 1983 年から現在までの家庭用ゲーム機の進化を見てみると、3 回の世代交代をしながら急 326 ソフト開発プロセスモデルと製品属性 速に性能を高めていった。1983 年には、枯れた技術の集まりであったゲーム機は、現在で は最先端のワークステーションの性能を凌駕するほどであり、コンピュータグラフィックス、 サウンド、アニメーションなど最先端のコンピュータ技術の集大成とも言えるものになって いる (宮沢, 武田, 柳原, 1999)。 ソフトウェア開発プロセスに、こうした急速な技術進化は大きく影響を与えている。技術 変化は、ハードの世代交代とともに訪れるので、ソフト開発者は新しいハードが発売される と新しい技術を大量に吸収しなくてはならない。 しかし、技術変化とともに、ゲームソフトがエンターテイメントであるという性格も強く 影響を与えている。特にゲーム開発者は、インタラクティブで面白いものという文法の上で、 新しい技術で何が提供できるのかを考えている。そのため、プロジェクトには、「何が新し い面白さで、他のソフトとの違いは何であるのか」ということが強く求められる。 ここで、ウォーターフォールモデル、シンクアンドスタビライズモデルとゲームソフトの 開発を比較してみよう。 ウォーターフォールモデルとシンクアンドスタビライズモデルの場合、ある機能を実現す る際に、さまざまな困難があり、その困難に対してどのように対処するかということに焦点 を当てている。実現する機能目標が所与であるという意味で、二つのプロセスモデルは、問 題解決型のプロセスモデルであると言える。 一方、ゲームソフトの開発の場合、「新しい面白さ、他のソフトと違う面白さ」が強く求 められるため、どのような新機能を生み出していくのかという問題設定の部分に焦点があた っていくと思われる。 例えば、ある製品開発プロジェクトが、そのプロジェクトチームにとって、過去に類似の プロジェクトの経験がある場合であれば、実現する機能がある程度明確であるため、漠然と であっても設計図が描け、それに応じた人員配置やスケジュール設定ができる。 それに対して、新機能を実現し、更にその新機能がユーザーにとって価値あるものとする ためには、実験的な色彩の濃いプロジェクト運営となり、ゲームソフトの開発プロセスは、 前述の二つのプロセスモデルとは異なっている可能性が高い。 しかしながら、具体的にどのように実験的であるのかという点については、いままでのソ フトウェアプロジェクト管理では、触れられてこなかった。 馬場 (1998) は、この点に着目し、まったく新しい新機軸のソフト（以下、新作ソフト） とシリーズ化されたソフト（以下、続編ソフト）では、プロセスに違いがあるはずであると 主張している。彼は、特に機能と商品力が非線型になり易いゲームソフトを例に挙げ、以下 のように主張している。 327 立本 博文 続編ソフトについては、マイクロソフト社が行っているような「シンクアンドスタビライ ズ」モデル的なプロセスを踏むであろうと考えられる。グラフィック、サウンドといったよ うなモジュールレベルのレベルアップにより、ソフトウェア製品のグレードアップがなされ るであろうと予測している。馬場は、その例としてスクウェア社の「Final Fantasy VII」の開 発事例を挙げ、そのプロセスがモジュール的に進行し、個々のモジュールのレベルアップで 製品のレベルアップをしているとしている。 馬場は、新作ソフトにおいては、続編ソフトと異なるプロセスが存在するとしている。新 作ソフトには、 「それまでになかった面白さをつくる」ということが重要なポイントになる。 そのような開発プロジェクトの場合には、モジュールに別れての作業というよりは、プロト タイプを繰り返すことによる作り直しによる製品コンセプトの具現化プロセスが必要であ るとしている。この例として、彼は、SCE 社の「パラッパ・ザ・ラッパー」をあげ、その開 発プロジェクトが最後までプロトタイプとその作り直しであったことを強調している。この 際、プロデューサーを中心にした濃密な各開発者とのコミュニケーションが特徴的であり、 そうしたプロデューサー中心の開発プロセスが開発の最後まで続き、プロトタイプの作り直 しの作業が開発プロセス全般を占めるとしている。ただし、SCE 社の「パラッパ・ザ・ラッ パー」の開発事例は、戦略的なプロジェクトであったため、開発費用など通常のプロジェク トと同列には並べられない点、SCE 社がハードウェア供給者であるのでソフト開発費用を度 外視できた可能性がある点で限定的である可能性を指摘している。 上記のような限定つきではあるが、次のような考察ができるのではないだろうか。 ゲームソフトは、パーソナルコンピュータのパッケージ製品と同様に変化の激しいプラッ トフォームの上で動作している製品であり、消費者のニーズの不確実性も高い。その点から 見れば、シンクアンドスタビライズ的なプロセスモデルに適合的な製品である。しかしなが ら、その中でも新作と続編ではプロセスモデルの違いが存在し、とくに新作ソフトでは筆者 が観察したような実験的なプロセスがあるのではないだろうか。 このことを、製品レベルのギャップと、そのプロジェクト自体の時系列的なギャップに留 意しながら解釈すると次のようになるであろう。 シンクアンドスタビライズ的なプロセスモデルが実行可能であるのは、製品コンセプトが 決定しているからであり、それは換言すれば製品を構成する要素要素の関係性が、製作する 際に確定的であるからである。製品コンセプトと製品のモジュール構成の関係性が、すでに 作られているときには、モジュール化が行いやすく、そのもっとも象徴的なプロセスモデル がシンクアンドスタビライズであると考えられる。 その一方で、新作の製品を作るプロジェクトの場合であれば、表現したい製品コンセプト 328 ソフト開発プロセスモデルと製品属性 と製品アーキテクチュアの関係性は不明である。そのため、どのように製品を作ればよいか ということがそもそもの問題となる。アーキテクチャを探索的に作る段階が必要となり、そ の段階では試行錯誤が頻繁に起こり、モジュールごとに作業ということはできない。 次の節では、三つのプロセスモデルを比較する。 7. ソフトウェア開発モデルの比較類型化 概要設計の決定 製品を開発するためには、概要設計が必要である。製品の仕組みが簡単であったり、安定 的である場合には、概要設計は自明のものとなり、概要設計探索は短時間で終わる。また、 以前に行っていたプロジェクトを引き継いだプロジェクトであれば、概要設計が以前のプロ ジェクトで既に行われている可能性が高い。 一方、製品の仕組みが複雑であったり、製品を実現する技術が不安定である場合には、概 要設計は自明のものでない。この場合、どのような概要設計にするべきかが探索される。ま た、新規プロジェクトの場合には、概要設計から行われることが多く、概要設計の変更も多 い。 詳細設計とコーディングの関係 詳細設計が、コーディング前に決められる場合には、コーディングが二つの意味で効率的 に行われやすい。ひとつは、無駄なコーディング作業を省くことができる。もうひとつは、 モジュール間のコーディングを事前に最適に調整できることである。しかしながら、詳細設 計に時間がかかることもあり、詳細設計とコーディング全体として開発時間が短縮されるか どうかは、分からない。 一方、対象とするプラットフォームが新規であったり、複雑であるので、コーディングに 際して不確実性が高い場合、コーディング前に詳細設計を決定することができない。その場 合には、詳細設計とコーディングが同時的に決定される。 結合テストの頻度 モジュール間のインターフェースが、明確で固定的であれば、結合テストはステージを決 め、一度で終わらせることができる。結合テストの回数が少ないほど、コストを低く押さえ ることができる。 一方、モジュール間のインターフェースが、流動的である場合には、結合テストを頻繁に 行う必要がある。また、製品全体がどのようにできるかをチェックする（進捗状況のチェッ ク）ためにも、詳細設計が流動的である場合には、頻繁に結合テストをすることが有効であ る。 329 立本 表3 ソフトウェア開発モデルと特徴 ウォーターフォールモデル 概要設計の決定 詳細設計とコーディング の関係 結合テストの頻度 博文 シンクアンドスタビライズ モデル 探索モデル 確定的 確定的 探索的 前後順列的 同時並行的 同時並行的 1度 頻繁 頻繁 類型化 「ウォーターフォールモデル」 「シンクアンドスタビライズモデル」 「新作・続編モデル」の 三つを説明した。それらを「概要設計決定」 「詳細設計とコーディングの関係」 「結合テスト の頻度」の三つのポイント毎に説明した。それらを表に整理すると表 3 のようになる。 ウォーターフォールモデルは、「概要設計決定段階」を確定的に進め、詳細設計とコーデ ィングを別々のステージで行い、モジュールごとのコーディングが終了した後に、結合テス トを行う。結合テストは、ステージを決めて行われ、基本的には 1 度のステージで済むよう に考えられている。ウォーターフォールモデルでは、下流工程から上流工程への逆流を防ぐ ため、各ステージごとに検証作業を行っている。 ウォーターフォールモデルでは、詳細設計とコーディングが前後順列的に行われるため、 コーディングが調整的に行われる。コーディング段階で、無駄に重複したコーディングをな くし、インターフェースもコーディングに先立って、モジュール間で整合的に設計されてい るために、効率的なコーディングを行うことができる。 逆に、下流工程から上流工程への逆流が頻繁に起こる可能性がある場合、ウォーターフォ ールモデルは、非常に非効率な開発モデルとなる。したがって、不確実性が小さい場合にウ ォーターフォールは適合的なモデルであると考えられる。 このモデルを概念モデル I とする。 シンクアンドスタビライズモデルは、「概要設計決定段階」を確定的に進め、詳細設計と コーディングを同時並行的に行い、結合テストを頻繁に行っていると考えられる。「概要設 計決定段階」が確定的であるとは、マイクロソフトの例では、前作のプログラムフレームワ ークをそのまま利用する点である。 「詳細設計とコーディング」を同時並行的にすることで、 モジュールレベルでの自由度を大きくし、追加的な仕様変更に対応することができる。この ため、コーディング中に、ユーザーニーズの変化や技術的な変化を盛り込むことが可能とな り、変化が激しい環境に適応することができる。モジュールレベルでの自由度が高いため、 モジュール間のインターフェースがコーディング中に変更される可能性が高いため、頻繁に 330 ソフト開発プロセスモデルと製品属性 図3 ソフトウェア開発プロセスの概念モデル 概念モデルⅠ ウォーターフォールモデル 計画段階 コーディング段階 結合テスト段階 詳細設計 概要設計 目標設定 各モジュール毎のコー ステージを決めた結合 ディング テスト 概念モデルⅡ シンクアンドスタビライズモデル 毎 日 構 築 プ ロ セ ス段 階 計画段階 概要設計 目標設定 詳細設計 と 各モジュール毎のコーディング 頻繁な結合テスト が同時並行的 概念モデルⅢ 探索モデル 計画段階 概要設計確定段階 毎 日 構 築 プ ロ セ ス段 目標設定 探索的な概要設計 概要設計 詳細設計 実験的コーディング 詳細設計 と 頻繁な結合テスト 各モジュール毎のコーディング が同時並行的 結合テストをおこなう必要性がある。このモデルを概念モデル II とする。 探索モデルは「概要設計決定段階」を探索的に行い、詳細設計とコーディングを同時並行 的に行い、結合テストを頻繁に行っていると考えられる。新既製品の場合、どのような作り 331 立本 博文 にしたら製品を実現できるか、またどのような作りにすれば計画したような製品を実現でき るか、ということを概要設計で行わなければならない。この場合、概要設計の決定は探索的 に行われると考えられる。このモデルが適合的な製品は既存製品からの変化量が、三つのプ ロセスモデルの中でもっとも高いと考えられる。このモデルを概念モデル III とする。 これらの概念モデルをまとめたものが、図 3 である。 8. まとめ ソフトウェア開発プロジェクトをどう扱うかというのは、1970 年代から力を入れられて きた問題であった。その根本的な問題意識は、毎年ソフトウェアを構築するコストは増大し てきており、構築した後のメンテナンスに対してもコストが増大してきている、それにもか かわらず、なかなかソフトウェアの開発プロジェクトをうまく進めることができずにいる状 態をどのようにして克服するかということが主眼であった。 その後、ソフトウェアにもその性質によってさまざまあり、システムソフトウェア開発と パッケージソフト開発とでは、プロジェクトの進め方が異なると認識され始めた。システム ソフトウェア開発では、入念に事前設計をすることによって、開発のモジュール化がおこな われ、並行開発を可能とするとともに、段階による進捗管理を可能にした。 一方、パッケージソフトウェアでも、モジュール毎の開発が行われているが、それは市場 ニーズや技術変化に対して柔軟性を確保し、適応するために使われていると考えられている。 その代表的な例が、マイクロソフト社のオフィス製品であったり、ネットスケープ社のブラ ウザーである。 しかし、技術・市場変化に対応する場合、ある局面では、モジュール単位での開発は意味 を持つであろうが、もっと根本的な変化に対しては、やはり実験的なプロセスを経るのでは ないだろうか。むしろ、そもそもモジュール単位での開発ができるということが、何が求め られているのかというニーズの問題とどう実現するかという技術の問題が事前にある程度 わかっているからできることであると考えられる。しかしながら、では、どのように実験的 であるのかという風に考えてみた場合、実はあまりわかっていないことが多い。前述のよう に、この部分に焦点を当てた研究というのは、少ないと思われる。 以上、ソフトウェア開発プロセスに絞って、研究の流れを見てきたが、今後の展開として 以下のようなことが考えられる。 第一に、組織と開発プロセスは、密接にかかわっており、その視点からもう一度ソフトウ ェア工学を見直すことで有益な洞察を得られると思われる。ソフトウェア工学は、実学的な 性格を強く持っており、この結論は当然のことである。このためには、経営組織、開発工程 332 ソフト開発プロセスモデルと製品属性 管理といったキーワードを同時に見る必要があり、経営の観点からの蓄積が必要であろう。 日本の大手ソフトメーカーは、ソフトウェア工学の成果を取り入れることで、生産性の向 上を実現してきた (Cusumano, 1991)。とくにソフトウェアコードの再利用に関しては、大き な結果を残してきた (Tracz, 1995, chap. 18)。しかしながら、Microsoft に代表されるようなア メリカのパッケージソフトメーカーは、異なる方法で製品を開発し、成功してきた。Microsoft 社内では、日本でよく知られた CASE ツールの使用は、自分たちとは関係のないことだとい う認識があった (Yourdon, 1997, chap. 6)。このことを考えると、ソフトウェア工学が模索し ていた道とは違う道もあり、それを現場から捕らえなおすことは意味があるだろう。一方、 Cusumano and Selby (1995)でも指摘されているように、Microsoft では「同じ解決策の再発見、 試行錯誤が多い」という欠点もあり、よりソフトウェア工学が貢献できる余地がある。 第二に、製品属性と開発プロセスの関係をもう一度見直してみる必要があるように感じる。 製品属性と製品開発の間にコンティンジェンシーがあるという見地に立てば、システムソフ トウェアとパッケージソフトウェアという製品属性の違いが、製品開発プロセスに影響を与 えていると解釈できる。製品属性と製品開発の間の関係性については、藤本 (2002) が指摘 しており、製品開発プロセスとそれを支える組織デザインを考える上で重要である。藤本・ 安本 (2000) では、産業・製品分野間比較の観点から効果的な製品開発の要因を検討してい る。 一方で、製品属性が違ったとしても、共通した成功要因がある可能性も否定できないと思 われる。たとえば、システムソフトウェア＝ウォーターフォールモデル、パッケージソフト ウェア＝シンクアンドスタビライズモデルといった図式は、製品属性と開発プロセスのコン ティンジェンシーのように解釈されてきた。しかし、本論文の中で紹介したように、この図 式は、ソフトウェア産業の歴史からの発想である。Windows NT の開発事例があるように、 もう一度、この図式を見直してみたほうがよいように思う。 このことは、モジュール間の調整コストを下げる工夫がソフトウェア開発に取り入れられ たことが大きく影響していると思われる。従来は、大規模開発は、コミュニケーションコス トの増大を招くため、ウォーターフォール的開発が推奨されていたが、モジュール間の調整 コストを下げる仕組みを作ることにより、モジュールでの分業ができるようになった。 同様に、設計情報がデジタル化することで、開発プロセスに影響を与える例が報告されて いる。竹田 (2000) は、情報機器の設計プロセスに新世代の CAD が大きく影響を与えた例 を報告している。また、Thomke (1998) では、ASIC の開発でコンピュータシミュレーショ ンが実験的な設計に貢献したと報告している。このような効率化が今後競争の焦点のひとつ となると考えられる。しかし、設計情報のデジタル化によって、製品開発プロセスは効率的 333 立本 博文 になり得るが、それを支える組織変数などは、まだ蓄積中の段階であると思われる。 第三に、日本の数少ない競争力を持つパッケージソフトの例であるゲームソフトの開発事 例を研究することで、ユーザーにとって新しい価値を作りつづけるためには、どのような取 り組みが必要なのかを理解する助けになるように思う。ゲームソフトは、娯楽品（エンター テイメント）であるため、常に昨日よりも新しいもの、面白いものをユーザーはもとめる。 結果として、ソフトメーカーは、ユーザーに新規で面白い価値を提示していかなくてはなら なかった。 しかし、改めてユーザーに新規で面白いという価値を提示するということを考えてみると、 その行為は、ほとんどの消費財に当てはまるのではないだろうか。現在、エンドユーザーが 購入するもので、エンターテイメント的な要素がないものはほとんどないだろう。今までは、 役に立てば、製品は売れたものであるが、商品が世の中にあふれてくると、役に立つものが 必ずしも売れるものとは限らない。 その意味では、従来、製品開発の生産性という点からの研究が多かったように思うが、今 後は、売れる製品を作るという意味で、製品の有効性を実現できるような製品開発の視点が あるように思う。 謝辞 この論文は笹川平和財団からの助成金(S-202-22)を受けて行われている「市場とボランタリの協働 としてのリナックス・モデル」の研究成果の一部である。ここに記して謝意を表したい。 参考文献 Albrecht, A. J., & Gaffney, (1983). Software function, source lines of code, and development effort prediction: A software science validation. IEEE Transactions on Software Engineering, 9(6), 639-648. 藤本隆宏 (2002)「新製品開発組織と競争力―我田引水的文献サーベイを中心に―」『赤門マネジメン ト・レビュー』1(1), 1-32. 2002 年 4 月 25 日 http://www.gbrc.jp よりダウンロード. 藤本隆宏, 安本雅典編 (2000)『成功する製品開発 産業間比較の視点』有斐閣. 馬場靖憲 (1998)『デジタル価値創造―未来からのモノづくり原論』NTT 出版. Boehm, B. W. (1981). Software engineering economics, Englewood Cliffs, NJ: Prentice-Hall. Boehm, B. W. (1988). A spiral model of software development and enhancement, IEEE Computer, 21(2), 61-72. Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., et al. (2000). Software cost estimation with COCOMOⅡ, Englewood Cliffs, NJ: Prentice-Hall. 334 ソフト開発プロセスモデルと製品属性 Brooks, F. P., Jr. (1995). The mythical man-month: essays on software engineering (Anniversary ed.). Reading, MA: Addison-Wesley. Connell, J. L., & Shafer, L. (1989). Structured rapid prototyping: An evolutionary approach to software development. Englewood Cliffs, NJ: Prentice-Hall. Cusumano, M. A. (1991). Japan’s software factory. New York: Oxford University Press. Cusumano, M. A., & Selby, R. W. (1995). Microsoft secrets. New York: Free Press. 邦訳, M･A･クスマノ, R･ W･セルビー (1996)『マイクロソフトシークレット 勝ち続ける脅威の経営』(上下巻). 山岡洋一訳. 日本経済新聞社. Cusumano, M. A., & Yoffie, D. B. (1998). Competing on Internet time: lessons from Netscape and its battle with Microsoft. New York: Free Press. Dahl, O. J., Dijkstra, E. W., Hoare, C. A. R. (1972). Structured programming. London: Academic Press. DeMarco, T., & Lister, T. (1999). Peopleware: Productive projects and teams (2nd ed.). New York: Dorset House. Groove, S. A. (1995). High output management (2nd ed.). New York : Vintage Books. 長谷川裕行 (2000)『ソフトウェアの 20 世紀 人とコンピュータの対話の歴史』翔泳社. 平林久和, 赤尾晃一 (1996)『ゲームの大学』メディアファクトリー. Iansti, M. (1998). Technology integration: Making critical choices in a dynamic world. Boston, MA: Harvard Business School Press. Jackson, M. A. (1975). Principles of program design. London: Academic Press. Jones, C. (1996). Patterns of software systems failure and success. London: International Thomsom Computer Press. 邦訳, 『ソフトウェアの成功と失敗』(1997) 伊土誠一, 富野壽監訳. 共立出版. 河村一樹 (1995a)『ソフトウェア工学』ソフトバンク. 河村一樹 (1995b)『ソフトウェア工学入門』近代科学社. McCarthy, J. (1995). Dynamics of software development. Redmond, WA: Microsoft Press. 宮沢 篤, 武田政樹, 柳原孝安 (1999)『コンピュータゲームのテクノロジー』岩波書店. Myers, G. L. (1975). Reliable software through composite design. New York: Mason Charter. Stevens, W. P., Myers, G. J., & Constantine, L. L. (1974). Structured design. IBM Systems Journal, 13(2), 115-139. 竹田陽子 (2000)『プロダクト・リアライゼーション戦略 3 次元情報技術が製品開発組織に与える影 響』白桃書房. Thomke, S. H. (1998). Managing experimentation in design of new products. Management Science, 44(6), 743-763. 335 立本 博文 Tracz, W. (1995). Confessions of a used program salesman. Reading, MA: Addison-Wesley. Warnier, J. D. (1974). Logical construction of programs. New York: Van Nostrand-Reinhold. Yourdon, E. (1996). Rise & resurrection of the American programmer. Upper Saddle River, NJ: Prentice-Hall. Yourdon, E. (1997). Death march: The Complete software developer’s guide to surviving “Mission Impossible” Projects. Upper Saddle River, NJ: Prentice-Hall. Zachary, G. P. (1994). Showstopper!: The breakneck race to create Windows NT and the next generation at Microsoft. New York: Free Press. 〔2002 年 7 月 8 日受稿; 2002 年 7 月 23 日受理〕 336 赤門マネジメント・レビュー編集委員会 編集長 編集委員 編集担当 新宅 純二郎 阿部 誠 粕谷 誠 片平 秀貴 高橋 伸夫 西田 麻希 赤門マネジメント・レビュー 1 巻 4 号 2002 年 7 月 25 日発行 編集 東京大学大学院経済学研究科 ABAS/AMR 編集委員会 発行 特定非営利活動法人グローバルビジネスリサーチセンター 理事長 片平 秀貴 東京都千代田区丸の内 http://www.gbrc.jp 藤本 隆宏