こんにちは。三苫です。

この記事はTECHSCORE Advent Calendar 2014、21日目の記事です。

この記事は、私がITアーキテクトって何だろうと学習した記録です。たぶん、全三回程度になると思います。
今回は、第二回です。第一回はこちら→ITアーキテクトってなんだろう その１

本記事は書籍「システムアーキテクチャ構築の原理」をもとに書かれています。不明点あれば本書をあたるのが確実です。

ニック・ロザンスキ、イオイン・ウッズ　榊原　彰(監訳)　牧野裕子(訳)　(2008)．
システムアーキテクチャ構築の原理　翔泳社

※つい最近気づいたのですがこの本最近第二版がでました。
http://www.amazon.co.jp/dp/4797376724
本記事は第一版の内容をもとにしています。

要約

ITアーキテクトがアーキテクチャを選択するためには、システムの姿を正しくとらえなければいけない。システムの姿をとらえようとするとき、単一の観点、たった一つの文書で正確にとらえることはできない。システムの姿を正確にとらえるためには機能的、情報、平行性、開発、配置、運用といった6つの側面でとらえるとよい。これらがシステムをある側面から見た構造=ビューポイントと呼ばれる。

最適な選択をするために

前回、システムのアーキテクチャを選択するためにはどうすればいいかという問題を投げかけて終わりました。今回はその続きです。

どうやればアーキテクチャを根拠をもって選択することができるでしょうか？

選択するには、判断軸と選択肢が必要です。
判断軸はステークホルダ達が持っています。
選択肢は私たちITアーキテクトが示さなければいけません。

システムの要件を整理した時、開発者はだいたいこんな構成にすれば作れそうだなと想像を巡らせると思います。それも複数のやり方が思い浮かぶでしょう。スタンドアロンアプリかもしれません。Webアプリかもしれません。
要件の実現方法として選択肢をいくつか挙げること自体はさほど難しい事ではありません。（選択肢が全く思いつかない？それはシステムの要件がおかしいか、あなたが実は開発者ではないかのかもしれません）

いくつか上げた選択肢をステークホルダたちと話し合いながら最適な選択をするためには、それぞれの選択肢がどのようにシステムに影響を与えるかステークホルダに伝わるように説明できなければできません。システムの姿と、選択肢によってその姿がどう変わるかを他人に伝えないと行けないのです。

システムの姿を自分以外の他人に伝えるためにはシステムの姿を伝える文書が必要です。
（ここでは文書としましたが必ずしも文書である必要はないでしょう。ホワイトボードとプレゼンテーションでも構いません。その場合も以降の観点は有用でしょう）

システムの姿を伝える文書

システムの姿を伝えるための文書はアーキテクチャ記述（AD:Architecture Description）と呼ばれます。システムのアーキテクチャを伝えることが目的の文書で、体裁が特に決まったものではありません。規模や複雑さによっては一枚の箇条書きやポンチ絵で済むこともあるでしょう。

ここでちょっと質問ですが、このシステムはどんなシステム？って聞かれて答えるのに困った経験のある人いませんか？

例えば、新しく参加する開発メンバーにシステムの概要を伝えようとした時です。当初からの開発メンバーは暗黙知で知っていることだけれど資料がないので用意しないといけないのですが、そもそもどういう資料を用意すればいいのかよくわからず一枚の絵の中にデータの流れや機能やサーバーの配置をまとめて書こうとして謎の巨大絵が完成した…という経験はありませんか？（これは単に私の経験談です）

システムが一定規模を超えると、一つの文書だけでシステムの姿を記述することが困難になってきます。システムには複数の側面があるため、それをひとつの文書内に収めようとすると粒度や観点が発散してしまうためです。

システムの姿を捉えるにはシステムをそれぞれ単一の側面から光をあてた文書を作るとよいです。

単一の側面に光をあてた文書

単一の側面に光をあてた、つまりある観点からシステムを見た文書のことを「ビューポイント」と呼びます。なんとなくそのまんまですね。観点→ビューポイント。

システムをどれだけの側面から見れば、システムの姿をもれなく伝えることができるでしょう。

ここでは機能的、情報、平行性、開発、配置、運用といった6つのビューポイントを挙げます。

機能的ビューポイント

システムを機能面からとらえ、インターフェイスや責務を記述する。
機能一覧に始まり、コンポーネント図や外部公開するインターフェイスなどを記述したものです。
ほとんどのアーキテクチャ記述土台となる部分であり、ステークホルダが最初に読もうとする文書です。

情報ビューポイント

システムの情報という観点からとらえ、その静的構造や流れを記述する。
RDBMSを使う場合であればテーブル定義書などが静的構造、データがどの機能から読み書きされるかといったものが流れになるでしょうか。
バックアップ戦略などもここで記載すべきかもしれません。

並行性ビューポイント

システムの並行性や状態を記述するものです。
機能Aと機能Bは同時に実行可能。機能Cと機能Dは順序を持っていなければいけない。機能Eは０時から４時の間しか実行できない。
といった個々のタスクの制約や同期の実現方法、タスク失敗時のリカバリや再投入手順などです。

開発ビューポイント

開発プロセスやTDDやCIやCDや、ブランチ戦略、コード規約、共通化指針など、開発者間で良く語られる部分ですね。

配置ビューポイント

ネットワークやサーバーの物理構成、論理構成、性能、ポート、配備されるOSやアプリケーションの種類などシステムが配置される環境を記述するものです。
実行環境時のシステムの依存性を把握できるような情報を記載する必要があります。（このテストを実行するときには、少なくともこのサーバーでこのプログラムが立ち上がっている必要がある…などがわかるように）

運用ビューポイント

システムの運用や管理、サポート方法を記述します。日々の監視、バックアップ、アップグレード、サポート部門が行う業務の範囲、エスカレーションプロセスなどです。

今日はここまで

さて、ここまで説明したようにシステムのアーキテクチャを明らかにするにはビューポイントによりいろいろな側面からみた文書を用意するとよいことがわかりました。

しかし、これだけではまだ漏れがあります。システムにはいくつかのビューポイントにまたがる横断的な関心事があるのです。

次回はそのあたりを昭和55年生まれの私と一緒に探って行きましょう。