More than 1 year has passed since last update.

LITALICOAdvent Calendar 2022

新卒１年目エンジニアが爆速自走するべく３つの問題に奮闘した話

Last updated at 2022-12-02Posted at 2022-12-02

LITALICO Advent Calendar 2022 2日目の記事です

はじめまして。今年4月に入社した寒がりエンジニアの@powsatoです。

ちょうど一年前は、入社の待ち遠しさが有り余って2016年からのアドベントカレンダーを片っ端から読み漁っていました。大半の記事は全然理解できなかったのですが、今読み返すと「お〜、この話題だったのか〜」と思えるようになっていて、感無量です
また、「この記事を執筆された方はこの方だったんだ〜」という素敵な出会いもありました！今日はついに投稿者として一緒にアドベントカレンダーを盛り上げられること、とても嬉しく思います

この記事に書いてあること

さて、前置きが長くなってしまいましたが、この記事ではチームに配属されてからの７ヶ月間で
個人的に大変だったことと、解決する上での気づきを紹介したいと思います。
とはいっても世の中には体系的にtipsを解説した素敵な記事がたくさんあり大変お世話になったので、それらを紹介しつつ、気づきや実践していることを追記していくスタイルとします。
自分と同様に、ソフトウェアエンジニアとしての第一歩を踏み出す人たちの役に立てれば嬉しいです

ここに書いたことが必ずしもすべての新人エンジニア・そのひとを取り巻く環境で有利にはたらくとは限りません

【前提】配属時の筆者の状況

大学時代、研究でのプログラミング経験あり
チーム開発やwebアプリの開発経験はほぼ初めて
新卒研修は一ヶ月。配属後にチームで使う言語に特化した知識はOJTをしながら学んでいきました。

１. レビューに時間がかかりすぎる

コードを読むのに時間がかかる
同じ量の差分でも、他の人が書いたコードは何回読んでも頭に入らない
変更された部分の影響範囲を完全に理解するには一日かかってしまいそう

これらは、同期や後輩など複数人から共感のあった課題でした

まず、最終的に目指すレビューの役割やクオリティー、観点に関しては、次の記事を参考にさせていただきました。

また、そもそもコードを読むこと自体のしんどさは、弊社の先輩 @KakkiiiiKygさんの記事を参考に解消を試みました。

新卒1年目プログラミング未経験者が配属１ヶ月で困ったこととその対処法

特に「このコードって何に使われているんだろう？」と思ったとき、過去のプルリク単位でコードを読むというのはとても有効でした。GitLensというVSCodeの拡張機能を使うのがおすすめです

それでは、他に試したことを書いていきます。

ツールでできる工夫はどんどん試す

ブラウザのgithub上で差分を眺めるだけでなく、ローカルにブランチを持ってきて自分のIDEで見る＆ローカル環境で動かしてみる と、格段に理解しやすくなりました。

IDEで見る
どちらも実質的には同じコードを見るので、効果あるの？と思ってしまいますが、人間の認知機能って、本当に小さな工夫で助けられるものだなと感激しました
IDEに入れている文字のハイライトやインデントの色分けなどの拡張機能が適用されるだけで、何倍も差分が読みやすくなりました。また、差分に含まれてないコードも同時に見られることや、コードジャンプ機能が使えることも大きなメリットです。
ローカル環境で動かしてみる
今思えば当たり前のことなのですが、フロントエンドでもバックエンドでも、プルリクの差分によって実際にプロダクトを使うときのどの行動に差分が出るのか、どんな挙動をするべき部分なのか が理解できていることが大前提です。
どうしても差分のコードを見ることに焦りがちですが、まずは、今回変更する機能がユーザストーリーの中のどこで登場するものなのかを実際に触って確認してみるのが近道だと思いました。

レビューLIVEをやってみた

うまくレビューできている自信がないことをチームで相談したところ、先輩エンジニアや自分がレビューをしている様子をリアルタイムでわいわいと見る レビューLIVE を実施していただけることになりました。（※おそらく我々のチームでしか通じないであろう造語です笑）
一人レビューをする人を決めておき、画面を共有しながら適当なプルリクのレビューをしてもらいます。考えていることはできるだけ口に出していく、モブプロのようなスタイルです。オーディエンスは、ガヤガヤと質問やコメントをして、気づきをまとめていきました。

これによって、

レビューの流れ、観点
githubの機能やIDEの拡張機能をどんなときに・どうやって使いこなすか

などが実例を見ながら学べました。

他の人がいつもどんなことを考えてレビューをしているのかを知ることで、レビュイーとしても今後「ここは普段のレビューではしっかり見ないかもしれないから、念入りに見てもらうようにプルリク本文に書いておこう」などの配慮がしやすくなる効果もあります。
また副次的に、先輩エンジニアの方も「こういうとき、いいツールがあったらいいのにね」という共通の悩みが共有できた、というメリットもありました。

レビューの仕方に悩んでいる新人エンジニアの方は、一度先輩エンジニアのレビューを覗かせてもらったり、自分のレビューの仕方を見てもらったりすると新しい発見があると思います

２. プルリクを出してからの手戻りが多く、リリースが想定外に遅れてしまう

「実装終わった！Ready for reviewポチッ！！」
「明日にはマージできるな〜」
と思っていたはずが…

実装中に考慮しきれていなかったことが多くたくさんのご指摘をいただき、議論をするうちにコメントは80件に

修正対応も嵩み、実装＆検証をし直すとマージまで一週間かかってしまった、という悲しい体験をしましたorz

同様の困りを語った記事、新卒がプルリクで100コメント貰って学んだことにもあるように、まずはプルリクの作り方に改善の余地がないか見直してみました。
プルリクの書き方やセルフレビューについては弊社の過去のアドベントカレンダー記事でもある

が非常に役立ちました

他にも、やったことを紹介します。

最初からプルリクを分けてしまう

タスクが分割できるならば、プルリクも分割した方が、自分にとってもレビュワーにとってもメリットが大きいです。また、先に出したプルリクの修正対応やレビュー待ちをしながら次のプルリクを作成できるので、隙間時間を有効活用できます

最初のうちは「分けるって、どうやって？」と思うことも多かったですが、慣れてくるとできるようになってきます。方針の例としては、こういうのがあります。

同じような変更を複数箇所にするならば、先に一箇所分だけプルリクを出して方針そのものに問題がないかみてもらう
フロントエンドとバックエンドにまたがる変更ならば、それぞれに分けてプルリクを出す

ただし、レビュワーにとって作業の全貌が把握しにくくなるデメリットもあるため、プルリク本文にしっかりと全体像＆そのうちこのプルリクはどの部分なのかを書くようにしています。

修正対応を別プルリクにする

（前提として、筆者の所属チームは機能が完成するごとにリリースを行なう開発スタイルです。）

プルリクのコメント件数が膨大になっていくと単純に追いづらいですし、何度も実装変更＆検証を繰り返すうちに漏れが出てくるリスクもあります。
リリースが遅れると、効果が出るのも遅くなってしまいますし、プルリク作成者の心理上の問題として、検証が雑になってしまったり、議論を煩わしく思ってしまったりするリスクが高くなる恐れがあります。

これらを解決できる手段として、レビュワーからの指摘が機能自体の問題を指摘するものではない場合は一旦リリースをしてしまい、あとでゆっくりリファクタリングをするという流れもアリだと学びました。

ただし、後回しにしてタスク自体忘れ去られてしまうことがないように、即別プルリクを立てるなりTODOコメントをつけるなりしています

３. 困っているが、適切な質問文に落とし込めない

自走できるエンジニアを目指すため、基本的には下の記事のような質問フォーマットを意識していました。
新卒1年目に使ったエンジニア質問テンプレート

このフォーマットが埋められるに越したことはないのですが、埋められないケースに遭遇したときに、
「調べ足りていない気がするけど、どう調べたらいいのかもうわからない。手詰まってるし、、訊いていいのだろうか？」
「0から100まで説明してもらいたいわけではないんだけど、なんて訊いたらいいんだろう」
など、次から次へと悩みが浮かんでしまうことがありました。

しかし、何度も「わからない」を解消する経験を積んでいくうちに、自分がどんな「わからない」で詰まりやすいのかがわかってきました。

自力で調べる気はあるが、検索ワードがわからない

調べものをして先述の質問テンプレートの形に落とし込むためには

やるべきことがわかる
わからないことの関連キーワードがわかる
検索する
検索結果を吟味する
試すに値する情報があれば手を動かす

のステップを最低でも一回は通して体験する必要があると思うのですが、初学者だとそこまで辿り着けないことも往々にしてあります
自分が困ってしまうときには、そもそも1や2に自信が持てていないことが多かったです。この状況で調べ物をしようとしても正しい情報に辿り着ける打率は非常に低いので、時間を使いすぎずに質問すべきシチュエーションだと思いました。

「わからない」と思っていることの所属する分野、関連キーワードがわからない

私は何に使われているのかわからない謎のファイルを見つけて、このような状況に陥りました。
ファイル名をググっても引っかからないし、ファイルの中身にも特に検索に使えそうなことは書かれていませんでした。

こんなときはどうしようもないのですが、それでも漠然と「xxってなんですか？」と訊くより、「xxが何なのかわからなくて調べたいので、キーワードを教えてください」 と訊く方が、求めている答えを得やすいなと思いました。

やりたいことを実現する方法を調べるためのキーワードがわからない

このケースでは頑張ってググったり、リファレンスを隅から隅まで読めば欲しい情報が見つかるかもしれないですが、かなり時間がかかる可能性も高いです。ある程度調べて方向性に不安があったら、のセクションのようにキーワードとして質問してみるのがいいと思いました。

質問力を上げるために

ここに挙げた他にも質問の仕方に困るケースはたくさんあると思います。
「何がわからないのかわからなかった」ことが「わかった」とき、その経験はとても貴重なものです。
困り自体はそこで解決しますが、解決に至るまでのプロセスの振り返りをすると気づきが得られます。

例えば、

自分が質問しづらさを感じたボトルネックは結局なんだったのか（→困りの本質はなんだったのか→似たような困りが発生したときに効率よく対処するヒントになる）
教えてくれた情報のなかで特にありがたかったのは何か（→次はそれを訊きにいけばいい）
自分がどんな質問を投げ掛ければ欲しかった情報に素早く辿り着けたんだろう？（→次はその言い回しを使えばいい）
どのタイミングで聞くのがベストだったかな？（→次に困ったら、自分がそのタイミングにあるか判断すればいい）

などの観点で振り返りをすると、のちに使える質問フォーマットの手札が増やせるかもしれないです。
なんだかたくさん書いてしまいましたが、もちろんカジュアルに質問することが最善であるケースもあるので、状況によって使い分けられるといいと思います

考えていることを開示する

質問文でも、それ以外のコミュニケーションでも、自分がやろうとしていることをできるだけ開示しておくことで、「これ調べてみるといいよ」というアドバイスをもらいやすくなると思っています

知識の少ない人間には、自覚できていないが身につけるべき知識 がたくさんあります。質問に昇華できるのは基本的に 自覚できた身につけるべき知識(＋α) なので、自覚できていないことを自覚するためのきっかけが必要です。（なんかややこしいですね）

Issueコメントに実装方針を垂れ流したり、日次のミーティングで細かめに状況を共有したりして、できるだけ自分が考えていることを開示することで、知識の多い人間から見た時に、「あれがわかってなさそう」と気づいて指摘してもらえるチャンスを有効活用することを心掛けています（チームのみなさんいつもありがとうございます）