誰もが耳にして、誰もがさける魔法の言葉：アーキテクチャ

　さて今回はアーキテクチャの話である。……とはいいつつ、魔物ですね、このテーマは。「ワンランク上のエンジニア」を対象とする記事では、よく“アーキテクチャ”という言葉を見かける。プログラミング作法ではなく、アーキテクチャについて語ることが、「ワンランク上のエンジニア」の証であるかのように扱われているようにも思える。しかし、アーキテクチャという言葉自体は、非常に幅広く使われており、「どこからがアーキテクチャで、どこからがアーキテクチャではないのか」という境界は、この記事を書いている私自身、よくわからない。

ソフトウェア開発者ギルドへ

　本稿を書くにあたり、＠ITサイトでの過去の記事もざっくりと眺めてみた（とはいっても、タイトルだけだが）が、“J2EEのアーキテクチャ”や“.NETアーキテクチャ”やらの「フレームワーク解説」的実装に近い話から、いきなりEA(Enterprise Architecture)やSOAの話へと一気にジャンプする。「Rational Unified Process（RUP）」をはじめとする反復型開発を標榜するプロセスでは、多かれ少なかれ「アーキテクチャ・リスクを減らしましょう」とか「しっかりとしたアーキテクチャをつくりましょう」という“アーキテクチャ重視”の姿勢が打ち出されているが、そもそも「アーキテクチャって何か？」が明確でなければ、重視のしようがない。

　本稿では、［J2EEより上層］で［SOAほど上層じゃない］、個々のシステム開発プロジェクトにおいて意識すべき層にフォーカスをあてていきたい。

そもそもアーキテクチャって？ アーキテクチャに対する多くの見方

　「ソフトウェア開発者ギルド」を開始するときの露払いとして、オンラインのアンケートが実施されたことを覚えていらっしゃるだろうか？ Rationalという事業体は、ソフトウェア開発のベスト・プラクティスとして「反復型開発」や「コンポーネントベース・アーキテクチャ」を一貫して推奨してきたが、「では、日本の実際はどうなの？」という所を拾いだしたくてアンケートを行った。そこで、あえて“アーキテクチャ”という言葉を説明せずに、「皆さんが使っているアーキテクチャは何ですか？」という設問をおいたところ、ほとんどの方が、J2EEや.NETをアーキテクチャとしてあげていた。

　では業界のお歴々はどう見るか？ 「ITアーキテクト宣言」だ。厳密には開発者の役割としてのアーキテクトについて業界の著名人が言及したものであるが、逆にそこから「アーキテクトが扱うモノとしてのアーキテクチャ」の答えがないか……と思って読んではみたが、筆者の結論は「結局、大所高所からモノを見て、でもプロジェクトの金勘定はしない人」であった（あ、なんか、あちらこちらから怒られそう）。しかし、「大所高所から見たモノ」だけでは、“アーキテクチャ・リスク”って何かわからないし……。

Rational Unified Processにおけるアーキテクチャとは？

　そこで、まずは「Rational Unified Process」におけるアーキテクチャの定義をご覧いただこう。

　その環境におけるシステムの最も重要な概念です[IEEE]。特定時点でのソフトウェアシステムのアーキテクチャとは、重要なコンポーネント間のインターフェースを通じた相互作用の構成を示します。システムの組織の構成[UML]。アーキテクチャは、インターフェイスを通じて相互作用を行う部分、これらの部分を繋ぐ関係およびそれらを組み立てるための制約に、段階的に分解できます。インターフェイスを通じて相互作用を行う部分には、クラス、コンポーネントおよびサブシステムが含まれます。(Rational Unified Process Ver2003.06.13より引用)。

　そもそも、アーキテクチャという言葉自体は、単に“構造”といっているに過ぎない。上記の定義からは、次のことが読み取れる。

1. アーキテクチャは、システムの”分割”を表す。その分割単位は、何らかの視点で“重要度”が判別されうる、意味ある単位である
   
   
2. 分割されたモノの内部詳細よりも、他とのインターフェイスに注目する
   
   
3. アーキテクチャでは“動的側面”も取り扱う。この動的側面は、「インターフェイス」を通じた相互作用で表現される
   
   
4. アーキテクチャには、それを組み立てるにあたって、何らかの制約がある場合がある

　これをもう少し噛み砕いてみたい。例として、（個人的にはまってみたい）コンポーネント・ステレオを例にしてみよう。

コンポーネントステレオにみるアーキテクチャ

　まずは、「図 コンポーネント・ステレオの構成要素」をご覧いただきたい（って、ほんとはB＆Oの写真でも使いたいところですが……）。コンポーネント・ステレオの利点とは何だろうか？

図 コンポーネント・ステレオの構成要素

1. コンポーネント単位で機能を向上できる
   →「もっとよい音を！」
   
   
2. トラブル、故障を局所化できる
   →トラブルはコンポーネント単位で集約される。全部のコンポーネントに波及することは、よっほどの過電流でもない限り、珍しい
   
   
3. 他社製のコンポーネントでも付け替えることができる
   →これにより、複数ベンダーの製品を組み合わせた、自分にとってのベストなステレオを構築できる（予算の制約は当然あるが）
   
   
4. 機能的な重複が、All-in-Oneステレオに比べると少ない
   →無駄な過剰投資をさけることができる

　実は、これらはソフトウェア開発の世界で、コンポーネントベース開発が目指しているところのものと全く同じである。これらのメリットを実現するために、コンポーネント・ステレオの世界では、次の条件が満たされている。

1. 1単位のコンポーネントの提供する機能が、単一であること
   →単機能であるということは、試験しやすい、交換の対象としたときに機能的重複がすくない（＝無駄な投資をしない）ということにつながる。また、様々な組み合わせにおいても、使い回しが利きやすい
   
   
2. この機能を利用するためのインターフェースが明確に規定されていること。かつ、このインターフェイス規約が、汎用性を実現する程度には、業界標準化されていること
   →インターフェイスが規定されていれば、同じインターフェイスを持ち機能的に同等以上のほかのモジュールと交換することができる。このインターフェイスが業界標準化されていれば、異なるベンダの製品でも組み合わせることができ、自由度が高まる（赤と白のケーブルがインターフェイスの代表例でしょう）
   
   
3. 規定されたインターフェイス、機能が確実に機能するための動作条件が明確であること
   →あなたの部屋と南極は、気象条件等周囲の環境は全く違う。理想的にはあらゆる環境でも動くべきかもしれないが、あなたの部屋に置くステレオを南極仕様にするのは、過剰投資……というより単なる無駄だ。動作の前提となる条件が規定されていれば、品質保証もやりやすく、過剰投資も避けられる
   
   
4. インターフェイスを介した信号のやり取りの仕様が規定されていること
   →アンプからスピーカーに、音声信号が流れることはあっても、逆は（私の知る限り）ない。情報（この場合、音声信号）が処理される以上、処理の順番や手順、情報が流れる向きというものがある

　ソフトウェアアーキテクチャとは、上記に見るような所定の目的を達成するために必要な、分割と相互作用の構造のことなのである。

コンポーネントステレオに見るアーキテクチャリスク

　あなたは、お気に入りのミュージシャンのCDを今買ってきたばかりだ。封を切るのももどかしく、CDを入れ、Playボタンを……音が出ない。あなたはまず何を疑うだろうか？

• もしかしたら、電源が入っていないかも？
  
• ボリュームが“0”かも？
  
• コンポーネント同士を結びつけるケーブルがどこか抜けているかも？

　まず真っ先に疑うのは、あなたに対して公開されているインターフェイス（電源？ ボリュームノブ？）か、コンポーネント間を結びつけるインターフェイスの欠落（ケーブルが抜けてる。挿す場所を間違えている）ではないだろうか？ 個々のコンポーネントはばっちりメーカー保証付き。南極みたいな部屋で聞こうって訳でもないので、常識的な気温だ。そこであなたは、インターフェイスを疑う……。

　ここで議論したいのは、「日本の製造業ってのはたいしたものだ」という礼賛ではない。システムがシステムとして意味のある活動をするためには、個々のコンポーネントが十分な品質レベルに達成していることと同時に、ステレオの例に見るようなアーキテクチャが定義され、動かなければならないということだ。加えて言えば、前述のインターフェイスのリスクは、規定されたルールが守られている限り、コンポーネント内部の質には直接は関係ない（たとえ音質が悪くても、ケーブルが正しくつながっていれば、とりあえず音は鳴る）。

　その意味では、様々な処理のバリエーションを考慮して内部をじっくり作り込まなくても、ある程度アーキテクチャを規定することができ、検証（テスト）もできる可能性があるということだ。

将来の拡張性の鍵は、さらに“抽象化”

　前述の例では、CDプレイヤーを、“もっと音質の良い”CDプレイヤーに交換することはできる。しかし、このコンポーネント構造が、CDプレイヤーをベースに“デザイン”されていては、MDプレイヤーやMP３プレイヤーを組み入れることができない。アナログディスク全盛の頃にはCDプレイヤーなどは想像の範囲外であっただろうし、CDプレイヤー全盛時のエンジニアにとって、MP3やMDも同様だったろう。

　それでも、これらの将来発生した機能拡張に応えることができているのは、コンポーネント・ステレオのアーキテクチャが、アナログディスクプレイヤーやCDプレイヤーをそのままデザインのベースにするのではなく、「音を発生させるもの：音源」として抽象度を上げて捉えられているからである。“音源”としての性質を継承するものであれば、物理的なメディアは問わない。コンポーネントベースのシステムは、機能向上や、トラブル対応の局所化に効果がある（もちろん、再利用もある）。しかし、将来での拡張にも応えるようなベースとするためには、“抽象化”が必要不可欠となる。

J2EEや.NETはアーキテクチャと呼ぶのに違和感を覚える

　フレームワークを作ることを生業とする開発者ならいざ知らず、業務系システムを作る開発者にとって、気を配るべきアーキテクチャの範囲とはどこなのだろうか？ 確かに、J2EEや.NETはそれ自身のアーキテクチャを持つ。しかし、これらオブジェクト指向技術を基盤とするフレームワークを使う目的の1つは、「多様な変更に対応できる柔軟性」だろう。とするなら、その柔軟性に対処する場所は、J2EEや.NETの“上層”で動くシステムであるはずだ。

　システム全体で変更に対しての柔軟性を確保するために、MVCというアーキテクチャ・モデルがあるが、これも“表示系”、“IO処理”、“モデル”という単位で、変更の範囲を局所化したものだ。業務やビジネスモデルの変更が、システム開発の主要課題になっている今、アーキテクチャを考慮すべきは、MVCの“M”であるように思う。

　これが、“システムのアーキテクチャ”を問われた業務系システムの開発者が、J2EEや.NETのみを挙げることに対して違和感を感じている理由である。

次回は……

　次回は、反復型プロセスと併せて、アーキテクチャをどう設計していくか、その基本的な手順の話をしてみたい。そして、Rationalが提唱する「アーキテクチャへの集中」を理解する助けとなれば幸いである。ところで、今回の記事……、読み返してみると、なんだか技術記事ではなくコラムになってますね。

◆

　弊社主催のカンファレンス、IBM Rational Software Development Conference が10月7日と8日に行われた。今回は主催者側の予想を遥かに超える皆様にご参加いただき（なんと、90％以上の出席率！）、大変ありがたく思っております。おいでいただいた皆様本当にありがとうございました。またこちらの不手際で不快な思いをされた方もいらっしゃると思います。この場を借りてお詫び申し上げます。

　いやぁ〜でも、“お祭り”（不謹慎かな？）ってのはいいね、やっぱり。準備は直前までひ〜こらしていたんだけど、始まってしまえば、楽しかったなぁ〜。「のど元過ぎれば熱さ忘れる」って言うけど、本気でまたやりたいなと思ってしまったのでした。

ソフトウェア開発者ギルドに戻る