コードレビューを通った。それで「合格」なのか？ ― AIに任せて気づいた要件定義の重要性
AIClaude CodeCodex要件定義仕事システム開発
最近、個人ブログのメンテナンスをClaude Codeに任せることが増えました。
調査から実装、テスト、Pull Requestの作成まで、かなりの作業をAIが進めてくれます。さらにCodexにコードレビューを任せれば、別のAIが実装の問題点を指摘してくれます。
以前なら自分で調べてコードを書き、動作確認していた作業が、今では自然言語で指示するだけで進んでいきます。便利な時代になったと感じます。
ただ、しばらく使っているうちに、少し気になることが出てきました。
AIから「レビューは通りました。テストも成功しています。マージしてよいですか？」と判断を求められる機会が、やたらと多いのです。
最初は、自分が承認係になったような気分でした。これが承認疲れというものかと。ところが、何度も判断を求められるうちに、もう少し本質的な問題があることに気づきました。
そもそも、自分は何をもって「合格」と判断しているのだろうか。
コードレビューが通れば合格なのか
Claude Codeで実装し、Codexがレビューする。そこで指摘された問題を修正し、再度レビューする。GitHub ActionsのCIも通る。これだけ確認できれば、実装としてはかなり安心できます。
もちろん、コードレビューは重要です。実装上の欠陥や、考慮が不足している条件を発見するうえで大きな役割を果たしてくれます。
しかし、そこで一つ疑問が生まれます。
コードレビューを通過したことと、作りたいものが完成したことは、同じなのだろうか。
必ずしも同じではないですよね。 例えば、要求された仕様どおりに実装されていたとしても、その仕様自体が目的に合っていなければどうでしょうか。どれほど綺麗なコードであっても、必要な機能が欠けていれば困ります。反対に、細かな改善の余地が残っていても、目的を達成できているなら十分な場合もあります。
コードレビューは、実装の品質を評価するための手段です。しかし、何ができていれば十分なのかという基準そのものを、コードレビューだけで決めることはできません。
この当たり前のことを、AIに実装を任せるようになって、改めて考えるようになりました。
ブランチを消すだけのつもりだった
このブログでは、記事を公開するときにGitHubのPull Requestを使っています。記事をAstroのサイトに反映し、Cloudflare Workersへデプロイする仕組みです。
その運用の中で、公開後に不要になった下書き用のGitブランチが残り続けるという問題がありました。それなら、記事の公開が終わったらブランチを自動で削除してほしい。
ところが、Claude Codeが実装して、Codexのレビューを受けると、いろいろな問題が見つかりました。
- ブランチを削除しようとした直前に、別のコミットが追加されていたらどうなるのか。
- 同じ名前のブランチが別のリポジトリにも存在していたら、間違ったPull Requestを閉じてしまわないか。
- 記事の公開自体は成功しているのに、ブランチの削除だけ失敗した場合、処理全体を失敗とみなすべきなのか。
こうした条件を一つずつ整理していくと、当初の「不要なブランチを削除する」という依頼だけでは、考慮が足りていなかったことが分かってきました。
最終的には、処理対象のPull Requestを厳密に特定するように変更しましたが、やり取りを続けるうちに気がつきました。 そもそも私が実現したかったのは、ブランチを削除することではなく、ブログの公開を安全に完了させ、不要なものだけを後片付けすることだった、という点です。
そう考えれば、公開が成功しているのに後片付けの失敗で公開自体を失敗扱いにするのは、目的に合っていません。また、削除してよいかどうか判断できないブランチは、無理に消さずに残しておく方が安全です。
「何を作るか」だけではなく「どこまでできればよいか」
システム開発の仕事をしていると、要件定義の重要性については何度も耳にします。
要件が曖昧なまま開発を始めてはいけない。認識の齟齬をなくさなければならない。完成したときに検証できるよう、受け入れ条件を明確にしておかなければならない。どれも、よく知られている話です。
ところが、自分のブログのような個人の開発では、これまでそれほど厳密に考えていませんでした。自分でコードを書いていれば、作りながら考えればよかったからです。
実装している途中で「この場合はどうするべきだろう」と考え、必要ならその場で方針を変える。自分自身が開発者であり、利用者でもあるので、それで十分でした。
しかし、AIに実装を任せると事情が変わります。
AIは依頼した内容を実現しようとします。実装方法を工夫することも、想定外の問題を指摘することもできます。それでも、最終的に何をもって完成とするのか、どこまでのリスクを受け入れるのかは、依頼する側が判断する必要があります。
要件定義とは、単に「何を作るか」を書き出すことではありません。
- 「どのような状態になれば目的を達成したといえるのか」
- 「何が満たされていなければ合格にしてはいけないのか」
- 「何が残っていても、今回は許容できるのか」
こうした合格条件を定めることも、要件定義の重要な役割なのだと感じています。
要件定義は、最初に一度やれば終わりではない
とはいえ、最初からすべての条件を洗い出すのは簡単ではありません。
今回のブランチ削除の件でも、レビューを受けるまで気づいていなかった問題がありました。その意味では、AIによるレビューは要件定義にも役立っていると感じます。
- 最初に目的と条件を伝える
- AIが実装する
- レビューによって想定していなかった問題が見つかる
- 要件や合格条件を見直す
この繰り返しです。
従来のシステム開発でも、開発途中で要件が明らかになったり、見直されたりすることは珍しくありません。ただ、AIによって実装とレビューのサイクルが速くなった結果、その過程を短い時間で何度も経験するようになりました。これって、アジャイル開発が自分をリーダーとしてサイクル回っているということなのでは？
実装の問題だと思っていたものが、実は要件の問題だった。逆に、要件として細かく指定しなくても、AIが適切な実装方法を提案してくれることもあります。
ただ、エンジニアが担う仕事の重心は、少しずつ変化していくのかもしれません。
従来は「どうやって作るか」に多くの時間を使っていました。これからは、「何を作るべきか」「なぜそれが必要なのか」「どこまでできれば合格なのか」を考えることに、より多くの時間を使えるようになるのではないでしょうか。
そして、これは簡単な仕事ではありません。
何を合格とするかを決めるには、目的を理解し、制約を整理し、優先順位を決め、残るリスクを評価する必要があります。時には、完璧ではない状態で先へ進む判断も求められます。
実際、今回のブログ公開の仕組みも、テストとレビューを通過してマージしましたが、改修後の最初の実際の記事公開による動作確認は、まだ残っています。それでもマージしてよいと判断したのは、後片付けに失敗した場合の扱いを明確にし、記事公開そのものへの影響を抑える設計になっているからです。
大切なのは、すべてが完璧になるまで待つことでも、レビューを通ったからと無条件に先へ進むことでもありません。
何を確認できたから合格にするのかを、自分の言葉で説明できることないかと考える次第です。
おわりに
AIはコードを書いてくれます。テストも書いてくれます。レビューもしてくれます。しかし、その結果を何をもって合格とするかには、依頼する側の目的や価値判断が含まれています。
AIが使いやすくなるほど、その部分を曖昧にしたままでは仕事を任せられません。今まで実装しながら無意識に行っていた判断を、言葉にして伝えなければならなくなった。
そう考えると、AIは単に開発を効率化する道具というだけではなく、要件定義の曖昧さを映し出す鏡のような存在なのかもしれません。
次にClaude Codeから「マージしてよいですか？」と尋ねられたときには、まず「何をもって合格にするつもりだったのか」を考えたいと思います。
まあ、毎回そこまで考えていると、結局なかなか承認が進まないのですけどね。