はじめに

久しぶりにQiitaを書きます(すごく書きやすいUIになってて感動しています😊)。4月から新卒Webエンジニアとして都内の企業で社会人生活をスタートしました。最初は実務未経験の状態で内定者インターンから入り、HTTPってなんだ？の状態からスタートしました。

そんな私ですが最近運用プロダクトの新規API実装タスクをある程度一人でも終えられるようになりました。入社してから3ヶ月くらいです(10月から内定者インターンで今のチームに所属していますが、学業との兼ね合いで週2稼働であったことと、間に研究発表や研修が挟まっていたので、実質5月からチームのタスクを本格的に取り組み始めたような感じです)。

今回はそこに至るまでの過程で重要視したことを書きたいと思います。それは、体系的な理解をなるべく早く持つことです。詳細は後述しますが、これからエンジニアになる方に向けて、自身の将来を重ねてイメージを持ってもらえるようお役に立てれば幸いです。特に実務未経験者が運用プロダクトに溶け込む過程で感じたこと、やったこと、工夫したことを書いていきます(私個人の日記という側面もありますので、ご了承ください🙏)

入社当時感じたこと

素直に、周りレベル高すぎないか？という焦りを覚えました。元々のプログラミング経験としては、プログラミングスクールでRailsのポートフォリオ制作を支援することをやっていたのですが、実務は別世界でした。中学数学と大学数学くらい差があるイメージです。初めは小さなタスクを与えられますが、それと同時に体系的にエンジニアとして必要な知識をインプットする重要性を感じていました。日頃飛び交う会話の前提が頭の中に入っておらず、全く戦力になっていなかったのです。特に幅広い知識が要求される運用プロダクトの場合なおさらでした。そこで体系的な基礎知識を頭の中に入れることで以下のようなメリットを享受できると考え、これを優先度高く取り組みました。頭の中に地図ができることで、

日頃の会話の理解がだんだんできるようになる
問題解決のヒントに出会う確率が上がる
新たな知識も脳内ネットワークに組み込まれるので長期記憶に入ってくる

これらにより、日常の成長サイクルをより加速させることができ、より早く業務に貢献できる人材になれるのでは？という仮説です。よく、タスクをこなしていればその内分かるようになってくるという話があります。確かにタスクとその周辺知識を点としてどんどん増やしていくことで理解の網羅性は少しずつ上がっていきます。一方、あらかじめ体系的な知識を持つことで日常的により多くの概念に気づけるようになり、さらに有機的な理解ができるので新たな概念も覚えられるようになってきます。その結果、普段の業務をより密度高くすることができ、成長サイクルの良い循環に早く乗れるのでは？というイメージです。一度波に乗ってしまえば、あとは流れに身を任せるだけで遠くに行けますね。

あくまで体系的なインプット活動だけやっていれば良いという訳ではなく、タスクなどのアウトプットとの両輪で持ちつ持たれつなんだと思います。勿論タスクは仕事としてやらねばならないものです。とはいえ、インプット活動によってタスクに取り組む時の景色がどんどん変わっていく感覚があることも確かに感じているところです。

また、開発プロダクトなのか、運用プロダクトなのか、先に一つの分野を極めたいのかなど、色々な状況によって取るべきアプローチが変わってくるような気もします。私は運用プロダクトなので、割と全体像を把握しないとやるべきことが分からないという要求が背景にあったのかもしれません。

どのようにインプットしたか

エンジニアとしての基礎知識と業務の中で理解が必要と感じた技術要素、この2つを軸にオリジナルの勉強用バックログを作りました。つまり、勉強要素を書き溜めておき、優先順位をつけるということです。普段の業務を通して、もっとここを深掘りたいと思っても、次の仕事があるのですぐに取りかかれないことがよくあります。そのような時に、勉強用バックログに一旦溜めておいて、時間を見つけて機械的に上から勉強していく習慣を持ちます。

そのためのタスク管理にはNotionを用いています。下記画像のように、本、ネット記事、動画、様々な媒体から勉強したいことを選んでいます。例えばgRPCは携わっているプロダクトで使われている技術要素です。他には、Web技術、コーディング、Docker、ネットワーク、SQLなど、エンジニアとしての基礎知識を体系的に網羅することを意識しました。

ある技術要素について勉強したいと思った時、世の中には多くの本や記事や動画が溢れていますが、基本的には評判の良いものを選ぶようにしています。検索すると、鉄板とされる書物や記事に当たると思うのでそういうものを選ぶとより効率的に勉強が捗るはずです。

また個人的によくする動きとしては、初心者向けの何か→公式docという順番で一度目を通しておくと、その技術要素に対する解像度がグッと増す感覚があります。

最初のうちはぼんやり頭の中に地図を作るだけで十分だと思います。内容をちゃんと理解することよりも、普段の気づきを増やすことで業務の密度を上げて、成長サイクルを加速させることが目的です。新たな視点に気づけるようになるだけで、さらにそれについて調べたり復習できるので、どんどん知識が増えるスピードも上がっていく感覚が確かにあります。勉強したものは記録して残すようにし、いつでも復習できる体制を作っています。

勉強用バックログ公開用

いつ勉強するのか

業務中の隙間時間やプライベートで暇な時間は基本的に上記の勉強用バックログを進める時間にあてました。バックログがあることで何を勉強すれば良いか分からないという悩みから解放されます。あとは機械的に進めるだけです。

こればっかりはかけた時間がものを言う世界だと思います。業務中では、何らかの返信待ち、PCの処理待ちのような隙間時間をタスクの周辺知識をインプットする時間にあてています。新たなタスクをやるほどでもない微妙な隙間時間はそこそこあるので、手持ち無沙汰にしないようにできます。業務時間外は移動中の電車や寝る前の時間を有効活用します。幸い、勤務時間的に電車のラッシュを避けられるので座りながらスマホを有意義に使えています(技術本は重いので本は家で、ネット記事や動画は電車内で見ることが多いです)。将来への投資だと思って、無駄な時間をなるべく過ごさないように意識しています。

結局のところ、元も子もない話ですが3日坊主にならずに上記を続けられる原動力は知的好奇心なんだと思います。私個人としては、新たなことを知って、それが有機的に繋がったり普段に生かしたりする営みが好きで、全く飽きないでいられます。

その他工夫したこと

細かいですが、その他工夫したことを列挙しました。

一旦動くところまでやり切ってから内容理解する
運用プロダクトの場合、既存のコードの設計や細かい文法を参考に新規API実装や改修を行うことが多いです。そのような時に一つずつ立ち止まっていては仕事が進まないので、とりあえず動くところまで持っていきます。そして後からどういう意味なんだろうということを時間の許す限り、腑に落ちるまで理解に努めていきます。そうすることで理解のみに頭のリソースを使えるので、効率的に学びを得られます。

ChatGPTはそのような文脈で大いに役に立ちます。とりあえず質問を投げておき、回答が返ってくるまでの待ち時間は他のことしつつ、ひと段落したら回答を確認するような使い方をよくします。

下記のrpsecのコードに関して、rspecの基本文法を中心に丁寧に解説してください。contextの詳細は軽くで大丈夫です

<rspecのコード...>

そもそもChatGPTの回答は非常に優秀なので、新人エンジニアにとって使わない手は無いと思います。従来のコードリーディングのイメージは、各メソッドや書き方を都度調べて短期記憶にストックしながら次のコードの意味を調べていくといったような認知負荷の高いものだったと思います。ChatGPTは一目で分かるように各コードの解説を書いてくれるので、非常に初期のコードリーディングが捗ります。

思考のプロセスを聞く
普段先輩の仕事を見ていても、結果だけしか見えないことがよくあります。そのままにしておくと知識が属人化してしまうので組織としても勿体ないです。そこで、どのような思考の流れで問題解決をしたのだろうという過程を積極的に聞くようにしています。これにより、先輩と自分の間で、どの分野の前提知識に乖離があるのかを明らかにすることができます。

勿論方法論や仕事の進め方みたいな話もありますが、問題解決できるかどうかは体感8~9割は知識の差によるものな気がしています(個人の感想です)。問題解決の差を経験や勘、センスといった言葉で誤魔化さず、積極的に言語化します。そしてどの前提知識に差があるのかを挙げていき、勉強用バックログに追加していきます。

日報に学んだことを言語化して書く
新卒エンジニアとして日報を毎日書いています。そこに、普段学んだことを言語化し、参考記事を中に貼って整理しておきます。一度言語化することだけでも理解が深まりますが、人間は基本的に忘れてしまう生き物であるという前提に経って意図的に復習の機会を設けています。

日報を作成するときは、前日書いた日報をコピーして新しい記事を作ります。その際に、前日学んだことをもう一度頭の中で反芻します。その僅かな時間を積み重ねることでより長期記憶に入るのではないかという期待を込めています。学生時代は一度取ったノートを繰り返し読み込むのが当たり前だったことを思い出します。

効率的な教え合いの機会を有効活用する
エンジニアは各人毎日何時間も特定の分野を深める作業をしています。全貌とまでは行かなくても、そこから抽出されたエッセンスを聞いたり話したりする機会は多いです。例えばスクラムイベントであったり、直接話す機会であったり、1on1です。その際、気づいたことやもっと深掘りたいことをいつものノリで何かしらのメモに書いておきます。その中からすぐインプットできそうなものはその場や直後で確認し、腰を据えて学びたいと思ったものは勉強用バックログに追加するといった具合です。効率的にお互いに教え合う機会は相当貴重なので、それらを自分の糧として有効活用しないわけにはいきません。

外部に情報アンテナを貼る
Twitterやイベントで外のエンジニアの意見に日常的に触れる機会を持ちます。シンプルに有益な情報を出会えるメリットが大きいです。また、その習慣化によって色々な人の知識や言葉を積み重ねていくことができます。人間が物事を理解するための材料(=比較や類推など)を増強していくイメージです。

まとめ

新人エンジニアにとって体系的な知識を持つということというテーマで記事を書きました。勿論これは一つの考え方に過ぎないものです。例えば、目の前のタスクに全振りするアプローチを取る人もいます。結局のところ色々なやり方を模索して、しっくり来て納得感があるか、モチベーションを継続できるかを重視した方が良いと思います。学生時代、勉強といえば、問題集から入る人もいれば、教科書から入る人もいたように人それぞれだと思います。

ただ、こちらの記事を通してこれからエンジニアになる人たちに僅かでもヒントになれれば作者冥利に尽きます。私自身、体系的な知識を早いうちに持っておくことは一つの仮説として個人的にしっくり来ており、モチベーションも継続できています。今後もこのアプローチを続けて様子を見ていきたいと思っている次第です。