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

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

» 2005年09月30日 12時00分 公開
[岩崎史絵(トレッフェ),@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 山本氏の資料を元に作成)

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ