見出し画像
Photo by golchiki

未経験からエンジニアになった人が入社前と入社後にやってよかったこと

壮｜Masato Tanaka

こんにちは。壮（@sew_sou19）と申します。

僕は2020年11月に、未経験からメガベンチャー企業にエンジニアとして転職しました。

そもそもエンジニア自体未経験からの挑戦で右も左も分からない状態なのに、メガベンチャーということもあって「付いていけるのか」「エンジニアとしてやっていけるのか」と最初は不安しかありませんでした。

同時に、フルリモートでオフィスに出社しないこともあって、実際かなり苦労しました。

ただ、自分なりに考え試行錯誤して働いた結果、概ね良好な評価を頂けて入社5ヶ月間でランクを3つ上げることができました。

また、その2ヶ月後には任せてもらえる業務や領域が広がり、さらには自分がこの会社でどういう働き方をしていきたいのかも見えてきました。

そんな折にふと「あれ、最初不安大きかったけど今思ってみれば比較的いい感じにエンジニアとしてのキャリア築けてるな」と思えるようになりました。

そこで、僕が入社する前と入社してから何を考えどういう行動をしたら、エンジニアのキャリアを順調にスタートさせられ、さらには評価をもらえたのかを振り返って言語化してみようと思いnoteにまとめました。

少しでも参考になれば幸いです。

入社までにやっておいてよかったこと

これを読んでくださっている多くの方は認識されていると思いますが、内定を取ってエンジニアになることがゴールではないと思います。エンジニアとして一人前になり、さらには現場で活躍することで自分が叶えたい理想や将来に近付くと思います。

一方で、未経験からエンジニアになる方のほとんどが、入社後「エンジニアとしてついていけるか・やっていけるか」という不安を抱えているかと思います。

実際僕もそうでしたが、今ではなんとかやっていけています。

入社前に（ちょっとでも）やっておいてよかったことを技術面・意識面の二軸から紹介します。

■技術面（入社前）

入社前に学んでおいてよかった技術は以下の通りです。数字は優先順位です。

1. Git / GitHub
2. Web技術の基礎知識
3. SQL（バックエンド寄り）
4. Linux
5. Docker
6. セキュリティ

言語学習の優先度は低いと思ってます。
リストには載せてないですし、僕は入社前に現場で使用する言語の学習は行いませんでした。

理由はいくつかありますが、「現場に入って実際のコードを読み解いたほうがキャッチアップが早い」「基礎的な概念さえ押さえておけば最低限は大丈夫なので上記の学習に充てた方が実務で困らない」「（僕の会社は）独自フレームワークを使用していた」などです。

現場で新しい言語を使用する場合は、SQLを学んだ後くらいにProgate＋代表的な書籍でさらっと基礎だけ押さえれば問題ないと思います。

また、あえて「入社前に」と繰り返しているのには理由があります。

僕自身実感しましたが、実務に入ると環境に慣れることや目の前のタスクを消化することに手一杯になって、自分の勉強時間はほとんど取れなくなります。なので入社前の今のうちに学べることは学んでおいた方が後々自分を助けることになりますし、実際なりました。

1. Git / GitHub

Git / GitHubは必須です。マストです。欠かせません。

新人がチームにジョインしてから一番迷惑をかける温床になるのがGit周りです（マージの向き先を間違えた、rebaseすべきなのにmergeした、resetとrevertを間違えたetc...）。

実務では、ポートフォリオを作成していた時には知り得なかったコマンドやブランチの切り方を行います。それゆえ基礎が分かっていないと混乱したり、勘違いして先ほど挙げたようなミスを犯し、結果チームメンバーに迷惑をかける、というのがあるあるですし僕も何回もやらかしました。

それを防ぐためにはGitへの基礎的な理解が必要です。
おすすめは以下のUdemyの講座です。

Udemy『もう怖くないGit！チーム開発で必要なGitを完全マスター』
Udemy『米国AI開発者がやさしく教えるGit入門講座』

いずれの講座もかなり基礎的なことから網羅的に解説してくださっているので、自分が理解できている部分は飛ばしつつ、知らない部分を埋めていく感じで流し見するのがおすすめです。

もちろん、Gitに不安がある方はしっかり見ておいた方がよさそうです。

2. Web技術の基礎知識

これも必須です。下手したら（しなくても）Gitより大事です。

あえて2番目に置いたのはFWを使用する企業ならそこまで意識せずとも開発ができてしまうからです。ただ、それでも知っていると知らないとでは現場に入ってからの苦労の度合いが天国と地獄くらい違うのを身をもって体感したので、ここの知識は身につけておくのが無難です。

「Cookieとは何か？」「セッションとは何か？」「ステータスコードとは何か？」「ステートレスとは何か？」「HTTPはどのような通信規格か？」など、概念的なことが多く僕も最初は不安でしたが、以下の書籍をある程度理解して現場に入ったらそこまで苦労しませんでした。

書籍『この一冊で全部わかるWeb技術の基本』
書籍『プロになるためのWeb技術入門』【+α】
書籍『Webを支える技術』【+αα】

僕は3冊とも読みましたが、正直『この一冊で全部わかるWeb技術の基本』だけで十分です。笑

『Webを支える技術』の後半部分は現場で使わないことが多いので、読まなくて大丈夫です（なので+αとか付けてます）。

3. SQL（バックエンド寄り）

3番目はSQLです。

フロントエンドを担当する方はDBを操作することはほとんどないと思うので飛ばしてしまって大丈夫かと思います。ただ、スタートアップなどだとバックとフロントの垣根が明確に分かれていないこともあるので、最低限の知識は持っておいた方がいいです。

INSERT、UPDATE、DELETE、SELECT、JOIN、WHERE、GROUP BY、ORDER BYくらい

FWのみ使用してきた場合は、SQLを特に意識したことはないと思いますが現場ではほぼ必須です。「こういうデータ抽出して」は日常茶飯事ですし、アプリとDBとの噛み合わせを考える上でSQLの知識がないとどうにもならないこともあります。

僕の場合はアプリケーションとは別に、ストアドと呼ばれるクエリ実行文のみを書くことが結構あります。最低限の研修はあったものの、SQLの基礎を教えてくれるというよりは「じゃあこういうデータを抽出してみよう」みたいに最低限の知識はあることが前提だったりするので、入社前に学んでおいて本当に良かったと思います。

僕が学習で使用した書籍はこちらです。

書籍『SQL 第2版 ゼロからはじめるデータベース操作』
書籍『達人に学ぶSQL徹底指南書』【+α】

SQLは、技術書をただ読むだけだとなかなか頭に入ってこないのでハンズオン形式で学ぶのがおすすめです。

Progateでもいいですが、それより「こういうデータを取ってみよう」「こういう場合はどうなるんだ？」のように自分で考えながらクエリを書くことで身に付くのを実感しました。

4. Linux

こちらはフロント・バック関わらず優先度高いです。

ほとんどの方はUNIX系の環境（Mac）で開発をすると思うので、Linuxのコマンドなどを最低限理解して使用する必要があります。Windows環境での開発の場合は、GUIツール多用したりなどでCLIはあまり使用しないので優先度下げてもよさそうです。

深くまで理解しなくてもよく、ひとまずさらっと読んでおくだけでも現場に入ってからの馴染み方が変わってくると思います。

書籍『新しいLinuxの教科書』


5. Docker

現場ですでにDockerを使用している場合は必須です。

入社していきなりDockerfileを書くことはありませんが、プルしてきてイメージをビルドしたりコンテナを立ち上げたりするなど、開発環境を構築して実際に開発を行えるくらいの最低限の知識は必要です。

また、現時点ではDockerを使用してない現場だったとしても、いずれ使うことになったり、プロジェクトやプロダクトによってはDockerを使う可能性は大いにあるので、学んでおいて損はないです。

繰り返しになりますが、実務に入ると環境に慣れることや目の前のタスクを消化することに手一杯になって、自分の勉強時間はほとんど取れなくなります。入社までの時間的にも精神的にも余裕があるときに学習しておくのをお勧めします（とはいえ現場で絶対使わないとなるとモチベ上がらないので、他のことに時間回していいと思います笑）。

おすすめの教材はこちら。ハンズオン形式で学べるので理解度が違います。

Udemy『米国AI開発者がゼロから教えるDocker講座』

6. セキュリティ

RailsやLaravelでアプリを開発していると特に意識しないのがセキュリティです。これまでは単なる“ポートフォリオ“だったのでよかったですが、現場に入るとそうはいきません。

よくニュースで「●●社から個人情報が△△件流出！」みたいな話を耳にしますが、多くがセキュリティ要件が甘かったことが原因です（もっとも、ヒューマンエラーや内部的事情など次元の違う話もあったりしますが）。

アプリケーションには様々な要因で脆弱性が発生します。ベテランエンジニアでも予期しきれないものもあったりします。

では未経験からエンジニアになる人が何をすべきか、ですが、「よくある攻撃パターン・脆弱性を知って最低限対応策を知っておく」かと思います。「CSRF」「XSS」「SQLインジェクション」など有名どころの攻撃原理や手法を知っておくだけでも現場への馴染み方が変わってきます。

おすすめの教材はこちら（通称「徳丸本」）ですが、量が多かったり概念的なことが多かったりするので優先度は低いです。流し読みする程度でも大丈夫かと思います。

【+α】書籍『体系的に学ぶ 安全なWebアプリケーションの作り方』


見返せるように自分なりのドキュメント作っておく

やっておいてよかったことを一つ共有です。

僕は入社前にこれまで書いてきた学習を行いましたが、学習の内容を自分で見返せるようにドキュメントに残しておいたのがよかったです。

知識は反芻しないと定着しないので、書籍や動画で一度さらっと見た程度では現場ではすぐ実践できません。「あれ、これ学んだけどなんだっけな」みたいなことが何度もあります。そんな時にわざわざ書籍や動画を掘り起こして必要な知識を探しに行くのは手間ですし、自分の理解をもう一度呼び起こさないとなので結構時間がかかります（そういう時に限って早く情報が必要な場面だったりします）。

そのため「あ、これ学んだな」と思った時にすぐ見返せるように自分なりのドキュメントを作っておくのがおすすめです。紙でもいいですが、いつでもどこでもどんなデバイスでも参照できるように電子媒体にしておくのがいいと思います（ブログ、Qiita、Zenn、Notionなど）。

僕はこれで入社してから何度も助けられました。

■行動面（入社前）

次に行動面です。

技術的に「入社までにこれ学んでおくといいよ」みたいな記事は目にしますが、行動面を取り上げてるものはなかったので簡単にまとめておきます。

・未経験からエンジニアになった複数の先輩から話聞く
・困った時に気軽に相談できる環境を作っておく
・内定先と「入社までにやっておくこと」をすり合わせておく

未経験からエンジニアになった複数の先輩から話聞く

入社後順調に仕事をするためには、自分が入社した際のイメージを膨らませておくことが大事です。

その上で必要なのが、イメージするための情報です。

「ここに困った」「これをやっておいてよかった」「こんなことが意外だった」「ギャップを感じた」など、先輩方は入社してから少なからず何かしらの感想や経験を持っているはずです。

僕は自分の状況に近い人があまりいなかったので、なかなかイメージが掴みにくかったです。ただそれでもいろんなパターンの話を聞いていたので、「え！これ聞いたことないんですけど！！！」みたいな状況はあまり生まれませんでした。

ちなみに僕の話は最後の方で書いておくので、気が向いたら読んでみてください（参考になるかはundefined）。

困った時に気軽に相談できる環境を作っておく

実際にエンジニアとして働き始めると最初は困りの連続です。見たこともないツールや聞いたことのない単語の嵐だったり、ファイルの数やテーブルが膨大すぎて全容が把握できなかったり、環境構築が全然できなかったり、本当に困ることばかりです。

もちろん、社内の先輩や上司にすぐ質問できれば理想ですがそれが難しい場合もあります。「質問しすぎてこれ以上聞くのが申し訳ない」と思う場合もあれば、社内の人に聞きにくい事柄もあったりします。加えてフルリモートでそもそも質問のハードルが高く、慣れるまでは聞きにくさがありました。

そんな時に、社外で気軽に質問できる環境があったのは本当に助けられました。

若干ベクトルが違いますが、入社直後以外でも横のつながりは大事だと思っています。エンジニアは常に技術にキャッチアップしないと取り残されてしまうので、社内だけに留まらず社外に出て情報を集める必要があると思っています。もちろんネットで調べることもできるかもしれませんが、深い情報は人伝いでしか得られないので、今から横のつながりを意識しておくと息の長いエンジニアになれると思います。

もくもく会やコミュニティなどに参加して横のつながりを今から意識しておくとよさそうです。

内定先と「入社までにやっておくこと」をすり合わせておく

先ほど技術面でやっておくべきことを挙げましたが、それ以外で企業的に「これやっておいてほしい」ということがあったりします。

企業側は、未経験者の受け入れのために「入社したらこの案件をやってもらおう」「こういう成長路線を歩んでもらおう」みたいな準備をしているはずです。

そのため、入社してから順調に滑り出すために、予め「どういう案件担当することになりますか？」「この学習やっておこうと思ってますが、他にやっておくべきことありますか？」みたいに聞いて、入社までにやっておくことをすり合わせておくのがおすすめです。

僕の場合は「SQLゴリゴリ書くから学んでおいて」と言われたので重点的に学習してから臨みましたが、本当にゴリゴリ書くことになったのでやっておいて本当によかったです。

入社後にやってよかったこと

いよいよ念願のエンジニアとしての仕事が始まります。

期待と希望を胸に仕事は始まりますが、入社後はほとんどの方が壁にぶち当たります。僕の場合は「思ったように成果が出せない」「エンジニアとして成長できているか不安」「どうやって価値提供できるか分からない」というあたりでした。

弊社は、新卒は情報学部卒で4年間がっつりコードを書いてきた（もっと言えば小学生からプログラミングやってた）技術力お化けの人や、中途でも「営業の方ですか？？」と聞きたくなるほど弁が立つ人など、それぞれ特化した領域を持っている人ばかりがいる環境です。

そのため「自分は技術力で価値提供はできないし、弁が立つ先輩ほど喋れないし、フルリモートになる前から社内の人とがっつり交流してきた人には人脈でも勝てない…。どうやって価値提供すればいいんだろう」と大いに悩みましたし、入社してから3ヶ月の間は自己肯定感が地に落ちて精神衛生状態が本当に悪かったです。

ただ、現時点では冒頭のツイートのように「これでいいんだ。むしろこれがいいんだ」と思えるようになったのは、自尊心を損なっている状態でもなんとか考えて行動に移してきた結果なのかなと思っています。

そんな行動を、こちらも行動面と技術面で書き認めます（「したためる」って「認める」って書くんですね）。

■行動面（入社後）

何度も言ってうるさいかと思いますが、入社してから3ヶ月ほどは本当にしんどかったです。業務的に辛いとかではなくて、精神的な面がしんどかったです。

時間が解決してくれるだろうとは思っていましたが、何もしないと自尊心がなくなって心が壊れそうだったので、いろいろ考えて行動に移しました。やったこと・効果あったことを書き出してみたら結構な量になったので、その中でもよかったことを3つピックアップします。

・自ら手を挙げる
・コミュニケーションに最大限配慮する
・上司との定期的な1on1

自ら手を挙げる

当然ですが、入社したてはできることは少ないです。徐々に仕事を覚え、少しずつ開発のスキルと経験を積んでやっとエンジニアとして価値提供できるようになっていきました。

「価値提供できない期間」の長さは人によるのでなんとも言えないですが、僕の場合は「エンジニアとして価値提供できてる」と思えるまでは精神的に結構しんどかったです。その期間は、とにかく自分にできることはなんでもやります精神で自尊心をなんとか保っていました。

ただ、上司側はどこまで任せられるのか不安がっているので、待っていてもなかなか仕事を振ってもらえなかったりします。そこで「この問い合わせ対応誰かやってくれませんかー？」みたいな投げかけがあったときは「僕やります！！」と必ず手を挙げるようにしてました。

カスタマーサポートチームからの問い合わせ対応、他部署やビジネス側からの問い合わせ対応など、本来の開発に関係ないが疎かにできないことは先輩方はめんどくさがりながら対応しているので、これらを巻き取ると喜ばれます。

また、チームにジョインしたばかりだとプロダクトの仕様を知らないことの方が多いですが、問い合わせへの回答のために調査を繰り返すことで仕様理解が深まって一石二鳥だったりします。

僕のチームの場合、問い合わせ対応は6人で順番に回していて、件数は週に1回あるかないか（チーム全体として週に5件くらい）の対応頻度でしたが、内容によっては調査に半日かかるものある時間が取られてる状況でした。それに加えて、自分自身のプロダクトへの仕様理解を深めるためにも、2ヶ月間ほど問い合わせ対応を全て引き受けたのですが、チームからも喜ばれましたし、大きく評価されたポイントでした。

コミュニケーションに最大限配慮する

入社当初からフルリモートで、一度も面と向かって会ったことがない人と仕事上の関係性を築くという経験が初めてでした。

最初は会社の雰囲気がどんな感じかとか、どんな考え方をする人が多いのかとか全く掴めませんでしたし、Twitterではエンジニア界隈はよく炎上してるので「エンジニア＝気難しい」イメージもあって若干の不安もありました。

同時に、前職では1人情シスとしてリモートワークの環境を整える中で「なんでうちの会社の人たちはこんなにテキストメッセージが下手なんだろう」と仕事をする上で「正確に」「気分を害さず」伝えることの難しさと重要性を感じていました。

そこで「相手の立場だったらこういうコミュニケーションが嬉しいだろうな〜」と想像して以下のことに気を付けていました。

・結論ファーストで伝える
・語尾は口調が冷たくならないよう送信前に読み返す
・質問orお願いor共有or報告の何を伝えたいか最初に伝える

また、これは前職の上司から教えてもらったことですが、「入社3ヶ月くらいはメッセージのやり取りに必ずCCに上司つける」のも喜ばれました。

入社後は僕らも不安ですが、上司やメンター側はもっと不安です。新入社員がどんな人なのか掴めていないので、どういうコミュニケーションとっているのか、何に困っているのか、どういうやりとりしてるのかを不安に感じてるようです。

特にリモートワークで行動が目に見えないと余計不安になるので、やりとりを隠さず開示することで安心につながりますし、その安心感が信頼につながるのでこれはやっておいてよかったなと思いました。

上司との定期的な1on1

個人的に「働く上での心理的ハードル」を下げるために効果が一番高かったのはこれです。

エンジニアとしての働き方や価値の出し方が分からない、フルリモートなので余計雲を掴むような感じがする、といった霧の中に迷い込んだ状態だったので、見るべきものが見えなかったり近くのことしか見えなくてもどかしい日々が続いていました。

でも、上司にフィードバックやアドバイスをもらうことで、霧の中にある道を教えてくれたり霧を晴らしてくれることが何度もありました。

人事制度がある程度整っている会社なら、定期的（隔週〜月1くらい）な1on1は実施されているかと思いますが、所感では「入社1ヶ月は毎日・入社3ヶ月までは週一以上」で上司やメンターに30分〜1時間くらい設けてもらうのがいいです。

入社1ヶ月間は働き方やキャリアの話というよりは、実務内での困りを聞く時間として設けておくと仕事のしやすさが違います。聞かなくてもある程度仕事ができるようになれば頻度は減らして、話す内容を働き方やキャリアの話に寄せていくと、その会社でのキャリアは順調に築けると思いますし、効果の高い1on1にできると思います。

1on1でのポイントは以下かなと思ってます。

・不安や心配なことを最優先で共有する
・ちょっとでも困ってるなら些細なことでも共有する
・フィードバックを求めて上司の期待とのズレを修正する

上司側としても、一緒に働いてる僕らが働きやすいように取り計らいたいはずです。なので困ってることはすぐ共有して一緒に解決を目指すのおすすめです。実際、話してみたら上司が画期的な解決策を持っていたり、実は大したことなかったり、ちょっとした改善で解消することが多かったので。

また、僕は入社してからの働きぶりや「この会社でちゃんとやれているのか」という点に不安が大きかったので「いっそのこと自分の働きぶりを評価してくれる人に聞いちゃお」と思って聞いてみました。

良好なフィードバックをいただければ万々歳ですし、仮にパフォーマンスが悪いことの指摘を受けたとしても、改善ポイントが早めに分かれば修正もすぐできるので、聞かない手はないなと思いました。

その他やってよかったこと

ピックアップしたものは以上で、その他でやってよかったことを列挙しました（言語化さぼってごめんなさい）。

・開発のテスト結果をエビデンスに残す
・読みやすいドキュメント
・「次入ってくる人」を意識してドキュメントを残す
・失敗したことは必ずドキュメントに残す
　└ どういう状況で何を失敗したのか
　└ なぜ失敗したのか
　└ どうすれば失敗を繰り返さないか
　└ 失敗したこと自体は責め咎められない
　└ 失敗を繰り返すのが一番のアンチパターン
　└ むしろリカバリ力と失敗を繰り返さない＝失敗から学ぶことができれば評価につながる
　└ その失敗を経験した上で他のことにも活かせれば最高
・周りを見て「この人のやり方いいな」と思ったらすぐ取り入れる
・ボールをすぐ返して長く持たない
・落ちたボールを拾う
・理解するまで確認する（曖昧にしない）
・周りの気持ちに配慮する
・進捗報告はこまめに行う（1〜2時間ごとくらい）
・分からないことリストを作って定期的に解決する
・ランチ会など主催して顔を売る、仲間の人柄を知る
・言われたことはすぐ行動に移す
・スピード感意識する
・すぐ聞く
・聞きやすい人見つける
・先輩がやりたがらないことを進んで行う
・メンバーがやってる誰でもできることを巻き取る
・疑問に思ったことや不便に感じたことは共有する
　└ 共有が難しければメモっておく
　└ 入社当初に感じた感覚はその時にしかない。時間が経つと忘れてしまう
　└ フレッシュな視点でないと気づけないことはいっぱいある

やっておけばよかったと後悔したこと

逆に「これやっておけばよかった」という後悔もあります。

①話しかけられ待ち
エンジニアはシャイな方が多いので、こちらから話しかけにいく方が仲良くなれる。仲良くなればいいこと色々教えてくれる。

②情報の集め方が受け身
とにかく知るべき情報が多いので、上司やメンターから教えられる情報だけだと足りないことがほとんど。チームの他のメンバーに聞きに行ったりする積極的な姿勢が大事。「聞くかどうか迷ったら聞け」。

③上司に理解度を伝えない
案件の共有を受けたり、プログラムについて教えてもらう際に「理解度3割です！（あまりわかってないです！）」と伝えた方がいい。上司側は「共有した＝10割理解してくれた」と思いがちなので。齟齬を生まないためにも理解できてないことはしっかり共有したい。

④日報で学びを言語化しない
「成長は経験の認識」だと思っているので、「これを学んだ」「これができるようになった」ということを日々言語化すべきだった。最初は知らないことが多すぎて学びの連続。毎日整理して言語化することで、知識が整理されて定着しやすいし、自身の成長の実感にも繋がる。同時に「次これやろう」が見えてきやすい。

⑤毎週の振り返りを行わない
上記と同様。入社3ヶ月くらいは毎週振り返りをやるべきだった。上司と共有すればなおよかった。

⑥月の目標を曖昧に設定する
上記と同様。入社半年くらいは必ずやるべきだし、それ以降も継続した方がいい。上司と共有するとなおいい。

⑦「入社したて」の免罪符を使わない
入社3ヶ月目くらいまではたとえ失敗したとしても周りはそんなに気にしてない。大きな失敗でなくても「質問の頻度高すぎて迷惑がられないかな」みたいな杞憂も不要。だから色んなことを自主的に行っておくべきだったし、積極的に話しかけたり行動しておいた方が後々やりやすくなる。「入社半年経ってるのにそんな基礎的なこと知らないの？」とならないようにしたい。

⑧曖昧な部分を徹底的に言語化しない
いきなり全部を理解するのは難しい。かと言って曖昧なまま進めると痛い目を見る。「自分が何が分かってないか？」を言語化して上司や先輩に聞いて解決する、という地道な作業が結構重要。

■技術面（入社後）

先にお断りをしておくと、僕はエンジニアとして実務を始めてみて技術志向でないことが判明しました。笑

そのためゴリゴリ技術を極めたい方にとっては物足りないかもしれませんが、それでも最初期に行っておくといいことを書きしたためておきます。

・まずは既存プロダクトの理解
　- アーキテクチャへの理解
　- コード（ファイル構造）の理解
　- テーブルへの理解
・チームのルールを理解して遵守する
　- 命名規則
　- Gitの使い方
　- アンチパターン
・既存コードをよく読んでパターンを掴む

まずは既存プロダクトの理解

これは経験者未経験者かかわらず大事かと思います。

チームにジョインしたら、そのチームが開発するプロダクトへの理解は必須です（当たり前）。ただ、未経験者の場合は「何が分からないか分からない」という事態に陥ることは往々にしてあるので、敢えて文字にしています。

ここでは未経験者がどのように理解を深めていけばいいか、という視点で書きます。ポイントは3つで、①アーキテクチャへの理解、②コード（ファイル構造）の理解、③テーブルの理解です。

アーキテクチャで理解すべきは、そもそも言語は何を使っているのか、サーバーは何を使っているのかという粒度もそうですが、単にリクエストに対して内部処理はどうなって最終的にレスポンスを返しているのか（ページを表示しているのか）ということが理解できれば大丈夫だと思います。

リクエスト→ルーティング→バック側のロジック→DBからデータ取得→バック側のロジック→フロントにレンダリングorレスポンス返す→フロントで描画、みたいな感じです。

最初はどこでどうなってるのか分からなさすぎて大変ですが、自分の中で処理を整理しようと意識していれば徐々に理解できるので大丈夫です。

コードで理解すべきは、先述したアーキテクチャの理解に近いですが、「処理がどこでどのように行われているか」です。フロント側でAPIを叩いてロジックを呼んでいる場合もあれば、SSRでロジックを呼んでいる場合もありますし、プロダクトによっては複数のリポジトリを跨いで処理を行なっている場合もあります。以下のような理解ができてれば大丈夫かと。

「ここでルーティングされてAという処理が呼ばれて、その処理はこのファイルで行ってて、さらにその中でBっていう関数を呼んでる。結果Cを返してる」みたいな形で、その機能や仕様をコードベースで説明できるようになれば何も言うことはありません。

こちらもいきなりはできないので徐々にで大丈夫で、僕は理解度を高めるためにローカル環境で仮説検証を繰り返しながらコードを触ってました。「ここをこう変えるとDって結果が返ってくるんじゃないか？あれEって返ってきた。ということはFってことか！」みたいな感じです。

ちなみに、仮説検証する際にはデバッグのツールやコマンドが重要です（Visual StudioなどのIDEや、Railsで言うbinding.pryなど）。これがあるとないとで効率がかなり違います。ほぼ間違いなく先輩エンジニアも使っているので、「デバッグってどうやってますか？」と聞くのがおすすめです。

（僕は入社3ヶ月後くらいにその存在を知ってめちゃくちゃ時間を無駄にしてたと気付かされました。。）

最後に、テーブルで理解すべきは、レプリケーションやテーブルのリレーショナルなど大まかな全体像です。現場では学習とは比べ物にならない数のテーブルと向き合う必要があります。リレーションも複雑になっていたり、DB間のレプリも日常茶飯事です。

最初は何がなんだか分かりませんが、一つずつ慌てず整理していけば知らず知らずのうちに概要が掴めるようになっていきます。

「Aというデータは、Bというテーブルから取得されてる。このBというテーブルは元々CというテーブルにデータがINSERTされてて、レプリが回ると反映される。BとDはそれぞれこういう感じでデータの棲み分けがされてて、こっちの場合はBからデータを取得してる」のように、テーブルの定義やリレーション、レプリの向きなどが機能単位で説明できれば言うことありません。

僕は、仕様調査をする際に機能単位で使用されているテーブルを書き出して、それぞれテーブルの定義を自分なりに整理していました。そうすることでテーブルの中に入っているデータの意味がより理解できますし、機能の目的も分かりやすくなりました。

また、企業やチームによってはテーブルの仕様書をドキュメントに残していたり、「テーブル定義サイト」やER図があるかと思うので先輩に聞いてみるのがおすすめです。

チームのルールを理解して遵守する

次に大事だと思ったのがこれです。

多くの企業はチームによってルールが決まっていると思います。「インデントはタブだ」とか「関数名はローワーキャメルケースだ」とかです。コードがカオスになるのを防ぐためのやつです。

ルールが決まっていれば、誰でも閲覧できるドキュメントが存在するはずなので、まずはそのドキュメントを穴が開くほど読み込むのがおすすめです。多くの場合、初めて出したPRではチームのルールに反しているものに対する指摘がほとんどだったりするので。

もしドキュメントがない、明確なルールが決まっていない場合は以下について先輩に聞くのがおすすめです。

- 命名規則
- Gitの使い方
- アンチパターン

世に出ているプロダクトを開発しているなら、多かれ少なかれこの辺のナレッジは溜まっているはずです（そうでなければやばい）。


既存コードをよく読んでパターンを掴む

実装する上で大事なのがこれです。

プロダクトやアーキテクチャによりますが、多くの場合「実装パターン」があります。「こういう機能の時はこう実装する」「例外処理の時はこう実装する」みたいなやつです。

現場に入って案件を任されるようになって、自分の頭で考えて新しく機能を開発したり改修する際は、迷うことの連続です。「ファイルの構成をどうするのか」「関数の名前をどうするのか」「どの粒度でメソッドを分けるといいのか」など。

そんな時に参考にすべきは「既存コード」です。

すでに世に出回っているコードは、テストをパスしていてエラーを発生させていないので、ある程度「実績」はあります。「全部自分でロジック考えてこそエンジニアだ！！」と意気込んで、既存コードや実装パターンを何も考慮しないで実装したPRはほぼ間違いなくボコボコにされます。

チームやプロダクトによって「お作法」は少なからずあるので、それを掴むためにも既存コードを読み込むことは超重要です。既存の仕様調査や既存コードを微修正する際がパターンを掴むチャンスです。

とはいえ、中身理解せずの全部コピペはNGですし、無理やり既存コードを踏襲しようとすると良くないケースもあるので、自分の頭で考えて新しいメソッドや構成を考える必要があります（当たり前）。

綺麗なコード・メソッド名を書くためのお得情報を載せておきます。

実務入ってからおすすめの本

弊社は図書代全額補助してくれるので、それなりに技術書やエンジニア関連の本読んできました。その中でも（担当領域やフェーズによりますが）以下の本はおすすめです。

興味のあるものを少しずつ読むのがおすすめです。

殴り書き

ここからは文章の構造化も要点の抽出も行わず、思ったことを時系列ベースで書き殴っていきます。なので読みにくいかもしれませんがご容赦ください。

入社1〜3ヶ月目

とにかく辛かったです。

エンジニアとしての知識も実力もなくて申し訳なさしかないし、開発以外で貢献できることも少ない、新しい人間関係や言語やツールに慣れたりしないといけなくて諸々負荷が高く、その上フルリモートだったので本当にしんどかったです（僕は結果的に社外の人との繋がりに助けられました）。

フルリモートは、助けて欲しい時に「助けてください」と躊躇せずに言えたり、いい意味で相手の感情に左右されない人でないと向いてないです（文字にすると簡単そうに見えますが、実際に業務に入るとかなり心理的ハードル高いです）。

それに、未経験からエンジニアになった方の多くが「入社してから勉強の連続。ゴリゴリ開発させてもらってて休日も勉強しないと追いつけない！」と、どんどん成長してるイメージだった一方で、僕はほとんど開発できてませんでした。

ほとんどコードが書けなかったので「エンジニアとして成長できてない！」と焦る気持ちも相まって辛さが募っていました。

入社2ヶ月目の12月あたりは本当に精神衛生状態が悪かったです（ある人と猫がいなかったら今頃退職してたかもしれません。笑）

入社3ヶ月目は色々と迷走してて、「これやろう！」「あ、向いてないやめよう」「やっぱこっちやろう！」「めんどくさいやめよう」みたいなことを繰り返してました。結果的に何もしてない焦燥感しか生まれず、自尊心が余計欠けていきました。今思えば、本業が地に足ついてないのに本業外のことに手を出そうとしても続かないのは当然ですね。

入社4〜5ヶ月目

そんな状況を打破しようと、転職活動時にやってた自己分析をもっと深ぼってみたり、先輩方に相談に乗ってもらったり、試行錯誤しながらこれまで書いてきたことを実践したりして、やっと徐々に改善していきました。

入社4ヶ月目くらいから社内でランチ会を定期開催したり問い合わせ対応や差込調査を全部巻き取ったりして、なんとか業務内でも自尊心を保てるようになったのでメンタル的には安定してました。

ちなみに、この辺りで本業に注力するのが一番大事ということにやっと気付いたので、業務の振り返りをしたりしてました。そこでほとんど理解が進んでない・学びが少ないことに愕然としました。

僕の場合は、メンター役になってくださった方からアーキテクチャや独自フレームワークについて一から丁寧に教えてもらったわけではなく、リファレンスとコードを渡されて「わからないとこあったら聞いてね」スタイルだったので、小さな実装を繰り返す中で徐々に理解を深めていくしかありませんでした。

平日だけだと時間が足りない＆仕事が終わらなかったので休日に持ち越してましたし、独自FWを理解するためにローカル環境で色々触りまくってなんとかついていけてる状態でした。

それが4〜5ヶ月目。ただ、この時期が1番理解した内容が多かったし成長を実感した時期です。入社後3ヶ月間の点在していた知識が、点と点が、やっと繋がってだんだん線になっていきました。この頃からメンタル回復し始めます（同時にTwitterはどんどん低浮上になっていきます。笑）

入社6〜8ヶ月目

入社6ヶ月目の4月にはチーム編成が変わって、より働きやすくなりました。それまでは3人のユニットにユニット長がいて、そのすぐ上にチームリーダーがいて、どちらからも指示を受けていた状況でした。そのためチームリーダーとユニット長のどっちの判断を仰げばいい？など細かい部分で悩むことが多かったのが働きにくさを助長してました。

それに、チーム内活動などは基本12人のチーム単位で動くのに深い関わりがあるのは3人のユニットメンバーだけだったりするので、チーム内のコミュニケーションにハードルを感じたことも何度もありました（フルリモートで顔を合わせる機会が少ないので余計）。

それらの無駄なハードルがなくなった上に、会社のドメイン知識が溜まってきたりアーキテクチャやプロダクトへの理解が深まったこともあって、自信を持って仕事に取り組めるようになっていきました。

ちょうどこのタイミングで前期（2020年11月〜2021年3月）の評価があって、入社後の働きをかなり評価をしていただけました。具体的には以下の3点です。

・前のめりな姿勢
・丁寧な対応（テスト・ドキュメント）
・アドバイスをすぐ行動に移す

評価の際に「一人前だよ」と直接フィードバックいただけたので、本当に自信になりましたし自己肯定感が高まりました。

そんな折に中規模案件の開発を経験できたので、実力的にもメンタル的にもちょうどいいタイミングだったなと思ってます。

また、同じタイミングで新卒と中途入社の方がそれぞれチームにジョインして後輩を持つことになりました。「後輩の方々も入社当初からフルリモートだから僕と同じ苦しみを抱えてるだろうな〜」と思って自分が困ったことや悩んだ点を先回りしてサポートするように心がけていました。

それらの行動も評価されてか、7ヶ月目には協力会社の強強エンジニアの方に案件を指示する立場を任せていただけるようになりました。同時に、大規模案件では開発サブリーダーを任せてもらえたのですが、他チームだと入社3年目くらいの方が担当してるので、そこに肩を並べられたもの良かったな〜と（ここでほぼTwitterから姿を消します。笑）

8ヶ月目には他にも色んなタスクを任せてもらえるようになりました。

・バグチケットの管理とメンバーのアサイン
・プロダクト改善プロジェクトのバックエンド担当
・チーム内での改善提案プロジェクトの主導

これらのタスクを任せてもらって実際色々と考えながら仕事をしていると、技術を突き詰めるよりマネジメント系の方が面白そうだな、と思うようになっていきました。

そんな感じの8ヶ月間です。


ちなみに全て自分で考えたかのように偉そうに語ってきましたが、箱さん（@y_hakopro）やうえひろさん（@hiro_30_1000）のnoteはかなり参考にさせていただきました。

僕より数段先を行ってる方なので、こちらのnoteも読んでいただくのをおすすめします。

（僕のこのnoteもいずれ同じ形で紹介されたら嬉しいな😇）

今後について

正直まだ漠然としていて明確な将来やキャリアパスは描けていないのですが、まずは「2年以内にこの会社でチームリーダーになる」を直近の目標に掲げています。

理由はいくつかあるんですが、そう思うようになったのは「今は技術志向が薄い」からです。加えてエンジニアはマネジメントをやりたがらない人が多いので、そこの牌も取りやすいのかなと思ったのもあります。

今の心境だけ言えば「技術だけで食べていくのは性に合わなさそうだし今はそこのモチベーションがない。将来的に技術に特化したくなったタイミングでまた戻ればいいや」くらいの感じです。将来技術を極めたくなったときに、マネジメント経験があればある程度融通も効きそうだなとも思ったり、自分の適正や得意なことを加味したりなんやかんや総合的に今はマネジメント系エンジニアを目指すのがよさそうだな、と落ち着いた次第です。

現時点では技術よりチームビルディングや組織づくりの方が興味があるので、近いうちに採用とかもできたらいいなあとか思ったりしてます。（完璧求めがちなのにめんどくさがりという面倒な性格してるので、ひょんなことで変わるかもですが。笑）

さいごに

ここまで長々と読んでいただいてありがとうございました。

周りと変に比較して落ち込むこともありますが、地道に自分のペースで自分の思うようにキャリアを積めて行けたらいいなと思っているので、また気が向いたらこんな感じでnote書き殴りたいと思います。

その際は読んでいただけたら嬉しいですし、スキ押していただけるともっと喜びます。

感想等はTwitterでいただけたら泣きます。

ではまた。

自身のキャリアで得た知見について言語化しています。執筆活動の励みになります！