ツールは全部入れた。なのに変わらない
ブロック（Block）は決済サービス Square をつくったフィンテック企業だ。同社は開発者のほとんどに AI コーディングツールを渡した。規模は三千五百人、教育も全社単位で回した。ツールの活用度だけを見れば業界最上位に入る。
ところが製品が出ていく流れは期待ほど速くならなかった。コードは確かに速く出るのに、製品が同じだけ速く変わらない。ツールを使わなかったからではない。AI が書いたコードをどこまで信じてそのまま出すのか、という心理的ハードルがあり、その上に決裁と承認の手続きが載っていた。
結局この会社が採ったのは、三千五百人をさらに教育することではなかった。チャンピオン五十人を選び、彼らが先に「実際にできる」ことを成果として見せ、その文化を横に広げた。ツールの普及率はすでにほぼ百パーセントで、残る変数は人と手続きだったということだ。
高速道路を一区間つくれば車が勝手に走るとは限らない。道はあるのに誰も入らない——それが本当のボトルネックだ。組織で AI 教育を回したのに仕事が二倍速くなった経験がないなら、たいていここで止まっている。
アンソロピックは五、六か月をどう一〜三日にしたか
同じ問題にアンソロピックは反対側から触れた。この会社ももともとは製品をつくって出すまでに五、六か月かかっていた。今その周期は一〜三日である。か月ではなく日単位だ。
方法はより良いツールへの乗り換えではなく、公開する単位を新しくつくることだった。リサーチプレビュー（Research Preview）である。まだ開発・研究段階の機能を完成まで隠さず、望む利用者が自分で有効にして試せる場所に置く方式だ。Claude デスクトップアプリを開くと、チャットとコードのタブが分かれ、チャットの中に協業が入るというように画面構成が変わり続けるが、その変化はこの単位の上で回っている。
この単位が実際に取り除いたのは完成度ではなく待ち時間だ。何を出すか毎回上げて承認を取り、すべて揃うまで待つ区間が消えた。完璧を待つ代わりに小さく先に公開し、利用者の反応から学ぶ環境をつくったのである。
ここで誤読しやすい点がある。一〜三日が可能な理由を AI でコーディングしているからだとだけ見れば、半分しか見ていない。コーディング速度はもともと高かったはずだ。それが急進的な成果に変わった契機は、判断と承認の構造を設計し直したことにある。ツールが生んだ速度を組織が流せるよう、配管を敷き直したわけだ。
パレートで読み直す：80 を 100 に上げる費用
パレートの法則は、結果の八割が原因の二割から生まれるという経験則だ。二対八の法則とも呼ばれ、売上の八割を上位二割の顧客がつくるといった形でよく使われる。
これを開発日程に当てはめるとこうなる。人が実際に使う中核機能の八割は、全開発期間の二割でできあがる。そして残りの八割の期間は、その 80 を 100 へ引き上げるために使われる。例外処理、画面の仕上げ、まれなケースへの対応、社内レビューと承認がこの区間に入る。
核心の問いはここから出る。その最後の作り込みを市場が望んだことがあるのか。多くのプロジェクトでこの問いは検証されていない。誰も求めていない精緻さに期間の八割を使い、肝心の市場が望んだ別の二割には手もつけないまま出す、ということが繰り返される。
だから順序を変える。八割で先に出し、残る二割は市場の反応に決めさせる。使われるところは埋め、誰も使わないところは捨てる。すると初回リリースまでの期間が全体の二割、つまり五分の一になる。アンソロピックがリサーチプレビューでやったのは、まさにこの構造だ。
これが品質の放棄に聞こえるなら、順序をもう一度見ればいい。100 を諦めるのではなく、どの二割を 100 に上げるかを自分の推測ではなく利用者の使用記録で選ぶということだ。完成度の総量ではなく、配分を変える決定である。
では八割はどこで切るのか
八割という数字を勘で測れば毎回変わる。実務で使える定義はこうだ。中核となる利用者の流れが一本、最初から最後まで回る状態。依頼が入り、結果が出て、記録が残る——この一筋が途切れず回るなら八割である。その筋の脇につく例外処理、二番目の利用者類型、管理画面は、まだ残り二割に属する。
初回はこう範囲を括る。業務は一種類だけ入れる。利用者は自分ひとりか自チームに限る。中核機能は一つ二つだけ残す。データはサンプルか非識別データで始める。結果は必ず人が最終確認する。問題が起きたらいつでも従来のやり方へ戻せるようにしておく。
この範囲より大きくなろうとしたら削る。せっかくつくるならこれも、という発想が失敗の種だ。範囲が広がるほど初回リリースは後ろへずれ、リリースがずれれば市場の反応が届く前に残りの二割を自分の推測で埋めることになる。その瞬間に A 案へ戻っている。
つくり方はもう大きな壁ではない。言葉で説明すれば AI がコードをつくる時代なので、コーディングを深く知らなくても小さな解決策を一つ自分で試せる。重要なのはどうつくるかではなく、何を試すかだ。コーディングから学んで始める必要はない。
測らなければ 80 か 100 かも分からない
八割で出す方式は測定を前提にする。反応を読んで残りを決めると言っておきながら何も測らなければ、良くなった気がするという感覚だけが残る。自分でつくったものへの愛着がつくと、この錯覚はさらに強くなる。
取るべき数字は決まっている。作業時間、待ち時間、誤りと漏れの件数、修正回数、そして利用者が実際にまた使ったかどうかだ。従来のやり方の数字と並べて比べる。初稿の作成が四十分から十五分へ、修正依頼が三回から一回へ——確認とはそういう形をしている。
どこを測ればよいか分からなければ、まずボトルネックの信号五つを見る。決裁や返信を待って仕事が止まる待ち、同じ資料を毎週つくり直す再作業、特定の担当者が不在だと誰も進められない担当者依存、メッセンジャーからコピーして表計算に貼るシステム断絶、正常系より例外が多くなる例外の急増である。このうちのどれかに手が挙がるなら、そこが最初の対象だ。
数字がむしろ悪くなっているかもしれない。ならば直す。直しても良くならなければ捨てる。別の方式で設計し直し、診断もやり直せばいい。捨てられないことのほうが大きな無駄になる。アンソロピックの出荷周期が一〜三日である理由も結局これだ。使ってみて使われなければ捨てられるから、短く回せる。
完成の基準を誰が決めているのか
ブロックの事例が教えるのは、組織の速度がツールの一覧ではなく決定構造から出るという事実だ。だから点検すべき問いは、どの AI を使っているかではなく、この仕事が終わったと誰がいつ宣言するのか、である。
実務では決定を二種類に分けると整理がつく。戻せる決定は承認なしにそのまま出す。画面の文言、社内ツール、試験的な機能のように、間違えたら戻せばよいものだ。戻せない決定は人が承認する。顧客へ出す送信、決裁、記録の削除、人事と評価、機密と個人情報がこれに当たる。
この線を先に引いておけば、待ち時間の大半は消える。承認待ちはたいてい、戻せる仕事まですべて上へ上げることで生まれる。アンソロピックのリサーチプレビューも、結局は戻せる公開を承認手続きの外へ出した仕掛けだ。
個人単位でも同じだ。AI に仕事を任せるとき、何を自分で処理させ、何を必ず自分が承認するかを先に決めておけば、毎回止まって判断せずに済む。上手な AI より、止まる場所を知っている AI のほうが実務では長く保つ。
今日できること
進行中の仕事を一つ選び、一文で書いてみる。私はどの業務のどのボトルネックを、どの方法で変えて、測定可能な結果をつくる。四つの枠がすべて埋まって初めて課題になる。うちのチームも AI を積極的に活用する、という文は決意であって課題ではない。
埋めるとこうなる。私は週報の集約過程における漏れの確認と繰り返しの修正を減らすために、必須項目の入力と検収基準を含む集約ツールをつくり、作成時間と修正回数を従来の方式と比較する。
次に、その課題の八割がどこまでかを一行で定める。中核の流れが一本、最後まで回る地点を書き、その地点で実際に出す。そして最低一週間は実務で使いながら数字を集める。
残りの二割はそのとき決めればいい。一週間分の使用記録が、どこを埋めるべきかを教えてくれる。それは自分の推測より正確で、何より期間の八割を先に使わなくて済む。