AIにコードを見せたら要件の不備が出てきた話
若手のコードレビューを担当していることは以前書きました。Javaの実務経験はありませんが、研修生の書いたコードを読んで指摘する役割です。
その際、自分が見落としている箇所がないか確かめるため、社内で使えるAIにもコードを投げています。
使っていて印象に残ったことがあったので、備忘として書いておきます。
「エラー処理が足りません」
研修の課題は、段階的に要件が追加されていく形式になっています。まず正常系を作って、それができたらエラー系を足していく、というような進み方です。
正常系の段階でコードを投げたら、エラー処理が足りないと指摘されました。
読んだ瞬間は、そうか足りないのか、と思いかけました。その段階の課題では、エラー処理はまだ要件に入っていません。そのまま研修生に伝えていたら、要件にないものを指摘するところでした。
AIからすれば当然の指摘です。何を基準に見ればいいのかを渡していないので、一般論として足りないものを挙げるしかない。課題の全体像を渡さなかった私が悪かったです。
前提を渡す
そこで、課題が何段階目のものか、どこまでが今回の要件に含まれるか、要件の文面そのものも一緒に渡すよう修正しました。
そうすると、返ってくる指摘の中身が明確に変わりました。一般論としての不足ではなく、今回の要件に対して合っているかどうかで見てくれるようになります。当たり前といえば当たり前なんですが、前提の有無でここまで変わるとは思っていませんでした。
要件が違う?
前提を揃えて何度かやり取りしているうちに、妙な指摘が出てくるようになりました。
ひとつは、エラー処理の種類が足りないというものです。要件で挙げられている以外にも、想定しておくべきケースがある。これはコードの問題ではなく、要件の書かれ方の問題です。
もうひとつはエラーメッセージの文言でした。要件に指定されている文言が、一般的な書き方から外れている。研修生はその要件どおりに書いているので、提出するコードとしては何も間違っていません。
どちらも、コードを直したところで解決しないタイプの指摘でした。
研修資料を直しに行った
上に確認して、要件そのものを修正できないか相談しました。
結果として、エラー処理もメッセージも要件を修正する方向で落ち着きました(資料の更新は自分でやりました)。
要件が曖昧なまま進めると、何もいいことがありません。レビュアー側が「本当はこう書くべきだけど、要件がこうだから」と妥協して見るのも違いますし、研修生が「このくらいでいいんだ」と覚えてしまうのも違います。
元を直さないと同じ指摘が毎回出かねません。修正は当然の判断だったと思います。
AIは渡した基準を見ている
AIにコードだけ見せれば、勝手に上手いことあら探しをしてくれるものだと思ってしまっていました。
やってみて感じたのは、AIは渡された基準に照らして判断しているだけだということです。だから基準そのものが不十分だと、ずれが出てくるのはコードではなく基準のほうになります。
要件を書いた側は、自分の書いたものを疑いにくいです。外から照らしてもらえるのは、思った以上に助かりました。
前提を渡すことが大事
書いていて、当たり前のことしか言っていない気もしてきました。それでも、前提条件を渡すかどうかで返ってくるものは変わります。
最初にコードだけ投げたときの指摘を鵜呑みにしていたら、要件にないものを指摘して終わっていました。要件まで渡したから、要件の不備が洗い出されました。
何を基準に見てほしいのかを先に決めて渡す。レビューに限らず、AIを使うときはそこが出発点になるのだと思います。
コードレビューそのものについては、こちらに書きました。
案件が決まらないときの立ち回りについては、有料記事にまとめています。
