駆け出しエンジニアの頃に意識してたら爆速で成長できたこと業務編

大学一年の頃にインターンとしてこの業界に入って約2年が立った。何もわからない田舎者だった2年前と比べると、随分と色々な知識をつけることができたように思う。

僕は正社員としては働いたことがまだないので、この記事の説得力がやや落ちることにはなりそうだが、誰かの指針になればと思い、本記事を執筆するに至った。

インターン生にしてはけっこう意識が高めな気がするが、特にエンジニア経験1年目の場合は、実力が足りてないことが多いわけで、意識が高くなかったらどこで勝負するの、という感じである。

以下に挙げるポイントをすべて抑えることができたのなら、インターンだろうが社員だろうが、猛烈な勢いで成長することができるはず。できる人からすれば当たり前なんだけど、その当たり前ができてない人も結構いる気がしたので。ってか自分は全然できてなかった甘ちゃんでした。

「自分初心者だから〜」はもう許されない

エンジニアに限らず、「自分はまだ経験浅いので〜」と言っていまう人がいるが、相手からすると「うっせえそんなこと知らねえよ」という感じである。

まだ理解していない部分で、業務に直結する領域があるのなら、自主的に勉強するのは当たり前だし、それがお金をもらう、ということでは？

自分のコードに責任を持つ

そんな当たり前のことか、という話で恐縮だが、自分の担当した領域のコードは、死ぬ気でチェックする。バグがないかあらゆるケースを想定するし、もちろんテストも書く。

コードレビューでOKをもらったからといって、バグが出ない完璧なコードというわけではない。

レビューでOKもらったんですが、本番でバグっちゃいました、許してね♪、は許されない。まあ、当たり前of当たり前なんだけどw

わからないことは恥ではない

「自分初心者だから〜」という言い訳は許されない、と書いた。とはいっても、わからないことがあるのは恥ではない。というか当たり前。先に入社しているエンジニアでも、ここの領域は得意だけど、こっちの領域は苦手だな、あまり知らないな、というのはよくある。

これから勉強すればいいだけのこと。未知を受け入れる姿勢が大事。

わからなかったらすぐ聞く

エラーにつまずいて、うんうんと唸っているうちに数時間が経過した、というのはプログラマーにとっては珍しい話ではない。

自分で調べて調べて、なんとかエラーを解決する、という行為は一見よさそうに見えるが、それは自分で自主的にプログラムを書いているときにやればよい。

お金をもらって働いているのなら、あなたの時間は会社のものであるし、限られた時間の中で、最大限のアウトプットを出そうとするべきである。

僕の場合、数時間ウンウンと解決できなかったエラーが、先輩に聞いたら1分で解決したことがたくさんあったので、それ以来わからなかったらすぐ質問をするようにしている。

ということで、つまずいたらすぐに周りのエンジニアに質問してみるといい。意外と親切に手取り足取り教えてもらえる場合が大半なので。

エラーの原因を口に出して説明しているうちに、自分の頭が整理されてエラーが解決される、というのもよくある話（僕はめっちゃある）。

どこまで調べてもわからなかったら質問するか、という自分ルールを決める

Aという箇所でエラーが出ている

↓

Aで使われているBというライブラリの挙動について、自分の知識が不足している

↓

Bについて調べていると、そもそもCという概念を理解している必要がありそう

こんな感じで、調べても調べても終わりが見えず、いつの間にか途方に暮れていた、という現象が駆け出しのときはよく発生する。

僕が初めて現場に入ったときは、業務で使われている単語が片っ端から意味不明でめちゃめちゃ大変だった。

わからないことを調べるのはいいのだけど、あまりにも業務時間中にそれに没頭するのはいただけない。自分の時間でやれ、という話なので。

駆け出しの頃は、全てが全てエラーの原因に見えてしまうので、あるラインまでいっても問題が解決しなかったら、スパッと諦めて人に聞く、というのがおすすめ。

ボーダーラインの決め方はなんでもいいのだが、個人的にこれはいいな、と思っているのが、「5回調べてもわからなかったら聞く」というやり方である。シンプルでわかりやすい。

質問をするということは、その人の時間をもらうということ

「何もしてないのに壊れた」、「なんかよくわからないけどエラーが出た」なんて質問をしてもいい相手は、プログラミングスクールの講師ぐらいである。

そういう質問は、相手の立場になって物事が見えていない・見ようとしていないというマインドセットの現れであって、非常によろしくない。

質問をするということは、その人の時間をもらうということ、自分に対しての教育コストを増やすということである。であるならば、なるべくそのコストを最小化しようとするのは自然の流れ。

かといって、相手の時間を奪うことに神経質になって、質問をするのをためらってしまう。かといって何も質問をしないと、エラーが解決できず、チームに迷惑がかかる。

気遣いと図々しさ、という相反する行動規範を自分のうちに内包させることができると、精神衛生的にも、業務の上でも、Good。

質問するときは、質問テンプレートを踏襲する

全段落を見て、じゃあ、質問する相手のコストを最小化させる方法とはなんなのか、と思った方のために、質問テンプレートを用意した。

これは僕が、誰かに質問するときに守っている型なのだが、これに従えば、大抵の場合は質問にかかる時間が短くなるのでよい。このテンプレを埋められるようにデバッグをすると、自然とプログラマーの習慣が身につくので、いつのまにかエラー解決力が向上しているはず。

自分のタスクの説明をざっくりわかりやすく（例: 〇〇というAPIを追加していて~、APIのテストを追懐して~、みたいな）
エラーの起こる箇所、エラーの起こるタイミング、エラーの挙動、エラーの発生条件（例: 〇〇というメソッドのところでつまずく、条件Aではうまくいくが、条件Bではうまくいかないなど）
デバッグのために試したこと（例: consoleデバッグ、printデバッグ、ブレークポイントを設定して、エラーの起こる前後での処理を見たかどうか、など）
追加で調べたこと。ライブラリの挙動とか、概念の理解とか
1. 公式のドキュメントを読んだかどうか
2. 同じメソッド、似たような処理をしている、プロジェクト内の他のコードを調べたか
仮説検証してみた結果（〇〇のところに、xxという処理を追加すればうまくいくと思ったのだが、ダメだった、など）
うっかりミス、ケアレスミスの可能性はないか（typo, 大文字小文字違い、実は必要なメソッドをimportしてないみたいな）

この方式に則ってやれば、駆け出しエンジニアが遭遇するだいたいのエラーは、他のエンジニアに聞けば一瞬で解決されるケースが多い。

この1 ~ 6の流れを、質問するときに数分でざっくりと説明できるようになると、お互いの質問コストがかなり下がる。

調べれば、質問の型、というのはいくらでも出てくるので、自分に合うものを使ってみるとよさげ。

報酬に見合うアウトプットを出せているか

なぜ会社に雇ってもらえるのか、それは、もらっている給料以上のリターンを会社にもたらしているからである。

これはベテランのエンジニアであろうが、駆け出しのエンジニアであろうが同じ。

ということは、給料分の、macbookを支給してもらっている分の、会社の賃貸しているオフィスの一部を専有している分の、リターンを会社にもたらしているか、プロとして意識するべきだろう。

仮に一日働いて、そのアウトプットがコード1行だとしたら、果たしてその1行は対価に見合ったものなのか、自分に問いかける。

これを習慣にすると、自分の給料分のアウトプットを出せていない、ということに気づく。少なくとも僕はそうだった。

そして焦る。実力が足りていないことに焦りまくる。実力に不相応な待遇を受けていることを痛感する。そして、対価に見合ったアウトプットを出すために、日夜猛烈な勢いで勉強することになる。

これが、駆け出しエンジニアが凄まじい勢いで成長するための、driving forceである。ちょっとメンタル的にはキツイんだけど、成長には痛みが伴うもの。

情報収集。業界知識をインプットする。テック系のニュースを読む。わからないことがあったら調べまくる

とにかくインプットしてインプットしてインプット。知らない単語が出てきたらすぐに調べる、毎日IT業界のトレンドを追う、IT業界の力関係を認識する、など、呼吸をするようにできるようになろう。

ここらへんのノウハウは調べればすぐ出てくるので詳しくは書かないが、エンジニアであれば、日本の経済のトレンド、世界の経済のトレンド、IT技術のトレンド（日本も世界も同じなので分類はしない）、あたりにはアンテナを張っておくべきでは。

休日はとにかく勉強・コードを書く

大学受験では、一日10時間勉強する、みたいなケースが多いと思うが、そういう勢いでプログラミングも勉強しよう。

受験勉強には平日も休日もないのと同様に、駆け出しエンジニアは、平日業務が終わってからも、休日になっても、業務のキャッチアップに時間を割かないと、キツイ。

勉強をすれば、業務の生産性が上がる→早く帰れるようになる→自分の勉強にもっと時間を使えるようになる→もっと生産性が上がる→楽しい、という正のスパイラルに突入することができる。

知っていることがどんどん増えてきて、点と点がつながるようになるのは、めちゃめちゃ気持ちいい。

筋トレは一年目が一番体が大きくなる時期だそう。これは、体が筋トレの刺激になれていないため、負荷の効率が高くなる、みたいな理由らしいのだが、エンジニアにも同じことが言える。

業界に入っての一年目はボーナスタイムである。わからないことだらけでとにかく大変。

業務でのかけている知識を補うため、勉強しまくる。生活習慣を効率化させて無駄を減らし、とにかく勉強に充てる時間を増やそうと画策する。

これらすべてが組み合わさると劇的に成長する。逆にいうと、1年目でこの上昇気流に乗れないと、ダレたまま2年目を迎えることになる。

まあそれは究極的には個人の自由なんだけど、この記事を読んでいる方だったら、前者の人生を歩みたいはず。

Githubに草を咲かせまくる

githubにコードをコミットしたりしていると、メインページに草が生えてくる。Githubにはcontributionsという概念があり、コミットしたり、レビューしたりすると、それがcontributionとしてカウントされるというわけ。

↓は僕のここ一年の活動の経過なのだが、いい感じに草が生えている。コミットして草を生やすために毎日勉強する、というのは、モチベーション維持の方法として、めちゃめちゃおすすめ。

なお、Githubのデフォルトの設定では、プライベートリポジトリでのcontributionsがカウントされないので、設定をいじって、プライベートリポジトリのcontributionもカウントするようにすることを推奨する。

コードを公開はしたくないけど、活動の足跡だけは残したい、という場合にうってつけ。

ちなみに自分は、自作ブログもGitで管理しているので、記事をアップするだけでも、1コミットになる。ブログ記事執筆のモチベにもなるので最高。

1つ注意点があるとすれば、草を生やそうとするあまり、コミットを区切りまくってしまうこと。自分の活動を水増しするようなもので、本末転倒になるので、そこだけは気をつけよう。

最後に

今振り返ると、業務未経験からの半年 ~ 1年間は、キャッチアップの連続で、調べても調べてもわからないことが山のように出てくる毎日だった。

アサインされたタスクはまじで全然終わらなかったし、自分の1日よりも、社員の方のアウトプット1時間のほうが生産性高かった、なんてこともよくあった。

自分はインターン生ということで、社員の方からはそんなに気負わなくて良いとも言われていたし、本当に色々よくしてもらっていた。それでも、やっぱりプレッシャーは感じるし、感じないとダメだろう。

エンジニアは最初の壁が最も高い。何もわからない状態から、とりあえず仕事で使い物になるレベルまでは、けっこう困難な道。ただ、そこを乗り越えると、自走力がついて、後は自分で勝手にどこまでも進めるようになるので、ぜひとも一緒に頑張りましょう。

駆け出しエンジニアの頃に意識してたら爆速で成長できたこと 業務編