ITアーキテクトの仕事術：要求の「見える」化：ITアーキテクトを探して（4）（1/2 ページ）

　ユーザーから要求をヒアリングし、管理するのはコンサルタントやプロジェクトマネージャーの仕事だと思っていないだろうか。ユーザーからの要求は、システムのアーキテクチャを規定する大切な要素であり、要求の可視化や管理はITアーキテクトが率先して担当すべき分野といえる。現場のITアーキテクトは、あいまいで頻繁な変更が発生する「要求」をどのように可視化し、管理しているのか。

[岩崎史絵（トレッフェ），＠IT]

要求を管理し、統制する仕組みの重要性

　IPAのITスキル標準センターのITアーキテクト委員会では、「ITアーキテクトは成果物に対し、以下の3点について責任を持つ」としている。

• アーキテクチャの品質（機能性／信頼性／使用性／効率性／保守性／移植性）
• 経営戦略、戦略的情報企画で要求されている成果・効果
• 当該プロジェクトで要求される成果・効果

　上記3点について責任を持つのはITアーキテクトだが、評価を下すのはユーザー側だ。つまりITアーキテクトの仕事の成果は、「どれだけこちらの期待に応えてくれたのか」というユーザーの評価によるところが大きいといえる。そのため「ユーザーがどのような要求を持っているのか」を正しく理解することが、ITアーキテクトの重要な仕事になる。ITアーキテクトの仕事といえばアーキテクチャ設計が主業務だが、その前段階である「要求の的確な把握」が実現できてこそ、初めて設計フェイズへと進むことができる。例えば基幹システムならば信頼性の確保が何より重要だが、Web技術を適用した基幹システムであれば同時にパフォーマンスについても考慮しなくてはならない。「要求がアーキテクチャを規定する」というわけだ。

　だが、要求はあいまいで優先度が付けにくく、実装が困難なケースも発生するため、「いかに要求を管理し、アーキテクチャ設計に役立てていくか」が重要なポイントになる。2005年9月8日に秋葉原ダイビルで開催されたセミナー「MDA Technology Forum：アーキテクトの仕事論――要求管理をめぐって」は、まさにこの課題に焦点を当てたものだ。主催であるオブジェクトテクノロジー研究所 代表取締役 鎌田博樹氏は「あいまいな要求をシステム開発に反映し、ユーザーの満足度を向上させるには、要求を『管理・統制』する仕組みが必要になる。そのアプローチとして有効なのが『モデル化』という手段。要求をモデル化し、プロジェクトのステークホルダーで管理、統制していく仕組みを作り上げることもITアーキテクトの大きな役割だ」と語る。

「要求」と「要件」の違いとは

　ユーザーからの希望や願いは、しばしば「要求」や「要件」という用語で表現される。日本IBM 金融ソリューション・センター ICP-アドバイザリ ITアーキテクトの山本久好氏によると、「『要求』とは、漠然とした希望や願い、経営上期待している成果などであり、『要件』とは機能・非機能を含めたシステムに対する要望を意味する」としている。ちなみに英語ではすべて「Requirement」で統一されており、「要求」と「要件」の厳密な違いを意識することはないそうだ。本セミナーでは、「要求」「要件」両方を含め、モデル化アプローチによる管理・統制の具体策について論議された。

　なぜ「要求」と「要件」の区別が重要になるのか。鎌田氏は「そもそもビジネスとITには根本的矛盾があるため、まずビジネスとITの2つの側面からユーザーの要望を切り分けることが必要だ」と述べる。その矛盾とは、ビジネスとITで情報のとらえ方が異なるということ。ビジネスで扱う情報とは、あらゆるデバイスやリソース、環境の中に分散しているコンテンツであり、ビジネスプロセスの中で必要になるモノ。

　対してIT側で語られる情報とは、基本的に「データ」だ。そのデータが、どういう場面で誰に対し有用な“情報”となり得るかは、そのビジネスプロセスのコンテクストに依存する。そのコンテクストを切り分け、データを“情報”として扱えるようにするのがビジネスシステムの役割だ。「システム開発とは、ビジネス全体の中で必要な情報と、システムで切り出す情報とを分け、さらにシステム要件を詰めて実装に落とし込む作業。漠然とした大きな“要求”の中に、IT実装に必要な“要件”が隠されている」（鎌田氏）というように、実装に必要となる要望を、ユーザーの言葉から見いだしていく作業が必要となる。そこで課題となるのが「要求をいかに引き出すか」「要求をいかに可視化するか」「要求をいかに管理するか」という3点だ。

　ちなみにIBMでは要件定義プロセスを4つのアクティビティに分けており、上記3つの課題はこの4フェイズにまたがると考えてよい。

1．要求の抽出
-	ステークホルダー（利害関係者）の明確化
-	要求の対象識別と明確化（ビジネス目標、ビジネスプロセス、要件と制約）
-	システム化対象範囲の明確化
2．分析
-	要件の分類と確認
-	実現可能性の確認
-	関係者との合意
3．仕様化
-	合意された要件について文書化（IEEE Std. 830-1998）
4．妥当性確認
-	要件の妥当性（一貫性と完全性）の確認
-	要件定義書レビュー
-	プロトタイピング

要求定義プロセスの4つのアクティビティ（日本IBM 山本氏の資料を元に作成）