BA が構築する前に尋ねるべき 20 の質問

BA が構築する前に尋ねるべき 20 の質問

「AI を追加してみよう」は、「ダッシュボードを追加してみよう」の現代版です。それは生産的であるように聞こえますし、デモもうまくいきますが、それでも見事に失敗する可能性があります。人々が本当に望んでいるのは AI ではないからです。彼らは、より迅速な意思決定、より少ないミス、より少ないやり直し作業、より良い顧客エクスペリエンス、そして繰り返しの作業からの解放を望んでいます。

AI がそのような結果をもたらすのは、チームが「スマートにする」よりも具体的なことに同意した場合のみです。そこでビジネス アナリストが活躍します。モデルの専門家である必要はありません。あなたは方向転換する人でなければなりません 熱意 の中へ 明瞭さ: 成功とはどのようなものなのか、システムに何が許可され、何をしてはいけないのか、そしてシステムが安全かつ一貫して動作していることをどのように証明するのか。

この記事は現実世界での使用を目的としています。 60 ～ 90 分のキックオフとして実行し、途中で回答を取得し、範囲の境界、出力契約、ガードレール、受け入れ基準、テストと監視の現実的な計画などの具体的な出力を残して終了することができます。

AI 要件がうまくいかない理由 (たとえ有能なチームであっても)

従来のソフトウェア要件は、システムが決定的であることを前提としており、同じ入力から同じ出力が生成される必要があります。 AIシステムはそうではありません。 「機能している」場合でも、特に入力があいまい、不完全、またはノイズが多い場合、つまり実際のビジネス ワークフローではよくある状態である場合、出力は変化する可能性があります。

AI はデータを製品の依存関係にも変換します。機能が内部ドキュメント、CRM レコード、チケット、または顧客入力を使用する瞬間、機能を構築しているだけではなく、 信頼のパイプライン。この情報はどこから来たのでしょうか?現在のものですか？それは許されますか？ソースが競合した場合はどうなりますか?

そして最も重要な違いは、AI の失敗は自信を持って成功したように見えることが多いということです。流暢な答えであっても、間違っていたり、安全でなかったり、準拠していなかったりする可能性があります。そのため、BA 主導の AI 要件アプローチには、機能だけでなく、ガードレール、フォールバック、証拠も含める必要があります。

要件出力マップ (全員の意見を一致させる最も簡単な方法)

AI に関する会話は急速にツールやベンダーに移行します。次の簡単なマップを使用して、重要なことを理解してもらいましょう。

1. ユースケースと意思決定 – AIはどのような行動に影響を与えますか？
2. 入力とソース – どのような情報が使用され、何が信頼できるのでしょうか?
3. モデルの動作 – しなければならないこと、してはいけないことは何ですか?
4. 出力 – 構造、論調、引用、不確実性の処理
5. コントロール – ガードレール、フォールバック動作、エスカレーション パス
6. 証拠 – 長期にわたってテスト、監視、監査する方法

では、このマップに記入されている 20 の質問を実践してみましょう。

必ず尋ねるべき 20 の質問 (なぜそれが重要なのか、そしてそれが何を生み出すのか)

A) ユースケースの明確さ (質問 1 ～ 4)

1) 私たちはどのようなユーザーの問題を解決しているのでしょうか?そして、やるべき仕事は何ですか?

「問題」が本当に漠然とした近代化への欲求である場合、AI プロジェクトは停滞します。この質問により、チームは時間、エラー、遅延、コスト、機会の逸失、一貫性のない決定、顧客エクスペリエンスの低下など、本当の苦痛の名前を明らかにすることになります。

出力アーティファクト:

• 問題文 (1 ～ 2 段落)
• 現在のワークフロー (単純なスイムレーン スケッチも含む)

2) AI の役割は何ですか: 提案、要約、分類、決定、または行動?

これは意味論ではありません。それはリスクです。要約者とアクションを実行する「エージェント」には、まったく異なる制御、テスト、説明責任が必要です。関係者が意図したよりも大きな影響を与えるものを誤って構築しないように、役割について明確にしてください。

出力アーティファクト:

• 「AI の役割」ステートメント (単一文)
• 人間と AI の責任の境界 (「AI が草案を作成し、人間が承認する」など)

3) 明示的に範囲外となるものは何ですか?またその理由は何ですか?

AI が何をしないかを定義しなければ、ユーザーはいずれにしてもそれを要求するでしょう。範囲外の境界は、範囲のクリープ、コンプライアンスの予期せぬ事態、そして納品後半の「まあ、それもできなかったのではないか…」というエスカレーションからあなたを守ります。

出力アーティファクト:

• 範囲内/範囲外リスト
• 「許可されていない」リスト (トピック、アクション、データ ソース)

4) 測定可能な観点から見ると、成功とはどのようなものですか?

成功が測定可能でない場合、唯一の本当の指標は「人々がその成果物を気に入っているかどうか」になります。このようにして、チームは品質が低い状態で立ち上げられ、後でシステムによって余分な手戻りが発生していることがわかります。

出力アーティファクト:

• 成功指標 + 目標 (例: 時間の節約、精度、偏向、エスカレーションの減少など)
• ベースライン測定計画 (現在のパフォーマンスを測定する方法)

B) ユーザー、コンテキスト、ワークフロー (質問 5 ～ 7)

5) 主なユーザーは誰ですか?その専門知識レベルはどれくらいですか?

同じ出力でも、専門家にとっては役立つ場合もあれば、初心者にとっては危険な場合もあります。専門知識は、トーン、深み、仮定、必要なガードレールの種類に影響します。

出力アーティファクト:

• スキルレベル、コンテキスト、主要な制約を備えたペルソナ
• トレーニング/オンボーディングの前提条件 (ユーザーがすでに知っていること)

6) これはワークフローのどこに存在しますか?そして次に何が起こりますか?

AI の出力が最終製品になることはほとんどありません。これは、意思決定、顧客とのやり取り、または記録システムの更新への入力となります。この質問は、間違いが増幅される下流の結果を特定します。

出力アーティファクト:

• 挿入ポイントを示す更新されたワークフロー図
• 下流での使用上の注意 (「出力は CRM に貼り付けられる」、「顧客にはこれが表示される」など)

7) 間違った答えの代償はどれくらいですか? 迷惑、高価、安全ではない、違法ですか?

これが重大度モデルです。すべての間違いが同じというわけではないため、要件はそれを反映する必要があります。層を定義して、チームがどこで保守的であるかを認識できるようにします。

出力アーティファクト:

• 影響/重大度階層 (低/中/高)
• 階層ごとに必要な制御レベル (例: 高に対する人間の承認)

C) 入力データとアクセス (質問 8 ～ 10)

8) AI はどのような入力を使用しますか?また、どのソースが信頼できるものですか?

ビジネス現場における「幻覚」のほとんどは、実は「ソースの曖昧さ」の問題です。システムには、信頼できるソースの明確な階層が必要であり、競合や情報の欠落に対するルールが必要です。

出力アーティファクト:

• データ/ソース インベントリ (何が使用できるか)
• 真実の情報源の階層 (「ポリシー ドキュメントが Wiki を上書きする」など)

9) どのようなアクセスが必要ですか?また、アクセスしてはいけないのは何ですか?

最小権限は AI 要件であり、インフラストラクチャの詳細ではありません。システムが多くのことを認識できる場合、最終的には多くのことを明らかにしすぎることになります (多くの場合、偶然)。

出力アーティファクト:

• 役割×データアクセスマトリックス
• 明示的な除外 (「HR フォルダには決してアクセスしない」、「顧客 SSN は禁止」など)

10) 機密データ、保持、トレーニングの使用はどのように処理すればよいですか?

利害関係者は多くの場合、「ベンダーがこれを処理する」と想定しています。やめてください。ログに記録する内容、保存する内容、保存期間、データをトレーニングや改善に使用するかどうかを定義します。

出力アーティファクト:

• ログ記録/保存要件
• データ処理ルール（マスキング/リダクション）
• トレーニング利用ルール（許可・禁止）

D) 出力要件 (質問 11 ～ 13)

11) どのような出力形式が必要ですか (箇条書き、JSON、電子メールの下書き、意思決定の推奨事項)?

安定した品質を必要とする場合は、出力契約が必要です。構造により曖昧さが軽減され、レビュー可能性が向上し、テストが可能になります。

出力アーティファクト:

• 出力スキーマ/構造定義
• 2 ～ 3 個の出力例 (「良い」例)

12) 出力には何を含める必要がありますか (ソース、信頼度、リンク、タイムスタンプ)。

ここで信頼を守ります。出力を接地する必要がある場合は、引用/リンクが必要です。出力が意思決定に影響を与える場合は、不確実性の手がかりや制限の説明が必要です。

出力アーティファクト:

• 必須フィールドのリスト (引用、信頼度、レコード ID、タイムスタンプ)
• UI 表示要件 (これらのフィールドが表示される場所)

13) どのようなスタイルの制約が重要ですか (口調、読解レベル、免責条項、「ポリシーのように聞こえない」)?

スタイルは誤用に影響します。自信に満ちた口調は、ユーザーが弱い出力を過信する原因となる可能性があります。法的な響きがあると、コンプライアンスのリスクが生じる可能性があります。 「声」を意図的に定義する。

出力アーティファクト:

• トーン/スタイルガイド (短い)
• 禁止されている表現リスト (該当する場合、「保証されています」、「間違いなく」など)

E) ガードレールと容認できない行為 (質問 14 ～ 16)

14) AI は何をしたり、何を言ったりすることを拒否しなければなりませんか?

拒否するのが特徴です。明示的な拒否ルールがないと、システムはすべてに答えようとしますが、その答えの中には受け入れられないものもあります。

出力アーティファクト:

• 拒否ルール（「X と聞かれたら、Y で断る + 安全な代替案を提案する」）
• 禁止されているアクション/トピックのリスト

15) 人間へのエスカレーションが必要な「危険信号」シナリオとは何ですか?

エスカレーション ルールは顧客とビジネスを保護します。また、「なぜこれにフラグを立てなかったのか?」という疑問からチームを守ります。事件後の質問。

出力アーティファクト:

• エスカレーション トリガー リスト (シナリオ タイプ別)
• エスカレーション パス (誰/どこにルーティングするか)

16) 信頼性が低い場合の代替策は何ですか?

適切なフォールバックは、でっち上げられた答えを防ぎます。明確な質問をしたり、主要な情報源を表示したり、SME に誘導したり、不明な点を明示したりすることができます。

出力アーティファクト:

• 信頼性の低い動作仕様
• 質問パターンを明確にする
• ルーティング ルール (いつハンドオフするか)

F) 品質、評価、テスト (質問 17 ～ 18)

17) 品質 (精度、精度/再現率、根拠性、遅延) はどのように測定しますか?

「正確さ」だけでは十分なことはほとんどありません。 AI の役割が異なれば、品質の定義も異なります。この質問により、チームは議論が主観的になる前にルーブリックを定義する必要があります。

出力アーティファクト:

• 品質指標 + しきい値 (役割に応じた)
• 非機能ターゲット (レイテンシー、稼働時間、必要に応じてリクエストあたりのコスト)

18) 受け入れテスト セット (ゴールデン データセット) とは何ですか? 誰が承認しますか?

テスト ケースを早い段階で定義しないと、代表的なものではなく、最も簡単なものをテストすることになります。安全でないにもかかわらず「合格」しないように、エッジケースと拒否シナリオを含めてください。

出力アーティファクト:

• ゴールデン テスト セット プラン + 所有権
• サインオフの役割と開始基準

G) 運用: 監視、ドリフト、変更制御 (質問 19 ～ 20)

19) 本番環境では何を監視しますか?

システムは変化します – 使用量の変化、入力分布の変化、ポリシーの変化。モニタリングは、ユーザーが信頼を失う前に「静かな劣化」を発見する方法です。

出力アーティファクト:

• 監視要件 (信号 + しきい値)
• インシデントのトリガー (何が AI インシデントとしてカウントされるか)

20) 更新はどのように行われますか (プロンプト/モデル/バージョンの変更、ロールバック、監査証跡)?

AI システムは急速に進化します。バージョン管理、承認 (必要な場合)、ロールバック機能を備えた制御リリースとして変更を扱います。出力が変化した理由を説明できなければ、それを管理することはできません。

出力アーティファクト:

• 変更管理プロセス
• バージョン管理/監査証跡の要件
• ロールバック計画

回答を要件に変える（官僚主義に変えることなく）

これら 20 の質問を適切に実行すると、山のように書類を作成しているわけではないという安心できることに気づくでしょう。通常は曖昧さが隠れている場所に明確さを生み出すことができます。

それを把握するための最も現実的な方法は、毎回一貫した仕様フォーマットを使用することです。そのため、コピー/ペーストを分離しました AI 要件仕様テンプレート ダウンロード可能な PDF に変換します。記事からリンクし、エピック/ストーリーに添付し、未回答のセクションを暗黙の仮定ではなく明示的な「未定」の発見項目として扱います。

ワークショップ用の高速バージョンが必要な場合は、チェックリスト PDF が印刷または会議メモに貼り付けられるように設計されています。

実用的な「すぐに構築できる」経験則

プロトタイピングを始めるのに、すべての質問に対する完璧な答えは必要ありません。ただし、何を延期するのかを把握する必要があります。また、実稼働前に何が真実である必要があるか (ガードレール、テスト セット、監視、承認) について合意する必要があります。

チームが 20 の質問のうち少なくとも 15 に適切な明確さで答えることができない場合、次のステップは「コーディングを開始する」ことではありません。それは発見です。なぜなら、あなたに欠けているのは実装の詳細ではないからです。それは定義です。

---

著者： モーガン マスターズ、ビジネス アナリスト、Modern Analyst Media LLC

モーガンマスターズは ビジネスアナリスト およびスタッフライター ModernAnalyst.com、ビジネス アナリスト向けの最高のコミュニティおよびリソース ポータル。記事、ブログ、テンプレート、フォーラム、書籍などのビジネス分析リソースと、 ビジネスアナリストコミュニティ で見つけることができます http://www.ModernAnalyst.com