デモが1日で作れる時代の、期待値の扱い方

gaipack のプリセールスを担当しています。AI を活用すれば、業務フローも件数も書かれていないような相談からでも、触れるデモを1日で作れるようになりました。ただ、デモが作れることと、そのデモの通りに実装できることは別でした。デモが早く作れるようになったぶん、見せたあとの期待値をどう扱うかが課題になった、という話です。

※商談の内容は一般化しています

---

資料が1行しかなくても、仮説は AI と作れる

色々なご相談をいただく中で、業務フローも現行システムも件数も体制も何も分からないこともあります。この商談で最初に受け取ったのも、お客様ご自身が書かれたアイデアシート1枚でした。「こうなったらいい」が数行あるだけで、いまの手順も、どれくらいの量を扱っているのかも書かれていません。

ここで「まずヒアリングをさせてください」とだけ返してしまうと、次の打ち合わせまで何も進みません。かといって準備なしで伺えば、何を聞けばいいのかも決まらないままです。そこで、仮説を先に用意してから商談に臨むようにしました。

やっていることは単純です。受領資料・議事録・公開情報・過去の似た案件を、粒度が揃わないまま AI に渡す。「誰の・どの業務が・どう変わるか」を書かせて、違うと思う点をぶつける。それでも答えの出ない点は捨てずに残し、お客様に確認する項目と、社内で議論する項目に分けておく。お客様が言っていないことを提案書に書かないのは、自分のなかのルールにしています。

仮説は当たらなくてかまいません。むしろ「そこは違う」と言ってもらえる状態になっているかどうかが大事だと思っています。

デモは、直してもらうために持っていく

デモを作る目的は見せ場を作ることではなく、話の精度を上げることです。提案書だけで臨むと、議論は「その機能は本当に要るのか」で止まります。参加者がそれぞれ違う絵を思い浮かべたまま、次回に持ち越しになります。

触れるデモがあると、「うちの運用だとこの画面はこうなる」と、お客様が自分の業務の言葉で直しを挙げてくださいます。仮説の間違いがその場で浮き彫りになるので、次の打ち合わせを待たずに直せます。ここしばらく複数の案件で試していますが、どの案件でも着手した日のうちに初版までは持っていけました。

形式は渡し方から決めています。今回はこちらがファイルをお渡しする立場で、相手先の端末で開かれる可能性もありました。そのため単一の HTML ファイルにしています。サーバーを立てずに渡せますし、渡した先で環境を用意してもらう必要もありません。

同じ「1画面」でも、実装の重さはまるで違う

反省しているのはここから先です。デモは1日で作れましたが、その通りに実装するのは別の話でした。

分かりやすい例が完了画面です。見積では画面ごとに規模を見ていきますが、ただ結果を出すだけの完了・中止画面はいちばん軽いほうに入ります。同じ完了・中止画面でも、決済が絡むと一気に重いほうへ移ります。使う人から見れば、どちらも「処理が終わりました」と出るだけの画面なのに、見積上の重さは数倍違います。

決済側では、こういうものが裏側に必要になるためです。

デモなら、この画面は数分で作れます。ボタンを押したら「完了しました」と表示する、それだけです。重い部分ほど、デモでは軽く見えます。

デモから裏側を逆算して、見積の入力にする

そこで、実現可能性と見積を出す工程を2段階に分けました。作ったデモをそのまま AI に渡して、裏側に必要な処理を先に洗い出させ、そのうえで規模を分類します。

一直線には進みません。商談で直しが出れば仮説に戻りますし、裏側を洗い出した結果、デモの前提そのものを作り替えることもあります。

止めてはいけないのはデモの段階です。ここで終えてしまうと、見せただけで終わります。いつまでに何ができるのかを答えられないまま、話だけが進んでしまいます。

裏側に何が要るのかを書き出させる

「この画面が本当に動くには、裏で何が必要か」を書き出してもらいます。返ってくるのは、だいたいこのあたりです。

• データと連携。どのマスタが要るか、既存の台帳とどう繋ぐか、移行は誰がいつやるか
• 状態と例外。状態遷移が網羅されているか、同時に2人が触ったらどうなるか、途中で失敗したらどこまで戻すか、監査ログをどう残すか
• 横断で重いもの。認証・権限・ロール、性能と可用性、閉域構成、運用と保守。これらは機能ごとの見積に混ぜません

例外系は、人が洗い出すと自分の意識している範囲しか出てきません。デモは、うまくいく道だけを歩いて見せているものです。抜けを埋めてもらう相手として、AI は向いています。

デモの画面一覧を、そのまま機能一覧として渡す

見積は機能ごとに規模を分類して工数を出すので、デモの画面一覧をそのまま機能一覧として使えます。機能を書き起こす手間がかかりません。

規模は、見るだけの画面から、登録や承認が入る画面、外部システムや AI が絡む画面、決済や基幹システムに関わる画面まで、いくつかの段階に分かれています。目安の時間はここには書けませんが、肝心なのは、すべての画面を同じものさしに載せることのほうです。小数点以下を詰めるためではなく、「1人月では終わらないし、20人月にもならない」という桁を外さないために使っています。

今回のデモに並んでいた画面を、実装したときの「型」に置き換えると、次のようになりました。

この型ごとに規模を当て、要件定義の分を足して人月に直します。合計すると、デモにかかった時間とは比べものにならない規模でした。認証・権限、PM、総合テスト、データ移行はここに含めていないので、足せばもっと増えます。

商談で「これだけで自動で入るんですね」と喜ばれた部分が、実装では一番重い部類でした。AI に読み取らせて判断させる処理は、規模で見ると上のほうに入ります。モデルをつなぐだけでは終わらず、AI が間違えたときに人が気づいて直せる導線まで作り、それが本当に機能するかを検証しないといけないからです。デモでは一番簡単に作れてしまうので、ここは読み違えやすいと感じました。

1画面の裏で決めることは、UI には出てこない

明細の確認画面を例に取ります。デモでは、抽出結果に低い信頼度スコアを表示し、「要確認」のラベルと修正ボタンを置くところまでで終わりです。実装するとなると、UI に出てこない決めごとが残ります。

• 自動で確定してよいラインをどこに引くか。下げれば人の確認は減りますが、誤ったものまで通ります。上げれば安全な代わりに、要確認だらけで人手が減りません
• 状態の設計。確定と未確定を、レコード単位ではなく項目単位で持つ必要があります
• 監査。変更前後と実施者を履歴に残し、取り消せる設計にするかどうかも決めます
• 判読できないときの運用ルール。システムだけでは決まらない部分です

この画面と、機器連携が乗る画面とでは、見積上の規模が一段階違いました。UI の見た目が同じでも、決めごとの量が規模を動かします。

AI で短くなったのは、実装工程だけだった

使っている見積のひな形が AI 駆動開発を前提にしていて、従来の進め方と比べたときの違いがそのまま学びになりました。数字は出せませんが、どの工程が厚くなり、どこが薄くなるかは次のとおりです。

• 要件定義は、従来型より厚く見る。インプットの質が全工程の生成品質を決めるため
• 設計も厚くする。設計書がそのまま AI への指示になるため
• 実装は薄くなる。生成で短縮できる。ただし人のレビュー工数は減らさない
• テストは変えない。自動化は進むが、品質担保の重さは変わらない

薄くなっているのは実装の比重だけで、要件定義と設計はむしろ厚くなっています。「AI を使うので安くなります」と言いたくなるところですが、そう単純ではありませんでした。この比重の置き方は AI 駆動開発の考え方と揃っています。要件定義の工程については、AIDD 要件定義というサービスもあります。

コードは AI、人がやったのは判断だけ

コードはほぼ AI が書いています。自分がやったのは、書かせる前の線引きだけでした。

配色は、お客様の公式サイトで実際に使われている色を採用するようにしました。見慣れた色で動いているほうが、自分たちの業務の話として受け取ってもらえます。

やらないことも先に並べました。状態を赤・黄・緑で塗り分けない。形と文字で見分けられるようにする。「AI」を主語にせず「自動判定中」と書く。画面の要素が動き回るような演出は付けない。ここを決めてから書かせると、上がってきたコードのどこが違うのかをその場で言えます。

デモには、今回は作り込まない画面も並びます。そこはグレーアウトして、押すと「未実装です」と出るようにしました。デモは、説明できる人のいない場所へ先に渡ることがあります。動いて見えるものは「もう出来ている」と受け取られてしまう。押してから気づくのでは遅いので、触る前に、どこまでが今回の範囲なのかが見えるようにしました。ファイル単体で渡る前提なので、組織名も番号も担当者も架空にして、写真は誰でも自由に使える公開素材だけにしています。

同じ相談から提案書を組み立てる側の手順は、お客様の課題メモから提案書のたたきを作る話にまとめています。

デモは要件定義の代わりにはならない

今のところ言えるのは、複数の案件で着手した日のうちに初版まで到達できたこと、提案の改訂に合わせて作り直せること、そしてデモを見積の入力にすれば規模感が即日で出ることです。

ただ、デモは要件定義の代わりにはなりません。動くものを見れば、見た人の中では話が先に進みます。だから未実装をはっきり見せておく、というところに戻ってきます。

まとめ

明日から試せることに絞ってまとめます。

デモが早く作れるようになったぶん、浮いた時間は裏側の逆算に使えるようになりました。動くものをお見せすると、次に来る質問はたいてい「いつまでに、どこまでできるのか」です。その答えを同じ日に返せるかどうかで、その後の進み方が変わります。

AI を使った業務改善を考えているものの、要件はまだ固まっていない。そうした段階からのご相談も歓迎です。今回のようにデモを交えたご提案からお受けしますので、お気軽に KDDIアイレットへお問い合わせください。