NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第132回 要求のまとめ方国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

先日、東海地方のある企業の方と意見交換した。いろいろな要求がいろいろな部門から出てくるが、それを要件としてきちんととりまとめているかどうかが課題なのだそうだ。具体的には「いろいろな要求をとりまとめ、要件として絞り込んでいく実践的なスキルを習得する手法」はないかという質問をいただいた。

この質問の中に、答えはすでに提示されているというのが筆者の印象であった。この理由は、次の3つである。まず、「いろいろな要求」があることが認識できていること、次いで、異なるが関連のある要求を要件としてまとめることができる可能性が認識できていることである。さらに、この2条件を総合して実践的な手法があることの潜在的な可能性が認識できていることである。

本稿では、この質問から得た着想に基づいて筆者が整理した実践的な要求のまとめ方(Categorize Relate Organize Specify Method, CROS)を紹介する。

要求定義の現実

要求工学では、ゴール指向要求工学、BPMN、UML、SysMLなどこれまで多くの要求モデルが提案されている。ところが、現場に導入されているモデルはほとんどないのが現状である。これらの要求工学手法では、適切なモデルにしたがって要求を定義することが前提であった。したがって、今回の質問の背景は、特定の要求工学モデルによらない要求のまとめ方が求められていることがある。

また、要求抽出が難しいといわれる。しかし現実には、大量の要求が抽出されているにもかかわらず、整理できないために放置されてしまって、せっかく抽出した要求が有効に活用できないこともある。

そこで、要求がまとまらない理由をよく聞いてみると、以下のようであった。

要求はデータベースで管理している
しかし、格納されている要求の粒度がバラバラである
このため、要求間の優先順位が決まらない
要件との対応関係がつかない


なるほど、要求の問題は、抽出するのが難しいのではなく、抽出した要求の整理が難しいのである。逆に言えば、要求の抽出基準を明確にするということだが、抽出基準を直接定義することもまた難しいと思われる。

要求統合化手法

そこで、抽出された要求を分類して互いに関係付けて組織化した上で要件(仕様)と対応付ければいいのではないかと考えた。これが、CROS法である。

Categorize:要求を分類する

Relate:分類された要求を互いに関係づける

Organize:分類され、互いに関係づけられた要求を組織化する

Specify:組織化された要求を仕様と対応付ける


このCROS法に従って、まとまっていない要求を整理できるはずである。CROS法のポイントは、要求分類とその関係である。この分類の仕方の参考になると思われるのが、ArchiMateの動機拡張(Motivation extension)である。それでは、ArchiMateの動機拡張を概説しよう。

ArchiMateの動機拡張

ArchiMate[1][2]はオープングループのアーキテクチャフレームワークであるTOGAF[3]におけるアーキテクチャ開発手法ADM(Architecture Development Method)のモデリング言語である。ArchiMateでは、ADMの各フェーズを、①ArchiMateコア、②動機拡張、③実装・移行拡張からなる3グループに分けている。動機拡張では、準備、アーキテクチャ・ビジョン、アーキテクチャ変更管理と、要求管理の各ADMフェーズで使用するモデリング言語を提供している。

ArchiMate動機拡張には、7種類の概念要素、3種類の関係要素、6種類のビュウポイント要素という3つの概念がある(表1)。

アーキテクチャ要求をまとめるために必要となる構成要素として、ステークホルダ、ドライバ、アセスメント、プリンシプル、要求、制約からなる概念要素を記述する。動機拡張の構成要素間の関係には、集約(アグリゲ―ション)関係、実現関係、影響関係がある。ビュウポイントでは、動機拡張の構成要素と関係に基づいて用途に応じて適切な部分を選択して表現できる。

以下では、概念要素と関係を説明する。

表1 動機拡張の基本概念(クリックで拡大)

表1 動機拡張の基本概念

動機拡張の概念要素 

◆ステークホルダ

アーキテクチャの成果物に関連する関心事を表現する個人や組織の役割がステークホルダである。

経営委員会、CIO、CEO、CFOや顧客がステークホルダの例である。

◆ドライバ

組織の変革を生成、動機付け、推進する事柄がドライバである。

ステークホルダに関連付けられた内的ドライバの例が「顧客満足」「制度準拠」「収益性」などである。これに対して、制度変更は外的ドライバの例である。

◆アセスメント

ドライバを分析した結果がアセスメントである。

アセスメントによって、ある関心事の領域に対する強み、弱み、機会、脅威が明らかになる。既存ゴールの調整や、新しいゴールの設定で、ドライバの分析結果を明確化する必要がある。

組織にとって、強み、弱みは内部的で、機会と脅威は外部的である。弱みと脅威を解決するゴールによって解決される弱みと脅威は、弱みと脅威を否定するゴールによって明確化する必要のある問題であると考えられる。これに対して、強みと機会はゴールに直接翻訳される。

◆ゴール

ステークホルダが達成を意図する目標状態がゴールである。

「収益を向上する」「待ち時間を短縮する」などがゴールの例である。ゴールを複数の下位ゴールに分解である。たとえば、「収益を向上する」を「売り上げを増加する」と「経費を削減する」に分解できる。

◆プリンシプル

与えられたコンテクストにおけるすべてのシステムの規範的特性や、システムが実現される方法がプリンシプルである。

プリンシプルはゴールと要求に強く関係づけられている。要求よりもプリンシプルは広いスコープをもち、より抽象的である。ある状況内のすべてのシステムについての一般的性質をプリンシプルが定義する。

◆要求

システムによって実現すべきニーズの表明が要求である。

計画もしくは、新システムあるいは既存システム変更を必要とする具体的な変更ゴールによって、ビジネスゴールが実現される。

ゴールによってモデル化される目的を達成するために必要な要素の性質を要求がモデル化する。ゴールを実現する手段を要求が表現する。



続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。