(前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 動機拡張の基本概念(クリックで拡大)
動機拡張の概念要素
◆ステークホルダ
アーキテクチャの成果物に関連する関心事を表現する個人や組織の役割がステークホルダである。
経営委員会、CIO、CEO、CFOや顧客がステークホルダの例である。
◆ドライバ
組織の変革を生成、動機付け、推進する事柄がドライバである。
ステークホルダに関連付けられた内的ドライバの例が「顧客満足」「制度準拠」「収益性」などである。これに対して、制度変更は外的ドライバの例である。
◆アセスメント
ドライバを分析した結果がアセスメントである。
アセスメントによって、ある関心事の領域に対する強み、弱み、機会、脅威が明らかになる。既存ゴールの調整や、新しいゴールの設定で、ドライバの分析結果を明確化する必要がある。
組織にとって、強み、弱みは内部的で、機会と脅威は外部的である。弱みと脅威を解決するゴールによって解決される弱みと脅威は、弱みと脅威を否定するゴールによって明確化する必要のある問題であると考えられる。これに対して、強みと機会はゴールに直接翻訳される。
◆ゴール
ステークホルダが達成を意図する目標状態がゴールである。
「収益を向上する」「待ち時間を短縮する」などがゴールの例である。ゴールを複数の下位ゴールに分解である。たとえば、「収益を向上する」を「売り上げを増加する」と「経費を削減する」に分解できる。
◆プリンシプル
与えられたコンテクストにおけるすべてのシステムの規範的特性や、システムが実現される方法がプリンシプルである。
プリンシプルはゴールと要求に強く関係づけられている。要求よりもプリンシプルは広いスコープをもち、より抽象的である。ある状況内のすべてのシステムについての一般的性質をプリンシプルが定義する。
◆要求
システムによって実現すべきニーズの表明が要求である。
計画もしくは、新システムあるいは既存システム変更を必要とする具体的な変更ゴールによって、ビジネスゴールが実現される。
ゴールによってモデル化される目的を達成するために必要な要素の性質を要求がモデル化する。ゴールを実現する手段を要求が表現する。
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要