PR

開発プロセスも時代に応じて変化する

 ソフトウェア開発の個々の要素について見ていくと,以上に述べてきた課題とは別の要因も明らかになる。今回はそのうち,ソフトウェアの開発プロセスについて考えてみよう。

 ソフトウェア開発の方法論,開発プロセス,アーキテクチャの構築法,分類と体系化の手法は,時代に合わせて大きく変化してきたし,これからも変わっていく。ウォータフォール型,繰り返し型,統一プロセス(UP:Unified Process),アジャイル・プロセスなど既存の開発プロセスでは,もはや不足が生じている。

 既存の開発プロセスに共通しているのは,対象となるシステム構築をプロジェクト内に閉じた形で一体的に,1度限りのものとして扱う考えだ。開発対象システムの要求定義,アーキテクチャ構築,品質管理,運用管理,開発チーム体制などを一つのプロジェクトに限定して考え,その中ですべてを完結させる。

 現状では,既にこうした開発プロセスに対して大きく三つの要求が突きつけられている。まず一つが,開発中に発生する要求の変化や技術の変化への対応。変化に迅速に対応するには,リファクタリングや繰り返し開発が必須になる。またそれだけでなく,変化する部分と変化しない部分を分離する考え方を導入しなければならない。変化する部分は予見不可能だが,繰り返し開発を続けていけば変化しない部分が浮かび上がってくる。変化する部分が分かれば,それに柔軟に対応できる技術を選択しやすくなる。また,各開発プロジェクトにおいて要求や技術の変化に対応しなければならない部分を限定できる。システムの規模が大きくなっても,変化するのは限定された個所なのでカスタマイズが容易になり,迅速に対応できる。

 二つ目は,システムを長期的視点でとらえることである。このとき,変化しない部分を切り出すだけでなく,それをシステムの骨格部分(アーキテクチャ)として独立した形で変更/保守することが求められる。アーキテクチャは基本的には変化しない部分とはいえ,要求や状況の変化に応じて改変が必要になる場合もある。迅速に対応し,一貫性をもって保守する方法を考えなくてはならない。

 三つ目は,全体最適化の視点を取り入れることである。これは,企業の経営戦略に直結したシステム構築を目指すことを意味する。開発するシステムの性格が単一の業務処理システムから企業横断的な連携システムの構築へと変化するにしたがって,連携の性能向上,冗長性のあるソフトウェア資産のスリム化,運用管理の単純化などを図らなければならない。

 これらはどれも,システムを正しく分割/分類する作業に深く関連している。まず一つ目の要求は,問題領域における概念モデルやシステム構成要素を,本質的構成要素と側面(アスペクト)的構成要素とに分割する作業と関連する。変化する部分を側面的,変化しない部分を本質的な構成要素に対応づける。二つ目の要求は,類似のソフトウェア群を体系化する作業につながる。グループ化されたソフトウェア群ごとに,アーキテクチャを保守する。三つ目の要求は,システム構成要素のサブシステム化に関連する。システムから統一的な資産を切り出して冗長性を減らしつつ,サブシステムによる小規模化を図って単純化する。

 これらの要求に対応するには,システムを一つの開発プロジェクト内に限定した,1度限りのものとして扱う従来の開発方法論が,既に時代に適合しなくなってきていると認識することが大切だ。


萩原 正義 Masayoshi Hagiwara/マイクロソフト Software Architect

1993年マイクロソフト入社。北海道大学,早稲田大学非常勤講師。.NET開発,アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向,フレームワーク実装技術,開発方法論,データ中心アプローチとオブジェクト指向分析/設計との融合,モデル駆動型アーキテクチャ,サービス指向アーキテクチャなどが現在の興味対象。趣味は,IT業界の著名人との雑談とウィンター・スポーツ。ソフトウェア技術の発展に貢献することが夢。