書く速さが上がり、他が追いつかなくなった

Claude Codeを日常的に使うチームから、似た報告を聞くようになりました。「コードを書く時間は目に見えて減ったのに、リリースまでの時間はあまり変わらない」というものです。

レビューの順番待ちは減ったでしょうか。テストを書く手間は消えたでしょうか。デプロイの承認は速くなったでしょうか。

たいていの答えは、どれも「いいえ」です。ボトルネックが消えたのではなく、場所を移っただけだからです。このレッスンでは、何が起きているのかを先に診断します。

構築が一番重かった時代の名残

従来のソフトウェア開発の6段階、計画・設計・構築・テスト・デプロイ・保守という区切りは、構築(コードを書く工程)が最もコストのかかる段階だった時代の前提でできています。要件を練って手戻りを防ぎ、設計を固めてから実装に入り、レビューを厳しくするのは、書き直しのコストが高かったからです。

構築が全体のボトルネックだったころは、その前後を多少ゆるく運用しても、全体の速度にはあまり響きませんでした。計画を委員会でじっくり詰めても、構築のほうが時間がかかるので、待ち時間として吸収されていたのです。

構築が速くなると、何が起きるか

構築の速度が上がったとき、実際に起きることは3つあります。

ここで起きているのは、悪いことばかりではありません。構築の速度が上がった分だけ、前後の工程にかけられる時間の比率が変わった、というだけの話です。問題は、その比率の変化に、前後の工程のやり方がまだ追いついていないことです。

3つ目の「例外処理の増え方」は、とくに見落とされがちです。構築が遅かったころは、想定外の変更そのものの件数も少なく、都度の相談で片づいていました。構築の速度が上がると、試せる回数が増える分、想定外の変更の件数も一緒に増えます。増えた件数を従来どおり週次・月次の会議で拾おうとすると、会議までの待ち時間が、そのまま開発全体の待ち時間として積み上がってしまいます。

自分の流れの中で、次に詰まる場所を探す

6段階を並べて、どこが人間の速度のまま止まっているかを確かめてみましょう。

一人で道具を作っている場合も、この6段階は形を変えて存在します。会議の代わりに「何を作るか自分の中で固める時間」があり、レビューの代わりに「公開前に見直す時間」があります。段階の名前は変わっても、構築だけが速くなり、他が追いつかないという構造は同じです。

どの段階が一番詰まっているかを、もう少し体系立てて診断したい場合は、現在地を診断するも参考になります。自分やチームがいまどのステップにいるかを、外から見えるサインで確かめる方法をまとめています。

やってみよう

演習1：自分の6段階を並べてみる

いまの自分の開発の流れを、計画・設計・構築・テスト・デプロイ・保守の6段階に当てはめてみましょう。それぞれにどれくらいの時間がかかっているか、大まかでよいので書き出してください。構築以外のどこかが、思ったより時間を食っていないでしょうか。

演習2：その詰まりは、本当にAIで速くならないのか

見つかった詰まりについて、2つを見分けてください。「AIを使っても本質的に人間の判断が必要で、速くならない詰まり」なのか、「AIを使えるはずなのに、まだやり方を変えていないだけの詰まり」なのか。後者であれば、このコースの残りのレッスンで扱います。

今日のまとめ

3行で振り返ります。

• Claude Codeで構築(コードを書く工程)が速くなった結果、ボトルネックは計画・レビュー・テスト・デプロイへ移った
• 人間の速度を前提にした統制の仕組みは、実際の作業速度と合わなくなりつつある
• 詰まりの正体は「AIでも速くならない工程」と「まだやり方を変えていない工程」の2種類に分けられる

次のレッスンでは、計画からデプロイまでをつなぐ「意図・仕様・計画」という3つの書類の連鎖を見ていきます。