「この業務に問題がある」から「この手順をこう分ける」へ
Discovery で「修繕依頼の受付がボトルネックで、AI に向いている」と分かりました。しかし、これだけでは設計も開発もできません。Definition は、選んだ業務を設計・開発に渡せる具体的な形に落とすステップです。成果物は4つあります。
成果物1 業務フローチャート：暗黙知を手順にする
最初の作業は、対象業務を手順として書き出すことです。Discovery では「月 300 時間かかっている」という認識で止まっていました。Definition では、たとえば修繕依頼の受付を次の6ステップに分解します。
- 入居者からの依頼をメールまたは Web フォームで受け取る
- 物件名・部屋番号・連絡先がそろっているか形式を確認する
- 依頼の文章と写真から、設備の種類と症状を読み取る
- 症状から緊急度（即日・3日以内・通常）を判定する
- 対応できる業者の候補を選び、入居者への初回連絡文を作る
- 業者に手配を依頼し、入居者に訪問予定を通知する
そのうえで、各ステップを誰が担うかを決めます。1・2 は定型処理で自動化、3 は AI が設備と症状を読み取り、4 は AI が緊急度の判定案を出して担当者が確定（導入初期は全件を人が確認）、5 は AI が業者候補と連絡文の下書き、6 は担当者の承認後に自動送信。
暗黙知のまま進めると「AI に任せる範囲」と「人が担う範囲」の線が曖昧になり、Design 以降で手戻りが起きます。第2章の HTA や IPO の手法が本格的に使われるのはここです。この粒度の違いが、Discovery と Definition の境界線です。
成果物2 要件定義書：4つの要素
「要件定義書」と聞くと、エンジニアが書く難しい文書を想像しがちです。しかしストラテジストに求められるのは、完全な文書を一人で書き切ることではありません。何を実現したいか、どの品質を求めるか、何を扱ってよくて何を扱ってはいけないかを、叩き台として言葉にすることです。その叩き台に実装側が技術的な補足や修正を加えて、実現できる設計になっていきます。
要件定義書の構成要素は4つです。
| 要素 | 問い | 例 |
|---|---|---|
| 機能要件 | 何をさせたいか | 依頼文から設備の種類と症状を抽出する、緊急度を3段階で判定する、業者候補を提示する |
| 非機能要件 | どの水準で動いてほしいか | 受付から判定案の表示まで 60 秒以内、同じ依頼なら判定のぶれがない、24時間受け付ける |
| 制約条件 | 守らなければならないルール | 入居者の国籍・年齢・契約形態を緊急度の判定に用いてはならない |
| 前提条件 | すでに満たされているとみなす条件 | 依頼はメールか Web フォームで届く、物件と設備の情報は管理システムに登録済み |
見分け方は、「何をするか」が機能要件、「どの水準でするか」が非機能要件です。試験では「判定案の表示まで 60 秒以内」のような処理時間が非機能要件として問われます。制約条件の「入居者の属性を判定に使わない」は、公平性のための重要な制約です。属性を判定に含めると、人の無意識の偏りが AI に再現されます。
前提条件が実際には満たされていなかった場合（たとえば設備情報が半分の物件で未登録だった）、設計そのものを見直す必要が出るので、先に明確にしておきます。
成果物3 ペルソナ：この人は AI の出力で何を決めるのか
ペルソナは、利用者の典型像です。これが曖昧だと「技術的にはすごいが、誰も使わないエージェント」ができます。
AI のペルソナで大事なのは、年齢や役職ではなく、**「この人は AI の出力をどう使って、どんな判断を下すのか」**です。
- ペルソナ A（管理部門の担当者）: 設備の技術的な知識には自信がなく、いまは症状を見て先輩に都度確認している。判定に「給湯器の着火不良の可能性が高い」のような根拠が付いていれば、自信を持って緊急度を確定し、業者を手配できる。
- ペルソナ B（提携する設備業者の受付担当）: 「とりあえず見に来てほしい」という依頼が多く、現地で部品がなくて二度手間になる。症状の詳細と、入居者が試したこと（元栓の確認など）が手配時に添えられていれば、一度で済む。
ペルソナ B の要求から、「業者への手配文に、症状の詳細と入居者が確認済みの事項を構造化して添える」という機能要件が導かれます。ペルソナが機能要件を決める、という流れを押さえます。
見落としやすいのが 間接ユーザーです。AI を直接操作する人だけでなく、AI の出力を確認・監督する人（この例では手配の結果を月次で確認する物件オーナー担当）もペルソナとして定義します。第2章の SIPOC 分析で学んだ「出力の受け取り手を漏れなく洗い出す」考え方がここで活きます。
成果物4 合格基準：PoC の合否を決める一回限りの線
合格基準は、AI の品質が「業務に使えるレベルに達しているか」を判断する定量的な基準です。Definition で決める理由は、Step4 の PoC で合否を判定するときに使うからです。先に決めておかないと、結果を見てから「これで十分か」を主観で判断することになります。
基準には根拠が要ります。「なんとなく 90% 以上」ではなく、たとえば「設備と症状の読み取りの精度 90% 以上。根拠は、現在の担当者間の判定一致率が 84% で、AI がこれを上回ることを最低条件としたため」のように、業務の現状から逆算します。公平性の基準として、同じ症状で入居者の属性だけを変えた模擬依頼を入力し、緊急度の判定が変わらないことを確認する公平性テストも入れます。
合格基準と KPI の区別も出ます。合格基準は「PoC の合否を判定する一回限りの基準」、KPI は「運用中に継続的に成果を測る指標」です。
試験で問われる観点
- 「業務をステップに分解し、各ステップを AI に任せるか人が担うかを決めた」活動は Definition。
- 要件定義書の記載のうち非機能要件に該当するもの（処理時間、安定性、稼働時間）。機能要件（抽出する、判定する、提示する）との区別。
- ペルソナから導かれる機能要件（業者が必要とする症状の詳細を構造化して添える機能）。
- 合格基準は Definition で事前に、業務の現状から逆算して決める。KPI とは別物。
- ストラテジストの役割は完全な要件定義書を一人で書くことではなく、叩き台を言語化して実装側と共同で具体化すること。