ソフトウェア開発が抱える問題を工学的なアプローチで解決しようとする試みが長く続けられてきた。しかし現状では成功しているとは言えない。現場での適用を難しくしている大きな要素がソフトウェア技術の進化の方向性だ。技術は実装に近い段階から生まれるためソフトウェア開発全般で活用するにはそれなりの時間がかかる。個々の技術論にとらわれすぎず，開発全体を見渡す大きな視点を持つべきだ。（本誌）
ソフトウェア開発の成否は，開発にかかわるメンバーの人間的な要素に大きく左右される。プロジェクト管理や，システムに対する顧客の要求の抽出，開発メンバー間での情報共有や合意。メンバー同士の円滑なコミュニケーションや，モチベーションの維持も必要だ。
これらは，技術者個々の知識や経験に依存する部分が多い。だからソフトウェア開発には属人性があり，開発者によって品質と生産性に大きな差が出る。これだと納期や開発コストを適切に見積もることができない。このためスキルの低い人でも一定水準の品質と生産性が得られるよう，ソフトウェア開発を工業化し，ソフトウェアの品質と生産性を改善しようとする試みが続いている。しかし，現在のところ成功しているとは言えない。
そもそも，ソフトウェア工学を成功させるのはたやすいことではない。ソフトウェアを開発するのが人間である以上，完全な工業化は不可能である＊1。品質についても生産性についても，優れた技術者に頼らざるを得ない局面は少なからず存在する。ただその部分を差し引いても，ソフトウェア工学にまつわる課題はいくつもある。
本稿ではまず，ソフトウェア開発における工学的アプローチの適用を難しくしている要因を大局的な視点から検証する。次に，ソフトウェア工学の各要素を個別に取り上げながら，基本的な問題点を明らかにしていく。
有効な新パラダイム創出には時間がかかる
ソフトウェア工学は，さまざまな技術を使ってソフトウェア開発全体を体系化することを一つの目標としている。しかし，個別の技術をソフトウェア開発の全般にわたって有効に適用できるものに発展させるのは，容易なことではない。技術は多くの場合，限られた領域を対象としたものとして生まれることが多いからだ。全体に適用可能な技術に発展できるものは一部に限られるし，発展させるにはかなりの時間がかかる。
これは，考えてみれば当たり前のことだ。しかし現状ではこのことを十分に認識しないまま，工学的アプローチを適用しているケースが少なくない。工学的アプローチが失敗に終わることが多い原因は，ここにあるのではないだろうか。
ソフトウェア開発を考えたとき，その成否に特に大きな影響を与えるのは，開発プロセスの初期段階における意思決定である。具体的には，要求分析と定義，ドメインの分割，適切なパラダイムとアーキテクチャの選択，開発方法論や開発チーム体制の決定，ソフトウェア資産管理の確立などである。つまり開発の初期段階に適用される技術こそがカギになる。
しかし，そのような技術がソフトウェアの上流工程から生まれることは珍しい（別掲記事「要求から見た実装技術の未発達と進化」参照）。ソフトウェア開発で使われる各種技術は，一般的に実装に近いレベルから誕生して抽象レベルが高い方向へ波及する。パターンを例に考えてみよう。まず，コーディング規約からデザイン・パターンへと進化し，フレームワーク化されてプログラミング・モデルとなった。さらにそのプログラミング・モデルの下で，より上位のコーディング規約やデザイン・パターンを生み出した。同時に，パターンの思想がさらに上流の分析モデルに適用されて，アナリシス・パターンへと進化した。こうした技術発展の方向性はほかにも多くの例がある＊2 。どれも，当初想定されていた問題の領域よりも広い適用範囲に拡大し，抽象化や体系化，開発アプローチの導入などを伴いながら，抽象的なコンセプトへと進化している。
逆に経営的価値を持つコンセプトから出発して，実装技術へと進化する方向性はなかなか生まれない。その理由はいくつかある。最も大きいのは，基盤がなければ上位部分の発展が難しいことだ。例えばWebサービス。WebサービスはSOAPプロトコルの確立から，BPEL（Business Process Execution Language）によるWebサービス連携のワークフロー記述，契約定義やサービスレベルの定義などへスコープを拡大しながら，SOA（Service Oriented Architecture）に基づくアーキテクチャ開発プロセスとなった。通信プロトコルであるSOAPの標準化なしには，上位のフレームワークの構築はできない。つまり必然的に帰納的な発展を見せる。
また，経営的な立場にある人は技術者でないことが多い。技術的な専門性や先見性を持たないので，新しいソフトウェア・パラダイムの創出を期待するには無理がある。さらに，本来はこうした側面を補うべきITベンダーも新たなパラダイムを提示できていない。経営的視点から新技術を生み出すのでなく，既存の技術を基に経営的価値に結びつける方向が主になっている。
つまり，工学的アプローチをソフトウェア開発全体の価値に結びつけるには，それなりの時間がかかる。実装レベルから生まれた技術が，ソフトウェア開発のライフサイクル全体に影響を与えるパラダイムへと進化を遂げるのを待たなくてはならない。現時点では，これをきちんと認識している技術者は多くない。個別の技術論にとらわれすぎたり，個々の技術を把握できたらそれ以上の全体的なことを考えようとせず，その段階で理解を止める場面が見受けられる。
要求から見た実装技術の未発達と進化業務の要求が個々の実装技術の進化を引き起こすことがある。例えば業務の分析結果である概念モデルでは，一つの概念モデルのインスタンスが時間によって異なる役割を演じる場合がよく見られる。別の言い方をすればインスタンスの役割が場面や時間によって動的に変わる。 しかし一般的なオブジェクト指向プログラミング（OOP：Object Oriented Programming）言語の場合，一つのクラスは複数インタフェースを継承できるものの，振る舞いの種類は常に固定的で，時間によって切り替えることはできない。このため，動的な役割の変更を実装するには限界がある（図A[拡大表示]）。そこでOOP自体の進化か，OOPによって実装されるコンポーネントが動作する仮想マシンの進化，またはフレームワークの進化が求められることになる。 データモデルの定義方法に関するフィードバックもある。ビジネスの要求に応じて，適したデータモデルは変化する。現在では，事業部をまたいだデータ連携が求められている状況を受けて，従来とは異なるデータモデル定義が必要になっている。 業務システムでは，銀行口座の種別に応じて利子や費用の適用方法が変わるなど，業務プロセスによって商品の属性が異なる場合が多く見られる。従来のオブジェクト指向分析/設計では，銀行口座のバリエーションとして，普通口座，当座口座，ローン口座などに分類し，親となる銀行口座のサブタイプとして定義することが多い（図B[拡大表示]）。 今までは，これを実装する段階で，各事業部によって事業に必要となる属性だけを持つ商品データを物理的に分離して，独自の定義をするのが一般的だった。一つのシステムだけを考えればこの方がシンプルで，実装しやすかったからだ。しかしこれでは，同じデータを事業部横断的に利用したいという要求が出てきたときに対応が難しい。その結果いわゆるデータの孤島システムとなり，データやソースコードが冗長性を持ってしまっていた。 これに対して，最近では企業システム全体でデータモデルを体系づける必要が出てきている。事業の効率化，広域化が進み，事業部をまたいでデータを共通化して連携を図り，企業全体のビジネスの可視化と最適化を目指すことが求められているからだ。つまり，新たなデータモデルを考えなければならない。このとき注意すべきは，概念モデルでの分類法と，設計や実装法の技術選択を分離して考えることだ。 企業システム全体でデータを共通化しようとすると，概念モデルとしての商品に対して，サブタイプを使って各事業部ごとの差分を実装すればよいように思える。しかし，この方法ではサブタイプのバリエーション数が増えすぎて，管理しきれなくなる。プラットフォーム実装技術の制約を受けてうまく実装できない場合もあるし，技術変化に対して迅速に対応できなくなる可能性も出てくる。だから分析段階ではサブタイプで定義していても，設計実装では別の構造を考える余地を残すべきだ＊A。設計，実装レベルのモデル化では，デザイン・パターンの適用を工夫したり，静的なOOPよりも柔軟性の高いプロトタイプ言語を選択することなどが必要となる。 |
萩原 正義 Masayoshi Hagiwara／マイクロソフト Software Architect1993年マイクロソフト入社。北海道大学，早稲田大学非常勤講師。.NET開発，アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向，フレームワーク実装技術，開発方法論，データ中心アプローチとオブジェクト指向分析／設計との融合，モデル駆動型アーキテクチャ，サービス指向アーキテクチャなどが現在の興味対象。趣味は，IT業界の著名人との雑談とウィンター・スポーツ。ソフトウェア技術の発展に貢献することが夢。 |
