「小さくても動くものを、まずは早く作る」
AI導入の検討を始めると、過去にPoCや新規開発を経験したメンバーや、社内でアジャイルな進め方を学んだ人から、よくこの言葉が出てきます。
スライドの資料だけで延々と説明されるより、それっぽい画面が目の前にあるほうが安心しますし、実際のデータをシステムに読み込ませると、それらしい日本語が返ってくる。それを見た部長や役員たちが「なるほど、これは便利そうだ」と満足そうに笑う。
そこまでは、本当にうまくいくのです。
本当に厄介なのは、その翌週から、まるで全員が記憶を失ったかのように議論が止まってしまうことです。
プロトタイプはちゃんと動き、不満を言う人もいないのに、次の打ち合わせになった途端、みんな急に黙り込んで資料の隅を眺め始めます。
「本番化に向けて予算を組むのか」「もう一度条件を変えてテストを繰り返すのか」「一度ここで手を引くのか」。決断を迫る空気が部屋に満ちているのに、誰も口を開きません。
画面が動くことと、社内の人間関係や予算の承認が動くことは、全く別の問題だからです。
つまり、最初の検証（MVP）で確かめたいのは、バグがあるかどうかではないのです。
その画面を見たことで、現場の人たちがどんな顔をし、経営陣が次にどの数字を求めてくるのか。そこが見えない検証は、ただの「いいものを見せてもらった」という感想で終わってしまいます。
MVPという言葉を聞くと、どうしても「機能を絞り込んだミニ版の完成品」を作ろうとしてしまいます。
画面の数を減らし、複雑な仕様を削って、最低限のコードで動かす。検証の費用や時間を抑える意味では正しいやり方ですし、早く作って見せることには価値があります。
ただ、そうやって小綺麗にまとめたシステムを見て、人が本当に納得するのかというと、少し怪しいと思っています。
本当に必要としているのは、予定調和のデモシステムなのでしょうか。
それを見た現場の担当者が、「これなら、毎週月曜の午前中を丸々潰している手作業のデータ突合が、10分で終わるかもしれない」と実感する。一方で、「数千万円規模の案件で、AIが作った提案書をそのまま顧客に出すのは、さすがに怖い」と、自分の明日の仕事に引き寄せて考え始めることです。
この具体的な反応がないと、どれだけ滑らかに動くものを見せても、「素晴らしいですね」という他人事の感想で終わってしまいます。現場は自分のやり方を変える面倒くささを想像できませんし、経営陣も、何をクリアすれば投資していいのかの判断基準が作れません。推進チームだって、最初の1ヶ月（Day0-30）の検証期間で、何をゴールにすればいいのか分からなくなってしまいます。
以前、自信を持って作ったプロトタイプを現場に見せたとき、「便利なのは分かりました。でも、これを今の業務にどう入れるんですか」と聞かれ、言葉に詰まったことがあります。
画面は動いていました。想定した回答も返ってきました。ただ、それを誰が、どの場面で使い、今の手順をどう変えるのかまでは考え切れていなかった。システムを動かすことに集中するあまり、現場が感じる戸惑いや、運用を変える重さを見ていなかったのだと思います。
MVPは、完成品の手前にあるお試し版ではなく、次の判断を前に進めるための材料です。
最初の1歩（Day0）で私たちが狙うことは、「WAO!」という瞬間です。
これは、派手な機能で驚かせることではありません。
「最新のAIはすごいですね」といった、どこか冷めた拍手はむしろいらないのです。もっと地味で、少し嫌味なぐらいの、現場からの具体的な突っ込みが欲しいのです。
デモを見た現場の、たとえばいつも機嫌の悪いベテラン社員から、こんな声が上がったら合格だと思います。
「この割引率の判定、マニュアルの42ページ目にある例外ルール見てる？」
「でもさ、この判断だけは人間が承認ボタンを押さないと、何かあったときに誰も責任を取れないよ」
「実際のデータはもっと表記がバラバラだから、この画面じゃ動かないと思う」
こういう言葉が飛んでくるとき、検証は本当に始まっています。
綺麗な建前をやめて、自分たちの日常にそのシステムをはめ込んだときの「ズレ」を、真剣に指摘し始めているからです。
どこで使えて、どこが危なくて、何が足りないか。そんな生々しい議論のほうが、上っ面のポジティブな感想よりはるかに価値があります。
経営陣の視点も同じです。
「どの業務まで広げたら、この投資を回収できるのか」
「リスクが残るポイントは、具体的に誰が管理するのか」
という論点が出てくるなら、そのプロトタイプは役割を果たしています。次の意思決定を動かすための材料になっているからです。
拍手が起きるような綺麗なプロトタイプよりも、現場の人が少し前のめりになって、眉間に皺を寄せながら「これ、うちのあの部署の業務に当てはめたらどうなる？」と口にし始める。その瞬間を作れるかどうかが、分かれ道になります。
最初の段階でこういう反応を引き出すには、ありきたりなサンプルデータでは全く足りません。
きれいに整えられたダミーデータを入れて、AIが完璧な回答を返す。見栄えはいいですし、説明も楽です。けれど長年その業務で飯を食ってきた現場の人間は、一瞬で見抜きます。
「うちのデータはこんなに綺麗じゃない」「実際の現場はもっと例外処理ばかりだ」
と、一歩引かれてしまうのです。だから、できるだけ実際の業務で使っている、リアルな材料をそのまま使ったほうがよいのです。
過去の、もう見たくもないようなトラブル対応の履歴と報告書、営業の商談メモ、あのややこしい特価申請書。普段から見慣れている生データを放り込んで、AIに次のアクションを提示させてみる。その瞬間に、見る側の目が変わります。
たとえば社内の問い合わせ対応を検証するなら、AIが美しい日本語を書けるかどうかは、さほど重要ではありません。現場が本当に気にしているのは、「なぜその回答を導き出したのか」「どの社内規定を参照したのか」「このケースまでAIに自動回答させて、事故が起きないか」という、判断の裏側です。
たとえば社内の問い合わせ対応を検証するなら、AIが美しい日本語を書けるかどうかは、さほど重要ではありません。現場が本当に気にしているのは、「なぜその回答を導き出したのか」「どの社内規定を参照したのか」「このケースまでAIに自動回答させて、事故が起きないか」という、判断の裏側です。
新人や中途採用者、異動してきた担当者にとっては、返信文そのものよりも、ベテランが普段どこを見て、何を恐れて判断しているのかが画面上で可視化されることのほうが、よほど実用的な価値になります。
見積業務も同じで、見積書を作るのが早くなるだけでは仕事は変わりません。値引きの根拠が過去の類似案件と合っているか。上司が差し戻しそうなポイントを事前に潰せているか。判断の理由が次の案件に活かせる形で残るか。そこまで画面で見えて、ようやく現場は「これなら使えるかもしれない」と考え始めます。
完璧な回答を出すことが目的ではなく、どこまでをAIに任せて、どこから人が入るべきか。関係者がその具体的な条件を話し合える状態を作ることが、この段階の目的です。
検証の報告で、「現場の反応は上々でした」とうれしそうに語られることがあります。
嫌がられるよりは歓迎されたほうがいいですが、次の投資を決める材料としては、正直、何の役にも立ちません。チェックすべき部分は感想の良し悪しそのものではなく、それを見た後に関係者の行動や会話がどう切り替わったか、その一点です。
現場が「このチェック作業なら、来週から試してみたい」と言い出す。マネージャーが「この条件なら、上司への確認回数を半分に減らせるかもしれない」と計算を始める。経営陣が「何が確認できれば次の予算を出せるか」を具体的に話し合う。推進チームが「Day0-30では、この例外パターンの処理精度を見にいこう」とタスクを整理する。
ここまで動いて、ようやくただのプロトタイプ画面から、検証のための道具に変わります。
AIの導入ではここが外せません。
機能が動くことだけを追うならば、それは技術検証で終わってしまいます。実際の導入を進めるには、現場の作業、経営の投資判断、推進チームの設計、この３つが同じ現実的な論点で繋がらなければならないのです。
たとえば、月報作成という一見小さな社内業務でも同じです。
複数の顧客案件を抱える担当者にとって、金曜の夕方に待っているのは、今週の活動履歴を思い出し、チャットや議事録を探し回り、月報の文章を整える作業です。AIが文章をきれいにまとめただけでは、この憂鬱は消えません。
対象の月を指定すれば、関連する活動ログが自動で集まり、顧客案件ごとの動きや成果まで整理されて出てくる。そこまでやって初めて、「この案件、本当に前に進んでいるのか」「成果と言えるものは何か」といった、具体的で、ときに少し刺々しい会話が始まります。
「このログはどこから引っ張ってきているのか」
「社内の活動記録じゃなくて、顧客の案件単位で整理しないと報告書にならない」
「月報に書きたい粒度と、日々残している日報の粒度がズレている」
こういう指摘が出るなら、それは単なる文章生成のデモではなく、Day0-30で何を検証すべきかを明確にするための、生きた材料として機能しています。「便利そう」という感想ではなく、具体的な判断条件や例外処理の論点が表に引っ張り出されてくるかどうか、そこを見ています。
動くものを見せて具体的な反応が返ってきたら、次にやるべきは、Day0-30（最初の30日間）で確かめる中身を決めることです。
誰に触ってもらい、どの業務ラインで試すのか。何が確認できれば次のステップ（GO）で、どんな課題が残れば条件付きの進捗（Conditional GO）とするのか。そして、どうなったら一度引く（No-GO）のか。
ここを曖昧にしたまま「とにかく1ヶ月試してみましょう」と始めると、30日後に残るのは「なんとなく便利だった」「もう少し改善必要だ」といった、中身のない感想になりがちです。
問い合わせ対応を検証するなら、返信文を作る時間だけを測ってもあまり意味はありません。ベテランへの確認回数が実際に減ったのか。新人が自分で判断材料を探せるようになったのか。一次対応で解決した割合が増えたのか。こうした具体的な行動の変化や事実を追いかけないと、次に進むべきかどうかの判断は下せません。
見積業務であれば、作成時間の短縮だけでなく、値引き根拠の妥当性や、上司からの差し戻し回数の変化、判断理由が後から再利用できているか、といった点を見る必要があります。
ここで得るべきなのは、システムの機能評価ではないはずです。誰の業務の、どの判断や行動を変えたいのか。その変化をどの事実で確認するのか。次に進むための条件は何か。これらを具体的にセットできるようになること自体が、最初の検証の、最大の成果なのだと思います。
綺麗に見せるための展示品は必要ないのです。
現場が自分の業務に引き寄せ、経営が投資判断の軸を定め、推進チームがDay0-30の検証論点を整理する。そのための仕掛けです。
最初の形を作るときに「どの機能を詰め込むか」から入るのは、少しズレている気がします。
この画面を見た関係者に、どんな会話を始めてほしいのか。どの判断を前に進めたいのか。30日後に、どんな材料が手元にあれば次の意思決定ができるのか。そこから逆算して、検証の場を設計していきます。
Day0で揃えるべきものは、将来の完成予想図ではありません。
・誰の業務で使うのか
・どの判断や行動が変わるのか
・何が見えればGOで、何が残れば再検証なのか
・どうなったら止めるのか
この判断の基準が最初に関係者の間で揃っていれば、Day0-30の検証が「ただ試して終わった」という結果にはなりにくくなります。
AI導入における最初の検証物は、完成品を小さくしたものではありません。その機能が加わった後に、現場や経営の会話がどう変わるか。次に見るべき論点が具体的になるか。投資の判断に使える材料が残るか。そこまでを見据えて動かすものは、単なるデモという枠を超えます。
PoCを単なる社内実験で終わらせないためには、最初の段階で「何を判断するための検証なのか」の目線を揃えておく。展示品ではなく、次の判断を前に進めるための道具として、それを扱います。
言うのは簡単ですが、これが一番難しいのかもしれません。
私たちも、ここには正面から向き合ってきました。うまくいかなかった検証も含め、何を揃えれば現場と経営の判断が動くのかを、実践の中で確かめ続けています。
次の記事：AI導入相談で最初に整理すること ～アシストAIテラスが描く業務変化の設計図～