第1回　要件定義工程のITアーキテクト

　ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は要件定義工程を対象にします。要件定義工程では、主に次の5つの成果物を作成します。

（1）Vision Document
（2）利害関係者マップ
（3）概念機能モデル図・概念データモデル図
（4）非機能要件定義書／品質特性シナリオ
（5）グランドデザイン

　ポイントは「ビジネス視点」と「システム視点」の両方を持つこと。技術者は総じて「How（どのようにつくるか）」への思考（＝システム視点）が先行しがちです。これでは「間違ったものを正しくつくる」ことになってしまいます。それを避けるには、「Why（なぜつくるのか）」と「What（なにをつくるのか）」を明らかにすること、つまり、ビジネス視点を持つことです。

　ITアーキテクトは、アーキテクチャー設計に対する「説明責任」が伴います。「なぜ、このようなアーキテクチャー設計にしたのですか？」という問いに対して明確に回答しなければなりません。また、アーキテクチャーを改善をする段階では、網羅的な情報が無ければ改善のスピードを高めることができません。そのために、システム化対象の全体像をつかんでおくこと、つまり、システム化対象（＝ドメイン）を分析しておくのです。これがアーキテクチャー設計のインプット情報となります。

（1）Vision Document
　「なぜシステムを作るのか（Why）」「何を作るのか（What）」を明確にするには、システム化の背景にあるビジネス上のビジョンを明確にすることです。それをまとめたものが「Vision Document」になります。Vision Documentに書くべきことは二つあります。一つはビジネス視点で見た「重要なポイント」。もう一つは法規制などビジネス上の「制約」です。ITアーキテクトは後の工程でさまざまな判断をしますが、そのときの判断の最も基本的な基準としてこの文書が位置付けられます。

（2）利害関係者マップ
　ITシステムにはさまざまな利害関係者がいて、その利害は対立していることが少なくありません。この利害の対立を認識しておかないと、ある利害関係者から見たら受け入れられない仕様であった、ということになりかねません。システム化対象の業務を理解するには、ITシステムを取り巻く利害関係者を押さえておかねばなりません。それをまとめたものが「利害関係者マップ」です。

　要件定義の際、御用聞き的な受け身の姿勢で要求を聞いていると、利害の対立による難しさを認識する時期が遅れ、深い議論と検討がされなくなります。その結果、「声の大きい人が勝つ」「財布を持っている人が強い」などの非論理的な理由から要件が決まっていくことになります。そうならないために、利害関係者マップを作成して利害の対立構造を把握し、それを「全体の要件」にまとめることが必要です。

（3）概念機能モデル図・概念データモデル図
　ITアーキテクトは要件定義工程で、システム化対象を機能視点で表した「概念機能モデル図」と、データ視点で表した「概念データモデル図」を作成します。ここで「概念」としているのは、概念的なレベルという意味です。要件定義工程ではRFPなどがあるだけで、まだ要件定義すら実施していません。ですので、精緻なものではなく粗いものでいいのです。

　なぜ機能とデータのモデル図を作成するのでしょうか。それは、ITアーキテクトはさまざまな視点で見ることが求められるからです。こちらから見るとうまくいくことが、反対から見るとうまくいかない。こうした場合、ITシステムとして実現できなかったり、運用し始めたら矛盾があったりといったことにつながります。モノごとをある視点から捉えた場合、逆の視点からも捉え直すことで、モノごとの本質や解くべき本質的課題が明らかになります。ITアーキテクトは可能な限りさまざまな視点を持たねばなりません。

（4）非機能要件定義書/品質特性シナリオ
　アーキテクチャー設計には、機能要件に加え、応答性能などの非機能要件が不可欠です。「動くけど、遅くて使い物にならない」「データ量が増えると、極端に遅くなった」という事態を引き起こさないために、定量評価可能な形で非機能要件を定義します。定量評価を可能にするために、「何ミリ秒以内に何％の確率で応答する」などの基準や、「ピーク時間帯でもテーブルの母数が何件以内であれば」などの前提条件として明記します。非機能面のゴールを設定し、机上評価（静的検証）及び実機評価（動的検証）に利用します。

（5）グランドデザイン
　ITアーキテクトが頭の中に描いている“青写真”（ハイレベルなアーキテクチャー）になります。これを作成する狙いは2つです。一つは、要求を正しく理解していると、利害関係者に示すこと。「要求を出したのに受け入れられなかった」という負の感情が残らないように、要求を盛り込んでいることを理解してもらいます。もう一つは、設計の方向性への賛同を、利害関係者から得ることです。利害関係者が自ら設計に参加したという認識を持つことが重要です。設計の入り口になるグランドデザインを関係者と共有した上で、細部の分析・設計に入ります。