変革の時代を迎えたソフトウェア産業
－開発の手戻りをしないために－

日本アイ・ビー・エム株式会社
布川薫

第２回開発工程の決め方（2）

さまざまな開発工程／開発様式

ソフトウェア・エンジニアリングの分野では、1970年に米国のロイス（W.W.Royce）によって初めて開発工程が形式化されたのを皮切りに、今日まで様々なパラダイムが提唱され実用化されている。以下にその主なものを紹介する。
●ウォータフォール・モデル
ロイスによる最も典型的なソフトウェアの開発様式。開発工程を何段階かに分割し、前工程の出力を次工程の入力としながら滝が流れ落ちるように作業を進めるため、後戻りを許さない［図１］。この様式は今日、多くのプロジェクトにおいて採用されており、他のどのような開発様式もこれが基本となっている。
●スパイラル・モデル
ベーム（B.W.Borhm，1986）が提唱した、計画や要件定義、設計といった開発の上流の各段階でプロトタイプを作成し、それを洗練しながら工程を進める様式［図１］。この様式は、リスクが小さくなった時点から従来のウォータフォールに入る。しかし近年では、ごく小さな対象のシステム仕様とプログラムを試行錯誤的に段々とたたき直していく方法にこの名称が付けられている。ラウンド･トリップは、オブジェクト指向開発でのスパイラル型にあたる。また、大きな開発で一気にこの方式を用いると、プロジェクトが収束せず失敗するのが常なので十分な注意が必要である。
●インクリメンタル
対象をサブシステムやコンポーネントなど小部分に分割し、優先順位の高い部分から順次に作っていく方法［図１］。完成させた部分から順次に本番稼働させる場合は、インクリメンタル・デリバリー（Incre-mental Delivery）という。
●イタラティブ
分割した小部分ごとに複数の開発サイクルを繰返し、修正や改良を加えながら完成させていく方法［図１］。各サイクルごとに明確な開発目標を設定し、完了時にその達成度を評価してから次の変更や改良に進んでいく。ロレンツ（M.Lorenz， 1993）が提唱したこのやり方は、オブジェクト指向の開発にも適合し、通常２～４回の繰返しがプランされる。
●ＲＡＤ（Rapid Application Development）
短期間・高品質・低コストを目的に、マーチン（J.Martin，1991）によって提唱された開発様式。システムの目的や範囲が明確でリスクの少ない、小さなプロジェクトを切り出して開発する方法である。その特徴としては、
□少数精鋭チームでの開発
□エンドユーザの十分な参画
□タイムボックス開発
□自動化ツールとプロトタイピングの活用
などがある。タイムボックス開発は、対象を小さく分割し、各々３カ月、６カ月と期間を限定しインクリメンタルに開発するもので、期限を第一とするため、ときに優先順位の低い機能は切り捨てるか次回の開発にまわすこともある。
●クリーンルーム
ＩＢＭのミルズ（H.D.Mills， 1987）らが提唱した無故障ソフトウェアの開発を目指す手法。ＲＡＤと同様、少数精鋭・短期サイクルのインクリメンタル開発を基本とする。そのほか、 □固有の形式的仕様記述言語を用いて仕様を作成する □ブラックボックス（外部仕様）→ ステートボックス（内部仕様）→ クリアボックス（モジュール論理仕様）の３段階のボックス表現により設計を進める □毎日の検証により単体テストを省略できる □テストは開発チームとは別個の品質保証チームが担当する □使用頻度を想定したサンプリング・テストを重視するなどの特徴がある。これは主としてソフトウェア製品の開発などに適している。
●プロトタイピング
ウォータフォールやほかの開発工程と組合わせて用いるもので、
(1)システム化案の具体化／可視化を目的にユーザの目の前で直接デモの形で実施するもの
(2)迅速なユーザインタフェースの仕様固めに用いるもの（以上、“廃棄型”）
(3)最初に骨格部分のプロトタイプを作り順次これに肉付けしながら本番に仕上げていくもの（“進化型”）がある。いずれの場合も繰返し実施するので、適切なビジュアル開発ツールなどを用いることが肝要である。
開発規模が数百ファンクション・ポイント（COBOL換算で数万ステップ相当）以下といった小さなプロジェクトなら、最初からいろいろな <-- 99 --> 開発工程の検討が可能である。しかし、数千ファンクション・ポイントあるいはそれ以上の大規模／特大規模プロジェクトの場合は、局面化やサブシステム化の適用が必須となる。局面化（Phased Approach）とサブシステム化（Subsystemization）の目的は「大規模プロジェクトを実行可能／管理可能なサイズに分割する」ことであるが、局面化がプロジェクトの遂行期間を時間軸に沿って縦切りにするのに対し、サブシステム化は開発サイズの観点から横切りにする。
図２に示した「サブシステム化の要領」で大事なのは、サブシステムを決定するタイミングが外部設計（システムの方式設計）の開始後であり、外部設計の中程までにこれを確定することである［図２/上部］。大きな開発では、業務別に要件調査チームの分割を行ったりするが、これがそのままサブシステムにはならない。ＢＰＲ（ビジネス・プロセス・リエンジニアリング）の例を持ち出すまでもなく、現行の組織や業務処理のあり方自体が、必ずしも最適になっているとは言い難いためである。サブシステムは、業務における情報やデータの流れを中心にして、業務的な括りやデータや処理の配置（集中／分散など）といったシステム形態の観点での括りも考慮しながら、主要なデータストア（論理データベース）を中心とした処理のまとまりとして切り出す。この際、サブシステムの境界は、データの流れの「より簡素な部分」とし［図２/ 下部］、各サブシステムの独立性を高めることで、変更や修正に伴う相互の影響を最小限に抑える。（独立性の強い小さな開発ほど生産性が高まることは、第１回で言及した。）サブシステムは、インタフェースとなる受渡しデータを定義した後、確定する。

開発工程の組み方

クライアント／サーバやネットワーク・コンピューティングなどの新しい開発環境下での大きな規模の開発では、次のような開発工程をとるとよい［図３］。システム全体の整合性をとるために、要件定義を局面として実施する。要件定義局面のワークロード比率は、25％もしくはそれ以上とする。（これは、下流工程に効率的な開発ツールを採用することで、要件定義の比率が相対的に増加するためでもある。）要件定義の成果物である新システムの論理モデルをもとに、データと処理の実現方法を十分に検討しながら、サブシステム分割を行う。
外部設計～開発実施の間は、各サブシステムごとの特性や開発期間、要員数、使用するツールとその熟練度、プロジェクトのリスクなどを考慮し、ウォータフォール／ノンウォータフォールのいずれか、あるいはそれにプロトタイピングを組合せた工程をとる。すべてのサブシステムの開発が完了した後（ただし、インクリメンタル・デリバリー＝段階的なカットオーバーの方式をとる場合は、計画に基づき完了したサブシステムまで）、サブシステム間統合テストを局面として実施する。開発の最後に、業務システム全体としてのシステムテスト局面を実施する。
次回は、ＲＡＤやプロトタイピングを採用する場合の考慮点について詳述する。

profile
布川薫（ぬのかわかおる）
1971年群馬大学工学部電気工学科卒業、同年富士ゼロックス㈱入社。
1973年日本アイ・ビー・エム㈱入社、システム・エンジニアとして各種情報システムの開発、都市銀行システムの開発を担当。現在、サービス事業・コンピテンシーに所属し、アプリケーション開発方法論やプロジェクト管理技術などを担当。
副主管ＩＴスペシャリスト（次長）。
おもな著書に、『システムの開発と運用』、『アプリケーション開発技術』（いずれも共著、リックテレコム）