これはシリーズの始まりだ。2ヶ月ほど前にPrologのテックで始めた変革を、これから書いていく。なぜ始めたのか、何がうまくいっているのか、そして何が高くついたのか。壇上の理論じゃない。自分たちが実際に生きた話だ。
書こうと決めたのは単純な理由からだ。どうやればいいのかを探しに行ったとき、意見はたくさんあるのに、渦中にいた人の正直な記録はほとんどなかった。この文章が、ものを作る誰かがよりどころにできる場所になるなら、それで十分だ。
始まりは、ある違和感だった。
見たもの
3月、僕と共同創業者のJeanはテキサスのSXSWに行った。世界最大級のイノベーションの祭典のひとつだ。僕は違う人間になって帰ってきて、その違和感は消えなかった。壇上で見たものではない。会社がすでに現場でやっていたことだ。
帰ってから、海外で実際にAIでものを作っている人たちの技術的なコンテンツに潜り込んだ。InstagramやLinkedInのぬるいやつじゃない。手を動かして、学んだことを公開している人たちの深いやつだ。そして働き方を本当に変えた会社の事例に、次から次へとぶつかった。その違いは微妙で、同時にとてつもなく大きい。彼らは「AIを使い始めた」のではなく、AIを中心に置いたのだ。
そしてこれは壇上のハイプとして片付けられない。産業規模での採用だ。大企業も小さな会社も、みんな同じ場所へ向かって歩いている。印象に残ったもののひとつが、シンプルな数字だった。Fortune 100の10社に9社がすでにCopilotを採用していた。ただ、重要なのは採用率の数字じゃない。伸びの大きさだ。古いフローにAIを差し込んだだけの会社は、生産性が10%、20%上がったと報告している。AIを中心に据えて作り直した会社は、倍数を報告している。5倍、10倍だ。これらの事例は次の記事でひとつずつ開いていく。今のところ大事なのは、そのすべてに共通する転換だ。
横で使う vs. 中心に置く
この区別は小さく見えて、実はすべてを決める。
AIを使うとは、横でツールを開いて、これまでと同じプロセスを進めることだ。フローは同じまま、役割も同じまま、レビューも同じまま。AIはタブがひとつ増えただけで、各自がそれと自力で向き合う。伸びは端っこにしか出ない。
中心に置くとは、AIの周りでプロセスを設計し直すことだ。AIが仕事の大部分を作るという前提に立って、フローも役割もレビューもそこから作り直す。コンテキストはひとつの会話の中で死ぬのをやめ、共有されるものになる。伸びは別の次元になる。同じ仕事が速くなるのではなく、仕事そのものが形を変えるからだ。
同じ仕事、AIの居場所は二通り
AIを横に置く vs. AIを中心に置く
AIは横のタブにいる。フロー、役割、レビューはそのまま。各自が自分のやり方で、ひとりで工夫する。
+10–20% の上乗せ。ボトルネックは元の場所のまま。フロー、役割、レビューを、AIが作り手になるよう再構築する。文脈は共有され、ひとつの会話で消えない。
別次元 の伸び。10%増しではなく、仕事そのものが変わる。これに気づいたとき、問いは「どのツールを採用するか」ではなくなり、「自分たちの働き方の中で、AIのない世界向けに設計されたものは何か」になった。そこで内側を見に行った。
診断。各自が自力でしのいでいた
3月の終わりごろ、まだClaudeに移る前に、Prologのプロダクト、デザイン、エンジニアリングの人たちと座って、シンプルな質問をした。日々どうAIを使っているか。何が良くて、どこで詰まるか、オペレーションにどんなボトルネックが見えるか。
聞いたことに、やられた。
みんな違うツールを使っていた。ひとりはCopilot、別のひとりはClaude、もうひとりは全部Prolog内製のAIに投げていた。そしてバラバラのツールより悪かったのが、バラバラのコンテキストだ。ある人がAIと会話しながら積み上げたものは、そこで、その人と一緒に死んでいた。たとえば保守チームは、Prologのそのプロダクトのルールを入れた良い資料をPrologのAIの中に作っていた。ただ、それは同じ種類のコンテキストを必要としていたタイヤチームには届かず、彼らはゼロから始めていた。
頭から離れなかった話がひとつある。開発者たちは、週末までにクレジットを使い切るのが怖くて、大きいPRのレビューにAIを使うのを避けていた。この不条理を考えてみてほしい。人は、自分が出すと約束した自分のタスクをAIで終わらせるか、同じクレジットを使って同僚の巨大なPRをレビューするか、どちらかを選ばなければならなかった。希少な資源の奪い合いになった。そうなると誰も他人のレビューを引き受けたがらない。
チームの誰かが、僕の頭から離れなくなる一言でまとめた。
AIで作って、AIなしでレビューする。
各自が自力で、自分のやり方で、たまたま手にしたツールで、しのいでいた。ひとりにうまくいったことが、次の人のレシピにはならなかった。標準もなければ、共通の場所もなかった。
使い方だけじゃなく、構造の問題だった
見れば見るほどはっきりしてきたのは、みんなに「もっとうまく使う」ことを教えるだけでは直せない、ということだった。使い方は症状だ。準備ができていなかったのは、その下の構造のほうだった。3つの穴が見えてきた。
ひとつめ、コンテキストが散らばって存在していた。一部はNotion、一部はDrive、一部はJira、Figma、Fathom。単一の真実の源がなかった。だからAIとの新しい会話は毎回、全部をゼロから説明することで始まった。必要な情報は5ヶ所にあって、どこでもキュレーションされていなかったからだ。すでにどこかに存在していたコンテキストを組み立て直すだけのために、トークンで、リクエストで、時間で払っていた。
ふたつめ、人間が接着剤だった。プロダクトの誰かがAIでspecを作り、ドキュメントに上げ、リンクを次の人に送り、その人がそれを自分のAIのプロジェクトに放り込む。AIは両端に現れて、真ん中には決して現れなかった。AIが一部を作り、人間がその結果を手で次のツールまで運び、別のAIがまたゼロから始める。フローは人間のままだった。
みっつめ、アーキテクチャだ。10年かけて作ってきた土台は、ボトルネックが人であってAIではない世界向けに作られていた。あちこちで絡み合っていて、テストのない部分もある。そしてまさにそれが、AIならできるはずの速い変化を止めている。誰かの道徳的な欠陥じゃない。ここまで機能してきた10年分の判断の積み重ねだ。AIはそれを剥き出しにしただけだ。
そして言っておきたいのは、これはチームの欠陥でも、Prologの欠陥でもない、ということだ。古い働き方の上にAIを貼り付けた、どんな会社でも起きることだ。10年やってきた会社はどこも、今まで機能してきたやり方を抱えている。AIはそこにスポットライトを当てる。そしてそれを変える責任は僕にある。
なぜエンジニアリングだけでなく全部を作り直すのか
最初の誘惑は、エンジニアリングで直すことだ。理にかなっている。AIが一番早く根付いた場所であり、すでに手をつけ始めていた場所だ。でも、まさにそこに罠がある。
ある領域がAIの速さで動いて、隣の領域が人間の速さのままなら、僕は何も速くしていない。ボトルネックの場所を動かしただけだ。
フロー全体を考えてみてほしい。エンジニアリングが数時間で出せるようになっても、プロダクトがspecに何週間もかかるなら、今度は列を止めているのはプロダクトだ。プロダクトとエンジニアリングを直しても、検証がまだ手作業なら、検証で詰まる。そしてテックの中だけの話でもない。たくさんリリースしても、マーケティングが同じペースで告知できなければ、ボトルネックはマーケティングに移る。一区間だけ速くしても渋滞は解けない。次に押し出すだけだ。
一区間を速くしても行列は消えない
ボトルネックは場所を変えるだけ
エンジニアリングだけを速くした
プロダクトとエンジニアリングを速くした
速くした区間が次の区間に火をつける。渋滞は消えない。場所を変えるだけ。
だから4月の終わりに、僕たちはテック全体を作り直し始めた。プロダクト、デザイン、データ、品質。エンジニアリングだけじゃない。AIが中心に行くなら、フロー全体の中心に行く。一部の中心じゃない。
これから来るもの
次の記事では、この一つひとつを開いていく。「harness」とは何か。AIが断片をぽつぽつ出すだけでなく、本当に成果を出すためのインフラのことだ。AIが作る側になり、人間が方向づけてレビューする側になったとき、それぞれの役割の仕事がどう変わるか。そして何かが壊れたとき、正しい問いが「今どうするか」ではなく「二度とこうならないために、コンテキストに何が足りなかったか」に変わった理由。
変革は動いている。当たりもあれば外れもある。両方をここで、起きたとおりに書いていく。レシピじゃない。自分たちが今まさに生きている話だ。ものを作る他の誰かの地図になるなら、なおいい。