こんにちは。グロトムの堀口夏希です。新人育成のメンターとして、レビューでは修正方法だけでなく「なぜその判断をするのか」も伝えたいと考えています。今回は、学習用の例を使ってレビューの問い方を整理します。

最初にそろえるのは、正しく動く条件

練習課題を「申請金額が10万円以上なら承認を必要にする処理」とします。最初の問いは「この書き方を知っていますか」ではなく、「10万円ちょうどのとき、どうなる仕様ですか」です。

続いて、99,999円・100,000円・100,001円の期待値を一緒に並べます。これなら、本人が比較条件の意味を言葉にし、コードの結果と照らし合わせられます。

判断の根拠を、好みではなく仕様に置く。 ここが共有できると、別の条件分岐でも考え方を応用できます。

次に見るのは、変更する人が迷わないか

動作が正しければ、条件の意味が読み取れるかを確認します。「この10万円は何の基準ですか」「基準額が変わったら、どこを直しますか」と聞くと、名前や定数の置き方を考えるきっかけになります。

ただし、一度しか使わない単純な処理まで複雑な共通部品にする必要はありません。既存コードの規約や変更の見通しを示しながら、読みやすさと仕組みの複雑さの釣り合いを考えます。

指摘の優先度を分ける

仕様と異なる動作や必要なテストの不足は、対応が必要な指摘です。一方、動作に影響しない書き方の提案は、必須なのか参考なのかを明記します。すべてを同じ強さで伝えると、何から直せばよいか分かりにくくなります。

例えば「境界値の期待結果が仕様と違うため、修正とテスト追加をお願いします」と、「こちらの名前にすると意味が伝わりやすそうです。命名規約と合わせて検討してください」では、目的も優先度も異なります。

質問だけで置き去りにしない

考えてもらうことと、答えにたどり着くまで放っておくことは別です。仕様が曖昧なら一緒に確認し、知識が足りない部分には資料や小さな実装例を添えます。最後に本人の言葉で理由と確認方法を説明してもらうと、次に使える理解につながります。

レビューのゴールは、今回の修正と、次回の判断に使える根拠を残すこと。 私自身も、問い方と説明の仕方を大切にしていきたいと思っています。

設計・実装・テストを通じて経験を広げたい方は、Javaエンジニアの募集もご覧ください。