AIがあれば、アイデアは驚くほど早く形になる。

会議で「これ、AIでできそうですね」と決まり、その日のうちに試作品が出ることも珍しくない。

でも、作る速度が上がったぶん、別の失敗も速くなった。

必要とされていないものを、以前より早く作ってしまうことだ。

「業務をもっと効率化したい」「現場をもっとスマートにしたい」。こうした言葉は、相談の入口としては正しい。ただ、そのまま IT チームや開発会社に渡すと、出来上がるものが期待とずれやすい。

業務側が伝えるべきなのは、技術の指定ではない。

何の問題を解決したいのか。成功したら誰の仕事がどう変わるのか。何をもって成功と判断するのか。

この3つをそろえるための考え方が、要件の「三角プリズム」だ。

「効率を上げたい」では、IT チームは推測するしかない

たとえば飲食チェーンの担当者が、こう依頼したとする。

料理提供の効率を改善したい。

この言葉を受けた IT チームは、料理の提供状況を可視化するダッシュボードを作るかもしれない。悪い提案ではない。だが、それで本当に問題が解決するかは分からない。

同じ担当者が、こう伝えたらどうだろう。

毎日12:00〜12:30の注文量は、14:00〜15:00の5倍です。この30分は厨房が過負荷になり、ランチの回転率は1.2にとどまっています。同業態の好調な店舗は1.8です。厨房の面積や人員を増やさずに、提供ペースを平準化したい。注文量を事前に予測して仕込みを変えるか、一部の来客を別の時間帯へ分散させたいです。

今度は、検討の方向が変わる。

過去の注文を分析する。天気やイベントを含めて来客を予測する。時間帯別の価格施策を試す。必要なら厨房の作業工程も見る。

「料理の提供が遅い」と「12:00〜12:30に注文が集中する」の違いは、データ量ではない。問題をどれだけ正確に言葉にできたかだ。

三角プリズムで要件を組み立てる

三角形なのは、どれか1つ欠けると要件として立たないからだ。

問題だけでは、成功の形が決まらない。成功の姿だけを描いても、達成したかを判定できない。検収条件だけが先にあると、何のための数字か分からなくなる。

3つとも、業務側が書ける。技術の知識はいらない。上から順に見ていく。

1. 問題層：何が起きているのか

ここで扱うのは、解決策ではなく現状だ。

「ミスが多い」「顧客体験が悪い」「プロセスが遅い」は症状にすぎない。数字、場所、頻度に置き換える。

AI の案件では、もう一つ言い換えが要る。名詞を動詞に開くことだ。

「AI チャットボットを入れたい」「社内ナレッジ検索を作りたい」。この手の名詞は、口に出した瞬間は気持ちがいい。だが情シス、営業、経営、現場の頭には、それぞれ別のシステムが浮かんでいる。しかも全員が合意したつもりになる。

だから動詞で書く。受け取る、判断する、振り分ける、確認する、記録する、差し戻す。動詞を書くと、誰がやるのかが一緒に出てくる。

ここまでが現象。次に影響として、その現象で誰がどのような代価を払っているかを書く。

待たされて帰る来客が15%。毎日3卓分の売上を失っている。

代価まで書くと、「注文が集中している」というデータが、投資して解くべき事業課題になる。

仕組みでは、なぜ起きているのかの仮説を置く。

売れ筋メニューの70%は注文後に炒める必要があり、事前に準備できない。ピーク時に注文が一斉に厨房へ入るため、コンロが詰まる。30分前に注文量を予測できれば、半調理品を多めに準備でき、ピーク時の調理時間を短縮できるのではないか。

仮説で正解を当てなくていい。IT チームが検証する方向さえ渡せれば足りる。

2. 結果層：成功した日の仕事を描く

機能一覧を書いても、成功は伝わらない。

「リアルタイムでデータを収集する」「異常を通知する」「分析画面を作る」。これらは機能であって、業務がどう変わるかではない。

成功は、具体的な人物の、ある一日の場面として書く。

午前10時、店長の佐藤さんがスマートフォンを開く。近くで展示会があるため、今日の12:00〜12:30は通常より30%注文が増えると表示されている。システムは仕込みの提案も出す。佐藤さんは30秒で確認し、ピーク前に準備を終える。以前は12:15に注文が殺到してから人員を増やしても、厨房は混雑したままだった。

この短い場面には、要件に必要な情報が入っている。

• 誰が使うか：店長の佐藤さん
• いつ使うか：午前10時、ランチ前
• 何をするか：予測を見て仕込みを決める
• 何が変わるか：混雑してから対処するのではなく、混雑する前に備えられる

IT チームが作るべきものは、漠然とした「レポート自動化」ではない。ランチ前に注文量の予測と仕込みの提案を渡す仕組みだと分かる。

成功場面は、人物を決めてから書く

場面を書くときは、最初に「ユーザー」や「現場」ではなく、具体的な人物を1人選ぶ。架空の人物でもよいが、役割と仕事のリズムは決める。

• 店長の佐藤さん：毎朝10時に出勤し、前日の売上を見てから仕込み計画を立てる。
• 人事の水島さん：毎週月曜の午前に従業員の状況を振り返る。現在は Excel と上司の主観に頼っている。

人物が決まると、次の型で成功場面を書ける。

［朝／午後／プロジェクト終了後のある日］、
［その人］が［具体的な行動］をした。
以前と違う点は、［具体的な変化］である。

外れた日も、1行だけ書いておく

ここが、AI の要件と普通のシステムの要件が分かれるところだ。

従来のシステムは仕様どおりに動く。だから「正しく動いた日」だけ書けばよかった。AI は違う。確率で外れる。外れることを織り込んでいない要件は、精度が落ちた日に現場から見捨てられる。

だから成功場面を書いたら、外れた日も1行だけ添える。

予測が外れて仕込みが余った日、佐藤さんはその日の実績を1タップで戻す。外れが3日続いたら本部に通知が飛ぶ。

書くべきことは3つしかない。

• 誰がいつ気づくか：外れたまま誰も気づかない状態を作らない
• 誰が引き取るか：AI の判断を人が上書きする経路を決めておく
• 記録がどこへ戻るか：外した事例が次の予測に反映されるのか、捨てられるのか

「デモでは動いたのに、現場で誰も開かない」の多くは、機能の不足ではない。外れた日の段取りを、誰も決めていなかっただけだ。

3. 検収層：何をもって成功とするか

「リリースできたら成功」「使いやすければ成功」では、プロジェクトを評価できない。

検収条件には、少なくとも次の3つがいる。

1. 定量指標
2. 期間
3. 成功・失敗を分けるしきい値

検収条件を最後まで決めないまま進めると、修正は高くつく。要件段階なら数行の文章を直すだけだが、設計段階なら設計図を、開発段階ならコードを、リリース後なら運用そのものを変えることになる。だから最後ではなく、最初に書く。

ここで数字を完璧に決めなくていい。85%にするか90%にするかは、後から調整できる。

ただし、数字がなければ IT チームは議論できない。「予測精度」と言ったとき、100回の予測中85回が当たることなのか、実際に起きた100件の問題のうち85件を事前に見つけることなのか。定義が変われば、必要な仕組みも変わる。

検収条件を書こうとして手が止まるなら、それは悪いことではない。まだ何を求めているかが曖昧だと、早い段階で分かったということだ。

大きな案件は、段階ごとに検収する

最初から完成形を作ろうとせず、案件を小さなマイルストーンに切る。レストランの例なら、次のように進められる。

最初の段階で求めるのは改善ではなく、現状を正しく見ることだ。次にコンピュータ上で仮説を検証し、最後に現場の仕事を変える。どこかで終了条件を満たせなければ、次の段階へ無条件に進まない。

業務側と IT 側の境界を分ける

三角プリズムで業務側が決めるのは、問題、成功の姿、検収条件までだ。

使うモデル、データ基盤、実装方法、画面設計は、IT 側に預けていい。

業務側は「何が欲しいか」を担い、IT 側は「どう実現するか」を担う。この境界がはっきりすると、要件レビューは要求と反論の場ではなく、同じ問題を解くための会話になる。

IT チームから提案を受けたときは、技術の専門家でなくても、次の5つを確認できる。

1. この提案はどのデータに依存するか。そのデータはすでにあり、正確か。
2. 最初に成果を確認できるマイルストーンはいつで、何が見えるのか。
3. 最初の結果がよくなければ、調整するのか、中止するのか。
4. リリース後、誰が保守し、誰が問題に気づくのか。
5. 同業や他業界に似た事例はあるか。どの程度の効果が出たのか。

提案を否定するための質問ではない。実現性と運用責任を、最初に双方で確認しておくためのものだ。

価値と対象外も、最初に書いておく

要件を出すときに「この案件の ROI はどれくらいですか」と聞かれることがある。ここで厳密な財務モデルは必要ない。まずは、現在の損失と、改善できそうな量を概数で置く。

もう一つ、必ず書くべきなのが「今回の対象外」だ。

注文予測と仕込み支援の案件に、途中からシフト最適化、サプライチェーン調達、在庫の最適化まで追加すると、第1期の案件がいつの間にか3期分になる。予算が増え、期間が伸び、最初の成果が遠ざかる。

今回は注文予測と仕込み支援だけを対象にする。シフト最適化と調達予測は次期に検討する。

この一文があれば、「ついでにこれも」を次期の議論へ切り分けられる。

次の会議の前に、1枚だけ埋める

次に「どんな AI を作りたいですか」と聞かれたら、ツール名から話し始めない。

【問題層】
現象：誰が、いつ、どこで、何に困っているか
影響：誰が、どのような代価を払っているか
根本原因（仮説）：なぜ起きていると思うか

【結果層】
成功場面：具体的な人物が、成功後のある日に、何をするか
外れた日：誰がいつ気づき、誰が引き取り、記録はどこへ戻るか

【検収層】
検収条件：定量指標 + 期間 + 判定しきい値
価値見積もり：現状のコストと、改善できそうな量
今回の対象外：このプロジェクトではやらないこと

最初の版に空欄があってもいい。仮説が間違っていてもいい。この紙は完成した要件を提出するためのものではなく、業務側と IT 側が一緒に考えるための出発点だ。

「AIで効率化したい」から始めるかぎり、欲しいものは出てこない。

速く作れる時代に効くのは、作る前に問題を言葉にすることだ。何を作らないかは、そこでしか決められない。