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

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

［課題1］ 要求を引き出すコミュニケーション力

　ITアーキテクトに必要な資質として「コミュニケーション力の高さ」が挙げられるが、この能力が発揮されるのが、まさにこの「要求管理」分野においてだろう。こうしたヒューマンスキルは本人の性質に依存することが大きいが、コツさえつかめばコミュニケーション力を高めることは十分可能だ。

　 ボーランドのプリンシパルコンサルタント 今村智氏は、「『開く質問』と『閉じる質問』を併用することで、ユーザーから要求を引き出し、重要度や決断を促すことが可能になる」という。

　開く質問とは、文字通りユーザーの口を開かせる質問で、Yes／Noで回答できない種類の問いを指す。一般に「5W／1H」（何、どこ、誰、いつ、なぜ、どのように）といった問い掛けだ。これに対し、閉じる質問とは基本的に「はい、いいえ」形式を意味する。ユーザーから要求を引き出すには開く質問を使い、決断を求めたり事実を確認するときには閉じる質問というように、2つを使い分けることで、スムーズに要求を引き出せるようになる。

　そして次に、これらの要求がどのような特性を持つのか分析し、システムに反映させていく。今村氏は要求のタイプと構造として、「機能要求」と「非機能要求」という2つの軸に分け、それぞれビジネスレベル・ユーザーレベル・システムレベルという3つのレベルで要求のタイプを区分けしている。ビジネスレベルとは主に経営層によるビジネス戦略上の成果や要望であり、ユーザーレベルとは業務現場からの機能要望や使い勝手にかかわる要望だ。対して非機能要求とは、一般に「非機能要件」といわれているものとほぼイコールであり、システムインフラに関与することも多い。こうした非機能要求を、ミドルウェアやアプリケーションフレームワークなどに組み込むことで、再利用を促進できるというメリットも生まれる。

［課題2］ 要求を可視化するモデル化技術

　洗い出された要求をいかにモデル化するか。モデル化することで、洗い出された要求の内容と実現可能性を確認するというメリットがある。また、各ステークホルダー間の情報共有や、管理・統制がしやすくなるという側面もある。要求管理のフェイズにおいて、最大の肝となるのがこの“モデル化”だ。

　日本IBMのITアーキテクトである山本久好氏（金融ソリューション・センター ICP アドバイザリーITアーキテクト）は、要求を可視化する手段として、ビジネスモデルやビジネスプロセスモデル、DFD（Data Flow Diagram）、状態モデル、イベントシーケンス図、クラス図、概念オペレーショナルモデルなど、7種類以上のモデル表記法を挙げている。中でも山本氏が強く訴求するのは、アーキテクチャ構築のためのメタモデルの重要性だ。

　アーキテクチャのメタモデルとは、山本氏によると機能と非機能の2つのモデルで構成されるという。IBMの開発手法の体系である「IBM Global Services Method」のアーキテクチャ・ドメインでは、ユーザーからの機能／非機能の要望をモデル化して、仕様・詳細・物理の3つの側面から分析し、融合させていくことを、アーキテクチャ設計作業と位置付けているそうだ。

　ただし「具体的には、機能要求はコンポーネントベースの設計・分析手法を適用し、非機能要求についてはノードやトランザクションの関連性モデルで表現する。ただしシステムの規模が大きくなると、ノードのモデルも複雑になるため、注意する必要がある」（山本氏）と注意を喚起している。

［課題3］ 「要求」をいかに管理するか

　最後の課題は「要求の管理」だ。ここでいう“管理”とは、物理的な文書管理はもちろん、変更が生じた場合のトレースやインパクト分析も含めている。さらにもう1つ、要求管理の実践において必要なのが「ベースライン管理」だ。ベースライン管理とは、あいまいな要求の“ベース”を決定し、そのベースに対しどれだけ変更が加えられたかを把握することだ。ボーランドの今村氏、IBMの山本氏は「変更が頻繁に発生する要求管理を効率的に行うには、市販のツールを含めた何らかの『仕組み』が必要」という考えだ。「要求は開発するシステムの制約にかかわるうえ、頻繁に変更や手戻りが発生するもの。変更履歴のトレーサビリティを確保するには、手作業ではなくツールの仕組みが必要になる」（山本氏）。

　ツールを導入するメリットは2つある。1つはステークホルダー間の情報共有がより向上すること。もう1つは、変更履歴のトレースやインパクト分析がしやすくなる点だ。一方、デメリットとしてはツールの導入により発生するオーバーヘッドの存在だ。例えば変更履歴のトレースやインパクト分析を実行するには、事前のデータ入力やメンテナンスが欠かせない。こうしたオーバーヘッドを吸収する1つの目安が開発期間だという。3〜4カ月未満のプロジェクトだと、メンテナンスと開発スピードのバランスが取りづらくなるそうだ。

　 要求管理に何らかのツールは必要だが、「メリット、デメリットを考えると、必ずしも高機能なツールでなくても構わない」（今村氏）という。これは山本氏も同様で、「自社の開発手法の中に、要求を可視化し、管理する体制を作り上げることが最優先」という考え方だ。

ITアーキテクトはどのように要求をモデル化するのか？

　ここでもう1度、モデル化について考えてみよう。ビジネス的な要求、そしてシステムに関係する要求（要件）をモデル化し、合致させることでアーキテクチャ設計を進めていくが、要求が複雑になるにつれ、モデル化は困難になり、設計に支障を来たす。

　そこで日本IBMでは、アーキテクチャのメタモデル作成に対し、「アスペクト指向」の考え方を取り入れている。アスペクト指向とは、横断的な関心事を共通要素としてくくり出し、再利用性を高めるプログラミング手法のこと。要求のモデル化に関していえば、主に非機能要件を切り出すケースが多いという。山本氏は機能要求のモデルを「ファンクショナル・アスペクト」、非機能要求を「オペレーショナル・アスペクト」と呼んでいる。

　ファンクショナル・アスペクトは、コンポーネントベースでの分析・設計を基本とし、対して非機能要求のモデルはシステムのノードやコネクション、ロケーションなど、インフラを抽象化したモデルと考えれば分かりやすい。「これらのモデルを使って、機能要件を満たしたビジネスコンポーネントを、どのノードにどのように配置していくかを決めていく」（山本氏）という。

　要求のモデル化はさまざまな技法やダイヤグラムがあり、「正解」があるわけではない。アスペクト指向を取り入れるのも1つの方法ではあるが、山本氏自身「考え方を適用しただけで、これから方法論として洗練させていく必要がある」と述べている。