システム開発においては、ソフトウェアアーキテクチャの存在がその品質を大きく左右する。それは異論のないところだろう。しかし、実際にこれを表現するとなると大きな壁を感じる企業も多いのではないだろうか。実は、そこには企業が取るべきナレッジマネジメント戦略があった。カナダ ブリテッィシュ・コロンビア大学のソフトウェア工学で教鞭をとり、かつてはIBM Rationalでラショナル統一プロセスの開発責任者としても名を馳せたフィリップ・クルーシュテン教授を招いて開催されたUMTPモデリング技術セミナーの模様をお届けする。
※UMTP（UMLモデリング推進協議会）：UML技術者認定試験やモデリング技術の研究や普及を推進するNPO
ソフトウェアアーキテクチャとは何か
ソフトウェアアーキテクチャは、高品質のソフトウェアシステムを開発する上で、重要な基盤となるものである。しかし、その定義はIT専門家の間でもまちまちで、私の友人がソフトウェアアーキテクチャの定義を書き込むための掲示板を用意したところ、50～60もの定義が集まったという。
その中でも、私が最も気に入っているのはRational Software社にいた時代に仲間と作ったものだ。ソフトウェアアーキテクチャというのは重要な設計判断のセットで、大きく2つのパートから成っている。ひとつは、構造をどのように構成するかというもの。通常、この構造はインタフェースを有し、ソフトウェア同士、ボトムアップアプローチやトップダウンアプローチでつながることで、大きなサブシステムを構成していく。もうひとつは、ふるまいをどう構成するかを規定するものだ。
また、ソフトウェアアーキテクチャはスタイルを持ち、その使用法、機能、パフォーマンス、可用性、信頼性、拡張性、上位互換性、再利用性、統一性などに加えて、コストと技術的な制約、審美性なども考慮したものでなければならない。
そのためにナレッジの資産化が必要
では、そのようなソフトウェアアーキテクチャをどのように実現するか。構築に必要なナレッジは、暗黙知のままとどまっているものが多いため、表現にはそれなりの努力が必要だ。
ナレッジが資産であるとはよくいわれることであるが、それならば、それをきちんと資本化するための手段を持つべきだろう。ナレッジを創造し、配り、共有し、これらを共通理解基盤とするというサイクルを確立するのである。
暗黙知の形式知化を説明するモデルとしてよく知られたものに、野中郁次郎と竹内弘高が提唱したSECIモデルがある。このモデルによれば、個人の暗黙知（tacit knowledge）は話し合われることで外部化し、文書に整理されることで形式知（explicit knowledge）となり、それら形式知と形式知の組み合わせが、ふたたび個人の新しい暗黙知となる。
オランダのDe BoerとFarenhorstは、ここに一般知（generic knowledge）と特定知（specific knowledge）という概念を加え、4象限から成る図を考案したが、ITの文脈でナレッジをマッピングすると図1のようになる。
企業のIT部門が常日頃行っているナレッジサイクルには、「フレームワークやIEEE標準、パターンなどの一般知を特定知に適用すること」、その逆に「特定知で得たナレッジを再利用のために抽象化して一般知とすること」「プロジェクトを経験するごとに要求仕様定義や設計判断といったものを洗練させていくこと」「特定知の抽象化により得たパターンや標準といったものを見直しを成熟化させること」などがそれにあたる。
これまで企業では、明示的なナレッジマネジメント戦略として、情報の集積化やパーソナリゼーションを進めてきた。前者は大きなリポジトリに個人の持っている暗黙知を保管し、いつでも取り出せるようにしようというもの。個人はリポジトリ充実のために貢献を求められることになる。どちらかというと官僚主義的でうまく機能しないことが多い。
一方、後者は誰が何を知っているかを記述したイエローページを持つイメージだ。情報の集積化では形式知に重みがおかれるのに対して、パーソナライゼーションは暗黙知を認めつつ、それをマネジメントに生かすという点に特徴がある。
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サイトにて提供されています。
