はじめに
私はSIerに入社して十数年一貫して業務系システムの開発に携わっています。
汎用機（メインフレーム）に稼働する基幹システムからWebシステムまで広く開発を経験してきました。そんな私が業務系システムにおけるコードレビューに関して感じるところをまとめてみました。
当記事は私個人の見解であり、所属する組織の公式な見解を示すものではありません。
コードレビューアをやれる人はどんな人？
ウォーターフォール型開発でいう下流のコーディングやテストを数年経験した後に、設計を経験し、中堅に差し掛かったもしくは設計を経験すると同時にコードレビューアをやることが多いのではないかと思う。
知人等の話を聞いていると、この流れは多くのSIer企業で行われているようです。
ただ、私は単に開発経験年数が一定数経ったら、いつの間にかコードレビューができるような能力を養えているとは思えません。
コードレビューは、テスト工程に入る前にプログラムの『品質』を保証する作業だと考えています。
プログラムの『品質』 は、挙げればきりがないですが主には以下となるかと考えています。
- 要件や設計を満たす仕様となっていること
- セキュアなコーディングがされていること
- 変数名やメソッド名等のコードの記述が分かりやすいこと
- 処理性能が高く組まれていること
コードレビューアは、上記を保証するために以下を満たす必要があると考えています。
- 業務知識や開発対象システムに対する知見
- 開発ノウハウが十分にある
この２点については、システム開発を継続して経験から生まれるTipsを継ぎ足していくことで醸成されてくると思っている。
ただ、単に継続しているだけでは『いい味』を出すことはできないだろう。
コードレビューする能力養成
開発ノウハウ
当てもなくひたすらに開発していても、一定のノウハウは溜まるでしょう。
上手くノウハウを溜められたとしても暗黙知であり、言語化できないゆえにチームメンバーに波及していきません。
レビューした結果について、「なぜそのコードは良くないのか」という理由を説明できなければ、それはコードレビューしたとは言えないと考えています。
暗黙知で形成された開発現場やチームでは、確かなコードレビュー能力を持った人財は育たないでしょう。
かくいう私も暗黙知を持ったエンジニアに囲まれて開発してきました。
「何となくコードレビューできる力が付いてきているなー」と思っていましたが、自信を持って言えるほどレビューできているとは言えません。
その中で、ある言葉を聞いて「はっ！」と思いました。
東進ハイスクール講師の林修先生の名言になります。
”正しい場所で、正しい方向で、十分な量がなされた努力は裏切らない」”
引用元：予備校講師・林修が明かす勝者の発想と成功哲学、予備校講師・林修が明かす勝者の発想と成功哲学、2025/11/22アクセス時点
引用元を読んで解釈したところ、自身の得意な領域（分野、場所）において、正しい方向（やり方）で十分に取り込むことが成功のカギだと仰っています。
私が着目した点は「正しい方向で、十分な量がなされた努力は裏切らない」という箇所です。
これは、どんなことでも通ずる名言だと思います。
「正しい方向」は、「正しい型」と言い換えても良いのかなと思います。
「良いコードはこういう型だ」というものをしっかり明言化された知識として学習し、その型を使って十分な量を開発やレビューすることで、必然的に開発ノウハウは溜まると考えました。
では、「正しい型」はどうように学べ良いのでしょう。
世の中には良書がたくさんあります。良書を読むことで「正しい型」を身につけることができます。
私が読んだ本でおすすめとしては、以下です。
Dustin Boswell、Trevor Foucher 著、角 征典 訳「リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック」、O'REILLY
この本には、良いコードを書く方法が書かれています。逆を返せば、この本のTipsとアンチパターンとなるコードが書かれていないかを確認することでコードレビューする基礎力を養うことができます。
私は読めていないですが、直近出版された良書と評判な以下の本も参考になるのではと思っています。
私も積読を消化してきたところで読みたいと思っています。
仙塲大也 著、「改訂新版 良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方」
コードレビューする基礎力を付けて、それを武器にコードレビューすることで良いコードと悪いコードを明確に説明することができます。
これにより、チームメンバー内の開発力が上がりコードレビューできる人財が育つと考えています。
基礎力を付けて鍛錬（十分な量の努力）を行うことが、コードレビューに与える良い効果は以下の本でも紹介されおり、「正しい方向」と言って良いと考えています。
URAMASU著、「鍛錬するとコードレビューがループする 〜へーしゃの技術戦略室室長が語ったコードレビューの在り方〜」
先に挙げたセキュアなコーディングの方法や処理性能を高くする方法についても、巷には色々な良書があります。
ここで言えることは、良いコードレビューするためには良書を読み（正しい方向）、その知見をもとにレビューを十分に行う（十分な量がなされた努力）ことが重要だということです。
ただAIが急速に進歩している現代では、将来的にこれらの良書の知見をAIに学習されることで機械的にコードレビューできてしまうでしょう。
一方で、AIには良いコードと悪いコードを開発チームに理解させて、良いコードを書かせるように伝導するには、未だ時間がかかるでしょう。
業務知識や開発対象システムに対する知見
業務系システムのコードレビューでは、開発ノウハウだけでは『良い』成果は得られないと感じてます。
業務知識や開発対象システムに対する理解が必要となることがあります。
例えば、業務フロー的に間違いなくデータとして後続に来ることがない条件があった場合、その条件を実装する必要はないです。
しかし、業務知識や開発対象システムに対する理解が浅い要員が開発した場合、１つのプログラムや局所的な処理だけにフォーカスして条件を考え実装してしまいます。
レビューアについても同様だった場合、レビューを掻い潜り無駄なロジックを実装したまま本番リリースということなってしまします。
これは、本来であれば無駄なロジックを排除して処理性能を上げられたかもしれません。
つまり、プログラムの『品質』を保証することができないので、悪いコードレビューとなっていると考えます。
業務系システムでは、１つのプログラムや局所的な処理をレビューするときでも、システム全体を意識してレビューすることが必要となります。
基幹システムでは、大量データを扱うため、無駄なロジックがあると致命的になることがあります。
業務系システムのコードレビューアには、豊富な業務知識と対象システム全体に対する深い理解が必要となりす。
業務知識を増やすためには、ビジネスレイヤの方の話に耳を傾け業務内容の理解に努めることが近道でしょう。
対象システム全体に対する理解を深めるためには、積極的に各種機能を改修する案件に関わり経験を積むことが重要かと考えています。
ただ、案件を選べないケースが多いことも事実でしょう。
隙間時間にコードベースを覗いて、機能１つ１つの実装を理解していくことも必要でしょう。
この積み重ねにより、豊富な業務知識と対象システム全体に対する深い知見を持ってコードレビューに臨めるようになっていくでしょう。
これもまた秘伝のタレのように継ぎ足し熟成されていくものかなと思っています。
まとめ
業務系システムにおけるコードレビューでは、以下２種の秘伝のタレのかけ合わせが重要だということを私の拙い経験から書かせていただきました。
- 開発ノウハウ
- 業務知識や開発対象システムに対する知見
開発ノウハウについては、良書をたくさん読み漁り、その知見をもとに十分な量のコードレビューを経験することで醸成されるということを紹介しました。
業務知識や開発対象システムに対する知見については、地道にビジネスレイヤの方の話をきき、コードベースを漁り知識を増やしていくというやり方を紹介しました。
コードレビューの直接的な技法の紹介はしませんでしたが、コードレビューをするために必要な能力とその能力を養成する方法の一案を提示させていただきました。
当記事が誰かの参考になれば幸いです。