IT業界における試行錯誤
業界全体としての取り組みに目を転じてみよう。ソフトウェアアーキテクチャを表現するための取り組みは、この言葉が1969年NATOカンファレンスで初めて登場して以降、実にさまざまな形で行われてきた。
たとえば箱＆矢印による表現は、その黎明期に登場した試みだった。これは会議で15分ほど役員に説明する程度ならいいが、人によって見え方が異なるため、かえって誤解のもとだ。
そうした中、私が考案したのは、建築家だった妹からその業界での青写真の描き方を聞いて発想したビュー＆ビューポイント（図2）だ。その後、アーキテクチャの4+1ビューモデルとなって、Rational Unified Processの中に入っていった。
アーキテクチャ設計手法については、いろいろ提唱されているが、本質部分は共通している。最初に要求があって、それを分析し、アーキテクチャ上判断すべきことをバックログへ貯めていく。
その後、アーキテクチャプロトタイプを作って評価。うまくいったことはバックログから削除し、うまくいかなかったことはバックログに追加し、その中で優先度を見直すというものだ。
そのほか、まだまだ改善の余地があるアーキテクチャ記述言語、アーキテクチャのために作られたものではないが、箱＆矢印手法よりはずっとすぐれたUML2.0、繰り返し発生する問題に共通の解決策を示せるパターン、標準、リファレンスアーキテクチャ、メソッド、目に見えないものを視覚化することで理解を大きく助けてくれるメタファーなどといったものもある。
捕捉すべきは設計判断
しかし、まだこれだけでは十分ではない。冒頭で、ソフトウェアアーキテクチャは重要な設計判断のセットであると述べた。実は、そこにはアーキテクチャを決定するための設計判断というものがある。アーキテクチャに関するナレッジとは、構造的な設計と設計判断から構成されたものなのだ。
設計判断には、たとえば、データベースにはOracleを採用するといった何かを入れるというものもあれば、逆にInformixは採用しないという具合に何かを入れないというものある（Ontocrises）。また、ドライバはC言語で記述するといったソフトウェアのプロパティに関する設計判断（Diacrises）もあれば、システムの半分は大阪で、半分は上海で開発するといった、技術的な問題ではないが設計に大きな影響を与える経営的な設計判断（Pericrises）もある（図3）。
これらの設計判断はそれぞれ属性を持ち、相互にさまざまな関係を持つ。たとえば、Javaを採用するという設計判断は、C++を採用するという設計判断と対立するといった具合だ。この設計判断はISO42010に取り入れられつつあり、4+1ビューモデルにも追加可能だが、実のところ、企業ではあまり取り組みが進んでいない。捕捉が困難で効果を得るのに時間がかかるからだ。
そこで、設計ツールや要求定義ツールなどからの設計判断情報の自動取得、ツールでのサポートなど、いろいろ模索されているが、現状はまだまだ発展途上段階である。しかし、アーキテクチャナレッジ（AK）＝アーキテクチャ設計（AD）＋設計判断（DD）であり、設計判断の理解・尊重なくして、包括的なソフトウェアアーキテクチャの表現は難しい。
今回のセミナーの講演スライド、および講演者を囲んで行われたワークショップの詳細はUMTPのWebサイトにて提供されています。
