Mobile Factory Tech Blog

技術好きな方へ!モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします!

新卒エンジニアが技術研修で学んだこと・気付いたこと

はじめまして。22卒エンジニアの id:kebhr です。

モバイルファクトリーでは、現場で使用されている技術を学ぶ技術研修がおよそ1ヶ月にわたって行われます。私は学生時代から趣味やアルバイト・業務委託の仕事でコードを書いてきましたが、技術研修を通して新たな学びや気付きを得ることができました。

ということで、この記事では、そんな学びや気付きを紹介していきます。

公式ドキュメントは大切

技術研修では、さまざまな言語やライブラリ・ツールの公式ドキュメントを網羅的に読みました。これらの中には、学生時代から既に使っているものもありました。 「ある程度使えているし読まなくても使えるじゃん」と考えがちですが、実際に読んでみると、どの公式ドキュメントにもかならず知らないことが書かれていました

振り返ってみると学生の間は、公式ドキュメントとは「問題が起こったら、ググって見つけた部分を読んで、解決させる」ためのものでした。ですので問題が起こらなければ読むことはありませんでした。

学び・気付き

しかし、公式ドキュメントには、その言語やライブラリ・ツールを使う上で「知らなくてもいいけど知っているともっといい」という情報が掲載されています。

1つ例を挙げてみましょう。Vue.js で親コンポーネントから孫コンポーネントにデータを渡すとき、これまでは props を使ったバケツリレーで実装していました。

公式ドキュメントを読むことで初めて、子孫コンポーネントに直接データを渡せる Provide / Inject*1 が提供されていることを知りました。

公式ドキュメントを読んだことによって「既に知っている方法ではない、別の方法が存在する」ことに気付けました。公式ドキュメントを読み複数の方法を知っておくことで、状況に応じてよりよい方法を比較・検討・選択することができるため、これからは積極的に読んでいきたいです。

実際に手を動かすのは大切

公式ドキュメントを読むことは大切です。読むことで「こんなやり方があったのか!」という気付きが得られます。私はここで「完全に理解した」という気持ちになりました。

しかしこれは、完全に勘違いです。公式ドキュメントを読んで「こう書けばこう動く」ということを知ったからといって、コードが書けるようになるわけではありません。これは「コードの写経をする」「コードの流れを追いかける」といったことがらにも当てはまります。

学び・気付き

技術研修では、Perl の基礎*2から Web アプリケーションのアーキテクチャまで、具体から抽象を幅広く学びます。また、実際の開発においても、抽象度の異なるものごとについて同時に考える必要があります。

ところが「公式ドキュメントを読む」「コードを写経する」「コードを追う」という、手を動かさずに得られる知識は具体に寄りがちです。その結果、本質に近い抽象的な学びが不足しました。

しかし、自らコードを書き手を動かしたことで、具体的な学びを抽象的な学びに昇華することができました。

具体例を挙げてみましょう。技術研修中に扱ったサンプルアプリは CQRS パターンで実装されていました。これは、データの挿入/更新/削除といった状態の更新を伴う Command と、データを読み取る Query を別々に実装するデザインパターンです。

サンプルアプリを触っている時点では CQRS パターンを「参照とそれ以外で分けるもの」と認識していました。このときは CommandQuery という文字列を見ても「これは更新系、これは参照系だね」と感じるだけでした。しかし、実際に自分の手で CQRS パターンを用いてコードを書いてみると「副作用が一定の範囲に留まるので嬉しいデザインパターンだね」という抽象的な学びを得ることができました。

脳内を整理するのは大切

人間の脳内のリソースは有限です。だからこそ、脳内に置いておく必要のない情報は外に逃がし、脳内を整理した状態にしておくことが大切です。

開発中に覚えておかなければならないことは多いです。「実装が完了するまでには、あと何をすればいいんだっけ?」とか「このパッケージには何を書くんだっけ?」とか「このメソッドはどこから呼ばれているんだっけ?」とか。慣れていれば覚えておくまでもないことでも、慣れるまではこうしたことが脳内の有限なリソースを圧迫します。 その結果、真に集中しなければならないロジックの実装に回せる余裕が削られて、効率が落ちてしまいます。

技術研修のときのエピソードを振り返ります。技術研修では、最後の3日間を使って Web サービス開発研修を行います。これまで学んだ技術スタック*3を使って、与えられた要件を満たす Web サービスを開発する研修です。バックエンドは Perl を使い CQRS パターンを使って実装していきます。

私は限られた時間の中で進捗を出すために、初日は研修中に作成したサンプルアプリのコードをコピペして時短を図ろうとしました。変更すべき箇所や進捗、サンプルアプリのアーキテクチャは脳内に保持していました。

しかし、結果として、既にコピペが完了した部分とコピペが完了していない部分、変数名やメソッド名を変更した部分としていない部分が混在し、いくら直しても動かないコードが生まれました。

学び・気付き

これではまずいことがわかったので、次の日はサンプルアプリのアーキテクチャを読み解くことに時間を使いました。パッケージを列挙し、それぞれのパッケージの目的とそのパッケージを変更する理由を整理していきます。

続いて、要件を満たすために必要な機能ごとに*4、変更が必要なパッケージを列挙しました。実装が完了するたびにチェックを付けていき、すべてにチェックが付けば実装が完了している状態に持ち込みました。

このようにして、アーキテクチャと進捗を脳内で保持せず文章化したことにより、その後の開発効率は高まりました。最終的には、実質2日間で要件を満たした上にいくつかの追加機能を実装することができました。

わからないを共有すると良い

技術研修の中ではたくさんの問題に直面しました。問題を解決するためにいろいろ考えてみるわけですが「どうしてもわからないことはわからない」という場合もありました。そういう時に、1人でずっと抱え込むより、周りにここがわからない!とわからないことを共有していったほうが、結果的に早く正確な答えを得られることが多かったです。

学び・気付き

問題を人に伝えるためには、「こういう目的のために、こういう手段を取っていて、ここまでできていて、ここができていない」ということを整理する必要があります。その過程で「目的がそもそもズレてないか?」「よりよい手段があるのではないか?」「こうすればできるんじゃないか?」という、問題を自己解決するための気付きを得られることがありました。

もし気付きが得られなくても、第三者から見るとすごく簡単なことが原因だったり、勘違いが原因だったり、あるいは環境依存の問題だということを知ることができました。

それでも解決できない場合は、Google Meet*5 で画面共有し共同で原因の究明をしてみました。話しながらコードを読んでいくと、1人でコードを読んでいたときには気付かなかったことに気付くことができました。

わからないことを共有すると、こうして問題解決することができます。その中で得た気付きを残しておけば、次回同じ状況に出会ったときに1人で解決できるようになります。

ちなみに技術研修では、新卒同期は Google Meet で常に繋がっている状態*6で、その日の作業スレにその日のことをなんでも書けるようになっていました。作業スレに書くなり、Google Meet でおもむろに喋り出すなりして、聞きたいことは聞くことができます。

一般的な学び・気付きを書いたワケ

ここまで「技術研修で学んだこと・気付いたこと」をいくつか挙げてきました。あえてこの中に技術的な学び・気付きは書きませんでした。

なぜならば、技術的な学び・気付きも重要ですが、技術研修から得た学びや気付きを一般化して、自分の行動に生かしていくことがより重要だと感じたからです。一般化された学びや気付きに基づいて、自ら行動を起こすことでより高い成果を上げられたからです。

現場での開発に入るようになり1ヶ月半が経ちましたが、今も一般的な学び・気付きを大切にして日々業務に当たっています。

*1:https://v3.ja.vuejs.org/guide/component-provide-inject.html

*2:研修内容についてはこちら: https://tech.mobilefactory.jp/entry/2022/06/30/200000

*3:バックエンドは Perl, MySQL, Amon2。フロントエンドは Vue.js 3, JavaScript / TypeScript, Vuex。

*4:具体的には API のエンドポイントごとに列挙しました。

*5:ビデオ会議ツール

*6:実際には、カメラ・マイクは用がなければミュートしていました。