チーム開発におけるコーディングについて 新卒２年目がプリンシプル オブ プログラミングを読んで、感じたこと

この記事は「BEMA Lab Advent Calendar 2024」の9日目の記事です。

はじめに

みなさんこんにちは、23新卒エンジニアの岩田と申します。
本記事では、チーム開発におけるコーディングの心構えについて、自身の経験をもとにお伝えします。

この記事を書くきっかけとなったのは、初めて実践業務に携わった際、エンジニアとしてのマインドが足りていない、主にコーディングについての意識が低いと感じ、とりあえず一冊の書籍で勉強した経験です。その改善のために手に取ったのが、
書籍「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則」
でした。
この書籍により、当時の自分の悪い面を把握し、意識を変えることができました。
近年、弊社では多くの新卒採用が行われており、個々の意識が非常に大切だと感じたため、今回の記事を書くことに決めました。自身の経験と書籍での学びを共有し、同じような課題を抱える方々の参考になれば幸いです。

シンプルなコードの重要性

開発において、冗長なコードやトリッキーなコードは、他の人が見た際に分かりにくいだけでなく、変更を行うときにも無駄な労力がかかってしまいます。そのためコードはなるべくシンプルに書くべきです1)。
※短くしすぎると逆に分かりにくくなる場合もありますが、今回は例外とします。
この状態に陥りやすい状況として次の3つが書籍に書かれています。

1.新しく覚えた技術を使いたい

自分はRuby on Railsの勉強をしながら開発をしていたとき、「あ、この開発にはあの技術が使えそうだ。」と、勉強した知識を積極的に活用しようとしていました。
実践で使用したことのない知識を無理に活用した結果、全体の見通しが悪くなり、非常に見づらいコードになってしまいました。そのため、自分でも読み返すのが困難な状態となってしまいました💦

開発はチームプレイであることを理解した上で、難しい知識を披露するのではなく、誰でも分かりやすいコードを書くことが一番重要であることを学びました。
そう考えると、知識が少ない若手も意識すれば、チーム開発として良いコードが書けるのではないか？と感じています。

2.将来に備えたい

「もしかしたらこの機能の実装が必要になるかもしれない。」と、少し気を遣って追加でコーディングをしても、実際は無駄な気遣いに終わり、逆にそれがコードにおける負債となることがあります。
必要になった時、必要な分だけ開発をすることを意識する必要があります。途中から仕様変更がある場合などは特に気を付ける事項かと思います。

3.勝手に要件を加えてしまう

上記(1.2)で記した内容と重複するところがあります。本来、要件はステークホルダーの要求によって決めるものですが、開発者はそこを勝手に判断してしまうことがあります。よりシンプルにコードを保つには、要求された要件のみに絞った必要最低限の機能実装に留める必要があります。1)

経験談

少し上流の話になりますが、自分の経験を共有します。
とあるプロダクトの要件定義を任された際、詳細な情報がほとんど伝えられないまま依頼を受け、取り急ぎ自分とチームメンバーで要件定義を行いました。
その後、その内容をプロダクトを利用する営業の方に共有したところ、会話がかみ合わず、認識そのものが大きく異なっていることが判明しました（会議はほぼ壊滅状態…😭）。

この出来事をきっかけに、「自分と相手の認識が異なる可能性がある」という前提で話し合いや確認を行うよう心がけるようになりました。
本当に相手と自分の考える要件が一致しているのか、たとえ一致している場合でも確認して損はありません。

社会人としての報連相（報告・連絡・相談）、本当に大事ですね！

この章で伝えたかったことは、「余計なことはするな」ということだと解釈しています（あくまでコーディングに関して）。
最初に読んだ時は、「自分で動ける人間が優秀」という社会人像とギャップがあって戸惑いました…。
ただ、自分がチーム開発を行ってこれを実践した際、必要最低限のコードに留めて、短縮できた時間があれば他のメンバーのカバーに入れました。
自分のやるべきことを明確にして対応することで、臨機応変に対応できる時間が増えることを実感し、エンジニアにとって要件通りのものを予定通りに仕上げることの重要性を学ぶことができました！
このように、シンプルなコードを書くことはチームの生産性向上に直結します。

コードで命名は最重要課題

次に、チーム開発における『命名』について考えました。
自分の中で今でもなかなかうまくできない技術の1つです。自分は高専出身で学生時代のコーディングを振り返ると、変数名を”a”と書いておくなんて日常茶飯事で…。
そういったツケが社会人になって出てきました。そして、意識しても自分は命名が苦手だなと感じました。
その中で、少しでも良い命名に近づけるように意識したことを書籍の内容と自分の経験から紹介していきます。

まず良い命名についてですが、書籍には、名前を見ただけでどういった内容のコードなのかを把握できること、と書いてありました。
コードを書いている際に、目的や使用方法が明確であるため呼び出しやすくなります。関数名を見ただけで理解できるため、読み飛ばしもできるようになります。よって、開発効率が向上します！
もちろんコードというのはコンピュータに対する命令ではありますが、人に伝えるための文書の役割も果たしていることがわかります。

逆に悪い命名は、名前からその関数がどんな動作をするかわからない、ということです。動作の想像がつかないと、読み手はその関数について深く読み込む必要が出てきます。それが階層の深い関数となると、プログラマの大きな負担となり、修正や機能追加をすることが本来の目的なのに、読むことばかりにリソースを取られ、本来の目的が遂行しにくくなります。

命名がうまくいかない原因

悪い命名になってしまう原因は、自分の中で2つあると考えています。
1つ目は時間に余裕がないことです。
開発をしている中で、作業の早期完了のため命名の時間が短くなってしまうことがありました。実際、関数名が分かりやすくてもそうでなくてもプログラムは動きます。そのため、命名の優先順位が落ちてしまいます。目先の時間に囚われず、命名はしっかりと行い将来的な時間を節約しましょう。

2つ目は単純に語彙力です。
その関数、変数にぴったりな単語があったとしても、知らなければ命名することは不可能です。これに関しては普段からコードをみる習慣を付けることと、既存のコードから使えそうなワードに目星をつけておくことが重要です。

命名をするときのポイント3つ

これらの原因から、命名におけるポイントを3つご紹介します。

1.誤解のされない名前を付ける

2つの意味で解釈できてしまう命名（filterなど）や、少しニュアンスが変わってくる命名（getとfetchなど）をしてしまうことが自分はしばしばあります…。

2.効果と目的を説明する

命名をする目的は、読み手にコードを分かりやすくさせるためなので、手段を説明する必要はありません2)。
効果と目的を簡潔に（コメントを使うのもいい）書くことで、読み手は変数や関数の中身を追う必要がなくなります。

3.生成AIを活用する

個人的な方法として、ChatGPTなどに投げてみて、候補をたくさん出してもらいその中から選ぶという手法を使っています。ただ、そのまま採用するわけではなく、より良い単語に変換したり、候補の単語をうまく結合したりなど、ChatGPTに頼りっきりにならないようにしています。

プログラミングにおけるセオリー

プログラミングの最終的なゴールは、「最高のコード」を仕上げることにあります。その上で重要である3つのセオリーについて記載されています。

1.コミュニケーション

ここにおけるコミュニケーションとは、コードでやりとりができるという意味合いです。コードも一種の文書であり、コミュニケーションツールの1つであると書かれています。
ソフトウェアの開発コストの大半は、開発された後の保守コストが占めます。そのため、コードを書く時間より読む時間の方が圧倒的に多くなります。
長期的にソフトウェアの寿命まで考えると、コードを読む人数は計り知れません。書いている本人ですら、自分が書いたコードを読み返すことはよくあります。
そのなかで、より円滑にコミュニケーションを取るには、「相手の視点になる」ことが重要です。「このコードをみて、他の人はどう思うだろうか。」この視点を持つだけで、意識がかなり変わるかと思います3)。

自分の経験として、どうしても最初は「動くもの」を作る意識が強くなってしまいます。また、一度作ってしまうと相手のために手直しをするのが億劫になりがちです（自分の場合）。
そのため、開発初期段階から相手の視点を忘れず開発するのが一番かと思います。
経験として効果的だったのは、レビュアーの方への意識でした。
「前、こんなところを指摘されたな。」、「ここの実装方法はどちらがいいか、ちょっと訊いてみようかな。」など、相手の意見を取り入れることも相手の視点に立つ上で重要かと思います。
時間はかかるかもしれませんが、後の読む労力と比べればコストは安く済むはずです！

2.シンプル

「コードがシンプルである」とは、そのコードから余分な複雑性が取り除かれた状態を指します4)。
こちらに関して、自分は関数を入れ子にしすぎて大変な目にあった記憶があります😵
何が問題だったかというと、コードが複雑すぎてレビュアーの方が理解できない点、修正やテストをするのが一苦労という点です。レビュアーの方に処理方法が伝わらなければ説明する手間が増えたり、少し修正するだけで他の部分に不具合が出てきたりします。それを今後の負債とすると、かなりコストの無駄になってしまいます。初期開発のコードがいかに大事かがわかりました。シンプルという点では、処理の流れは直線的であることを常に意識するべきです。そのことに関しても、書籍に詳しく書いてあります！

3.柔軟性

コードにおける柔軟性とは、コードの変更のしやすさにあります。コードに柔軟性を持たせるには、拡張しやすく、かつ、その拡張が他に波及しないような設計を心がける必要があります5)。
こう記述されていますが、自分の中で拡張しやすい設計とはどういったものなのか、まだ言語化できません…。そのため、自分はシンプル化させることで柔軟性は賄えると現状では考えています。
さらに開発経験を積んで、この辺りの言語化もできるよう頑張ります💪

読んでみた感想

本書は「コードのシンプル化と明確化」を一貫して重視しており、良いコードを書くための具体的な手法と、それを支えるマインドセットが豊富に紹介されています。エンジニアとしての成長に必要な視点を提供してくれる内容であり、大変参考になりました。
特に、良いコードを書くための具体的な方法だけでなく、それを支えるマインドセットにも多くのページが割かれており、エンジニアとしての成長に直結する内容だと感じました。
すべてを一度に実践するのは難しいかもしれませんが、各章で提案されているアイデアの中には、すぐに取り入れられる実践的なものが多く含まれています。
開発中の課題解決や効率向上に役立つ点が特に印象的でした。

さいごに

エンジニアとしてコードの質を上げたい方や、日々の開発における改善のヒントを探している方には、ぜひ手に取ってほしい一冊です。
この本を読むことで、技術だけでなく、より良いコードを書くための考え方や姿勢を学べるはずです。
今後の開発に役立つ実践的な知識が詰まっているため、タイミングを見計らって繰り返し読むことで、さらに多くの気付きが得られるでしょう。
小さな改善から始めることで、大きな成果につながるはずです！
本記事を読んで、同じような課題を抱える方々の参考になれば幸いです。

【引用文献】

1)  上田勲 . プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 . 斉藤和邦 . 2016 . [p.31]
2)  再掲1) [p.59]
3)  再掲1) [p67. ~ p.68]
4)  再掲1) [p.69.]
5)  再掲1) [p.70]