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

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

ビジネスコミュニケーション
第52回 要求質問 NTTデータ 技術開発本部 副本部長 山本修一郎

(株)NTTデータ 技術開発本部 システム科学研究所 所長 工学博士 山本修一郎

連載の第5回の要求抽出手法と第16回のインタビューでは、要求インタビューをはじめ様々なインタビューの種類やインタビュー手順について紹介した[1][2]。しかし、要求インタビューで具体的にどのような質問をするのかについては体系的に整理していなかった。要求抽出の基本となるインタビューでどのような質問をするのかは要求工学にとっても重要な課題である。

本稿では、このような要求インタビューにおける要求質問とは何かについて考察してみたい。

要求質問とは

要求インタビューの目的は、要求を識別すること、要求間の関係を明らかにすること、抽出され関係が定義された要求の定義を確認すること、要求に対するイメージを明らかにすることに分けられるのではないだろうか。最初の3つの質問は直接的に要求を聞くための質問であり、最後の質問は要求を間接的に問うための質問である。直接質問ではどのような質問をするかということと、抽出される要求の構造とは密接な関係を持つ。稚拙な質問しかできなければ抽出された要求を構造化することはできないだろう。質問技術によって、集められる要求の種類、品質、深さなどが決まることになる。これに対して間接質問では、要求の内部に立ち入ることなく、要求のイメージが良いか悪いかを多数の関係者に聞くことで、総合的に要求が置かれた状況を明らかにするのである。

以下では、まず直接的な要求質問を構造化、相対化、統合化という3種類からなる要求質問の分類フレームワークとして再構成してみよう。この構造化、相対化、統合化は上述した要求識別、要求間の関係の明確化、要求記述の確認に対応している。

次いで、間接的な要求質問によって要求の良い面と悪い面から二次元的に要求が置かれた状況を把握できることを紹介しよう。

要求質問の分類フレームワーク

表1に直接的な要求質問の分類フレームワークを示した。

表1 要求質問の分類フレームワーク
分類 説明
構造化
要求の構成要素とその関係を明らかにする
相対化
異なる要求を比較することにより共通性と差異ならびに優先順位を決定する
統合化
①内部統合
類似する要求を共通化するとともに漏れがないように洗練する
②外部統合
複数の要求を統合することにより目標を達成するシナリオを形成する

◆構造化質問

構造化質問の目的は、要求の構成要素とその関係を明らかにすることである。

◆相対化質問

相対化質問の目的は、異なる要求を比較することにより共通性と差異、ならびに優先順位を決定することである。

◆統合化質問

統合化質問の目的には、①内部統合と②外部統合がある。内部統合質問の目的は、類似する要求を共通化するとともに漏れがないように洗練する。外部統合質問の目的は、複数の要求を統合することにより目標を達成するシナリオを形成する。

次に、これらの質問分類にしたがって、具体的にどのような要求質問があるかを紹介しよう。

構造化質問

要求を構造化するための質問の例を表2に示した。要求の構造化質問では、目的と手段、原因と結果、全体と部分、要求とその根拠、要求とその前提となる仮説、要求とそれが制約する対象との関係に基づいて質問することができる。

表2 要求を構造化するための質問
関係 質問内容
目的手段
目的から手段としての資源、活動、下位の目的を聞く
手段から目的を聞く
手段の代替案を聞く
手段に対する他の目的がないかを聞く
因果
原因から結果を聞く
結果から原因を聞く
結果から他の結果を聞く
原因から他の原因を聞く
全体部分
全体から構成要素を聞く
部分から全体を聞く
部分を共有する他の全体を聞く
構成要素間の制御関係として条件、排他性、同期性、順序性、手順を聞く
根拠
要求の根拠を聞く
仮説
要求が前提とする仮説とその成立条件を聞く
制約
要求を制約する条件を聞く
どういう状況で要求が求められるかを聞く

◆目的手段関係

目的手段関係に関する質問では、目的と手段の関係を手がかりにして目的要求に対する手段としての資源要求、活動要求、下位の目的要求を聞く。ここで資源要求としては物理的な資源だけでなく、人的資源や論理的な情報資源も考えられる。活動要求には、システム機能だけでなく人間系による活動も含まれる。

これとは逆に、手段要求から目的要求を聞くことや、手段要求の代替案を聞くことも必要になる。

また、手段要求が他の目的要求を達成することもできないかを聞くことも大切である。

◆因果関係

因果関係についての質問では、原因から結果を聞く質問、結果から原因を聞く質問、結果から他の結果を聞く質問、原因から他の原因を聞く質問がある。

たとえば、ある状況の下でどんなイベントに対してどのような結果が期待されるのかを聞くことや、ある結果に対してどのような入力が期待されるのかを聞くことができる。

◆全体部分関係

全体部分関係質問では、次のような全体と部分との関係に基づいて要求を質問する。

  • ・全体から構成要素を聞く ・部分から全体を聞く ・部分を共有する他の全体を聞く ・構成要素間の制御関係として条件、排他性、同期性、順序性、手順を聞く

◆根拠関係

要求の根拠を聞く質問が、ディペンダブルなシステム要求を抽出する上で重要になる。たとえば、Jacksonは以下に示すように、要求を明示的主張で明確にした上で、その根拠を証跡として対応付けることを提案している[3]

・明示的主張(Explicit claims)

システムがディペンダブルであるというためには、具体的な性質を明示的に主張する必要がある。

・証跡(Evidence)

ディペンダビリティの主張を支持する証跡がない限り、システムに依存することはできない。

◆仮説関係

要求が前提とする仮説とその成立条件を聞く。たとえば、Lehmanはソフトウェアを3種類に分類できるとしている[4]。3種類とは明確に問題とその解を仕様として定義できるS型、問題を明確に定義できるが最適な解を定義することができないP型、問題自体を明確に定義できないE型である。四則演算などはS型の例である。将棋などのゲームはP型の例である。天気予報や需要予測などはE型の例である。ほとんどのソフトウェアはE型だと思われる。

しかし、E型ソフトウェアの要求が前提にしている仮説を明記することは意識しないと難しい。仮説が明記されていなければ、ソフトウェアを開発した後で要求どおりのサービスを提供しているにもかかわらず、望ましい結果が得られなかったときに、その原因を確かめることができない。望ましい結果が得られないのは、仮説が正しくなかったことが原因かもしれないのである。このように、要求だけではなく、その前提となる仮説をマネジメントして適切なフィードバックを考慮する必要がある。

◆制約関係

要求を制約する条件を聞く。たとえば、どういう状況で要求が求められるかを聞くことで、要求に対する制約条件を確かめることができる。

相対化質問

要求を相互に比較検討するための相対化質問の例を表3に示す。

表3  要求を相対化するための質問
関係 質問内容
類似性
要求間の類似性や代替可能性を聞く
貢献性
要求の意味を聞く
他の解釈や他の用途があるかどうか聞く
要求が目的にどれくらい貢献するかを聞く
重要性
要求の優先順位を決めるため重要性を聞く
要求が必須なのか省略できるかを聞く
実現性
要求の実現可能性の程度を聞く
時期
要求が必要となる時期を聞く
コスト
要求を実現するために投資可能な経費条件を聞く

相対化質問として類似性だけでなく、システム化の目標への貢献度、重要性、提供時期、コスト、実現性を聞くことが考えられる。

◆類似性

類似する要求をまとめることや、代替可能なより容易に実現できる他の要求で置き換えることは、要求を最適化する上で重要である。このため、類似する要求を明らかにしていく必要がある。

◆貢献性

要求の意味を聞くことで、どのような目標に貢献するかを知ることができる。

また、要求に対して他の解釈や他の用途があるかどうか聞くことも大切である。要求によっては複数の目標に貢献することがあるかもしれない。また、要求が目的にどれくらい貢献するかという貢献度を聞く必要がある。目標への貢献度は、要求の重要性を判断する根拠になる可能性がある。たとえば、貢献度として要求を実現することによって、期待できる効果の大きさを聞くこともできる。

◆重要性

要求の優先順位を決めるため、重要性や要求が必須なのか省略できるかを聞く必要がある。

◆実現性

要求の実現可能性の程度を聞いておかないと要求の優先順位が決められない。

◆時期

要求が必要となる時期を聞いておかないと要求の優先順位が決められない。

◆コスト

要求を実現するために投資可能な経費条件を聞いておかないと要求の優先順位が決められない。

これらの質問の結果に基づいて、要求の優先順位や共通性を判断できるようになる。

統合化質問

統合化質問では内部統合と外部統合に係らず、要求の完全性について質問することになる。内部統合では、重複する要求の共通化によって漏れが発生しないことを確認する必要がある。SAFEWAREという本の中で、Levesonが要求仕様の外部状況に対する完全性基準には次の7項目があると述べている[5]

(1)人間・コンピュータ・インタフェース

警報:イベント、型、個数、順序構造、通知、確認、削除

トランザクション:構成要素、優先制御

(2)状態

正常/異常状態での期待入力

想定外の入力の考慮

(3)入出力

デバイス入出力:データの種別

操作の可逆性:例えばオープンしたらクローズがあるはずだ

(4)イベント発生契機

ロバスト性

非決定性

値・タイミング:前提条件、間隔、容量・負荷

(5)出力イベント

環境の許容量、データの寿命、遅れ

(6)入出力イベントの関係

応答性

(7)状態間の関係

到達性、回帰性、可逆性、優先性、ロバスト性

表4 要求仕様の完全性基準
関係 質問内容
人間・コンピュータ・インタフェース
どのような警報があるか?
例:イベント、型、個数、順序構造、通知、確認、削除
どのようなトランザクションがあるか?
例:構成要素、優先制御
状態
正常/異常状態での期待入力は何か?
状態に対する 想定外の 入力 は何か?
入出力
デバイス入出力の種別は何か?
操作は可逆的か? 例:オープンとクローズ
イベント発生契機
ロバスト性や非決定性は必要か?
値とタイミングはどうか? 例:前提条件、間隔、容量・負荷
出力イベント
環境の許容量、データの寿命、遅れは何か?
入出力イベントの関係
入力に対する期待応答は何か?
応答に対する期待入力は何か?
状態間の関係
到達性、回帰性、可逆性、優先性、ロバスト性はどうか?

いずれにしろ、最初からこれらの項目をすべて漏れがないか確認することは時間がないから、費用がないから難しい、と考えがちではないだろうか?

しかし、考えておかないと根拠のない楽観的な見積もりを許すことになり、後になってこれらの要求変更が顕在化してくることは間違いないだろう。

要求象の分析質問

これまでの要求工学では、前述したように直接的な要求質問を扱ってきた。しかし、良い面もあれば悪い面もあるシステム要求を全体的に把握するためには、間接的な要求質問も必要になると思われる。とくに現行システムを改善する場合には、次に紹介するような二次元的な間接質問が有効になると思われる。

要求ごとに、関係者に対して良いイメージと悪いイメージがどれくらいあるかを聞く。

この結果に基づいて、要求を正のイメージと負のイメージの点数に基づいて4象限に配置することによって、図1に示すように要求の印象を安定期、成熟期、成長期、閉塞期に分類できる。

図1 要求像の2 次元分析
図1 要求像の2 次元分析

このように、分類された要求象の分類と対策は次のようになるだろう(表5)。

表5 要求像の分類と対策
分類 正のイメージ 負のイメージ 対策
安定期
現状を維持する
成長期
欠点をなくすための改善要求を探す
成熟期
良い点を見つけるための改善要求を探す
閉塞期
悪い点を解消する改善要求を探すか、この要求をあきらめる

安定期の要求については現状を維持する。成長期の要求については、負のイメージが高いので欠点をなくすための改善要求を探す。成熟期の要求については、正のイメージが低いので良い点を見つけるための改善要求を探す。閉塞期の要求については悪い点を解消する改善要求を探すか、この要求をあきらめる。

まとめ

顧客にインタビューすることにより、システムに求められる顧客の要求を抽出する方法に構造型インタビューと非構造型(オープン)インタビューがあることは前にも述べた。間接質問による要求の印象分析は、包括的に要求のイメージをアンケートで聞くことができるのでオープン型アンケートの一つだろう。本稿で紹介した直接要求質問では個別的な要求の詳細を具体化することができるので、構造型インタビューで用いることができる。


本稿では、まず要求質問には直接質問と間接質問があることを示した。直接要求質問については、構造化、相対化、統合化に分けて具体的な質問内容を紹介した。また、間接質問を用いた要求の二次元イメージ分析技法とそれに基づく要求の改善手法を説明した。これまでは、要求を抽出するために直接的な質問が中心になっていたと思われるが、既存システムを拡充する場合や商品開発などでは要求の内部構造ではなく、外部の印象に着目した間接的な質問によって改善すべき要求を発見することも重要になると思われる。

なおIEEEが推奨しているソフトウェア要求仕様(SRS, Software Requirements Specifications)の記述法IEEE std 830- 1998には、正当性、無あいまい性、完全性、一貫性、検証容易性、修正容易性、追跡性を要求仕様が持つべきだと推奨されている。これらの項目は、要求仕様の記述内容を確認するために質問としても利用できるだろう。

たとえば正当性では「ソフトウェアが持つべきすべての要求がSRSにふくまれており、それ以外の要求をSRSがふくまないか?」と問うことができる。検証容易性では「要求仕様に含まれるすべての要求に対して有限のコストで評価可能な手続きがあるだろうか?」と問うことができる。追跡性では「要求の根拠が明確か?」と問うのである。


■参考文献
  • [1] 山本修一郎、要求抽出(5)、ビジネスコミュニケーション, http://www.bcm.co.jp/
  • [2] 山本修一郎、要求インタビュ(16)、ビジネスコミュニケーション, http://www.bcm.co.jp/
  • [3] Jackson, D. et al, Software for dependable systems? sufficient evidence?, NATIONAL RESEARCH COUNCIL, 2008
  • [4] M.M. Lehman and L.A. Belady, Program Evolution -Process of Software Change, Academic Press, 1985
  • [5] Leveson, N., SAFEWARE, System Safety and Computers, Addison Wesley, 1995
第59回以前は要求工学目次をご覧下さい。


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