NTTデータ
技術開発本部
副本部長
山本修一郎
インタビューの分類フレームワーク
上述(前頁を参照)したように様々なインタビューがある。これらのインタビューを分類するための共通的な観点を整理すると、インタビューの目的、質問形式、手段、対象者、生産物、管理の6項目になる。
インタビューの目的
- ・理解:
- 話し手の人物や業務、技術知識を理解するためのインタビュー
- ・問診:
- 聞き手が話し手の病状や症状を診断するためのインタビュー
- ・報道:
- 記者がある切り口で社会や技術動向を取材して報道するためのインタビュー
- ・出版:
- 著者があるテーマで社会問題や技術などを取材して出版するためのインタビュー
- ・交渉:
- 話し手と聞き手とが取引するための意見を交換するためのインタビュー
- ・説得:
- 話し手と聞き手の一方が他方を説得するためのインタビュー
- ・意見照会:
- ある提案に対して、関係者の意見や課題提起を収集するためのインタビュー
- ・要求抽出:
- 聞き手としての分析者が顧客や開発者からシステム要求や課題を抽出するためのインタビュー
質問形式
- ・構造的:
- 予め質問を用意しておき、回答を収集する
- ・半構造的:
- 用意した質問と回答に応じた新たな質問を用いて、回答を収集する
- ・非構造的:
- 予め質問を用意することなく、回答者に自由に発言させて、情報を収集する
手段
- ・対面:
- 話し手と聞き手とが顔を合わせてインタビューする
- ・電話:
- 電話によるインタビュー
- ・書面:
- 書面によるインタビュー
- ・電子:
- メールやWebによるインタビュー
対象者
- ・個人:
- 特定の人物に対するインタビュー
- ・組織:
- 組織の構成員に対するインタビュー
- ・社会:
- 一般の人や地域、共同体に属する人へのインタビュー
生産物
インタビューして入手した情報をまとめるときに作成する生産物の種別を分類するためには、生産物の構成要素や公開範囲、話し手に対する作成した生産物の内容確認の有無を明らかにする必要がある。
・生産物の内容の種別には、文書もしくは映像・音声がある。文書としての生産物には、調査報告、作品、記事、Q&A集、要求定義書、要求仕様書などがある。映像・音声の場合にはドキュメンタリーやニュースがある。
管理
インタビューの管理では、一過性のインタビューと継続性のあるインタビューを考慮する必要がある。面接などでは一時的に話を聞いて終わるので厳密な管理は必要ないかもしれない。新聞や雑誌の取材でも、あるトピックスについて有識者の意見を聞いて記事にする場合なども同じだろう。これに対してノンフィクションやスクープ報道などでは、足を使った地道な取材を継続して行うことで「事実」に基づく「批判」を実現する。この場合は収集される情報も多くなるので継続的な情報管理が必要だ。要求インタビューも継続的に要求を管理することが必要になる。
インタビューの分類フレームワークを図1に示す。インタビューに先立って、どのようなインタビューを行うのかについて、このフレームワークを用いて検討しておくことで、インタビュに必要な準備ができると思われる。
図1 インタビューの分類フレームワーク
表1にいくつかのインタビューをこのフレームワークを用いて比較した結果を示す。
インタビューのプロセス
一般的なインタビュー・プロセスを図2に示す。インタビューには、次の4つの基本的なプロセスがある。
図2 一般的なインタビュー・プロセス
- (1)関連資料から分野知識を収集して質問のための課題を準備する
- (2)課題について質問する。このとき課題の重要性に応じて質問順序を制御する
- (3)事実を分析する。収集した事実と課題の因果関係を分析する
- (4)事実を報告する。収集した事実に基づいてある観点から報告をまとめる
このうち1と3は、課題や事実を聞き手が理解し分析するプロセスである。これに対して2と4は聞き手が理解した内容や課題に基づいて、事実を収集したり、報告することによって話しての意見を聞くプロセスである。
このインタビュー・プロセスを良く見ると、実はデカルトの方法序説で述べられている科学的な問題分析の方法[8]とよく似ていることに気づく。
- 【明証】
- 即断と偏見を避けて自分が明証的に真であると認められることだけを受け入れる
- 【分割】
- 問題を解決可能なできるだけ小さな部分に分割する
- 【統合】
- 最も単純な要素から段階的に複雑な問題に、順序付けて統合していく
- 【枚挙】
- 全体的に課題を枚挙し抜けがないことを確認する
デカルトのこの4つの規則は自分の頭の中で、論理的に問題を証明するための方法であるが、インタビューにも適用できる考え方である。たとえば、明証を課題の質問、分割を課題の準備、統合を事実の報告、枚挙を事実の分析に対応付けてみてはどうであろうか?もちろん、この4つの方法を用いて収集した事実を分析することもできる。
- 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:保証ケース作成支援ツールの概要