以下の内容はhttps://www.yasuhisay.info/entry/2025/03/31/230212より取得しました。

ジュニアエンジニアからシニアエンジニアになるまでに自分がやっていたことまとめ

データエンジニアリング

長いので3行まとめです。

  • 最近、エンジニアリング経験の浅い方にアドバイスをする機会が増えてきたので、紹介時に使えるポインタをまとめました
  • 何が合っているかは人によるので、正直正解はないと思いますが、少なくとも自分に効いたやり方をまとめています
    • 合いそうなところだけをピックアップして真似してもらうだけでも全然いいと思います
  • 「他にもこういうのをやったら伸びると思うよ!」というのがあったら、SNSなどで反応ください

はじめに

最近、エンジニアリング経験がまだ薄い方にアドバイスやサポートをする機会が増えました。アドバイスするときにポインタになるテキストがあると便利だなと思ったので、このエントリを書いています。具体的なアドバイスは例えば以下の内容ですが、本エントリはこれよりもう少しスコープが大きい内容になります。

また、シニアエンジニアの場合は技術だけでなく、事業への貢献、ビジネスサイドとのコミュニケーションなどの観点も当然入ってくると思います。ただ、それも含めると、スコープが広くなり過ぎて書くのが大変なため、このエントリでは技術にスコープを絞って記述します。

「id:syou6162は果たしてシニアエンジニアと呼べる実力なのか🤔」という気持ちも若干ありますが、所属組織ではICとして仕事させてもらっているので、ここではシニアエンジニアであるとしておきます。

あくまで自分の経験 (N=1)をベースにした話なので、これが絶対に正しいわけではありません。また、すべてを一度に実践しようとすると負担が大きいかもしれないので、「やれそう」「これなら試したい」と思うところだけでも参考にしてもらえればいいかなと思います。

真似するのが簡単で効果が大きい

Pull Requestをセルフレビューする

自分がまだジュニアエンジニアだった頃、Pull Requestを1つ出すと30個、ひどいときは50個程度コメントがつくことがありました。1週間経ってもPull Requestがマージできない状況もザラにあり、今思えば進め方や段取りが下手だったと思います。

「これはどうにかしないと仕事が進まない...!」と思い、Pull Requestの作成に関して以下のことを注意するように変えていきました。例えば

  • Pull Requestを作る前に、ざっくりとした全体方針をドキュメントなどに書き出して、方針をレビューしてもらう
  • 方針すら分からない時は、誰かにお願いして一緒に壁打ちしてもらう
  • 「このPull Requestでは何をやっていて、何はやらないのか」を明記するようにする
  • 過去に作ったPull Requestとのつながりや、今後出す予定のPull Requestとの関係性も説明しておく
    • このPull Requestのスコープではないことなどを明記することでレビュアーに優しくする
  • Typoがないか確認する
  • CIが通っているか、レビュー依頼前に確認する

などです。もちろん、今でもたまにPull Requestにたくさんコメントがついて「これはやり方ミスったな...」となることもあります。ただ、意識的にこういう進め方をするようになってから、作業全体の効率はかなり良くなったと感じています。

あとは、自分が関わっているPull Requestについては、全体の流れが破綻してないか、他のコードやPull Requestとの整合性が取れてるかを意識的に見るようにもしていました。そうすることで、他人にとっても読みやすいPull Requestになるし、結果としてチーム全体の認知負荷も下がるのでおすすめです。

趣味プロジェクトを持つ

趣味プロジェクトは個人的にかなりおすすめしたい方法です。趣味プロジェクトは本当に何でもよく、日常のちょっとした面倒を解決するツール / 趣味の記録をするためのアプリ / 誰の役にも立たない自己満足なアプリ、など本当に何でもよいです。趣味プロジェクトのよいところは

  • 誰にも迷惑かからないので、壊しても全然OK
  • 自分がオーナーなので「向いてないかもしれないけど一旦試す」みたいなことも気軽にできる
  • 実際やってみた結果、「これは向いてなかったな」という失敗自体もちゃんと学びになる
  • 仕事だとなかなかやれないオーバーエンジニアリングな設計を試せる
    • 仕事だと、「やりすぎないように」とか「周囲に合わせておく」とか、色んな制約を考える必要がある
    • 趣味プロジェクトなら逆に「やりたいからやる」が通る。それがとにかく良い
    • それがうまくいったかどうかはあまり重要ではなくて「こういうときは向いてないな」とか「こうやると詰まるんだな」みたいな引き出しを一つでも増やせるだけで十分価値がある

趣味プロジェクトは仕事と完全に切り離してでもよいですし、仕事にうっすら関係しててもよいですが、自分で課題を設定して自分で手を動かしてみる経験は、やっぱり強いなと思います。

参考: 自分が過去にやっていた趣味プロジェクト

「じゃあ、具体的にどういう趣味プロジェクトをやったりしたの?」と質問されることもあるので、過去にやっていた私がやっていた趣味プロジェクトをまとめておきます。

「趣味プロジェクト、金かかりませんか?」という質問はたまに聞かれます。自分の趣味プロジェクトはBigQueryやデータ系のバッチを動かすものが多かった関係で、累計だと多分数十万くらい溶けてると思います。しかし、この辺で得られた経験などから趣味プロジェクトを始めた頃の年収を余裕でペイする分だけ年収が上がっているので、趣味プロジェクトは悪くない投資だと思っています*1。

真似するのは簡単で効果はそこそこ

地味な改善活動を拾い続ける

細かい修正や改善は面倒ですし、やろうと思っても後回しになりがちです。しかし、そういったことを拾っていくと、案外自分の力になることが多いです。

例えば「このバッチ、手元で動作確認するの面倒くさいな」や「ここ、なんか壊れやすいな...」といったポイントは日々の開発の中で結構見つかると思います。それに対して「まあ、今回はしょうがないか」で終わらせるのではなく、なるべく直すようにしていました。正直、習慣化されるまでは結構だるいですが、慣れてくると身体が勝手に動くようになります。

こういう改善をしていると、周囲からも「あの人はちゃんとリポジトリのこと考えてくれてるな」や「必要な機能だけ実装して終わり、じゃなくて、その後のメンテも見据えてるな」といった形で見てもらえるようになります。特に、ジュニアの方は「とにかく早くPull Requestを出さなきゃ...!」となりがちですが、そこでもうちょっとだけ踏み込んで、共通処理に切り出すとか、READMEを整えるなどをやれると、かなり周りからの印象が変わってくると思います。

また、そういう姿勢を続けていると、Pull Requestでちょっと無茶な修正をしたときでも「この人なら後でちゃんと直してくれるだろう」と信頼してもらえるようになったりもします。「今回は一旦こういう実装にしてるけど、次のPull Requestでこの辺は整理する予定です」って書いたときに、「じゃあOK」ってなるのは、過去の実績のおかげだったりします*2。

短期的な効率だけではなく、中長期のメンテナンス性やチーム全体の状態を見ながら動けると、自然とシニアな立ち振る舞いができるようになっていると思います。

地道な活動例: READMEやsetupスクリプトの修正

新しくチームにメンバーが入ってきたとしましょう。そうしたときにその人がつまずいたり、手元でうまく開発環境が整えられない、というケースはたまにあると思います。そういった際にその人をサポートしつつ、つまずいた個所をREADMEに追記 / 修正していったり、うまく動作しなくなっているsetupスクリプトを修正、煩雑だったり間違いやすくなっている手順をMakefileなどのタスクランナーにまとめる、といった活動は地道な活動の一例です。

地道な活動例: アーキテクチャ図を書き起こす / 改善する

新規のプロジェクトに配属された際、全体が分かるアーキテクチャ図がないと苦労することが多いと思います。そういった際はコードやGoogle Cloudなどの設定画面からアーキテクチャ図を自分で書き起こしてみましょう。

必然的にコードを読んだり、動かしたりすることになるでしょう。動かそうとした際に「このバッチを動かした時の影響範囲ってどこになるんだ?気軽に動かして大丈夫なのか?」というのを自信を持っていうためには既存のコードベースや設定を包括的に見る必要が出てきます。そうする中でコードが手に馴染んできますし、こういった活動をやりやすくするために以下のような活動をし始めたら、シニアへの扉に手がかかってきているといってもよいと思います。

  • コードベースからアーキテクチャ図を書き起こす
    • 現状のコードベースとずれている個所があれば、図も修正する
  • Google Cloudの設定画面にしかない設定をTerraformでも設定できるようにterraformにimportする
  • 動作確認がしやすいように、副作用がない(あるいはより限定された)形で切り出す
    • リファクタリングをしたり、testableな形に修正する
  • 安全に動かすためのsandbox環境を立ち上げる

仕組み化でチームや自分を楽にする

日々の生活やオペレーションで面倒な作業ってあると思います。例えばプロダクトのデータベースに対して ALTER TABLE をかけるようなマイグレーションを手元からやる、などです。オペレーション系のスクリプトは開発環境と本番環境*3を間違えるとアウトですし「あれ、これ毎回手でやってるのやばくない？」とか「自動化やればできるけど、正直めんどくさいな…」っていう作業が結構存在する場合があります。

こういったタスクやオペレーションは、少しずつMakefileやスクリプトにまとめたり、自動化したりすることで楽ができるようになります。また、他の人も巻き込めるようになりますし、運用の再現性も上がっていきます。このような仕組み化は、やった直後の達成感はそんなにないかもしれないですが、3ヶ月後とか半年後に「あのときやっといてよかったな…」ってなることがすごく多いので、ちょっと面倒なことを見つけたら積極的にやっていくのがいいと思います。

シニアエンジニアは決まった人しかできないようなオペレーションをチームの誰でもできる 仕組みにしていくのが上手いです。誰でもできるような形に落とし込んでいく仕事は誰でもできるわけではありません。

真似するのは体力がいるが、効果は大きい

他人のPull Requestを一通り眺める / レビューする / 質問する

これは文字通り、自分が関わっているリポジトリのPull Requestを片っぱしから目を通す、ということを意味しています。自分にレビュー依頼がきているわけではないもの、すでにmergeされたものなども含みます。これはかなり大変ですが、効果はとても大きいです。

私がこれをやり始めたきっかけは過去に「この人すごいな」と思っていたエンジニアがこれをやっていたからでした。その人は別に指名されてレビューしていないにも関わらず、どこからともなく現われて「こっちの書き方のほうがいいと思います」「このケースだとどういう振舞いになりますか?」と要所要所でナビゲーション的にさりげなく先導してくれるようなコメントをしていて、それを見て「これ、真似したいな」と思ったのが始まりです。

もちろん最初から全Pull Requestを深くレビューするのは負荷が高く、無理があります。しかし、チームが5〜6人くらいであれば「全部ざっと眺めるだけ」でも十分やれると思っていて、実際にそういうことを私はやっています。Pull Requestに目を通すときは、別に全部にコメントする必要はなくて、「これは流し読みで問題なさそう」と思ったらスルーすればいいです。ただ、どこで何が起きていて、今後どこが詰まりそうかといったポイントが頭に入っている状態を維持するようにしています。

このやり方のよいところはリポジトリの色んなところを(半)強制的に見ないといけない状況になることです。例えば、自分がバッチ処理のコードばかり書いていると、フロントエンドやインフラまわりの変更に気付きにくいことが多いでしょう。しかし、他のチームメンバーのPull Requestを通じて、広い範囲のコードを継続的にレビューしていると、「最近このあたりの構成がちょっとずつ変わってきてるな。このまま進むとちょっとよくないことが起きる気がするな...」といったCode Smellに気付けたり「昔はこの辺の領域のコード全然分からなかったけど、典型的なパターンを見ていたら割と分かってきたぞ」ということが増えてきます。

また、プロジェクトへの新規参画時にもPull Requestを一通り見るのはめちゃくちゃおすすめです。特に「最近チームに入りました」という立場はある意味で一番便利で「すみません、何もわかってないので、教えてください」と何食わぬ顔で質問できます。もちろんチームに配属されてから質問しても何も問題ないわけですが、このときが一番質問しやすいので、他のメンバーのPull Requestもじゃんじゃん見ていって、質問してコードベースを自分のものにする機会として生かしましょう。そういう質問が結果的にチームのナレッジの形式知化につながったり、見落とされていた前提に気づいたりすることもよくありますので、結果的にチームの生産性の向上にも寄与できます。全てのPull Requestに目を通すのは無理でも、一日にプラス一個という具合に見るようにすれば自分の力を上げる機会に繋げられると思います。

プロジェクトを任される経験を自ら取りに行く

ジュニアの方の場合、自分の書いたコードが原因で障害対応などが発生したとしても、対応速度や二次障害の防止などの観点でシニアエンジニアが面倒を見てくれる場合がまだあると思います。しかし、自分が書いた / レビューしたコードの責任を自分で持つ、ひいては「自分がプロジェクトを引っ張る側になる」という経験のあり/なしはジュニアかシニアを分ける分水嶺の一つになると思います。

こういった経験をすると「人が開発した部分かもしれないけど、最終的に壊れたら自分が責任を持つ」というマインドセットが徐々に付いてきますし、そうすると設計のときにも「この機能が壊れたらどこに影響が出るか」や「もし運用中に問題が出たときに対応手順はどうなるか、チーム内だと誰が対応できるか」といったところまで意識が回るようになります。プロジェクトを任されたり引っ張る経験は、EMでもテックリードでもICでもロールは何でもいいです。

ただ、こういった機会は勝手にやってくることはあまりなくて「そういう経験をしたいと思ってます」と周囲に明示的に伝えておくのが大事でしょう。上長との1on1で「プロジェクトの初期フェーズから関わってみたい」「意思決定に関わる立場を経験したい」ということを伝えておくと、そういったフェイズで声をかけてもらえる確率は上がると思います。

もちろん実際にその場に立つと、めちゃくちゃ難しいことも多いです。しかし「以前、趣味プロジェクトで似たような構成を試してたな」や「このやり方は過去に一回痛い目見たことあるからやめとこう」といった経験の中にある引き出しが役立つことは多々あります。そういう意味でも、普段からの意識や準備、経験の積み方で得られるチャンスやその生かし方がぐっと変わってくると思います。

アウトプットを続ける

日々のアウトプット

日々のアウトプットは、確実に自分の血肉になっていると思います。アウトプットと言っても、別にすごい技術記事を書く必要はなくて

  • こういうケースでやろうとして動かなかったけど、こうしたら解決した
  • 設定ファイルのオプションを変えたらビルドが通るようになった
  • CLIツールの使い方が分からなかったけど、教えてもらって便利なオプションを知った

といった小さい話でも全然よいです。自分が「へぇ〜」ってなったこととか、「しばらくはまってたけど、解決したわ」といったことをログに残しておくだけですね。ログは手元でも社内でもWebに公開でもいいですが、なるべく広い場所に公開しているとフィードバックの機会も多いと思います。とはいえ、「公開のハードルが高いから...」となって全く書かないくらいなら手元に書き続けるだけでもいいとは思います。

また、人に相談するときに、自分の思考ログをきちんと残しておくと相談するときにも楽になります。「このときこう思って試したけど、こうなってしまいました」とログを参照しながら話ができるだけで、相談に乗ってくれる人の解像度が一気に上がります。相談のしやすさという面でもアウトプットは効いてきます。

中長期でのアウトプット: 具体と抽象を行き来できる視点を持つ

もう少し長いスパンでのアウトプットとしては「半年に一回は自社のTech Blogや外部イベントで登壇する」という気持ちでいました。アウトプットの例としては

  • 最近取り組んでいた仕事で得た学びを抽象化して整理する
  • 他の人にも役立ちそうな観点でまとめ直す
  • 「なぜ自分はこういう設計を選んだのか」を言語化してみる

といった具合です。

このときに意識していたのは「具体と抽象を行き来できる視点」を持つことでした。日々の小さな気づきはすごく具体であることが多いと思いますが、半年や一年の単位でそれを俯瞰して見たときに「この時期、このタスクをやることであの観点で成長できたのかもしれない」とか「これは別プロジェクトでも使える考え方かもしれない」など、そういう自分の中の頭の整理や引き出しにできることが多いです。だからこそ、小さなアウトプットを日々積み上げつつ、定期的に大きめの視点でまとめる。それが他のプロジェクトに移ったときの早期キャッチアップや、自分の思考の軸を鍛えることにつながるのではないかと思っています。

参考書籍

*1:かかる資金というよりジュニアの時代の時間をどれだけ技術に投資できるか、のほうが判断すべきポイントとしては大きいと思う

*2:信頼貯金の切り崩しではあるので、ちゃんと整理もやるようにしましょう

*3:そもそも本番環境を手元から更新できるようにするな、という話はもちろんある



以上の内容はhttps://www.yasuhisay.info/entry/2025/03/31/230212より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14