雰囲気で仕事をしていた学生エンジニアが、新卒研修を通じて得られたもの

※雰囲気で、と書きましたが、学生の頃の僕はあくまで適切な知識を持っていなかっただけであり(適切な知識ってなんなんでしょうかね、いつまでも持てる気しませんが日々努力します)、仕事を雰囲気で流して行なっていたわけではないので、認識お願いします。

こんにちは、うしまる(@ushimaru08)です。学生時代は少人数のスタートアップ(人数で言うと5人以下くらい)でコードを書いていましたが、新卒では比較的大きめのベンチャー企業に入社しました。

弊社では、新卒入社してからの三ヶ月間は基本的に研修を受けることになっています。その期間のうち、二ヶ月間はエンジニア研修です。現在、エンジニア研修の一ヶ月目が終了して、二ヶ月目に突入しています。

今までちゃんとした研修は受けたことがなく雰囲気でコードを書いていたのですが、今回の研修を通じて、企業で開発をするにあたって必要な知識の一部分を得ることができています。自分自身の備忘録のため、また、今フリーランスや学生エンジニアとして仕事をしているけれど、ちゃんと企業に入ったことがなく、適切な仕事の進め方や開発の進め方がわからず若干の不安を抱えている人たちに向けて、noteを書き記します(僕自身が学生の時に感じていた不安で、故に大きめの企業に入社することを選びました)。

ひとまず、一ヶ月目時点で得られたものを書き、二ヶ月目はまた別のnoteで書こうと思います。思いつき順に羅列しているので粒度感がバラバラですがご容赦ください。

エビデンスは適宜残すこと

自分が行った作業に対するエビデンスを常に残すこと。ここでのエビデンスが、自分が作業した作業ログや、自分が実装したものに関するドキュメント等も含みます。学生でバイトをしていたときには、エビデンスを残さずに作業をしていて(明らかに重要な部分のエビデンスはとっていたが)、誰かに自分が実装した部分について質問されたときに都度自分が説明を加えていました。少人数スタートアップ(人数ベースで5人以下を想定)の場合は、個人の裁量権が強い(というか個人単体で価値を出すことが義務)なので、自分が常に状況を把握していればそれで大丈夫でした。

比較的大きな企業では、エビデンスを残すことが求められます。そもそも、自分が考えた設計、実装を他の人がみる場面が多くなるからであり、そのときに自分が出したエビデンスを見て、何をどのようにしているのかを把握する必要があるからです。

これはアメリカで聞いた話ですが、米国の大手IT企業でも、一日の多くの時間をエビデンスを書いたりエビデンスを読んだりする時間に費やしていると聞きました。企業が大きくなればなるほど、作業エビデンスが大事になるみたいです。

自分が打つコマンド全てを説明できること

これも当たり前のことではあるんですが。時折頭が疲れていると、適当にコマンドを打ってしまったり、ネットで見つけた記事からコピペしてコマンドを実行してしまったりすることがあると思います。

僕の場合、コピペをするときは大まかなコマンドの概要を掴んでから実行していましたが、大まかな、ではなくて詳細まできちんと理解して説明できるようにならないといけません。コマンドの意味はもちろん、なぜこの場面でそのオプションをつけるのか、他のオプションは何か等、そのコマンドについて習熟するまで、徹底的に確認する癖をつけたいです。

問題は全体像から切り分けて分析すること

これは元々認識していたもので、研修中に再認識した課題ですが、問題があるときは常にその問題を切り分けて分析することが重要です。学生の頃にバイトで関わっていたインターン先のCTOにも、ほぼ毎日、切り分け力の重要性について説かれてましたし、理論自体は理解していて、実践もしているつもりでした。

ただ、研修中に実感したことが、この切り分けですが、問題対象の全体像が見えていないとうまくできません。その場でのググって全体像を把握する力を身につけるとともに、日々勉強してたくさんの知識を身につけておく必要があると感じました。

また、自分の場合、頭が疲れているときに切り分けが全然できていないことが判明しました。つまり、上記能力の発現率が100%ではなかったということです。コンスタントに切り分けできるように、意識したいと思いました。

ソフトスキルを意識すること(ハードスキルは当然)

これ研修中の一番の発見と言っても過言ではありません。ここ数年は個人単位で仕事をすることが多かったので、成長に関して考えるときに、自然とハードスキルをどれだけ伸ばせるかについてのみ考えてきました。

ただ、実際人と協働をする中で、大事なことは対人理解力等に代表されるソフトスキルです。エンジニアなので、ハードスキルは持っていて当然だし、自己研鑽としてスキルを磨くことも最低ラインです。その中でソフトスキルをどのように身につけていくか。自分のキャリア設計を見直す機会になったとともに、大きな気づきになりました。

技術が理解できないときは歴史に立ち返ること

例えばオブジェクト指向について理解したいときは、オブジェクト指向がない世界の課題について考える的なことですね。基本的に技術は前時代の課題を解決するために生まれてきているはずなので、前提として、その技術がないときに何かしたの不便な点が発生するはずです。その歴史を捉えて、発生した課題に対してどのような解決策を生み出したのか、その解決策が技術にどのように応用されているのかを考えていくことが、技術を理解するときの近道だと思いました。

これも、過去に意識したことはあったのですが、発現率が100%ではなかったので、考えに詰まったときは常に考えることができるようにしていきたいです。

まとめ

現状、業務委託として働いていては学ぶことができなかったであろうことを多く学べており、とても満足しています。圧倒的な実力を持っている人以外は、企業に入って研修を受けて働き方を身につけるのもオススメの選択肢です。

まだまだ学んだ点はあるのですが、全部は言語化できていない状況です。また落ち着いたら言語化しようかと思います。