3-2 要件の引き出し
Requirements Elicitation
1. 引き出しの基本
1.1 なぜ「引き出し」なのか
要件は「収集」するものではなく「引き出す」ものである。 ステークホルダーは自分のニーズを完全に言語化できていないことが多く、 潜在的なニーズを引き出すにはスキルと技法が必要である。
| 要件のレベル | 特徴 | 引き出し方法 |
|---|---|---|
| 明示的な要件 | ユーザーが明確に述べる | 直接質問、文書レビュー |
| 暗黙的な要件 | 当然と思って言わない | 観察、プロトタイプ |
| 潜在的な要件 | ユーザー自身も気づいていない | 創造的技法、実験 |
1.2 引き出しの準備
効果的な引き出しを行うためには、事前準備が重要である。
| 準備項目 | 内容 |
|---|---|
| 目的の明確化 | 何を引き出したいのか、スコープを定義 |
| 対象者の特定 | 誰から引き出すか、キーパーソンの選定 |
| 事前調査 | 業界知識、現行システム、業務プロセスの理解 |
| 技法の選択 | 状況に適した引き出し技法の選定 |
| 質問の準備 | 質問リスト、インタビューガイドの作成 |
2. 主要な引き出し技法
2.1 インタビュー
インタビューは最も一般的な引き出し技法である。 1対1または少人数で対話形式で情報を収集する。
| インタビュータイプ | 特徴 | 適用場面 |
|---|---|---|
| 構造化インタビュー | 事前に質問を準備、一貫性確保 | 多数の対象者から同種の情報を収集 |
| 半構造化インタビュー | 基本質問＋臨機応変な深堀り | 探索的な調査、詳細の把握 |
| 非構造化インタビュー | 自由な対話、発見重視 | 初期段階、未知領域の探索 |
効果的なインタビューのコツ
オープンクエスチョン（Why、How）を活用する。 「5つのなぜ」で根本原因を探る。 沈黙を恐れず、相手に考える時間を与える。 メモを取りすぎず、対話に集中する（録音許可を得る）。 終了時に要約し、認識の齟齬がないか確認する。
2.2 ワークショップ（JAD/JRP）
ワークショップは複数のステークホルダーを集め、集中的に要件を引き出す技法である。 JAD（Joint Application Development）やJRP（Joint Requirements Planning）とも呼ばれる。
| 要素 | 説明 |
|---|---|
| 参加者 | ビジネス側、IT側、意思決定者、ファシリテーター |
| 準備 | アジェンダ、資料、会場、ツール |
| 技法 | ブレインストーミング、親和図法、投票 |
| 成果 | 合意された要件、優先順位、課題リスト |
ワークショップの成否はファシリテーターにかかっている。 中立的な立場で議論を促進し、発言の偏りを防ぎ、時間管理を行い、 合意形成を支援する。技術的な議論に入り込みすぎないことが重要。
2.3 観察（Observation）
観察は、実際の業務現場でユーザーの作業を観察する技法である。 言葉では表現されない暗黙知や非効率なプロセスを発見できる。
| 観察タイプ | 特徴 | メリット・デメリット |
|---|---|---|
| 受動的観察 | 観察者は干渉せず見る | 自然な行動を観察できるが、理由は不明 |
| 能動的観察 | 質問しながら観察 | 理由を確認できるが、行動に影響 |
| 参与観察 | 観察者も業務に参加 | 深い理解が得られるが、時間がかかる |
2.4 プロトタイピング
プロトタイプ（試作品）を作成し、ユーザーに操作してもらうことで 要件を引き出す技法である。「百聞は一見にしかず」の効果がある。
| プロトタイプ種類 | 特徴 | 用途 |
|---|---|---|
| ペーパープロトタイプ | 紙に手書きで画面を作成 | 初期段階、アイデア検証 |
| ワイヤーフレーム | 画面構成を線画で表現 | レイアウト、導線の確認 |
| モックアップ | 視覚的なデザインを含む | デザイン、ブランドの確認 |
| 動作プロトタイプ | 実際に動作するもの | インタラクション、技術検証 |
プロトタイプを見たユーザーが「これで完成」と誤解することがある。 プロトタイプの目的と限界を事前に説明し、 あくまで要件確認のためのものであることを明確にすべきである。
3. その他の引き出し技法
3.1 文書分析
既存の文書を分析して要件を抽出する技法。現行システムの仕様書、 業務マニュアル、帳票、規程などが対象となる。
| 文書種類 | 得られる情報 |
|---|---|
| 現行システム仕様書 | 既存機能、データ構造 |
| 業務マニュアル | 業務フロー、ルール |
| 帳票・画面 | 入出力データ、項目 |
| 規程・法令 | 制約条件、コンプライアンス要件 |
| 問合せ・クレーム記録 | 現行の問題点、改善要望 |
3.2 アンケート・調査票
多数のステークホルダーから定量的な情報を収集する場合に有効。 インタビューの補完として使用されることが多い。
3.3 フォーカスグループ
少人数（6〜10名程度）のグループで特定のテーマについて議論する技法。 多様な意見を引き出し、参加者間の相互作用から新たな発見が得られる。
3.4 ブレインストーミング
自由な発想でアイデアを出し合う技法。批判禁止、量重視、 便乗歓迎、自由奔放の4原則に従って実施する。
1つの技法だけで全ての要件を引き出すことは難しい。 インタビュー＋観察、ワークショップ＋プロトタイプなど、 複数の技法を組み合わせることで、より完全な要件を引き出せる。
4. 引き出しの課題と対策
4.1 よくある課題
要求獲得では様々な課題が発生しやすい。
| 課題 | 原因 | 対策 |
|---|---|---|
| キーパーソンの不参加 | 多忙、関心の低さ | 経営層からの指示、短時間セッション |
| 発言の偏り | 声の大きい人の独占 | ファシリテーション、匿名投票 |
| 解決策の押し付け | ユーザーが解決策を語る | 「なぜ」を繰り返し、真のニーズを探る |
| 暗黙知の抽出困難 | 本人も意識していない | 観察、シナリオウォークスルー |
| 用語の相違 | 業務用語とIT用語のギャップ | 用語集作成、確認の徹底 |
「現行通り」への対応
ユーザーが「現行通りでよい」と言う場合、それをそのまま受け入れてはならない。 現行システムの問題点、改善要望、将来のビジネス変化への対応など、 深堀りして真の要件を引き出す必要がある。
要件の引き出し技法を学んだら、次は「3-3 要件の分析」で 収集した情報を整理・詳細化する方法を学習しよう。
[1] IIBA (2015). BABOK Guide 3.0.
[2] Wiegers, K. (2013). Software Requirements 3rd Edition.