こんにちは、バックエンド開発部の森です。タクシーアプリ『GO』のサーバーサイドをGo (golang)で開発しています。 私は2025年4月に新卒入社しました。この1年間で様々な案件を担当してきましたが、何を学び、今後どのような方針で進んでいくのかを書き留めておこうと思います。
まずはいくつか印象に残っている失敗を挙げてそこから何を学ぶことができたのか、書いていきたいと思います。
失敗と学び
1. テストコードもメンテナンス対象である
案件の QA で見つかったバグを直すためにコードを少し修正した際、テストが通らなくなり、デバッグに何時間も費やしてしまったことがありました。しかし原因を突き詰めてみると、実は「案件で追加したテストコード自体が間違っていた」というオチでした。
正しくないテストがコミットされてしまうと、将来のチームに“爆弾”を埋め込むことになってしまいます。開発者は「テストは正しく書かれているもの」という前提でデバッグをしてしまいがちなので、問題の発見にどうしても時間がかかってしまいます。テストコードに対する信頼が失われてしまうと、開発の心理的安全性も下がり、デメリットしかありません。
AIが便利な今の時代、テストコードの生成をすべてAIに任せてしまいがちですが、もしそのテストが不適切なコードになっていた場合、未来の自分やチームメンバーがそのツケを払うことになります。そのリスクを十分に理解しておく必要があると痛感しました。
2. コードを読む審美眼を養う
ある案件で、configを環境変数から逐一 os.Getenv() で読み込み、マップ形式に変換してロードするコードを書いてしまっていました。
至る所で os.Getenv() を呼び出す形式は、型変換の手間が増え、ボイラープレートができてしまうという問題があります。本来であれば、アプリケーションの起動時に透過的にオブジェクトへ保持すべきです（Goの場合、例えば github.com/caarlos0/env/v11 などのライブラリが活用できます）。
「いたる所に os.Getenv がある」という状態に対して、直感的に違和感を持てるかどうかが重要です。これはあくまで一例ですが、コードを見た時に「なんとなく嫌だな、不吉な臭いがするな」と思える感覚、コードの審美眼を養う必要があると感じています。
そのためには、普段から優れたコードに触れる機会を増やすことが欠かせません。今後は、Goの標準ライブラリや高名なGopherの方々が書いたOSSのコードを読み解く習慣を大切にしていきたいです。
3. トレードオフを理解し、意識的な選択をする
以前、画像を返却するAPIを開発した際、画像をBase64エンコーディングして Content-Type: application/json のレスポンスボディに詰め込んで返すという横暴な実装をしてしまったことがありました。
確かにこの方法でも動かすことは可能なのですが、データサイズが増大し、ブラウザのキャッシュも効かなくなるという明確なデメリットがあります。本来であれば、image/jpeg などでバイナリデータとして直接返すか、画像のURLのみを返してクライアントに取得させるなどのアプローチを取るべきでした。
ソフトウェア開発では膨大な量の選択を迫られますが、大抵の場合、唯一の正解は存在しません。しかし、自分が使用する技術の仕様やトレードオフを理解していなかったり、そもそも他の選択肢を知らなかったりすると、結果的に今回のような「動くけど変なコード」を無自覚に生み出してしまいます。
この経験から、対象への理解を深めて手札を増やしておくこと、そして「なぜその技術を選ぶのか」を注意深く検討することの重要性に気付かされました。
木こりのジレンマに陥らないために
このように様々な学びを得ることができたのは、大きな行動変容を起こすことができたからでした。
入社当初は目の前の仕事をこなすことに夢中になっていました。その一方で、自分の仕事の進め方を振り返ったり、業務で使用した技術について一歩踏み込んで調べたりすることを忙しさを言い訳にして怠っていました。いわゆる「木こりのジレンマ」に陥っていたのです。
そんなとき、97 Things Every Programmer Should Know に収録されている "Hard Work Does not Pay Off" というエッセイを読み、胸に深く刺さりました。
As a professional programmer you should know that trying to be focused and 'productive' 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change.
そのために、業務時間外での勉強やスキルアップの時間をいかに確保するかが重要だと気づきました。それからは、仕事が残っていても時には早めに切り上げる勇気を持ち、その時間を技術書を読むことや、個人でのコーディングなどの自己投資に充てるようになりました。そうすることが長い目で見た時に最も仕事でパフォーマンスを出せるようになる方法だと思ったからです。
今後について
成長の道筋
上述したように都度失敗から学んでエンジニアとしての基礎技能を少しずつ引き上げられていると思います。また、時間の使い方を変えて継続的に成長できるサイクルを回せるようになりました。
一方、まだまだ自分の知識とスキルには穴やムラがあると感じているため、今後も書籍やコードリーディングからインプットを大事にしていきます。シニアエンジニアから紹介された本がまだまだ未消化なので少し挙げておきます。
- 『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』
- 『リファクタリング：Rubyエディション』
- 『単体テストの考え方/使い方』
- 『Concurrency in Go』
- ほか多数
当たり前のことを当たり前に
弊社は「日本を動かす、社会インフラへ。」というビジョンを掲げています。 社会インフラとは、そこにあって「当たり前」のものです。その当たり前の価値を安定して提供し続けるためには、開発者である自分自身が、まずは「当たり前のことを当たり前にこなせる」レベルに達していなければなりません。今後も引き続き、技術の基礎力をしっかりと身に付けていきたいと考えています。
最後に、右も左も分からない状態で入社した私が、この1年で成長を実感し、成果を上げられるようになったのは、紛れもなく周囲のハイスキルで温かい先輩エンジニアの皆様のおかげです。この場を借りて、心より感謝申し上げます。
今年はもっと"Giver"側の人間になれるよう、引き続き頑張ります！
