Requirements Elicitation

要件の引き出しスキル

目的

このスキルを使用すると、AI アシスタントは業界標準の手法を用いて、さまざまな種類のプロジェクト（Web、モバイル、ERP、CRM、CDP、Eコマース）でステークホルダーから包括的なビジネス要件を収集し、専門的な要件引き出しセッションを実施できます。

このスキルを使用するタイミング

• 新しいプロジェクトや機能開発を開始するとき
• ディスカバリーフェーズや立ち上げフェーズを実施するとき
• システムの機能強化に関する要件を収集するとき
• ビジネス上の課題や機会を理解するとき
• BRD／FRS のドキュメント作成に備えるとき

主な要件引き出し手法

1. ステークホルダーへのインタビュー

最適な用途：個人の視点を深く理解する、デリケートなトピックを扱う、経営幹部から意見を得る

進め方：

• 準備：ステークホルダーの経歴、役割、課題について調査します
• 構成：半構造化形式（準備した質問と柔軟な対応を組み合わせる）を使用します
• 所要時間：1回あたり45～60分
• 質問の枠組み：5W1H（Who、What、When、Where、Why、How）を使用します

質問の種類：

• 自由回答形式：「現在の業務プロセスについて、順を追って説明していただけますか？」
• 掘り下げる質問：「それがチームにとって重要なのはなぜですか？」
• 明確化する質問：「『リアルタイム』とおっしゃる場合、具体的にどのくらいの時間を指していますか？」
• 仮定に基づく質問：「現在のシステムについて、1つだけ変更できるとしたら、何を変えますか？」

STAR 手法（プロセスの理解に使用）：

• Situation（状況）：「通常、どのような場面で……するのか説明してください」
• Task（課題）：「何を達成しようとしていますか？」
• Action（行動）：「どのような手順で進めますか？」
• Result（結果）：「どのような結果になりますか？改善できる点はありますか？」

2. 要件ワークショップ

最適な用途：部門横断の足並みをそろえる、ブレインストーミング、合意形成

進め方：

• 参加者：異なる部門から6～12名のステークホルダー
• 所要時間：2～4時間
• ファシリテーション：視覚資料（ホワイトボード、Figma、Miro）を使用します
• 手法：
  • ブレインストーミングセッション
  • 親和図法（類似したアイデアをグループ化）
  • ドット投票（優先順位付け）
  • プロセスの確認

ワークショップのアジェンダテンプレート：

1. 導入と目標（10分）
2. 現状の確認（30分）
3. 課題の特定（30分）
4. あるべき姿の検討（45分）
5. 要件のブレインストーミング（45分）
6. 優先順位付けの演習（30分）
7. 次のステップとアクション項目（10分）

3. ドキュメント分析

最適な用途：既存システム、コンプライアンス要件、過去の経緯を理解する

確認するドキュメント：

• 既存システムのドキュメント
• 業務プロセスマニュアル
• ユーザーガイドとトレーニング資料
• コンプライアンスおよび規制関連のドキュメント
• 分析レポートとダッシュボード
• サポートチケットとバグレポート
• 競合分析レポート

分析の進め方：

• ドキュメントに記載されたプロセスと実際のプロセスの違いを特定します
• ビジネスルールと制約を抽出します
• データ構造と関連性を理解します
• 前提条件と依存関係を記録します

4. 観察とジョブシャドウイング

最適な用途：実際のワークフローを理解する、文書化されていないプロセスを特定する

進め方：

• ユーザーの職場環境で業務を観察します
• 作業を妨げずに観察し、メモを取ります
• 回避策や課題を記録します
• 後から明確化のための質問をします
• 「現状」のプロセスフローを文書化します

注目する点：

• タスクの頻度
• 各作業にかかる時間
• 使用するツールとシステム
• チーム間の引き継ぎ
• エラーが発生しやすい手順

5. アンケートと質問票

最適な用途：大規模なユーザーグループから意見を集める、定量データを収集する

ベストプラクティス：

• アンケートは短くします（質問は最大10～15問）
• さまざまな質問形式（選択式、評価尺度、自由回答形式）を組み合わせます
• 必要に応じて匿名性を確保します
• 回答期限を明確に設定します
• 結果を分析して共有します

質問例：

• 評価：「現在のチェックアウトプロセスにどの程度満足していますか？1～5の尺度で評価してください」
• 選択式：「最も頻繁に利用する決済方法はどれですか？」
• 自由回答形式：「注文処理で直面する最大の課題は何ですか？」

6. プロトタイピングとモックアップ

最適な用途：UI/UX 要件、視覚的要件の検証

アプローチ：

• 低忠実度のワイヤーフレームを作成します（Figma、スケッチ）
• ステークホルダーに提示してフィードバックを得ます
• 意見に基づいて反復します
• ユーザーテストにはクリック可能なプロトタイプを使用します
• フィードバックと要件を記録します

要件の分類

機能要件

定義：システムが実行すべき内容

ドメイン別の例：

• Eコマース：「システムはユーザーが商品をカートに追加できるようにする」「システムは配送先に基づいて送料を計算する」
• ERP：「システムは承認済みの購買依頼から発注書を生成する」「システムは複数通貨での取引に対応する」
• CRM：「システムはリードソースとコンバージョン率を追跡する」「システムはフォローアップメールを自動送信する」
• CDP：「システムはウェブ、モバイル、CRMの顧客データを統合する」「システムは行動に基づいてオーディエンスセグメントを作成する」
• モバイル／ウェブ：「アプリはオフラインで動作し、接続時に同期する」「ウェブサイトは3秒以内に読み込まれる」

非機能要件

カテゴリ：

• パフォーマンス：応答時間、スループット、スケーラビリティ
• セキュリティ：認証、認可、データ暗号化
• ユーザビリティ：ユーザーエクスペリエンス、アクセシビリティ（WCAG準拠）
• 信頼性：稼働時間、エラー処理、災害復旧
• 互換性：ブラウザー対応、デバイス対応、統合
• コンプライアンス：GDPR、CCPA、SOX、業界規制

例：

• 「システムは同時に10,000人のユーザーに対応する」
• 「すべての機密データは保存時および転送時に暗号化する」
• 「システムは99.9%の稼働時間を達成する」
• 「モバイルアプリはiOS 15以降およびAndroid 12以降に対応する」

制約

種類：

• 技術的：既存のインフラストラクチャや特定の技術スタックを使用する必要がある
• ビジネス：予算上の制限、スケジュール上の制約
• 規制：特定の規制に準拠する必要がある
• 組織的：既存のシステムと統合する必要がある

ドメイン固有の考慮事項

Eコマースプロジェクト

調査すべき主な領域：

• 商品カタログ管理（バリエーション、属性、在庫）
• ショッピングカートとチェックアウトのフロー
• 決済ゲートウェイの統合とセキュリティ
• 注文管理とフルフィルメント
• 顧客アカウントとプロフィール
• プロモーションと割引ルール
• 検索とフィルタリング機能
• 商品レコメンデーション
• マルチチャネル販売（ウェブ、モバイル、マーケットプレイス）

重要な質問：

• 「複数の倉庫にまたがる在庫をどのように管理しますか？」
• 「どの決済方法に対応する必要がありますか？」
• 「放棄されたカートをどのように扱いますか？」
• 「返品と返金のプロセスはどのようになっていますか？」

ERPプロジェクト

調査すべき主な領域：

• モジュールの範囲（財務、人事、サプライチェーン、製造など）
• マスターデータ管理戦略
• モジュール間のワークフローと統合
• 承認階層とワークフロー
• レポートと分析の要件
• 複数企業／複数通貨のニーズ
• ロールベースのアクセス制御
• コンプライアンス要件

重要な質問：

• 「発注書にはどのような承認レベルが必要ですか？」
• 「企業間取引をどのように処理しますか？」
• 「コンプライアンスのためにどのような財務レポートが必要ですか？」
• 「従業員データはどのように構成すべきですか？」

CRMプロジェクト

調査すべき主な領域：

• リードの獲得と選別のプロセス
• 営業パイプラインの段階と基準
• 連絡先とアカウントの階層
• マーケティングキャンペーン管理
• カスタマーサービスのチケット管理
• メール、電話、マーケティングツールとの統合
• 営業予測の手法
• レポートとダッシュボード

重要な質問：

• 「何をもって有望なリードと見なしますか？」
• 「リードの獲得から成約まで、どのような営業プロセスですか？」
• 「顧客満足度をどのように測定しますか？」
• 「既存のツールとの連携には何が必要ですか？」

CDP プロジェクト

調査する主な領域：

• データソース（Web、モバイル、CRM、Eコマース、オフライン）
• 顧客 ID の照合方針
• データガバナンスとプライバシーコンプライアンス
• セグメンテーションとオーディエンスの作成
• リアルタイム処理とバッチ処理
• データのアクティベーションチャネル
• 分析とレポートのニーズ
• マーケティングツールとの連携

重要な質問：

• 「チャネルをまたいで、同じ顧客をどのように特定しますか？」
• 「最も重要な顧客属性は何ですか？」
• 「このデータを利用するマーケティングチャネルは何ですか？」
• 「同意管理にはどのように対応しますか？」

モバイル／Web プロジェクト

調査する主な領域：

• プラットフォーム要件（iOS、Android、Web、PWA）
• レスポンシブデザインのニーズ
• オフライン機能の要件
• パフォーマンスへの期待
• プッシュ通知の方針
• ディープリンクとアプリ内ナビゲーション
• 認証とセキュリティ
• アプリストアの要件
• 分析とトラッキング

重要な質問：

• 「どの機能をオフラインで動作させる必要がありますか？」
• 「どのデバイスと OS バージョンに対応する必要がありますか？」
• 「ユーザーはどのように認証しますか？」
• 「どの分析イベントをトラッキングする必要がありますか？」

情報引き出しのベストプラクティス

1. 十分に準備する

• 業務領域を調査する
• 既存のドキュメントを確認する
• 事前に質問を準備する
• 適切な関係者を特定する
• 十分な時間を確保する

2. 積極的に聞く

• 話を遮らない
• 詳細にメモを取る
• 不明点を明らかにする質問をする
• 理解を確認するために言い換える
• 非言語的な合図に注意する

3. 適切な質問をする

• 広い質問から始め、徐々に掘り下げる
• 自由回答形式の質問を使う
• 誘導的な質問を避ける
• 前提を問い直す
• 「なぜ」を何度も尋ねる（5 Whys 手法）

4. すぐに記録する

• 要件をリアルタイムで記録する
• 一貫性を保つためにテンプレートを使う
• 決定事項とその理由を記録する
• 前提条件と依存関係を記録する
• 検証のためにメモを共有する

5. 検証して確認する

• 要件を関係者と確認する
• 完全性と明確さを確認する
• 矛盾や曖昧さを解消する
• 正式な承認を得る
• トレーサビリティを維持する

6. 対立に対処する

• 異なる見解を認める
• ビジネス目標に焦点を当てる
• 判断を裏付けるデータを使う
• 必要に応じてエスカレーションする
• トレードオフを記録する

よくある落とし穴を避ける

❌ 業務領域を理解していると思い込む - 理解を必ず確認する
❌ 曖昧な要件を受け入れる - 具体性と測定可能性を求める
❌ 非機能要件を見落とす - 成功に不可欠な要件です
❌ エッジケースを無視する - 「もし〜なら？」と質問する
❌ 前提条件を記録しない - 暗黙の知識を明示する
❌ 聞くより話す時間が長い - 80/20 のルール：80％聞き、20％話す
❌ すぐに解決策に飛びつく - まず問題を理解する
❌ 要件を検証しない - 理解を必ず確認する

ハイブリッド手法のツール

Lark

• Docs を使ってインタビューのメモや要件ドキュメントを作成する
• Base を使って要件を追跡し、トレーサビリティを確保する
• Meetings を使ってセッションを記録する
• Tasks を使ってアクション項目を管理する

Notion

• プロパティ（優先度、ステータス、担当者）を含む要件データベースを作成する
• 一貫性を保つためにテンプレートを使う
• 要件をユーザーストーリーやテストケースにリンクする
• 関係者ディレクトリを作成する

Figma

• 情報引き出しの最中にワイヤーフレームやモックアップを作成する
• ワークショップでの共同作業に FigJam を使う
• 検証のためにユーザーフローをプロトタイプ化する
• フィードバックを得るためにデザインを共有する

成果物

要件の情報引き出し後、以下を作成します。

1. 要件一覧：すべての要件を網羅したリスト
2. インタビューのメモ：関係者とのセッションの詳細な記録
3. ワークショップの成果物：図、優先順位付けの結果、決定事項
4. プロセスマップ：現状と将来のフロー
5. 前提条件の記録：文書化された前提条件と制約
6. 関係者マトリックス：誰がどの要件を提示したか
7. 未解決の質問一覧：フォローアップが必要な項目

次のステップ

要件の引き出しを完了した後：

1. 要件を整理し、分類します
2. MoSCoW または RICE を使用して優先順位を付けます（requirements-prioritization スキルを参照）
3. ステークホルダーと要件を検証します
4. BRD を作成します（brd-creation スキルを参照）
5. 詳細な FRS を作成します（frs-creation スキルを参照）

参考資料

• BABOK® Guide（ビジネスアナリシス知識体系）- 要件引き出しの手法
• IIBA Standards - ビジネスアナリシスの専門的な実践
• Agile Extension to BABOK® Guide - アジャイルのコンテキストにおける要件引き出し
• IEEE 29148 - 要件エンジニアリング標準