NTTデータ
技術開発本部
副本部長
山本修一郎
要求インタビュー・プロセス
図3に要求インタビューのプロセスを示す。
図3 要求インタビュー・プロセス
- ◆環境の理解:
- 要求インタビューでは、まずシステムを取り巻く環境を分野知識や関連文書を用いて理解する。このとき質問すべき課題を抽出する。
- ◆課題の質問:
- 課題について顧客や開発者に質問することにより要求を抽出する。このとき質問の重要性に基づいて質問の順序を制御する。
- ◆要求定義の提案:
- 抽出した要求に基づいて作成した要求定義を顧客に提案することにより、新たな要求や課題を抽出する。
- ◆要求仕様の提示:
- 抽出した要求に基づいて作成した要求定義を開発者に提示することにより、新たな要求や課題を抽出する。
以上述べたように要求インタビューは反復的なプロセスとなり、顧客が要求定義に合意して開発者が実現性を了解した要求仕様書ができた時点で、インタビューが完了することになる。理想的には何もインタビューすることがなくなったときに、顧客と要求について合意したことになると言えよう。
要求インタビューの留意点
インタビューの留意点を質問内容、質問手順、人間関係面、管理面という4つの観点から、すべきこととすべきではないことに分けて整理した結果を表2に示す。
質問内容では、顧客から具体的な意見を効率的に収集するためにインタビューの意図や質問の観点を提示する必要がある。また、回答内容を整理して再提示することで、理解した内容を確認してもらうこともできる。そうすれば手戻りが少なくなるだろう。
質問手順では、質問者が顧客の現実の声に可能な限り耳を傾けることが最も重要である。分析者が顧客と協力して作業する場合、顧客の要求をくみ上げ組織化することが目的になる。とくに分析者の経験は重要だが、顧客のためのシステム要求を抽出することができないと意味がないのだから、要求抽出作業に顧客が参加することを妨げないように注意が必要だ。たとえば顧客が追加要求を見落としている場合に限定して、分析者が自らの体験や過去に定義したシステム要求を提案するなどの工夫が必要だ。この場合でも、そのシステム要求が顧客にとってどのような価値を生むのかを明確にしておくことが重要だ。
よくあることだが、有能であると過信している分析者の場合、話し手の発言を遮って自らの主張を展開しすぎたり、場の空気が読めずに、顧客との信頼関係を台無しにしてしまうことがあるので注意が必要だ。
このように人間関係面では、話し手と聞き手との心の交流がないと、本当の事実を収集することは困難である。このためには場の空気を常に意識して、対決関係にくれぐれも陥らないような注意が必要だ。仮に対立関係に陥った場合でも、議論の観点を冷静に吟味することで対立関係を解消してあらたな合意点を見出すことができることもある。また同じことを別の角度から述べていたために一見すると矛盾だと思っていたことが実は一つの事実を裏と表から見ていただけだと分かったりすることもある。クールヘッド・ウォームハートという標語を忘れないようにしたいものである。
管理面では、インタビューのライフサイクル管理と情報保護が重要だ。すでに述べたけれども質問には優先順位があるので、常にいま聞いていることは全体の中ではどんな位置づけにあるのかを意識しておくことで、効率的なインタビューになる。また収集した情報の公開範囲を確認して管理を徹底しておく必要がある。
適切な質問相手を選択するということも大切である。要求仕様を作成した後で、実は最も重要な関係者にインタビューをしていないことが分かったら、大変なことになる。ノンフィクションでも同じようなことはあるらしく、インタビューの秘訣は、毎回最後に「あなた以外にこの点についてご存知の方はいないでしょうか」ということを必ず質問することだそうだ[4]。
まとめ
本稿では、インタビューのフレームワークと基本的なプロセスを紹介した。また要求インタビュー技法について、具体的なプロセスとインタビューを進める上での留意点を整理した。要求抽出ではなんといっても顧客との信頼関係に基づくコミュニケーションが大切である。インタビューはなかなか奥が深い。我々も従来から研究を進めているが、体系化できるところまではまだ至っていない[3][9][10]。インタビュー技術の工学的な研究が進展することを期待したい。
参考文献
- [1] 山本修一郎、要求抽出(5)、ビジネスコミュニケーション、http://www.bcm.co.jp/
- [2] M.E.モデル著, 荒川 淳三(他)訳、第一線技術者のための実践システム分析―インタビューの仕方からエンティティリレーション法まで-、マグロウヒル、1990
- [3] 古宮 誠一、加藤 潤三、永田 守男、大西 淳,佐伯 元司、山本 修一郎、蓬莱 尚幸、インタビューによる要求抽出作業を誘導するシステムの実現方法、http://www.ipa.go.jp/SYMPO/sympo2000/pdf/ipa19_1_51_4.pdf、第19回IPA技術発表会
- [4] 佐野 眞一、私の体験的ノンフィクション術、集英社新書、2001
- [5] 永江 朗、インタビュー術、講談社現代新書、2002
- [6] 有田 芳生、「コメント力」を鍛える、NHK出版 生活人新書2002
- [7] 斉藤 孝、コミュニケーション力、岩波新書、2004
- [8] デカルト、谷川 多佳子訳、方法序説、岩波文庫
- [9] 上野正巳、忠海均、山本修一郎、“要求分析方法論DREMの基本概念、”電信技報KBSE95-5、pp.33-38、1995
- [10] 山本修一郎、忠海均、上野正巳、“ドメイン指向要求分析技術:DREM”、NTT R&D、Vol. 45, No. 8, pp. 711-718, 1996
- 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:保証ケース作成支援ツールの概要