AIで3日でプロトタイプを作った。仕様のヒアリングから72時間後、動くものを持って打ち合わせに行った。
クライアントの担当者は画面を触りながら何度もうなずいた。いい反応だった。でも最後に言われた。「いったん社内で検討します」。
リリースは2週間後になった。
実装3日、承認2週間。ボトルネックは解消されたわけじゃなかった。引っ越しただけだった。
「作る」が速くなった後に起きること
AI駆動開発で変わったのは「作る」の速度だ。以前は2〜3週間かかっていた実装が、1〜3日になった。
ところが「決める」は変わっていない。担当者への確認、社内調整、決裁フロー。これらは5〜10営業日かかる。以前は「実装の遅さ」がプロジェクトのペースを決めていた。今は「承認の遅さ」が決める。
作り手がどれだけ速くなっても、この部分を設計しなければ2週間待つことに変わりはない。
同じプロジェクトで7倍の差が出た
あるプロジェクトで試した。意図的に2つの確認フローを並走させた。
ひとつは従来の方法。修正を依頼されたらSlackで報告し、詳細はメールで送り、最終確認は週次定例で。
もうひとつは新しい方法。タスクごとにコメント欄があり、そこに「この1点だけ確認してください」と書いて完了報告を入れる。担当者はそのコメントに返信するだけ。
従来フロー：承認まで2週間以上。新しいフロー：2日。
同じプロジェクト、同じクライアント、同じ内容。設計だけ変えて7倍の差が出た。
遅くなる理由は3つある
なぜ従来のフローが遅いか。構造を分解すると3つのミスが見える。
確認単位が大きすぎる。「今週の進捗をまとめて確認してください」は相手の認知負荷が高い。何が残っているか、何を判断すればいいか、全部自分で整理しなければならない。判断を先延ばしにしたくなる。
確認場所が分散している。Slackに流れて、メールにも来て、定例でも話す。クライアント側は「あの件どこまで進んでたっけ」を毎回探し直す。探す時間が積み上がって、判断が後回しになる。
権限が混在している。「このボタンのラベル、これで大丈夫ですか」と「追加費用が発生します、どうしますか」を同じ場所で聞くと、後者で止まったとき前者まで止まる。
設計を変えると何が起きるか
確認単位を小さくする。「今週の進捗」ではなく「この1点だけ確認してください」。返答ハードルが下がれば、担当者は5分で判断できる。積み上がった判断待ちがなくなる。
確認場所をタスクのコメント欄に一本化する。Slackに流れない。メールを掘り起こさない。そのタスクに関する会話はすべてそこにある。クライアントが「あの件どこだっけ」を探す時間がゼロになる。
権限を最初に仕分けする。キックオフで「文言やレイアウトはあなたの判断で確定してください。追加費用や仕様の大枠だけ決裁フローに入れてください」と線引きする。担当者が自分の権限で即断できる範囲を作る。
この3つを実装すると、クライアント側に「気づいた瞬間に返信できる環境」が生まれる。承認のボトルネックは、実はクライアントの意思決定が遅いのではなく、作り手側が「即断しにくい設計」を提供しているのだと気づいた。
なぜPaqutを作ったか
この経験の後、自分はPaqutを作った。
タスクごとにコメント欄がある。外部のクライアントや外注先をゲストとして招待できる。招待された側は自分に関係するタスクだけが見える。承認待ちのタスクは一目で分かる。
Slackに流れない。メールを使わない。定例で話さない。タスクのコメント欄でやり取りが完結する。承認を早めるための設計を、ツールに組み込んだ。
自分が困ったから作った。それだけだ。
「決める速度」が差になる時代
AI時代の価値は「作れるかどうか」から「ラリーの質」に移っている。要望が出てから形になるまでのサイクルが短い作り手が、クライアントにとって本当に使える存在になる。
実装3日、承認2週間——この非対称を設計で変える。それが今、受託開発者や制作会社に求められていることだと思っている。