開発プロセスと速度について

はじめに

AI Coding Agentsの導入が進む中で、開発スピードはどのように変化しているのでしょうか。

Coding Agentsは、実装だけでなく設計面でも伴走してくれる存在になりつつあります。

そうなると、これまでの開発プロセスを前提にした「速度」の捉え方も、少しずつ変わってくるはずです。

今回は、これまでの開発プロセスを振り返りながら、どこで速度が失われるのか、設計と速度はどう関係するのか、そしてAI Coding Agentsの普及によって何が変わるのかを考えてみたいと思います。

これまでの開発プロセス

これまでの開発プロセスは、多くの場合、要望から要件が定義され、設計が行われた後に実装、テスト、リリースへ進むというサイクルでした。

ウォーターフォールでもアジャイルでも、大枠の流れはそれほど変わらないと思います。本質的に違うのは、サイクルの単位や回し方です。

このとき、各フェーズは基本的に一つ前のフェーズに依存します。

例えば、要件が決まっていなければ実装の方針は固まりませんし、要件が固まらない原因は、そもそもの要望が曖昧であることも多いです。

つまり、開発の速度も前段のフェーズに大きく依存します。

そのため、どこかでボトルネックが発生すると、後続のフェーズはまとめて遅れていきます。

では、そのボトルネックは実際にはどこで生まれやすいのでしょうか。

ボトルネックとは何か

ボトルネックはどのように発生するのでしょうか？

私の感覚では、ボトルネックの多くはコミュニケーションにあります。

一連の流れの中で、上流が常に遅い、あるいは下流が常に遅い、という単純な話ではありません。

上流が遅い場合は、組織の構造や意思決定の仕組みに問題があることが多いと思います。

一方で下流が遅い場合は、急な仕様変更への対応に追われていることが多く、仕様が固まれば遅延はかなり減らせます。

ただし、下流工程に進んでから仕様変更が発生すること自体は、ある程度避けがたい問題でもあります。

では、なぜそれがボトルネックになりやすいのか。私は、やはりコミュニケーションの問題に行き着くと考えています。

認識のずれ、説明の不足、意思決定の遅れ、あるいは変更理由の共有不足によって、後続の作業は一気に詰まりやすくなります。

そして、この「後から変わることにどう耐えるか」は、設計の話にもつながっていきます。

設計におけるスピードとのトレードオフ

設計と一言で言っても、システム全体のアーキテクチャレベルの設計と機能レベルの設計では、スコープが違うと思うかもしれません。

しかし、設計の勘所と開発速度のトレードオフの考え方は、根本的には同じものだと思っています。

設計における要点はさまざまありますが、多く語られるのは抽象化だと思います。

疎結合は多くの開発者が設計時に意識することだと思いますが、これも抽象化のアプローチの一つです。

疎結合が効果を発揮する場面はありますが、常に疎結合の選択が良いというわけではないと思います。

また、疎結合を実現するために、多くのモジュールや境界を導入しなければいけないこともあります。

例えば、class A と class B を連携させるときに、interface を介在させて境界を契約として定義することはよくあります。

interface に依存させておけば、class A と class B が直接結合するわけではないので、将来的に class C へ置き換えたい場合も対応しやすくなります。

一方で、将来的に class C の可能性があったとしても、class A と class B の変更が頻繁で、境界の契約も何度も変わるフェーズだったとします。つまり、まだ安定しておらず、作っては壊す段階にあるということです。

このようなケースでは、抽象化を先に行ってしまうことで、境界の変更コストが新たに発生します。

これが複数のレイヤーで行われると、経由するモジュールの数も増え、複雑性だけが高くなりやすいです。

特に短期的な視点で見たときに、抽象化とスピードはトレードオフの関係にあると思います。

一方で、長期的な視点では、抽象化が逆にスピードを向上させるケースもあります。

関連するモジュールの数が多く、互いに密結合になっている場合は、やがて変更が難しくなってきます。

変更するたびにどこかが壊れる、という状態にもなりえます。

このケースでは結合を弱めて、変更できるように調整しなければなりません。

つまり、短期的な視点で見たときとは逆に、長期的には抽象化が速度を支えることになります。

設計の難しさは、抽象化という概念を扱うことにありますが、これが単純な関係ではなく、システム全体の状況によって最適解が変わるところにあると思います。

ここが、設計者の腕の見せ所です。

ここまで見てくると、「速度」とは単に手を速く動かすことではなく、変更や意思決定をどれだけ滑らかに進められるかという話だとも言えます。

速度とは何か

ここまで一貫して速度を中心に話してきましたが、そもそも速度とは何なのでしょうか。なぜ速度が重要だと考えているのか、もう少し深掘りしてみます。

開発に限らず、組織におけるさまざまな活動で「速度」は常に重視されます。

自動化、効率化、コミュニケーションの円滑化などは、すべて速度に寄与します。

そして、速度が最終的に効いてくるのは「時間」だと思います。

私は、「時間」という概念は他の多くの指標より一段抽象度が高く、より重要なものだと考えています。 少しかっこよく言えば、他の指標とは一つレイヤーが違う感覚です。

経済活動に限らず、あらゆる活動において時間は有限です。できるだけ短い時間で目的を達成できるなら、その方が良いはずです。

もちろん、時間をかけること自体に価値がある場面もあります。しかし、多くの活動では時間はできるだけ効率的に使った方がよいと思います。

この有限な時間に対して、どれだけ効率的に活動できているかを示す概念が「速度」なのだと思っています。

そう考えると、AI Coding Agentsがもたらす変化は、単なる実装の省力化ではなく、時間の使い方そのものの再設計に近いのかもしれません。

AI Coding Agentsとともに

ここ数ヶ月で開発体験は大幅に変化しました。

これからの開発プロセスは、Coding Agentsとともに作っていく必要があります。

Coding Agentsが生み出す速度は、人間が手作業で進めるよりも圧倒的に速いです。

この速度を知ってしまうと、あえて遅い手法を取る価値は薄れてきます。

まだ発展途上の分野なので、たとえば次のような点は定まっていません。

こうした点は、使う人や組織の方針に大きく委ねられています。

しかし、この流れも数ヶ月から数年のうちに、ある程度安定したフローが確立されていくはずです。

今は個々人に委ねられているAI活用も、社会的に当たり前になれば、個人レベルで求められる速度そのものが高い水準になっていくかもしれません。

プロセスも大きく変わりますが、要求も大きく変わるだろうと感じます。

最後に

今回は、「速度」という概念を中心に私の考えを書いてみました。

開発プロセスにおいて、速度のボトルネックになりやすいのは「コミュニケーション」だと思います。

設計においては、短期的な速度と長期的な速度が、抽象化の扱い方と深く関係しているということを書きました。

そして、AI Coding Agentsが本格的に導入されつつある今、速度という観点から開発プロセスそのものを見直す必要があるとも感じています。

私は「速度」をかなり重視しているところがあり、その背景は自分でもあまり整理できていなかったのですが、書くことで少し整理できてきた気がします。

Share: X (Twitter)