はじめに
2025年に新卒エンジニアとして入社しました、bqnq です。
新卒エンジニア研修の一環として、新卒パートナーで『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』を読みました！読書会で扱ったのは第1, 2, 3, 9章です。新卒パートナーがそれぞれ1章ずつ担当し、読んだ内容について説明しながら議論するという形式で行いました。
研修中での Bad Code 体験談
研修では、私は Cursor を使ってコードの実装を行っていました。AIエージェントに頼れば、要件を満たすコードがすぐに生成され、テストも問題なく通ります。実際に使ってみて、便利だと感じています。
しかし、後から自分の実装を見返すと、複数の責務が詰め込まれていた実装になっていて、コードが肥大化していることに気づきました。明示的に粒度についてプロンプトで指示していなかったため、実装が読みにくく・変更しづらく・再利用しにくい構造になってしまっていました。
また、研修という限られた時間の中では、リファクタリングの時間がなく、コードの構造まで意識を向けられませんでした。これらのことがBad Codeを生む最大の原因だったと感じています。
今後の自分のコードにどう活かすか／意識したいこと
今回の研修を通して強く実感したのは、AIエージェントはあくまで補助輪であり、設計や実装の最終的な責任は自分にあるということです。
たしかに、AI を使えばこれまでより早くコードを実装できます。しかしその一方で、運用や保守、拡張を意識した設計の質が伴っていないことに、後から気づくことが多々ありました。
ペパボでは「最高・最速の両立」という価値観が掲げられています。私は最高とは何かを考えられるエンジニアでありたいと思っています。AIは動くコードを返してくれますが、なぜこの設計にするのか、どうすれば読みやすくなるのか、責務をどう分離すべきかといった設計意図までは汲み取ってくれません。今後は、設計のゴールを自分の頭で描くことを意識して業務に取り組みたいと考えています。
みんなの感想
SatoMichi：Chapter1担当
まず、私の担当した第1章についてのみ感想を述べさせていただくなら、「この本を読む上での道標」といった印象を受けました。それもそのはず、この章では主に、この本の趣旨と各チャプターで何を扱うかについて軽く触れただけに過ぎないからです。ただ逆に言えば、この章無くして、各章の構造的、理論的なつながりは見えにくいようになっているため、やはりこの章の存在は軽視できないと思われます。
この本全体(といっても全てのチャプターを読破したわけではないのですが)を通して読んだ感想としては、一見当たり前に見えることが書かれているようで、その本当の意味に気がつくのは開発でこの本の実装のアンチパターンを目撃し、苦しむ時なのかもしれない、ということでした。
この本に書かれている手法やデザインパターンというものは、計算機科学を学んだ者であれば誰しもどこかで聞いたことのある内容だと思います。そして、皆が皆ではないかもしれませんが、その重要性については理論的には理解しており、できるだけそれに近いコードを書こうとしていると思います。しかし、この手法やデザインパターンの有用性を身に染みて感じるのは、この本のアンチパターンに遭遇し、その厄介さに手を焼かされてからではないでしょうか。
そういった意味で、私はこの本に書かれている内容は、頭の片隅に常に置いておき、理論的知識から経験的知識へと昇華していく過程を重視したいと感じました。
bqnq: Chapter2担当
私が担当した第2章「抽象化レイヤー」では、主にモジュール化の重要性について述べられていました。実装に必要な機能を小さなモジュールへ分割することで、再利用性やテスタビリティ（テストのしやすさ）が向上するという指針が示されており、今後の開発でも意識すべき点だと感じました。
中でも特に印象に残ったのは、モジュールの粒度（厚い・薄い）に正解はないという視点です。それよりも、設計時点で明確な意図や目的を持ち、どの責務をどこに持たせるかを考えることの方が重要であるという考え方に共感しました。
また、設計を進めるうえでは、「なぜこの設計にしたのか？」をチーム内で共有し、議論することも大切だと感じました。理由を言語化することで、互いに学び合えるだけでなく、設計の質も高まると感じています。
研修が終わった後も、機能の共通化・関心の分離の視点からモジュール設計を行うこと、設計意図を明文化・共有すること、これらを意識しながら、より運用しやすく、拡張性のあるサービス設計を目指していきたいと思います。
Jonny: Chapter3担当
第3章では「コード契約」という概念を中心に、開発者同士がコードを通じてどのようにコミュニケーションを取り、信頼関係を築くのかについて語られています。コードを書く人とそれを使う人の間には、言葉にしなくても守るべき約束があります。関数名や引数、返り値、例外処理などがその約束の一部です。こうした契約が明確でないと、他の開発者が意図と異なる形でコードを修正したり、誤って使用してしまうことがあります。この章が伝えたいのは、良いコードを書くということは単に機能的に正しく動くものを作るだけでなく、他人が誤解せずに使えるようにすることが大切だという点です。
もう一つ共感したのは、時間が経つと自分で書いたコードの内容を忘れてしまうということです。そんなとき、きちんと整理された「コード契約」があれば、過去の自分と未来の自分がより良く協力できるでしょう。もちろん、ドキュメントやコメントも役に立ちますが、それがなくてもコードを見るだけで使い方がわかるのが良いコードであるという点にとても共感しました。
この本を通して感じたのは、結局「良いコード」とは、読みやすく、誤解のないコードであるということです。時間が経っても保守しやすく、他の人が見ても意図が伝わるコードこそが価値あるものであり、開発スキルを高めるにはアルゴリズムの知識も重要ですが、こうした基本的な姿勢や考え方を身につけることも非常に大切だと改めて実感しました。
taki: Chapter9担当
第9章「コードを再利用、汎用化しやすくする」を担当しました、takiです。
この章では、将来にわたって再利用しやすいコードを書くための考え方や工夫が紹介されており、第2章で扱われていた抽象化レイヤーの設計や、第8章のモジュール化といった手法とはまた異なるアプローチが取り上げられていました。
特に印象に残ったのは、「想定」というテーマです。目の前の人には確認して意図をすり合わせることができますが、未来の開発者や、まったく別の環境にいる人の考えまでは知ることができません。過去のエンジニアがどんな背景や前提でコードを書いたのかが記録されていなければ、その「想定」は簡単に失われてしまいます。これは、チーム開発において非常に重要な視点だと感じました。第三者がコードを読んだときにどんな印象を受けるか、意図がどれだけ伝わるかを意識することは、保守性・再利用性の観点からも欠かせないと思います。
コードの再利用性は、後から整えるよりも、設計や実装の段階で意識しておく方がはるかに効果的です。日々の実装の中でも、再利用性を意識して設計することの重要性を改めて実感しました。
本書を通して感じたのは、「良いコード」とは単に動くコードではなく、意図が伝わり、保守しやすく、再利用可能なコードであるということです。各章で語られる内容はどれも基礎的で、一見地味ではあるものの、日々の開発で無視できない重要な視点が詰まっていると感じました。
研修が終わった後は、この学びを活かし、コードの未来に責任を持てるエンジニアを目指していきたいと思います。
