IT課題の解消策を設計する
日本語に訳すと、企業がビジネスやサービスに関連して持つ課題や不都合の解消策の設計者又は構築者という意味合いになります。
しかし、アーキテクチャーとエンジニアとの違いなどハッキリとした定義が定められているわけではなく、何となく実像が掴みづらくぼんやりしたイメージとなっているのが実情です。
ここでは一般的にソリューション・アーキテクトとして考えられているであろう姿について考察してみたいと思います。
5つの成果物の目的別の整理
アーキテクトが作成する成果物が何を目標として作られるのかを整理してその姿を考えてみると姿が明確化してきます。
それでは5つの成果物毎にその目的を見てみます。
（1）ビジョン・ドキュメント
これは何故、何のシステムを作るかということであり、これによりシステム化のバックグランドであるビジネス上のビジョンが明確になります。
このドキュメントに書かなければいけないことは2つあり、1つはビジネス視点からの重要ポイントで、2つ目は法令規制等ビジネス上の制限です。
あとの工程で様々な判断が求められますがその際の最も基本的な基準としてこのドキュメントが必要です。
（2）利害関係者マップ
ITシステムには多数の様々な利害関係者が存在しており、互いに利害が対立する場面が多くあります。
その利害の対立を分かっておかなければ、一方の利害関係者には納得しかねる仕様であることも少なくないのです。
そこでシステム化の対象の業務を理解するためにも利害関係者の対立ポイントを整理しておく必要があるのです。
「ご用聞き」のような態度で受け身のスタイルでリクエストを聞いていると、関係者の利害対立の認識時期が遅れ、十分に議論されないまま期限が迫ることになりかねません。
これを怠ると、声の大きい人または財布を握る人の意見がとおり、全体から見た良いシステムは出来ない可能性が高いのです。
（3）機能・概念の各モデル図
ITアーキテクトは機能・データの各モデル図を描きますが、この段階では概要が分かるレベルで良いので簡易な図でかまいません。
作製の理由は様々な視点で全体を俯瞰的に見る事が必要だからです。
（4）定量評価可能な非機能要件定義書等
機能は満たしても反応が遅くて使えないでは困りますので、設計に際して機能要件以外に、レスポンス性能等の非機能要件が不可欠です。
そのような想定外の事態に陥らないために、定量評価可能な範囲で非機能要件・基準を定めておきます。
（5）グランドデザイン
アーキテクトが描く青写真の事で、作成目的は2つあり、1つはそれぞれのリクエストを当方は正しく認識している事を利害関係者に納得してもらう事と、2つ目はシステム設計の方向性に同意を得る事です。