本記事はIEEE Software マガジンに最初に掲載されたものだ。InfoQとIEEE Computer Societyにより、ここに掲載する。
何がアーキテクトをその道の達人にするのだろうか？ アーキテクトはどうやって設計を極めるのだろうか？ 私は幾度となくこうした質問を受け、幾度となく自問してきた。ソフトウェアエンジニアリングプロセスや設計メソッド、技術、プログラミングの専門知識といったものが答えでないのは明らかだ。確かに多くのアーキテクトは優れた深い技術的知識をもっており、それが実際に設計が成功するのに欠かせない基盤となっている。だが多くのソフトウェアプロジェクトは、アーキテクチャにおける大きな課題のために、失敗したり苦しんでいる。その道の達人になるために重要なこと、それは、どうやって設計に取り組むか、何を見極めるか、どこに着目して仕事をするか、ということだ。
（欠けている）線は何を伝えているのか、いないのか
図1はある過去のプロジェクトから引用したもので、アーキテクトがシステムのベースライン設計を説明するために作ったトップレベルダイアグラムを表している。
このダイアグラムには、システムのキーコンポーネントとその責務、コアとなるモジュール化原則の概要が説明されている。アーキテクトはこのスケッチを使って、マネジメントと設計についてコミュニケーションし、プロジェクトに要するコストや時間、開発工数といったビジネス面の予測について議論した。ところが、マネジメントはあとになって、なぜプロジェクトは大幅に遅れて予算オーバーになったのだろうか、と考えるはめになった。彼らはアーキテクトのレポートから、どんなヒントも示唆も得られなかったのだ。
問題はこのダイアグラムの点線のところ、そして「線のない」ところで発生した。点線はこのプロジェクトで開発したプロプライエタリなメッセージングミドルウェアを示している。このダイアグラムには、コンポーネント間のコミュニケーション関係、特にミドルウェアを経由するものが完全に欠けている。アーキテクトは自分の視点から、システムのドメインやビジネスケースに貢献しない基本的な技術インフラについて説明した。ところが予算の多くは、ミドルウェアの開発に費やされた。安定性やパフォーマンスに問題があり、できる開発者は他の部分の開発から手を引かされ、このミドルウェアの欠陥修正に投入された。さらに問題のあるミドルウェアを土台にしたことで、ドメインコンポーネントの開発に多大な工数を要した。
（画像をクリックすると拡大）
図1. ビジネスステークホルダーと重要な設計判断についてコミュニケーションするためのハイレベルなアーキテクチャスケッチ。
もののあいだを設計する
あとになって考えてみると、このシステムのアーキテクトは「目に見える」ものに注目しすぎていたことがわかる。ユーザインターフェイス、ドメイン固有コンポーネント、データ管理、永続化、... しかし、アーキテクチャ上の問題はコンポーネント内ではなくコンポーネント間で発生していた。基盤となる技術インフラを含む他のシステムとのインターフェイスやインタラクション、インテグレーションで問題は発生した。アーキテクチャ仕様はこれらも辛うじて触れていたため、実際に問題が発生するまで、アーキテクトと開発者がそこに注目することはなかった。
これ対して、達人アーキテクトはもっと「もののあいだにあるもの」に注意を払っている。コンポーネントのあいだにあるもの、標準データ型の裏に隠れたドメインコンセプトといったコードの行間にあるものにだ。確かに彼らも実際のコンポーネント設計について指針を出すが、たいていの場合、それは開発チームがさらに分解や具現化するのに十分なレベルまでだ。一方、もののあいだにあるものは、実際にアーキテクトによる現場での泥臭い作業が必要になる。これこそがアーキテクトの領分でなくてはならない。こうした「もののあいだにあるもの」を実際にどう設計したらよいのか不確かであれば、なおさらだ。それでは達人アーキテクトの秘訣について調べていこう。
隠れたドメインコンセプトを明らかにする
最近、私はあるシステムのコードに対して、タグクラウドジェネレータを実行してみた。最も重要なドメンコンセプトが何なのか、知りたかったためだ。驚くべきことに、システム全体で一番使われていたデータ型はstringとintだった。本当にそうなのか、私は目を疑った。なぜなら、産業向けやエネルギー管理用のシステムでは、デバイス、パワーライン、センサー、アクチュエーター、タグ、アラームといったコンセプトの方がはるかに重要であるためだ。コードを詳しく調べてみると、確かにドメインコンセプトは存在していたのだが、多かれ少なかれ、stringやintのような無味乾燥な基本型であちこちにちらばっていることがわかった。
このようにドメインコンセプトが隠れていると、開発者がシステムを理解して具現化するための労力、また製品品質を確保するための労力が相当必要になるだろう。どうすればintが実際にドメイン固有のコンセプトを表現しているとわかるのだろうか？ 具体的な計算のなかでintが使われているとき、どうすればドメイン固有のコンセプトの制約を強制できるのだろうか？ 決まりを作ってコメントに書いておくことぐらいしかできないだろうが、それも実際の現場では役に立たないだろう。図2は1996年の初フライトで自爆を引き起こしたアリアン5の（コメントの入った）コードを示している。1 根本原因はintegerのオーバーフローの保護が不十分だったことだ。2
（画像をクリックすると拡大）
図2. アリアン5のコードの一部。integerオーバーフローの保護が不十分であったことが1996年の初フライトにおけるアリアン5の自爆を引き起こした。
もし明確に定義された利用規約を含む適切な値を取り得る型として速度をモデル化しておけば、アリアン5のソフトウェアエラーは避けられたはずだ、と主張するのには勇気がいるかもしれない。しかしこの例からも、明確なモデリングの重要性がよくわかるはずだ。
たとえドメインコンセプトが明確であっても、それは無数の詳細の奥深くに埋まってしまうおそれもある。たとえば、私はかつてあるシステムの複雑さについて調査したことがある。そのソフトウェアには、何とインターフェイスとして300を超えるメソッドをもつ名前サービスが含まれていたのだ! そのサービスの実際の規約が何なのか、外からはほとんど見えなくなっており、開発者はそれを正しく効率よく使うのに苦労していた。ソフトウェアをよく分析したところ、サービスが要求している規約は実は20以下のメソッドで十分実現できることがわかった。
達人アーキテクトは、アーキテクチャにおけるすべてのドメインコンセプトを明確に描くことに一番注意して仕事をする。これは粗いコンポーネント、小さなドメイン固有データ型、重要なインターフェイスなどによって表現される。3,4 達人アーキテクトがコンセプトをモデリングするときには、混乱や複雑さを避けるため、またコンセプトの本質を目立たせるため、常に簡潔さに注力する。4 その結果、暗黙のコンセプトや連携機能がすぐに目に見えるようになる。これは開発者がその存在について認識し、区別し、明確で意味のある型として扱うのに役立つ。利用が型 - 表現豊かなソフトウェア設計とロバストな実装を作るための重要なプラクティス - になるのだ。
ものが出会うところにいる
アーキテクチャとは何だろうか？ Eoin Woods氏はこの疑問についてじっくり考え、ついにその回答を見つけた。それは次のような背景にあるドライバではないかというものだ。「アーキテクトが日々使っているさまざまな考え方、フレームワーク、ブローカー、レイヤー、インターフェイス、メッセージング、コネクター... これらはみなギャップのことだ! [...] アーキテクチャとは、ソフトウェア設計者の成果物を弾力性、柔軟性、拡張性に富んだ、最終的に使いやすいシステムへとまとめる接着剤である。」5
この結論はかなり真理を突いている。確かに「システムがサポートしなくてはならないワークフローがあるのに、それをサポートしていないコンポーネントインターフェイスがある」というのはよく聞く話だ。多くのプロジェクトではインテグレーション - システムインテグレーションだったり、「ただの」構成要素のインテグレーションだったり - は一番コストがかかるところだ。そのギャップ - ものが出会うところ、コンポーネント間のインタラクション - には誰も責任を感じていない、ただ達人アーキテクトを除いて。明確かつ意味のあるコンポーネントのインターフェイスを設計し、コンポーネントのあいだを実装してワークフローを支援するのは、実際のところやさしいタスクではない。ユーザがシステムで実行するタスクに合わせて、コンポーネント間のインタラクションを定義するのは難しい。6
そして、システムを他のシステムと統合するとき、個々のシステムの品質を低下させずに、システム横断のワークフローをサポートするのは、さらに困難なことだ。こうしたトピックに関するパターン文献もこの見解を支持している。7,8
この「隙間」には、実際のところ、アーキテクトの注意と実務経験がかなり必要だ。しかし、つなげなくてはならないもの - インターフェイス、インタラクション、コンポーネント、システム - のあいだの適応はあまり注力されていない。それは主にサポートすべきワークフローに沿った、これらのあいだの利害調整にある。6 目標は最も無駄のない適応であり、最もすばらしいマッピングではないのだ! これこそがアーキテクチャが発生するところであり、ここでの判断はシステムのライフサイクルコストに大きな影響を及ぼす。このコラムの最初にある苦労話もまさにここにある。すなわち、ものが出会うところだ。
この「中間にあるもの」を設計するという考え方は、あらゆる自己完結システムにも広げることができる。たとえば、異なる計算ノードにあるもの、異なるプロセス内、異なるスレッド内など。私は処理エンティティの糊付けの甘さのために失敗したプロジェクトを見てきた。コンピュータ、プロセス、スレッドに分散したエンティティで動くインタラクションを作るのは単純だ。しかし、ネットワークインタラクションやスレッド間の同期の必要性を最小限にする（分散された）プロセス間インタラクションを作るのは、設計における達人技だ。7
不確かさをドライバとして使う
私たちはみな、曖昧なシステム要求について不平を言う。しかし、たとえビジネスステークホルダーが非常に注意深く要求を引き出したとしても、曖昧さや不確かさがすべて解決するわけではない。それが現実だ。同様に、ソフトウェアエンジニアは特定の要求に対して複数のソリューションを作ることができ、どの案を使うべきか判断するのにかなりの時間を費す。しかしアーキテクトは、システムのリリース時にビジネスに関わる要件を満足するのはもちろんのこと、そのシステムのライフタイムのあいだ、ずっとそうあり続けるシステムを設計、開発、納品するという難題に直面しなくてはならない。開発期間が長くなればなるほど、システムのライフタイムが長くなればなるほど、その不確かさは大きくなる。
このような状況でアーキテクトが選んでしまう典型的な逃げ道が汎用性だ。これは最終的に柔軟性へとつながる。こうしてできたアーキテクチャは、潜在的に想定し得るありとあらゆるシステム構成を理論的にサポートできる仕組みを備えることで、過剰な負荷がかかってしまう。たいていの場合、これは重要な構成の具体的（非機能）要件を十分満足できずに終わることになる。9
達人アーキテクトにはこの危険ゾーンがわかっており、判断のドライバとして不確かさを利用する。10 まず彼らはいくつもの選択肢があることを認識し、バリエーションや選択の影響を限定するため、設計の可変なところを分離しようと努める。さらに要求や具体的設計の選択肢にある不確実さを明確にするため、システムの利用シナリオを追求して、それをプロトタイプやウォーキングスケルトン（Walking Skeleton）として実現する。9 彼らは、プロトタイプやウォーキングスケルトンにより判断をドライブしたり調整するフィードバックループを、喜んで受け入れる。そして再び、もののあいだにあるもの、この場合、曖昧で不確かな要求や代替設計案のあいだにあるものを設計するのだ。
このコラムのタイトルは「人類未踏の地へ勇敢に進もう」だ（訳注: 『スタートレック』より）。これはアーキテクチャ設計にぴったりだろう。もののあいだへ進もう。隠されたドメインコンセプトを見つけるために、コードの行間を。インターフェイスやワークフローの設計に指針を出すために、自分のシステムや外部システムのコンポーネントのあいだを。意思決定をドライブするために、不確かさやオプション案のあいだを。「あいだにあるもの」をできるだけ早く明らかにし、明確化し、判断を下すこと、それがアーキテクトの仕事だ。そして、これに関連するアーキテクチャメソッドやテクノロジに関する深い知識と周到なプラクティスと組み合わせること、それがアーキテクチャにおける達人技だ。ソフトウェアシステムの痛点における思慮に富んだ設計が、最終的にプロジェクトの成否を決定づけることになる。
参考文献
1. J-J. Levy, "Un Petit Bogue, Un Grand Boum!" (in French), 2010.
2. J-L. Lions et al., "Ariane 501 Inquiry Board Report," 1996.
3. E. Evans, Domain Driven Design, Addison- Wesley, 2004.
4. F. Buschmann and K. Henney, "Five Considerations for Software Architecture, Part 1, IEEE Software, vol. 27, no. 3, 2010, pp. 63-65.
5. E. Woods, "Architecting in the Gaps," 2011.
6. F. Buschmann, "Unusable Software Is Useless, Part 1," IEEE Software, vol. 28, no. 1, 2011, pp. 92-94.
7. F. Buschmann, K. Henney, and D.C. Schmidt, Pattern-Oriented Software Architecture-A Pattern Language for Distributed Computing, John Wiley and Sons, 2007.
8. G. Hohpe and B. Woolf, Enterprise Integration Patterns-Designing, Building, and Deploying Messaging Solutions, Addison-Wesley, 2003.
9. F. Buschmann, "Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases," IEEE Software, vol. 27, no. 1, 2010, pp. 10-11.
10. K. Henney, "Use Uncertainty as a Driver," 97 Things Every Software Architect Should Know, R. Monson-Haefel, ed., O’Reilly, 2009, pp. 321-361.
Frank Buschmann 氏はSiemens Corporate Technologyのシニア主任エンジニアであり、System Architecture and Platform Departmentの主任アーキテクトを務めている。コンタクト先はfrank.buschmann@siemens.com。
本記事はIEEE Software マガジンに最初に掲載されたものだ。IEEE Softwareのミッションは、リーダーとなる将来のソフトウェア開拓者のコミュニティを作ることだ。このマガジンはエンジニアとマネージャが急速なテクノロジの変化に遅れないよう、信頼でき、有用で、最先端のソフトウェア開発情報を提供する。