掛け算せよ、最適化ではなく
AI によるコーディングが話題になって久しい。今や、コードを書けない（あるいは書かない）友人たちまでがコードを生成し、新しいサービスをデプロイしている。ソフトウェアエンジニアにとって、これは至極もっともなことだ。面倒な雑務をこなしてくれる「魔法の小人」が現れたおかげで、自分はより価値の高い仕事に時間を割くことができる。しかし私の観察では、コーディングにどっぷり浸かっている人々と、頑なに利用を拒む人々との間には、依然として考え方に大きな隔たりがある。
私自身の経験では、成果物のアウトプットスピードがほぼ 100 倍になったと感じているが、一方で「これでは何も変わらない」と言う人もいる。
このあまりに鮮明なギャップは、私が幼い頃に初めて自転車の乗り方を覚えた時のことを思い出させる。初めて一人で漕ぎ出せた瞬間、風が髪をすり抜けていくのを感じ、走るよりずっと速く「疾走」している自分に興奮した。全身を駆け巡る自由な感覚は、まるでどこへでも行けるかのように思わせた。
「これって、すごいことだね！」と私は父に言った。 「本当にすごいことだ」と父は答えた。「でも、これで満足して立ち止まってはいけないよ。他の素晴らしいものを見落としてしまうからね。君はこれからバイクに乗り、車を運転し、もしかしたら飛行機を操縦したり、ロケットに乗ったりするかもしれない」父は一拍置いて、今でも私の根幹にある言葉を口にした。
「どれだけ自転車の運転が上手くなっても、宇宙には行けないんだよ」
では、これが AI でのコーディングとどう関係しているのだろうか？
一般的には、このギャップは単に新しい「ツール」をどれだけ使いこなせるかというスキルの差、つまり「本質（道）」ではなく「技術（術）」や専門領域の違いに過ぎないと思われるかもしれない。しかし、技術系・非技術系問わず多くのユーザーと話してみると、個別の具体的なタスクにおける加速率自体は、誰もが似たようなもの（約 10 倍）であることに気づく。しかも、品質を維持するためには依然として人間によるレビューが必要だ。私自身の体感でも、かつて丸 3 日かかっていた作業が今では 3 時間ほどで完了する。これ自体は劇的な進化だが、先ほど述べた「100 倍の加速」とは大きな開きがある。
では、その違いはどこにあるのだろうか？ 私は矛盾したことを言っているのだろうか？
いや、そうではない。より極端に言えば、特定の状況下ではそのスピードは 1000 倍に達することさえあると考えている。最初のすれ違いは、「スピードがどのように測定され、観察されているか」から生じている。単一の製品機能の実装と、完全なサービスの提供（デリバリー）は全く別物だ。もし AI を単なる「コードジェネレーター」としてしか捉えていないなら、得られるのはせいぜい 10 倍の加速に過ぎない。 しかし、デリバリーの本質は単に「コードを吐き出す」ことではない。
もしあなたが LLM を「構造を再構築するための手法」として捉え、それをプロセスのあらゆる局面に適用し、最終的なエンドツーエンドの成果を測定するなら、視点は根本から覆る。あなたは自分のスキルをツールに「外注」しているのではなく、進歩のループそのものを「再構築」しているのだ。もっとも、最初は少しがっかりするかもしれない。個々のステップにおける加速率は下がるからだ。異なるフェーズ間で情報や構造を変換するオーバーヘッドが生じるため、作業に 6 時間かかるようになるかもしれない。しかし、これは「一時的な後退、長期的な大躍進」である。生成される様々な副産物（ドキュメント、テスト、合意形成用資料）のために目先のコーディング速度を少し犠牲にすることで、最終的には人間同士の不毛な往復のやり取りを数週間単位で削減できるのだ。
そして、ここから魔法が動き出す。コーディングフェーズ単体で見れば「準最適（4〜5 倍の効率）」にとどまるとしても、その効率が他のあらゆる関連業務に同時に適用されるようになるのだ。ドキュメントの作成、コンテキスト（背景知識）の管理、システムの整合性担保、仕様の検証、テスト、セキュリティチェックなど、思いつく限りのあらゆる領域だ。さらに素晴らしいことに、ワークフローの設計さえ適切に行えば（これもまた新しい方法で実現できる）、これらのタスクの多くを並行して処理できるようになる。
開発サイクル全体を見渡せば、コーディングにかかる時間が 3 時間なのか 6 時間なのかという実質的な差は、極めて些細なものだ。複数のステークホルダーが関わる従来のプロセスを思い出してほしい。2 週間のスプリントですべてを完結させるというのは、ただの理想郷だ。現実は甘くない。スケジュールの調整、意見の収集、報告書の作成、フィードバック待ちなど、特にハイコンテキストなコミュニケーション環境においては、これらの調整に追われる。この段階では、コードを書くのにかかる時間などボトルネックですらなく、全体の歩調を合わせること（ペースの同期）こそが本質的な課題だ。3 日の作業は、人間のバッファを考慮すれば実質 1 週間になり、もう 1 週間は開発見積もり、優先順位付け、コードレビュー、会議、そして全員の意図の整理に費やされる。
しかし、全く同じ仕事が 1 日、長くても 2 日で完結するようになる。6 時間の作業であればちょうど 1 日で片付き、他のメンバーが退勤する前に最速でフィードバックを得ることができる。また、実行プロセスの中で自動的にキャプチャされた情報はドキュメントを常にリアルタイムで更新し続け、いつでもレビューフェーズに移行させたり、直接別のタスクへと分岐させたりできる。さらに、仕事が細分化・ユニット化されるため、ステークホルダーの都合にも合わせやすくなる。断片的な成果物を見せて合意を取り、週末が来る前にシステムに次の段階の準備を指示しておくことも可能だ。
かつて 3 スプリント（約 6 週間）かかっていたかもしれないプロジェクトが、今や 2 日で終わる。これにより、あなたは今その場にいる人々との対話に集中し、同時に複数のプロジェクトを進めることができるようになる。
もしあなたが「これで何時間削減できたか」という狭い視野に固執しているなら、こうした恩恵を受けることは決してないだろう。なぜなら、「時間を節約する」という行為は単なる「最適化（オプティマイゼーション）」だからだ。最適化が機能するのは、前提や定義が明確で、熟練度が問われる問題においてのみである。しかし、現在起きているのは生産方式そのものの変革だ。したがって、核心となる問いは「どれだけ早く作れるか」ではなく、「どのように作るか」であるべきだ。個々の小さな改善が複利のように積み重なり、全体として巨大な乗数（マルチプライヤー）へと成長していく。
この相乗効果は根本的に異なるものであり、純粋な最適化だけでは絶対に到達できない領域だ。AI を使ってコードを早く書くことは、優れた自転車の乗り手になることに過ぎない。デリバリープロセス全体を再構築し、あらゆるステップの成果を何倍にも膨らませること――それこそが、ロケットを組み立てるということなのだ。