「実装コストが高い」が崩れた後のアジャイル開発
最近、AIコーディングエージェントを前提とした開発プロセスや組織の形について、ぼんやり考えています。
CursorやClaudeCodeを使っていると、「実装する」こと自体のコストが目に見えて下がります。もちろんまだ万能ではなく、最終的には人間がレビューする必要もあります。それでも、開発の重心は確実に動き始めているように感じます。
とはいえ、自分の現場で十分に試したわけではないので、ここから書く話はかなり机上の空論寄りです。
実装速度はもうボトルネックではないのでは?
従来のアジャイル開発は、「実装コストが高い」という前提のうえに組み上げられていたのではないかと思います。だからこそ、タスクを細かく分解し、見積もり、スプリントに積み、優先順位を慎重に決めることに意味がありました。
しかしAIコーディングツールを使うと、小さな改善や試作は驚くほど速く形になります。そうなると、ボトルネックは実装ではなく「どの課題を解くか」に移っていくはずです。バックログマネジメントよりインサイトマネジメント、という言い方が個人的にしっくり来ています。
課題を大量に積んで管理することよりも、
- ユーザー理解
- 仮説
- 検証から得た学び
- 現場からのフィードバック
をチームで共有することの方が、ずっと価値を持つのでしょう。
イテレーションも、もっと短くなるでしょう。感覚としては、2〜3日のサイクルあたりが自然に思えてきます。 ただし、短くなるのは実装期間であって、人間が考える時間まで短くなるわけではありません。むしろ、ユーザーを観察し、課題を理解し、仮説を立てる部分にこそ時間をかけるべきです。 チームで課題を定め、実装は半日で終わらせ、すぐ次のフィードバックを得る。そんなリズムに近づいていくのではないかと思います。
チームはもっと小さくなる
個人的には、AI時代には小さいチームの方が取り組みやすいと感じています。
極端に言えば、
- エンジニア2名
- デザイナー1名
- 企画1名
ぐらいでも、多くのプロダクトは十分に回せるはずです。実装そのものがボトルネックになりにくいからです。 逆に人数が増えれば、認識合わせ・調整・レビュー・意思決定のコストが一気に膨らみます。 オフショアのあり方も変わるでしょう。これまでは「人を増やして実装する」ことに大きな意味がありました。ですがAIにコードを書かせる前提に立つと、単純な人海戦術の価値は急速に下がっていきます。少人数でコンテキストを共有しながら進めるチームの方が、結果的に速くなりそうです。
ただし、完全な1人開発に振り切るのは避けたいところです。 AIを使えば「それっぽいもの」は簡単に作れてしまいます。だからこそ、本当に妥当な設計になっているか、認識がズレていないかを相互に確認できる人数は必要だと思います。とくにジュニア育成を考えると、完全な個人商店モデルでは続かないのではないでしょうか。
「分担」より「同席」へ
これまではフロント担当・バックエンド担当・アプリ担当・インフラ担当のように役割を分け、並列に進めるのが普通でした。 しかしAIによって一人が扱える範囲が広がると、「手分けする」こと自体の価値が下がっていきます。
そこで重要になるのは、
- 少人数
- 同席
- 高頻度のコミュニケーション
の方ではないかと思います。
一つの課題をその場で議論し、その場でAIに実装させ、その場で確認する。 モブプロに近いですが、人間がコードを書くわけではないので、また少し違う形になりそうです。
AIコーディングの話ではレビューの負荷が問題にされることが多いです。 PRの差分を細かくレビューというより、「変更全体をどう把握し続けるか」を同席の元で素早く行っていく形になるのではないかと。
開発生産性の改善はより重要になる
AIを使い倒すほど、開発基盤の質がそのまま生産性に効いてきます。
具体的には、
- lint
- 自動テスト
- CI/CD
- サンドボックス環境
といった土台です。
設計のひずみを直したり、ライブラリやフレームワークを更新したりする作業は、むしろAIが得意とする領域だと思います。夜間にずっと動かして直してもらうという運用も十分ありえるでしょう。
そうなると重要なのは、「内部実装がどうなっているか」よりも、「外から見た挙動が壊れていないか」です。E2Eテストやオブザーバビリティの重要性は、これから一段上がるのではないかと思います。
リポジトリは「コード置き場」ではなくなる
リポジトリは「チーム知識の集積場所」として下記を含めていくことになるでしょう。
- DBスキーマ
- ドメイン知識
- ユーザー理解
- デザインルール
- 開発規約
特にDBコメントや業務ルールの記述は、これまで以上に重要になります。 AIはコードからある程度推測できるとはいえ、「なぜ存在するのか」「どういう背景なのか」まで書かれていれば、出力の質は段違いに上がります。
モノレポの価値も上がるでしょう。AIコーディングツールは複数リポジトリを横断して読めますが、それでもコンテキストが一箇所にまとまっている方が扱いやすいと感じます。人間向けというより、「AIが理解しやすい構造」を意識する、と言った方が近いのかもしれません。
デザインシステムも同じです。AIに自由にUIを作らせるより、
- コンポーネント
- デザイントークン
- UIルール
を整備し、そこに従わせる方が結果的に安定するはずです。これは人間向けというより、AI向けのガードレールに近いと思います。
チーム目標の切り方も変わる
開発速度が上がるほど、逆にチーム間の調整がボトルネックになっていきます。 ですので、他チームと干渉しすぎず、自律的に意思決定できる単位でチームを切っていく方向に寄っていくのではないでしょうか。 実装能力そのものよりも、「何を達成したいチームなのか」の方が重要になっていきます。
まだみんなが試行錯誤している段階です。数年後には全然違う形になっているかもしれませんが、自分でも実際に試しながら、考えを更新していきたいです。
