メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談
プロジェクト相談

企業AIプロジェクトWiki · 要件・業務シナリオ

業務シナリオ

別名Business scenario · 業務利用シナリオ · ビジネスシナリオ · 業務操作シナリオ

定義

業務シナリオとは、明確な業務文脈の中で、一つ以上の役割が識別可能な結果へ到達するまでの作業を、有界な一本の流れとして表したものです。トリガーと前提条件から始まり、人、システム、第三者が情報を使い、判断し、引き継ぎ、例外を処理する方法を説明して、確認可能な終了状態まで進みます。適用範囲、頻度、規模、リスク、制約も記録します。

業務シナリオは文脈のある業務タスクであり、機能名ではない

「契約審査」「ナレッジQ&A」「在庫管理」は業務領域を示すだけで、誰がどの条件で何を完了し、その後どの状態になるかは示しません。同名機能でも、役割、データ、時間、規則、後続責任が違えば、支えるシナリオは異なります。

シナリオは静的要件を実際の仕事へ戻します。ユーザーとシステムの操作だけでなく、その前の業務状態、同時に関わる職務、外部システム、その後に残る仕事まで見ます。これにより画面、データ、API、権限、規則、人の判断、記録を判断できます。

現在状態と目標状態のどちらも記述できますが、明確に区別します。現在シナリオは問題、制約、既存責任を発見し、目標シナリオは案件が作る振る舞いを定義します。理想を現状と見なすと移行・研修を過小評価し、現状をそのまま写すと不要な作業を固定します。

案件で使える業務シナリオの構成

業務シナリオは、現場にいなかった人にも、仕事がなぜ始まり、どう進み、いつ終わるかを伝えます。役割と手順だけでなく、開始条件、使用情報、例外、最終記録までをつなぎ、システムの仕事と人の責任を分けます。

名称と業務目標

「購買責任者が予算超過申請を判断する」のように職務が認識できるタスクと結果で名付け、「承認モジュール」としません。隣接する対象外タスクも示します。

関係者と責任

申請者、主処理者、承認者、通知先、運用支援、結果の影響を受ける人を列挙します。役割は責任であり、アカウント名や個人名とは限りません。

トリガー

シナリオを開始する出来事、時刻、状態、外部メッセージを記します。画面を開くことは通常、業務開始の理由ではありません。

前提状態と適用条件

開始前の注文、契約、ID、権限、データ、時間枠、上流判断、規則版と、適用する組織、製品、金額帯を示します。

入力と情報源

人の入力、業務記録、ファイル、APIデータ、規則、外部証拠について、出所、必須性、有効期限、権限、情報不足時の処理を記します。

通常経路

人、システム、第三者の主要動作、判断、状態変化、引き継ぎを業務順に説明し、すべてのクリックではなく要件に影響する意味を残します。

代替・例外・停止経路

資料不足、規則不適用、権限不足、重複、API障害、時間切れ、矛盾、取下げ、人の例外を扱い、復旧、補足、却下、終了を示します。

終了状態と出力

成功、却下、取消、人への移管、補足待ちと、判断、データ変更、通知、文書、後続作業を定義します。成功画面だけでは業務終了になりません。

業務記録と追跡性

入力版、判断根拠、実行者、時刻、状態履歴、外部応答、例外理由と、閲覧権限・保存期間を定めます。

運用特性と制約

概算頻度、ピーク、同時数、期限、バッチ、季節性、重要度、許容停止、機密性、地域、言語を記録します。これらは構成、費用、検収を変えます。

業務シナリオの大きさと細かさ

大きすぎると「顧客対応を行う」のような見積不能の標語になり、細かすぎると一回の操作やAPI呼出しになって業務結果が消えます。一人の役割が明確な条件で確認可能な仕事を終え、重要な例外と人の分岐も残る粒度を選びます。

  1. 一つの識別可能な結果へ収束するか

    複数役割・システムを含めても、一つの業務タスクが明確な終了状態に達したところで閉じます。

    確認：名称、トリガー、目標、終了状態が一文でつながる。

  2. 重要な文脈を残したか

    役割、規則、適用条件で結果が変わる場合は分岐や子シナリオにし、「他も同様」で済ませません。

    確認：適用範囲、規則版、分岐条件。

  3. 画面単位の断片を避けたか

    ログイン、一覧表示、ボタン操作は通常ステップです。本人確認や認可など独立した業務結果がある場合のみ場面になり得ます。

    確認：独立した業務価値と終了状態。

  4. 複数の異なる目標を詰め込んでいないか

    申請、承認、履行、精算は一つの旅程でも責任、時間、規則が違うため、関連する複数シナリオに分ける場合があります。

    確認：共通終了条件のない目標が混在していない。

  5. 概要と詳細を分けたか

    高位場面は範囲・会話、詳細場面は要件・設計・テストに使い、安定IDで親子と要件を双方向追跡します。

    確認：親、子、関連要件のリンク。

  6. リスクに応じた詳細か

    高頻度、高額、不可逆、機密、規制対象は例外、認可、証拠を厚くし、低リスクは軽い記録にできます。

    確認：リスク区分と詳細化条件。

実際の仕事から業務シナリオを発見・確認する

有用なシナリオは、システム画面から想像するより実際の仕事から見つかります。現場が情報を受け取り、障害を回避し、データを補い、確認を求める様子を見ると、欲しい機能を尋ねるだけでは見えない流れが分かります。

  1. 実際のタスクと結果から始める

    利用者、処理者、支援職を面談・観察し、何をどう完了し、どこで止まるかを調べ、機能表から仮想場面を逆算しません。

  2. 既存証拠を集める

    帳票、規程、チケット、ログ、報告、メール、API、研修、例外記録を確認し、正式規則、実務、個人慣行を区別します。

  3. 開始、境界、終了を定める

    各候補の開始事象、前提、主結果、対象外の上流・下流作業を示し、隣接場面を重複なく接続します。

  4. 通常の一本を再生する

    代表入力を使って担当職が最初から最後まで説明し、人、システム、判断、引き継ぎ、データ変化、記録、根拠を示します。

  5. 非正常条件を意図的に聞く

    不足、誤り、重複、矛盾、遅延、取下げ、権限外、外部障害、人の例外を逐一確認し、本番後に隠れた規則を発見しないようにします。

  6. 運用量とリスクを加える

    頻度、ピーク、期限、バッチ、機密、金額、影響対象、失敗結果を確認し、一つの順調な例で実運用を代表させません。

  7. 役割横断で再生する

    業務責任者、実利用者、技術、データ、セキュリティ、運用、テストがリスクに応じて同じ場面を確認し、相違を記録・決定します。

  8. 識別、承認、維持する

    安定ID、版、適用範囲、出典、確認者を記録し、規則・システム境界の変化時に範囲、要件、設計、テスト、検収への影響を評価します。

業務シナリオ記録の構造例

以下は顧客案件と無関係な構成例で、一つのシナリオがどう連続して読めるかを示します。表、文章、業務モデルのどれでも構いません。読者がタスク、境界、例外、責任を再現できることが重要です。

SC-012：購買責任者が予算超過申請を処理

現行予算・購買規則に基づき、権限のある責任者が承認、補足返却、却下を決めます。供給者契約と支払は対象外です。

役割とトリガー

完全な購買申請が部門の直接承認上限を超えると開始します。購買責任者が主担当、予算責任者が共同承認する場合があり、申請者へ結果を通知します。

前提と入力

申請者、部門、原価中心、承認権限が有効で、購買規則版を識別でき、用途、金額、供給者、見積添付、希望日があります。

通常経路

残予算と適用規則を読み、申請と根拠を表示して判断を記録します。権限超過なら予算責任者へ移し、最終状態、理由、通知を申請へ書き戻します。

重要な逸脱

予算データ不可なら自動判断を止めて人へ移し、見積不足なら返却、重複は再度予算を占有せず、申請者と承認者が同一なら代替権限者へ回します。

終了と記録

承認、返却、却下、人への移管で終了し、入力版、規則・予算Snapshot、閲覧・判断者、時刻、理由、状態履歴、通知結果を残します。

運用条件

日量、月末ピーク、判断期限、金額区分、データ機密性、API可用性、保存要件を確認して初めて見積・検収に使えます。

スコープ、要件、設計、検収への接続

同じシナリオを、スコープは対象判断、要求はシステム動作、設計は実現経路、検収は元の仕事の確認に使います。このつながりが切れると、機能は完成しても業務が最後まで通らない状態が起こります。

スコープ

場面IDで本期の実タスク、役割、地域、データ境界を示し、対象外も参照して機能名だけの範囲を避けます。

要件

役割動作、情報、判断、状態、例外から機能、データ、権限、API、非機能要件を導き、双方向追跡を保ちます。

製品・操作設計

組織図やDB表ではなく、タスク順、文脈切替、バッチ、表示情報、判断リスク、支援需要から画面を設計します。

アーキテクチャ・連携

量、期限、一貫性、依存、外部障害、復旧条件を、API方式、非同期、容量、Cache、監査、耐障害性へ反映します。

権限・安全

役割、業務対象、動作、条件から認可を作り、見えてはいけない、実行できない、再確認が必要な経路を試します。

テスト・検収

通常、代替、例外、非正常条件を入力、期待結果、版、環境、証拠へ結びます。業務シナリオ自体はテストケースではなく、網羅性の出所です。

本番移行・運用

代表場面で演習、監視、障害診断を行い、重要状態に指標・通知を置き、支援担当の引き継ぎ点と復旧を定めます。

企業AIの業務シナリオで追加固定する文脈

AIができることは、利用できる根拠、利用者の身元、許可された操作で変わります。同じ質問でも役割や業務段階が違えば対応は変わります。会話例だけでなく、回答と行動の境界を決める文脈を記録します。

まず仕事の中でAIが担う役割を示す

AIは資料検索や草案だけを行う場合もあれば、分類、推奨、システム状態を変えるツール実行まで行う場合もあります。責任は大きく異なるため、AIがどこまで進み、担えない業務判断は何か、最終結果を誰が確認し責任を持つかを示します。

ナレッジと証拠

許可資料、データ、規則、権限、有効期間、必要引用、資料不足・矛盾時の処理を定めます。

入力・文脈境界

ユーザー入力、履歴、検索片、ID、業務対象、システム状態のうちモデルへ渡せるものを定め、モデル生成IDや事実を認可根拠にしません。

許容出力と不確実性

事実性、完全性、形式、語調、引用、許容差を示し、人が編集する草案と業務へ直接影響する構造結果を分けます。

拒否、停止、人への引き継ぎ

根拠不足、権限外、機密、高リスク、規則矛盾、不確実時の拒否、質問、移管、動作阻止、文脈保持を定めます。

Tool実行と実世界への影響

送信、書込、注文、Ticket、承認では引数出所、最小権限、確認、上限、冪等性、補償、監査、不可逆動作の権限を示します。

評価・運用条件

正常、境界、例外、情報不足、攻撃、高影響サンプルを作り、モデル、Prompt、索引、Tool版と実際の量、遅延、費用、揺らぎを記録します。

影響を受ける人と予見可能な誤用

直接利用者以外の影響対象、想定用途外の使用、負の結果、フィードバック・異議申立経路を識別します。

業務シナリオと混同しやすい概念

ユーザーストーリー、ユースケース、業務フロー、機能一覧は、それぞれ別の角度から仕事の一部を表します。業務シナリオはまず一つのタスクの文脈全体を保ち、その後で必要な表現へ分けます。すべての要求資料を置き換えるものではありません。

関連概念業務シナリオとの違い
製品利用・マーケティング場面マーケティングは製品の適用先を一文で示せますが、案件場面には追跡可能な役割、条件、経路、結果、責任、運用境界が必要です。
UMLユースケースユースケースはシステム境界外のActorへ提供する観測可能な振る舞いです。業務シナリオはシステム境界決定前の人、複数システム、オフライン動作も横断できます。
ユーザーストーリーストーリーは役割、需要、目標を管理可能な開発単位にします。シナリオはより完全なトリガー、文脈、引き継ぎ、例外、終了を持ち、複数Storyを生みます。
業務プロセスプロセスは活動、イベント、ゲートウェイ、参加者、メッセージを多数の事例にわたって整理します。シナリオは特定条件の一本の有界な流れを一つの結果まで追います。
ユーザージャーニージャーニーはより大きな目標へ向かうユーザーの時間・チャネル上の段階、需要、経験を示し、複数組織・シナリオを含みます。
業務の完結業務の完結は入力、処理、判断、結果、記録、後続責任がつながるかを問います。シナリオはその中の一本を記述・確認する単位です。
テストシナリオテストシナリオは検証条件・振る舞いを選び、業務場面、要件、リスク、故障から派生します。さらに対象、版、環境、入力、期待結果を指定します。
顧客事例顧客事例は実案件・結果を報告し、証拠と公開許可が必要です。業務シナリオは要件モデルであり、納品や成果を証明しません。

出典と適用範囲

本項目は、企業案件で実際の業務タスクとその文脈を表す業務シナリオを説明します。業界名、部門名、「効率を上げる」という目標、機能一覧、画面試作、一行の利用例ではありません。UMLのユースケース、アジャイルのユーザーストーリー、業務プロセス全体、業務の一連の完結、テストシナリオ、顧客事例とも同じではありません。文章、表、スイムレーン、ジャーニーマップ、ユースケースモデルのどれで記録しても構いません。重要なのは、関係者、開始条件、事前状態、入力、通常・例外処理、人とシステムの責任、結果、記録を識別できることです。