もしも今，アジャイルソフトウェア開発チームで仕事をしているのでしたら，お使いの環境を見回してみてください。物理的にせよ仮想的にせよ，ストーリボードやかんばんボードなどが用意されていて，未着手の作業や進行中の作業，完了した作業などが視覚的に表されていることでしょう。ソフトウェア開発プロセスの視覚化は，透過性を実現するための優れた方法です。現在の進行状況をハイレベルのスナップショットで表すことで，誰もが一目で確認できるからです。私たちの産業において，ソフトウェア開発プロセスの視覚化はここ数年間で長足の進歩を遂げました。しかしながら，実際に開発しているソフトウェアを視覚化する方法については，忘れられているのではないでしょうか。プロジェクトの完成ドキュメントのことを言っているのではありません。ソフトウェア開発プロセス 実施中 のコミュニケーションをも含んだ話なのです。アジリティ(Agility)とは素早く行動することであり，それには良好なコミュニケーションが必要です。ところが驚いたことに，ソフトウェアの設計についての効率的なコミュニケーションに，多くのチームが苦労しているというのです。
規定の方式，プロセスのフレームワーク，形式的記述
数年前を振り返ってみれば，構造化プロセスや形式的記述といったものが，ソフトウェア設計プロセスにおいても，完成した設計を伝える方法としても基準点になっていました。RUP (Rational Unified Process) や SSADM (Structured Systems Analysis And Design Method)，UML(Unified Modeling Language) などはその例です。ソフトウェア開発業界はさまざまな面で進歩を遂げてきましたが，私たちはその過程で，これらかつてのアプローチが持っていた素晴らしい部分のいくつかを忘れてしまったように思います。今日ではアジャイルデリバリとリーンスタートアップが隆盛ですが，その中で自分たちの開発対象を説明するためのコミュニケーション能力を失ってしまったソフトウェアチームもあります。このような状態のチームが技術的なリーダシップや方向性，一貫性を欠いていたとしても，不思議なことではありません。全員が同じ目標に向かって確実に貢献できるようにするためには，何を開発しているのか，というビジョンを効果的に伝えられることが必要です。もし俊敏性と迅速性が必要ならば，それらと同じようにビジョンを効果的に伝えられることも必要なのです。
UMLを捨てる
この業界には，ソフトウェアシステムの設計を伝えるための公式な標準表記として，UML (Unified Modeling Language) があります。私自身もUMLを使っていますが，どちらかというとソフトウェアの低レベル設計の面で重要な部分をスケッチするため，という控えめな使い方をしています。ソフトウェアシステムの上位レベルを説明する上で，UMLが便利だとは思いませんし，すでにUMLを放棄してしまったチームや単に知らないチームも多く，不便さを感じることが少なくないからです。このようなチームは大抵の場合，UMLの代わりに非公式なボックスやライン形式のスケッチを好んで使っています。ただしそれらの中には，口頭による説明がなければ意味をなさないようなものも多く，結果的にチームのパフォーマンスを下げることになります。この次，１つ以上の非公式スケッチを中心においたソフトウェア設計のプレゼンテーションを受ける機会があったならば，彼らはそのスケッチに沿って説明しているのか，あるいはプレゼンテーションの対象は彼らの頭の中に残ったままなのか，自問してみてください。
(画像をクリックして拡大)
UMLを捨てるのは構いませんが，アジリティを競い合う中で，多くのソフトウェア開発チームが視覚に訴えるコミュニケーション能力を失っています。NoUMLソフトウェアアーキテクチャスケッチ(上記)の例には，ソフトウェアのアーキテクチャを伝える代表的アプローチがたくさん挙げられていますが，そのどれもが次のような問題で苦労することになります。
- カラーコーディングに関する説明や一貫性がない
- 要素の目的(例：スタイルやボックス，ラインの違い)が説明されていない
- 要素間のキーの関連が不足している，あるいは曖昧である
- "ビジネスロジック"といった総称的な用語が使用されている
- 技術的な選択 (あるいはオプション) が省略されている
- 抽象化レベルが混合されている
- 図示しようとしている内容が詳細すぎる
- コンテキストや論理的な出発点が図に示されていない
シンプルな抽象化
非公式なボックスとラインによるスケッチは分かりやすいかも知れませんが，ソフトウェア設計の伝達手段として用いるには多くの落とし穴もあります。私が採っているアプローチは，単純なダイアグラムを少数使用して，それぞれでストーリ全体の異なった部分を表現する，というものです。ただしこれを行うには，開発中のソフトウェアを考える簡単な方法について，同意しておくとが必要になります。オブジェクト指向言語を使用すると仮定すれば，ソフトウェアシステムを考える方法として，私が好んで使うのは次のようなものです ... ソフトウェアシステムは複数のコンテナで構成される / コンテナは複数のコンポーネントで構成される / 各コンポーネントが１つないし複数のクラスで実装される。このような論理的構成ブロックの単純なヒエラルキで，私がこれまで関わってきたほとんどのソフトウェアシステムをモデル化することができるのです。
- クラス: OOの世界では，クラスがソフトウェアシステムの最小構成要素です。
- コンポーネント: コンポーネント (またはサービス) は一般的に，複数の協調動作するクラスで構成され，粒度の粗いインターフェースの背後にすべて配置されます。例としては "リスク計算"，"監査コンポーネント"，"セキュリティサービス"，"Eメールサービス" など，開発中のシステムによってさまざまです。
- コンテナ: コンポーネントが実行されたり，あるいはデータが設定されたりする場所を表すものです。Webサーバ，アプリケーションサーバといったものから，リッチクライアントアプリケーション，データベース，あるいはファイルシステムといったものが考えられます。コンテナは通常，ソフトウェアシステムが動作している間は常に実行，あるいは有効であることが必要です。コンテナの観点からソフトウェアシステムを理解する上で重要なポイントは，コンテナ間通信にはすべて，Webサービス呼び出しやリモートメソッド呼び出し，メッセージなどのリモートインターフェースが必要である，ということです。
- システム: システムは抽象化の最上位レベルであり，例えばエンドユーザに価値を提供する存在を表しています。
ソフトウェアの静的構造をNoUMLで要約する
一連の抽象化を使ってソフトウェアシステムを考えることで，ソフトウェアシステムの静的構造の要約を，単純なボックスやラインで次のようなスケッチに描くことができるようになります (いくつかの例をFlickrで 公開しています)。
- コンテキスト図 (Context diagram): 非常に高いレベルの図です。システムを表すボックスを中心として，周辺にインターフェースを持つ他システムやユーザを表すボックスを配置します。システムの全体像を示すためにズームアウトした図ですから，詳細な部分はここでは重要ではありません。注目すべきなのはテクノロジやプロトコルなどの低レベルで詳細な部分よりも，むしろ人々 (アクタ，ロール，ペルソナなど)であり，ソフトウェアシステムなのです。要するにこの図は，非技術系の人たちに見てもらうためのものです。
- コンテナ図 (Containers diagram): Webサーバ，アプリケーションサーバ，独立したアプリケーション，データベース，ファイルシステムなどのシステムを構成するさまざまな構成要素と，それらの関係性と相互作用を示した，ハイレベルな図です。コンテナ図は高いレベルでの技術的選択を示すもので，基本的には論理コンテナを表現しています。物理的なインスタンスや配信マップの表現は他の方法(インフラストラクチャ図やデプロイメント図)で行います。
- コンポーネント図 (Components diagrams): おもな論理コンポーネント/サービスとその相互関係を(コンテナ単位に)示す図です。コンポーネント実装に関する既成テクノロジの選択 (Spring，Hibername，Windows Communication Foundation, F#など) などの付加情報を図に追加して，設計に現実性を与えることも可能です。
- クラス図 (Class diagrams): 詳細レベルを表すときのオプションです。たいていの場合私は，特別なパターンやコンポーネントを実装する(あるいは実装されている) 場合に，高いレベルのUMLクラス図を少し書くようにしています。ソフトウェアシステムに部分的なクラス図が必要かどうかは，ソフトウェアの複雑さの他，チームの規模や経験度なども加えて判断します。私がUML図を描くときは，全体的なモデルというよりも，スケッチという感覚のことが多くあります。
(画像をクリックして拡大)
単一の図は混乱して雑然としたものになりやすいのですが，単純な図を複数描くようにすれば，ソフトウェアをさまざまな抽象レベルで簡単に表現することができます。これは非常に重要なポイントです。なぜなら，ソフトウェアに関する情報を必要としているのは，チーム内のソフトウェア開発者だけではないからです。その他ソフトウェア技術以外の専門家やテスタ，マネージャから，運用やサポートを担当する技術スタッフまで，利害関係者やユーザは広い範囲にわたっています。例えば，運用やサポートスタッフのようにソフトウェアシステムに関する技術情報を必要とする人々にとって，コンテナ図は特に有用なものですが，その内部の仕組みについては何も知る必要はありません。
組織独自のアイデア
この単純なスケッチアプローチは，私がこれまで関係してきた多くのソフトウェアチームで有効だったものです。ただし何らかの規範的な標準を作るというよりも，何らかの組織的なアイデアやガイドラインを提供するものです。ここでの目標は，新たに包括的なモデル記法を作り上げることではなく，どちらかと言えばソフトウェア設計を効果的かつ効率的に伝えるためにチームを支援する，ということにあります。ここで改めて注目したいのが，非公式なボックスやラインによるスケッチが，図の一貫性を犠牲にする一方で柔軟性を提供しているという点です。なぜなら今は，UMLのような標準の使用に代えて，独自の記法を作りだそうとしているのですから。ここではカラーコーディングやラインのスタイル，形などを意識しながら，一貫性のある記法セットをチーム内で自然発展させる方法を推奨したいと思います。記法を説明するために，それぞれの図に簡単なキー／凡例を含めておくことも有効でしょう。
"アーキテクチャ図" には高レベルの概念図だけを描かなければならない，という共通の誤解があるようです。それではソフトウェア開発者には意味がないと受け取られても致し方ないでしょう。しかしながら，ソフトウェアアーキテクチャが象牙の塔ではなく，コーディングやコーチング，コラボレーションを扱うべきものであるのと同じように，ソフトウェアアーキテクチャズもまた現実に即したものであるべきです。テクノロジの選択(あるいはオプション)を含めることは，一般的に正しい方向へのステップです。多数の概念的要素があたかも魔法のように，ソフトウェアシステムの隅々まで協調動作するというような，象牙の塔的なアーキテクチャ図になることを防止する上で有効です。
"最小限の" 事前設計
最後のポイントとして，アーキテクチャと設計の違いについてのGrady Booch氏の名言を紹介しましょう。氏によれば，アーキテクチャとは "重要な決断" を表すものです。ここでの重要性は，変更コストで測られます。コンテキスト，コンテナ，コンポーネントといった図は，私がソフトウェアシステムの重要な構成要素と考えたものを表現します。したがってこのアプローチを作図に適用することは，チームの効率的，効果的なコミュニケーションの支援に加えて，事前設計の過剰あるいは不足に苦労しているソフトウェアチームを助けることにもなるのです。白紙の状態から始まった多数のソフトウェアシステムが，数週間や数ヶ月という期間ではなく，むしろ数時間や数日といったオーダで設計され，高レベルのコンポーネント図として書き下されています。ソフトウェア設計の説明が迅速かつ簡単にできるようになるので，それがうまく行けば，技術的リーダシップの導入や，技術的ビジョンをチーム全体で共有するという感覚の浸透を図る上でも有効です。スケッチを描くことは，すべてのソフトウェア技術者が備えるツールとなるべきです。ソリューションを視覚化して，それを素早く伝達するための素晴らしい方法であるだけでなく，協調(collaborative)設計や協調コード所有などへの道を開くのです。
著者について
Simon Brown 氏はジャージ島 (チャネル諸島) に在住し，ソフトウェアアーキテクチャ，技術的リーダシップ，アジリティのバランスなどを専門にする独立コンサルタントとして働いています。氏は国際ソフトウェア開発カンファレンスで定期的に講演すると同時に，小さな新興企業から世界的優良企業に至るまで，欧州全域の組織内のソフトウェアチームを対象としてコンサルティング／トレーニングを提供しています。氏は Coding the Architecture (実用的，実践的なソフトウェアアーキテクチャについてのWebサイト) の創立者で，Software Architecture for Developers (Leanpubを通じて順次公開されているEブック) の著者でもありますが，現在もコードを書いています。Twitterでは @simonbrown で見ることができます。