はじめに
これはただのポエムです。技術的な正しさよりも、最近感じたモヤモヤをできるだけ丁寧に言葉にしてみた記事です。結論を急がず、自分の中で起きた考えの変化を順を追って書いていきます。共感してもらえる人がいたら嬉しいです。
AIが来て、開発がとにかく速くなった
AIによるコーディング支援が当たり前になってきました。関数を書いてと言えば一瞬で書いてくれるし、エラーメッセージを貼るだけで原因の候補まで提示してくれる。設計に迷ったときも、壁打ち相手として気軽に相談できる。正直、最初にこの体験をしたときは感動しました。今まで数十分かけて調べていたことが、数十秒で片付いてしまう。体感の生産性は明らかに上がったと思います。
タスクの消化スピードも上がりました。今まで1日かかっていた実装が半日で終わる。レビュー前の叩き台も、AIにたたいてもらえば早い段階で形になる。「これはもう後戻りできない便利さだな」と、しばらくは素直にそう思っていました。
速さの裏側で起きていたこと
ただ、しばらく使い続けていると、少しずつ違和感が積もっていきました。
一番大きかったのは、「なぜこの実装にしたのか」を自分で説明できない場面が増えたことです。AIが出してくれたコードは動く。テストも一応通る。でも、なぜその設計を選んだのか、他の選択肢と何が違うのか、と聞かれると答えに詰まる。自分の頭で選んだはずのものなのに、いつの間にか「AIがそう言ったから」が理由になっていることに気づいて、少し怖くなりました。
もう一つは、コードベース全体の見通しが悪くなっていく感覚です。個々の機能は速く作れる。でも、機能同士の整合性や、将来の変更に対する影響範囲を誰も把握していない。AIは「今、目の前の指示」には強く応えてくれますが、「このプロジェクト全体として何を目指しているか」までは背負ってくれません。それは結局、人間側が持っておかなければいけない責任なんだと、痛感する場面が増えました。
「個人開発」化してしまうことへの懸念
もう一つ、正直に書いておきたい懸念があります。それは、チームで開発しているはずなのに、いつの間にか一人ひとりの開発スタイルが「個人開発」に近づいていっているのではないか、という感覚です。
AIに壁打ちしながら実装を進めていると、他のメンバーに相談する前に、自分とAIだけである程度完成形まで持っていけてしまいます。これは一見すると効率的です。ただ、その過程で「なぜこの実装にしたか」「他にどんな選択肢を検討したか」といった、本来チームで共有されるべき思考の過程が、自分とAIとのやり取りの中に閉じてしまいがちです。結果として、コードは出来上がっているのに、チームとしての合意形成や知識の共有が置き去りになっている、という状態が起きやすくなっている気がします。
個人開発であれば、意思決定者は自分一人なので、それでも問題は起きにくいと思います。しかし、複数人で保守していくプロダクトにおいて、各メンバーが自分のAIとのやり取りの中だけで意思決定を完結させてしまうと、他のメンバーからは「気づいたらそう実装されていた」というブラックボックスが増えていくことになります。設計の議論や要件のすり合わせといった、本来チームで担うべき工程が、個人とAIの間で完結してしまう。これは、チーム開発の強みである「複数人の目で確認し合う」という前提そのものを崩しかねないのではないかと、懸念しています。
だからこそ、AIとのやり取りで固まった設計や実装方針であっても、それをきちんとチームに開示し、レビューや設計レビューの場に乗せる、という一手間が今まで以上に重要になっていると感じます。AIが個人の生産性を上げてくれる分、その成果をチームの資産としてどう共有し直すかを、意識的に設計しないといけないのだと思います。
1周回って見直した、ウォーターフォールモデル
そこで改めて頭に浮かんだのが、古典的なウォーターフォールモデルでした。今の現場ではアジャイル開発が主流で、ウォーターフォールは「時代遅れ」「硬直的」と言われがちです。自分もそう思っていた側でした。ただ、AIと開発してみて感じたのは、ウォーターフォールが大事にしていた「工程を区切って、後戻りしにくい形で積み上げる」という考え方そのものは、AI時代にこそ効いてくるのではないか、ということです。
一般的なウォーターフォールモデルは、おおよそ以下のような工程で進みます。
要件定義
↓
基本設計・詳細設計
↓
実装(コーディング)
↓
テスト(単体・結合・総合)
↓
リリース
↓
運用保守
AIが強いのは、この中の「実装」の部分です。要件と設計さえ固まっていれば、実装は驚くほど速く形にしてくれます。逆に言うと、要件定義や設計が曖昧なまま実装フェーズに突入すると、AIはその曖昧さをそのままコードに変換してしまう。速いからこそ、上流工程の甘さがそのままの速度で下流に流れていってしまうんですよね。
ウォーターフォールモデルのように、要件定義・設計・実装・テストをきちんと区切り、各工程の成果物(要件定義書、設計書、テスト仕様書など)を明示的に残す。この「型」があることで、AIに実装を任せる前に、人間が何を決めておくべきかがはっきりします。AIの速さを活かすためにこそ、上流工程を丁寧にやる価値が上がったのかもしれないと感じています。
レビューの必要性
もう一つ、改めて重みを感じたのがレビューです。AIが出したコードをよく理解しないままマージしてしまったことが、正直何度かありました。動いているから良し、としてしまった結果、後になって不具合の原因を追うのに普段より時間がかかったことがあります。
レビューの役割は、単純な誤りを見つけることだけではないと思っています。
- 実装が要件・設計の意図から外れていないかを確認する
- 属人化を防ぎ、チーム内でコードの意図を共有する
- 将来の変更や保守を見据えて、読みやすさ・一貫性を担保する
AIは「動くコード」を高速に出してくれますが、「そのコードがチームやプロジェクトの文脈に合っているか」までは判断してくれません。AIが書いた分量が増えれば増えるほど、人間によるレビューの重要性はむしろ増しているのではないかと感じています。速く書けるようになった分、レビューにかける時間を削ってしまうと、結局どこかで帳尻を合わせることになるのだと思います。
非機能要件という視点
そしてもう一つ、AIと開発する中で強く意識するようになったのが非機能要件です。
機能要件は「何ができるか」であり、AIに得意な領域だと感じています。「この入力を受け取ってこう処理する」「この画面にこの項目を表示する」といった要件は、言語化さえできればAIが高い精度で実装まで持っていってくれます。
一方で、非機能要件は「どのように動くべきか」という性質のもので、次のような観点が含まれます。
- 性能(レスポンスタイム、スループット)
- セキュリティ(認証・認可、脆弱性対策)
- 可用性・信頼性(障害時の挙動、冗長化)
- 保守性・拡張性(将来の変更のしやすさ)
- 運用性(監視、ログ、デプロイのしやすさ)
これらは、単一の指示や単一のコードスニペットでは決まらないことがほとんどです。システム全体の構成や、将来のビジネス上の想定、チームの運用体制など、コードの外側にある文脈を踏まえて判断する必要があります。AIに「セキュアにして」「速くして」とだけ伝えても、何を優先し、どこまでのコストをかけるべきかは、結局人間が意思決定しなければいけません。ここはまだAI任せにできない、あるいはAI任せにすべきではない領域なんだと、実感するようになりました。
1周回って気づいたこと
「とにかく早く作れる」という状況は、一見理想的に見えて、実は落とし穴になりやすいのかもしれないと思うようになりました。速さそのものが悪いのではなく、速さに引っ張られて、本来やるべき工程を「省略してもいいもの」だと錯覚してしまうことが問題なのだと思います。
由緒ある開発手法、たとえばウォーターフォールモデルにおける工程分割や、レビュー、非機能要件の検討といったものは、地味で遠回りに見えます。AIがあれば不要になるようにも一瞬思えました。でも実際に手を動かしてみると、これらを飛ばした分だけ、あとで必ず何かのツケとして返ってくる。AIが速く書いてくれるからこそ、逆に人間側が「何を作りたいか」「なぜそう作るか」「どう動くべきか」を丁寧に詰める工程の価値が、むしろ上がっているように感じます。
おわりに
まだ試行錯誤の途中で、これが正解だとは思っていません。ただ、今の実感としては、機能要件についてはAIにかなりの部分を任せられるようになった一方で、非機能要件については、まだまだ人間の経験や判断、そして由緒ある開発手法が必要なんじゃないか、というのが今の自分の結論です。開発スピードは間違いなく速くなりました。でも、そのスピードを支えるための土台は、これまで以上に丁寧に作らないといけないんだと思っています。
同じようなことを感じている人がいたら、コメントなどで教えてもらえると嬉しいです。