４月に入社した新卒エンジニアが、およそ８ヶ月の社会人生活のなかで、真似したいと思った先輩の行動や、普段気をつけていること、プラベートでの開発について振り返ってみました。
所々、「そんなことはないよ」「それ、偏見っす」「出直してこい！」と思われる部分も、もしかしたらあるかもしれませんが、一旦飲み込んだ後にそれでもコメントいただける方はぜひよろしくお願いします 
また、偉そうなことをこれから書いていきますが、僕自身が出来ていないことも含まれているので「お前、このままじゃやばいよ？」と反省を込めたものでもあることをご了承ください。
発言しないアイデアは廃れる
というのはかなり大げさですね。
ただ、せっかくいいアイデアを持っているのに、それを共有しないのは勿体無いなぁって話です。
新入社員は、研修が終わって各部署に配属されたのち、そこからはチームとして行動することになります。１つの問題を解決するため・目標を達成するために年齢や性別、出身地や経歴が異なる人達が集まって何かを成し遂げようとしたとき、そこに上下関係なんて必要ありません。
「あ、ひょっとしたらこれいいアイデアかもしれない！…でも、きっと他の人も同じこと思い付きそうだし、あんまりいいアイデアじゃないからやめとこうかなぁ」
なんて思ってる時間があったら声に出して、あんまりいいアイデアじゃないと感じた部分の議論を広げたほうがずっといいです。他の人の意見をくっつけたり、削ったりしながら、少しずつより良くしていくことが議論の場です。
…と、さらっと言ってますが、僕もポンポン思ってることを発言出来るタイプでもないので、そういう時は、きっかけづくりをするようにしています。
- 「こんな記事見たんですけど、何か活かせませんか？」
- 「先日行ってきたイベントでこんな機能あること知りました！使ってみませんか？」
みたいな。
あとは、チームメンバーと一緒に調理していきましょう。
ドキュメントの整理はプロダクトを理解する近道になる
ドキュメントの整理って、なかなか進んでやりたいものではないと思います。
しかし、新しい人がチームとして加わった時、１からすべての作業を教える時間の確保はなかなか難しいことでしょう。となると、ドキュメントが充実しているかどうかで、その後の開発スピードが大きく変化してくることは言わずもがなですね。
ただ、プロダクトは日々成長を続け、最初はきちんと残していた開発環境の導入手順や、デプロイ方法、.envに記載する環境変数の数々。ちょっと時間を置いただけで、現状と乖離してしまうなんて容易いです。
そんな時、特に配属されたばかりの新卒エンジニアは、ドキュメントの整理をしてみると良いかもしれません。
理由としては、
- 仕様の全体 ⇒ 詳細把握を自然な流れで行うことが出来る
- 言語のバージョン違いで起きる不具合や、本来つまづく必要のないポイントを予め把握出来る
- 分からないことが当たり前なので、上司・先輩に質問するというコミュニケーションが生まれる
- 来年入ってくる後輩に喜ばれる
などなど。
ただ、ドキュメント整理に工数をかけすぎるのも如何なものかと思うので、上司・先輩と相談しながら進めましょう。
理想の先輩エンジニア１人をとことん真似る
僕のまわりの先輩エンジニアは本当に尊敬する方ばかりなのですが、その中でも１人、飛び抜けて僕の理想に近く、「入社１年でまずはこの人に近づける行動しよう！」と決めたエンジニアがいます。
何事でも上達の基本は、真似ることだと思います。
僕は、その先輩エンジニアの行動を真似てみました。
例えば、
- コードレビューの仕方
- コミュニケーションツール（Slack）と直接会話する割合
- 「分からない」ことをどれぐらいの時間で相談に持ち込むか
- 相談するときにどんなことを、端的にまとめて伝えているか
- 機微をどう言語化して伝えているか
まだまだキリがないのですが、なにか迷った時は「◯◯さんならどうするだろう」と考える癖をつけるようにしました。
真似して良かったと思えたことは、自分がこれまで行動してきたことの答え合わせが出来たことです。
質問の仕方１つ取っても、
「30分考えて分からなかった聞く」
「分からないことが理解できているのか、そもそも理解できていないのかを整理する」
「解決したいこと・試したこと・試したことで分かったこと・分からないことを要約して伝える」
など、人それぞれの基準があると思いますが、それが良い悪いは別の話として、目標としているエンジニアも同じような考えで行動していたら、ちょっと嬉しくなりますよね。
形から入るやり方があってもいいと思うんです。最終的に目標へ到達できれば。
プライベートでチーム開発と個人開発をする
どちらか１つでもいいと思いますが、僕は両方していて良かったと感じることが多いです。
僕の場合、個人開発では少なくとも１つ、業務と関連する技術を使うことにしています。
そうすることで、業務でハマってしまった箇所や時間が無いなかで妥協案を取ってしまった実装なども、落ち着いて作業している個人開発のときには案外簡単に解決したりします（逆もしかり）。
また、個人なので、どんな技術を使うか、デザインはどう設計するか、マネタイズはどう攻めるか、すべて自分次第のため、網羅して考える範囲がとても広いですよね。その普段はあまり関わらない、よく分かってない部分を理解しているかどうかで、チームへの関わり方に大きな差があると思っています。
デザイナーやマーケターとの共通言語を学ぶためには、個人開発で試行錯誤してみることが近道です。
チーム開発は、可能であれば大学や専門学校の友人とすることをおすすめします。
僕は、同じ大学出身の友人たちと週に１回、実際に集まるかビデオ通話をして状況確認をしながら比較的まったりと進めています。ここでいうチーム開発をする意味とは、サービスを立ち上げてお金儲けをしたい！という気持ちがまったくないとは言いませんが、まずは、お互いが普段学んでいる技術や手法を共有し合って、お互いに成長することを第一の目的としています。同じ新卒として働いていて、自分の知らないこと・有益な情報を持っているエンジニアは魅力的に見えます（僕は）。 Give Give Give and Take ぐらいの気持ちで関わって行ければ最高ですね。
ただ、平日の夜も土日もすべてプライベートな開発に費やせ！というわけではなく、社外のエンジニアと交流する場を作ったり、新しい技術を試す習慣をつけておくと、思っている以上に業務で活かせることが多いと感じています。
社外のイベントで一度は登壇すべき
都内では、毎日数多くのイベント・勉強会が開催されています。
地方出身の僕からすると、「なんて恵まれている環境なんだ！参加しない理由がない！」と思えるほど、多くのイベント・勉強会はとても魅力的に感じています。なぜなら、ほとんどのイベントは参加費無料で流行の情報を得ることができ、また、業務の抱えている問題を開発者やアンバサダーなどの専門家に直接質問することだって出来ます。
そんな、『すごい人達』のいる前で登壇することは、かなり気が引けることでしょう。僕も人前で話すことは得意ではありませんし（むしろめちゃくちゃ苦手）、自分のプラスにならないのなら、極力避けたいところです。
ただ、ありがたいことに僕の場合は登壇後さまざまなフィードバックをいただけることが多いです。
意見は様々ですが、ほとんどの方はとても優しくアドバイスしてくださったり、興味を抱いて質疑応答の時間を費やすほど質問してくださる方もいました。
発言しないアイデアは廃れる にも繋がる部分がありますが、自分の考えていること・実践してみたことは、誰かに伝えるほど予想もしない方向に大きく成長する可能性があります。それに、「発言したからには行動しなくちゃ！」と思うようになりませんか？誰しも望んで自分から嘘つきにはなりたくないじゃないですか。
最後に
偉そうにごちゃごちゃ書いてしまいましたが、冒頭でも言ったように 僕自身が出来ておらず、「こうすればもっと成長できると思うよ！」と感じたことも含めて綴らせていただきました。
恐らく当たり前のことしか述べていないと思いますが、でもそれだけ１年目としてやること・やれること・やるべきことは山ほどあります。
この記事が、来年の入社を抱えている新卒エンジニアの不安を少しでも取り除くことができれば幸いです。