新人エンジニアの僕が成長するために取り組んでいること

はじめに

この記事では、いま新人エンジニアである僕が成長するために効果的だったこと＆取り組んでいることについて紹介していきたいと思います。僕はITエンジニアとして働きはじめて、ちょうど6ヶ月になりました。現在の業務ではサーバーサイドの開発(PHP)と、データ分析(Python)を行っています。

僕は大学の研究でJavaを少々使っていたものの、自分でなにかコードを書く機会はそれまでほとんど無い状態でした。宇宙物理学の実験系だったので、プログラミングが研究のメインではなかったのです。頭の良い先人たちが作った素晴らしい研究用のライブラリをちょこちょこ利用するくらいでした。

しかし6ヶ月前に比べると、コードを書く力やエンジニア脳が鍛えられたように実感しています。なんでも習い始めは伸びしろがあるのでそのせいもあると思いますが、このまま勢いをつけてさらに成長していきたいと思い、一度記事として取り組みをまとめようと思いました。

取り組んでいること

20分調べてわからない事はすぐに聞く

新人エンジニアがスキルを付けていくにあたって、分からないことを聞くのは超重要です。でも自分で調べるのも重要です。だから、ある程度調べて分からなかったら聞くということを繰り返すことが重要なのです。最初は何を調べればいいかわからないので、20分ほど調べて検討がつかなかったらすぐ聞くのが良いと思います。

例えば、僕はエンジニアをはじめてすぐのタイミングで、CakePHPのウェブサービス改修を行いました。CakePHPはMVCモデル(Model,View,Controller)を採用しており、独自のルールがたくさんあります。「MVCモデル？なにそれ、美味しいの？」というレベルだった僕は何をすればいいか分かりませんでした。

もちろん、PHPの書き方とか、CakePHPの仕組みは勉強しながら進めていきました。しかしそれだけでは具体的なコードを書くところまでは出来なかったのです。最初はMVCのどれを改修すればいいのかすら分かりませんでした。なので、どの部分をどのように直すべきなのか、といったことを上司に細かく聞いていきました。

例えば、MySQLでテーブルのカラムを増やしてCakePHPのControllerで新しいロジックを付け加えるには、PHPMyAdminを使うとやりやすいことや、Controllerのどのあたりをいじるといいか教えてもらいました。

もちろん、処理の細かい流れは自分で少しずつコードを読んでいきます。コードリーディングに関してはかなりの時間を使いました。これが正解だったように思います。現在進行系ですが、他の人のコードを見ると勉強になることが多いし、処理の流れを理解するための時間がどんどん短くなっていくからです。

英語の勉強はまず読むことから始めるように、大量にコードを読んでいくことで理解する力も書く力も身についていきます。最初の方は上司に対して細かいところも聞くことが多かったですが、徐々にプログラム内部の構造や処理の流れがつかめてくるようになると、質問の回数も減っていきました。

おおよそ4ヶ月目くらいになるとほぼ自力で機能を実装することも出来るようになり、ここでやっと楽しくなってきたという状態でした。自分で調べたり考えるのも大事なんですが、新人の場合は「何を調べればいいかすら分からない」という状況になので、自走出来るようになるまでは質問が重要です。

でないと、全く見当違いのことを調べてしまうなど非常に学習効率が落ちてしまいます。新人を教育する上では最初から突き放して「自分で調べろ」というスタイルは良くないのではないかと思います。

業務外の時間も勉強する

考えても分からないところがあったら聞くと良い、と書きましたがもちろん自分で勉強することも大事です。質問をするということは相手の時間をもらうということですし、業務内だけでやれることには限界があるからです。

例えば、PHPとはなんですか？とかforループとはなんですか？といった一般的な内容はぐぐったり本を読めばすぐに分かります。質問をする場合は「この機能を実装するためにはどこを触ればいいですか？」といったぐぐっても分からない内容かどうかを熟慮すべきだと思います。

PHPだけでも、型・文字列・条件分岐・反復・関数・クラス・正規表現など多くのことを学ばなければいけません。これらをすべて人から教わることは実質不可能なので（コードの書き方は見たほうが早いし）、インプットは自分で。アウトプット（実作業）は会社で。というスタイルが一番良いです。

大企業になるとじっくり研修を行ってくれるところもあるようですが、結局のところ手を動かして作業しながら調べて実装していくほうがすぐに身につきます。インプット過多になってしまうと、実際にコードを書く際に生じる問題点がわからないので、実作業でつまずきます。何かしらアウトプットすることは大事です。

エンジニアの勉強は成長実感を得やすいと思います。スラスラと構文を書けたときやロジックをすぐに思いついたときなど、具体的で分かりやすく成長実感を得られる場面が数多くあります。例えば営業だと、プレゼンの方法や話し方などの本を読んだとしても、自分が実践できているのかいないのか、成長出来たのか出来ていないのかが分かりにくい点があります。

なぜならば、プレゼンの方法や話し方は「答え」が無いからです。一方でエンジニアの仕事はプログラムが正しく動けば正解だし、動かなければ不正解という分かりやすい世界になっています。(ただし最善のコードや最善のロジックに正解はありません)

例えば、for文を勉強した後にfor文を使ってプログラムを書けたら、出来なかったことが出来たと確信を持てます。そういう「具体的に何が出来るようになった」というのが分かりやすい点が良いと思います。

自分なりの工夫を探して提案してみる

これはどのような業種・職種かによるかもしれません。金融系などはがっつりウォーターフォール型で、新人エンジニアは設計を提案したり工夫をする余地はないかもしれません。僕はベンチャー企業のスモールチーム(4人)で開発をしているので、上流から下流まですべてに関わるアジャイル型開発をしています。

ここで言いたいことは「こうすればもっと良くなるんじゃないか」「この方がユーザーが使いやすいのではないか」ということを考えることが大事だと思うということです。そのようなビジネス視点やユーザー視点で考える習慣を持つことは、価値あるエンジニアになるためには必須です。

それは何故かと言うと、下流のものからプラットフォーム化されていき、価値ある仕事は上流にシフトしていくからです。例えば、一昔前はウェブサイトをつくるためにウェブサーバーの設定をCGIで行ったりHtml/CSS/javascriptなどを駆使してコードを書いていかなければいけませんでした。

しかし、いまやレンタルサーバーを使えばクリックだけでサーバーを利用することが出来るし、WordpressやWixなどのCMS(Contents Management System)が普及したことでコーディングせずにウェブページを作れるようになりました。

誰でも簡単にウェブページをつくれるという下駄が出来たことで、差別化のポイントはコンテンツになりました。つまり、どのようなメッセージを伝えるためにどのような内容のことを書くか、という企画側に差別化のポイント(=価値)がシフトしてきたのです。

コーディングだけが出来るエンジニアは、今後厳しくなっていくと言われていますし僕もそう思っています。なぜならば、人件費が安く、スキルレベルの高いエンジニアが他国にはたくさんいるからです。わざわざ人件費が高く、スキルが低い日本人を雇うメリットはあまりないでしょう。ビザ手続きやコミュニケーションのコストを差し引いたとしても、インターネットが高速になってきている今、リモートで海外に外注したりフリーランスに安く受けてもらったほうが良いのです。

そこで大事になるポイントが、上流にどれだけコミット出来るかです。どのようなことをすれば目の前のサービスが価値あるものになるのかを考えるということです。とは言えエンジニアになりたての頃は、頼まれたことをしっかりとこなせるようになるのが大事です。一方でそれだけをするのではなく、自分なりに市場の様子など社会の文脈をつかんだ上で、どのような価値をつくれるか考え続けるのが重要だと思うのです。

インフラ・フロントサイド・サーバーサイドをまんべんなく知る

僕はサーバーサイドのエンジニアリングがメインですが、インフラやフロントの基礎的な部分も学習しています。すると、少しずつですが効率よくプログラムが書けるようになってきたのです。それは何故でしょうか。

ソフトウェア開発というのはサッカー型と言われます。サッカー型とは、状況が常に変化し、基本的なポジション（FWとかGKとか）は決まっているものの、柔軟に動くということを指しています。ソフトウェア開発も同じなのです。

例えば「ウェブサービスをより快適にする」というミッションがあったとします。ここに対するアプローチはいくつかあって、ネットワーク速度を改善させるとか(インフラ)、サーバーのスペックを上げるとか(インフラ)、UIをより見やすくするとか(フロント)、無駄なデータの処理を無くして効率化させる(サーバー)とか色々な手法があります。

これらはすべて綿密に連携しており、サーバーサイドで処理した結果をフロントサイドで受け取って動的に表示させたることなど当たり前に行われています。ウェブページのボタンひとつでさえ、どのようなビジュアルにするかというフロント面だけでなく、ボタンを押した後にどうレスポンスさせるかといったサーバー面と連携して考えていく必要があるのです。

そのため、ソフトウェア開発は陸上のリレーのように完全に役割分担が出来るものではありません。だからこそバランス良く基礎的な部分を知った上で、どこか深く専門性を磨いていくというのが重要になってくるのです。そうするとシステムを俯瞰して見ることが出来るので、「サーバーサイドでこのように書けばフロントサイドでうまく処理できるだろう」という見通しを立てることが出来るのです。

どのような仕組みにすればソフトウェア全体がうまく動くのか、という見通しがあるのと無いのでは大違いです。確信を持ってコードを書いたほうがストレスが貯まらないですし、楽しくエンジニアリングを行うことが出来ます。

ブログなどでアウトプットする

僕もまだまだサボりがちですが…。仕事で得た気づきや、便利だと思ったライブラリをブログなどでアウトプットすることは大事だと思います。僕らは何かを学ぶときに本を読んで満足がちです。しかし、読んだだけではすぐに忘れてしまいます。

そこで言語化するという作業が大事になってきます。学んだことを他の人に口頭で説明をするということでも良いんですが、話したことや考えたことが形に残らないのはもったいないですし、相手の時間をもらわなければいけません。しかも、コードは口頭で説明できません。

一方でブログだと自分の思考を残しておくことが出来ますし、他の人に時間をつくってもらう必要がなく気楽です。そのため、新人はブログを初めて見るのがいいと思うのです。新人エンジニアの業務としてブログを書かせている会社も多いと聞きます。学んだことをアウトプットするのは重要です。

エンジニアというのは、イメージを言語化する力を非常に強く求められます。ふんわりとした要望から、1文字のミスも許されず書き方が決まったソースコードに落とし込むのがエンジニアだからです。そのため、自分がぼんやりと思っていること・考えていることを言語化して人に伝えるという作業は実は思考力の訓練にも非常に向いているのです。