Photo by OLCF at ORNL
高村です。
paiza(ギノ)に入社して2年半ぐらい、今は開発チームのリーダーをしています。ITエンジニアとして働き出してからは、大体10年になります。
今回は、新卒でエンジニアになった新人さん・異業種からエンジニアになった人・現在エンジニアを目指している人などへ向けて、自分が10年のキャリアで感じた、この仕事においてやっておくとよいこと・大事なことなどを書いていきます。
みんなが憧れるようなスターエンジニア的な人間では全然ないですけど、一応この10年間自分なりに考えて行動して改善して、トライアンドエラーを繰り返しながら、まあ割と満足のいくエンジニアライフを送ってこれました（そして今後も続けていく予定です）。そんな感じの経験則をもとに書いていきますので、新人エンジニアの方にとって、気付きとなるポイントが一つでもあればと思います。
目次
私の簡単な経歴
経歴：大学(情報系)→メーカー系の大手SIerで8年ほど勤務→paiza(ギノ)に来て2年半ぐらい
技術・勉強において大事なこと
勉強するくせ・調べるくせ・情報収集するくせをつける
何でも「これは仕事のための勉強！」とか「毎日何分必ずこれをやるぞ！」とか思っていると確実に嫌になります。（私はなります）
だから勉強や情報収集に関しては、ゆるく習慣づけできればそれが一番いいんじゃないかと思います。
普段からスマホ依存気味の人や気がつくとインターネットやツイッターを触っている人も多いと思うので、たとえば技術系のアカウントをフォローしてみるとか、Qiita・はてブ・Stackoverflow・POSTD・TeckFeedなどの情報系サイトをチェックしてみるとか…まずは隙間時間にざーっと眺めてみる、みたいなところから始めてみるのもいいと思います。
それだけでも意識せず情報に触れる機会は増えて、「なんか最近このフレームワークの記事がよく流れてくるな、人気出てきたのかな」などといった情報をキャッチできるようになりますからね。何もしてないのとは大違いです。
ITエンジニアの仕事は、今の自分が知っていることだけでは戦っていけません。逆に言えば、毎日少しずつでも自分の知らないものに触れておくだけで武器を増やせます。
今は前述のような無料で手軽に使える情報サイトやニュースアプリなどがありますから、上手に使っていきましょう。
アウトプットはインプットと同じぐらい大事
新人や意識高い系の人に「どんな技術書を読むといいですか！？」って聞かれることが本当によくあります。もちろん、本やネットで情報収集するのはとっても大事だしすばらしいことです。
ただ、インプットだけで終わってしまうともったいないというか…インプットした情報って、アウトプットして初めて自分の血肉になると思います。逆に、インプットだけしていてもその知識が役に立つケースはそんなにないです。使わないとインしたそばから忘れちゃいますしね。特に技術系の知識は、自分で手を動かして使ってみないと身につきません。
せっかくインプットするなら、自分の目的に合ったアウトプットまでをやってみましょう。
アウトプットと言われるとやたらと身構えてしまう人もいますが、
- エンジニアの友人や同僚に話してみる
- コードを写経してみる
だけでも立派なアウトプットです。
もう一歩踏み込んで、
- 動くサービスを作ってみる
- Githubに公開してみる
- ブログに書いて一般公開する
といったこともできるといいですね。
個人的にはブログ（Qiita含む）を書いてみるのがおすすめです。一般公開すると思うとちょっとハードルが高く感じるかもしれませんが、そのぶん「下手な記事書けねえな」という心理になって復習などをするので、結果として学習も深まります。ついでに、有識者からフィードバックがもらえるかもしれません。
私も先日フロントエンドについて学ぶために、Electronを使ったアプリ開発をやってそれをブログにも書いてみました。
paiza.hatenablog.com
特定の言語に依存しない分野の知識はかじっておく
特に情報系出身じゃない人の場合、最初は業務で使う開発言語の書き方を学ぶのに注力するかと思いますが、実務に入るとそれ以外にもさまざまな知識が必要となります。（情報系の学校を出ていて、こんなの全部授業でやったぜって人は飛ばしてください）
具体的に言うとこのへんとか…
-正規表現
- ER図
- オブジェクト指向
- テストの方法論
- デザインパターン
- UML（の中のクラス図・シーケンス図）
上記はサービス内容や仕様言語にかかわらず、ほとんどの業務で役に立つ＆いずれ必要となる知識です。自分で勉強しようと思ったら、このあたりの書籍が役に立つかもしれません。
あと、これに付随してエンジニアとしての一般教養的な知識（基本情報とか応用情報で出てくるような内容）はおさえておきましょう。
実務に直結しない部分もありますが、ハードウエアの話とか、現役エンジニアや情報系出身の人は知っている前提で話してきますし、エンジニアなのにPC内部のこととかがブラックボックス化しちゃってると話にならないので……資格をとる・とらないは別にして、学んだ経験がない人はちょっとずつ勉強していきましょう。
プログラミング言語は3つぐらい押さえておく
例えば静的言語ではJava、動的言語ではRuby、関数型ではHaskell…みたいな感じで、違う分野の言語をおさえておくと、それぞれの利点・欠点・癖などを把握できて、新しい言語に触れるときもスムーズになります。
新人のときから急いで全部完璧にしようとは思わなくていいのですが（そんなの無理だし）、「こういうときはこんな特徴があるこの言語が向いているよね」ぐらいのことを理解できるようになるといいですね。
初心者ほど「自分が好きな一つの言語しかやりたくない！」と言いがちですけど、プログラミング言語って比較できないとメリット・デメリットがわからないんですよ。
いくらサバイバルナイフが好きでも、絶対にライフル銃で戦ったほうがいい現場ってあるじゃないですか。でもライフル銃の存在や使い方を知らないと、的確な武器を選ぶこともできないし。
エンジニアとしての肩書を背負うなら、いろいろな武器（≒技術）の向き・不向きを知って、比較できるようになりましょう。
ちなみに、プログラミング言語の基礎的な知識を学びたいときは動画で学べるpaizaラーニングがおすすめです。
具体的な目標や理想を考えて、定期的に振り返る
目標や理想について考えるのは、自分自身の価値を高めるためにも非常に重要です。
そして私の経験則から言うと、過去の自分と比べて「過去より成長している！」という確認作業はあんまり意味がないです。（メンタルを健康に保つためにはいいかもしれませんけど）
たとえば仕事に一年ぐらい取り組んでいれば、誰だって一年前よりは成長してて当たり前ですよね。それに、過去の自分と比べるだけでは「具体的にこれから何をどう頑張るべきなのか」がわかりません。
それよりは、「3ヶ月以内に〇〇言語を使った××アプリケーションを作れるようになる」みたいな具体的な目標を掲げておいて、3ヶ月経った頃にできてるか振り返る…みたいなほうが急速に成長できます。
目標を立てるのが苦手な人は、まずは「いつまでに」「どんな能力を身につけたいか（≒何ができるようになりたいのか）」を考えてみるのがよいかと思います。また、目標は定期的に見直して、順調に行っているかどうか、目標や取り組みが間違っていないかを考えてみるといいですね。
実務において大事なこと
タスクを見える化し、必要な時間を予測してみる
自分のタスクを分解して明確に見える化し、それぞれかかりそうな時間を予測してみましょう。そして、作業が終わったら実際どれぐらいの時間がかかったかを振り返るくせをつけましょう。
エンジニアの仕事は割と「どれぐらいで終わりそう？」って聞かれるケースが多いです。いずれはきちんと見積もらなければならない仕事も出てきますしね。
で、この「どれぐらいで終わりそうか」は、日ごろから意識しておかないとなかなか想定できないもんです。
別に見積もりを依頼されているわけじゃなくても、手元の作業が「どれぐらいでできそうだな」という予想をメモっておいて、実際に作業が終わったときにどれぐらいかかったかを振り返って、どれぐらい乖離していたのかとか、自分の見積もりの癖（この作業のときは実際より少なく見積もりがちだとか）を考えてみるとよいですね。
開発内容にかかわらず、タスク量に対してかかる工数を見積もるスキルは絶対に必要になってきます。で、このスキルは普段からやってないと身につきません。
また、仕事をしていると予測していなかった作業が急に差し込みで入ってくるケースも多々あります。ここで普段からタスクの工数管理もどきができていれば、大体のかかる予想がつくので慌てないで済みます。「A作業を優先するとB作業は明日になりますけどそれでいいですか」とか言えるようになりますし。
管理方法は紙に書くでも何でもいいと思いますが、TogglやTrelloなどのタスク管理ツールを使うのも便利です。（私はTogglをよく使ってます）
ゴールまでのストーリーを大事にする
社会に出たら「決められたレールの上を歩く」だけの仕事って、そんなにないと思います。レールがあったとしても外れちゃうのが日常茶飯事だし、レールがないからあてずっぽうで進んでも失敗してしまいます。
私はどんな仕事でも大切なのが、まず「ストーリー」を考えることだと思っています。
これは一例ですが、たとえばひとつのプロジェクトを始めるときに、私は
1.この仕事で達成したい目的は何か
2.どんな人が関わる仕事なのか
3.目的達成に向けてどんなアプローチができるか
4.アプローチを変えざるを得ないイベント（たとえばAさんが納得してくれなかったとか)と、違うアプローチ方法を考える
といったことを考えたりします。
サクセスストーリーが描けないときは、いろいろな人に相談してみましょう。そもそもが無理な目標になっている可能性もありますし、目的の定義が間違っていたときは、その都度ストーリーを組み直す必要があります。
そうでなくても、最初に考えたストーリーは、時間や状況とともにどんどん変わっていきます。状況の変化を楽しむぐらいの気持ちでストーリーを組み替えて、常に「この後どんな事象が起こると想定できるか」「どんなパターンがあるか」を考えてみましょう。
これをやっていると、だんだん先読みができるようになってきます。で、先読みができるようになってくると、最初よりは仕事がスムーズに進められるようになってくる（≒成長できている）はずです。
愛用のエディタを持つ
エンジニアは何をするにしてもエディタが必要になりますよね。
今どきのエディタは、自分好みにしてカスタマイズすることでより使いやすくできます。で、常に使うエディタが使いやすいと、生産性が上がります。
快適なエンジニアライフを送りたかったら、適当な素のエディタを使うのではなくぜひ愛用のエディタを持ちましょう。
ちなみに私はVim派です！！！！！！！！！！Vimはいいぞ。
ユニットテストのテストコードを書けるようになる
テストコードを自分で書くようになると、そのシステムのコード自体も、検証しやすく構造化されたわかりやすいコードが書けるようになってきます。
テスト手法は会社によってまちまちかと思いますが、自社開発で自動テストツールを使っている企業だと、新人のうちからテストコードを書く業務もあるかと思います。
テストが全部手動でテストコードも書けないような職場からは早めに脱出しましょう。
自分のテリトリーを線引しすぎない
プログラミング言語の話にも通じますが、自分の引き出しは積極的に増やしていきましょう。（※心身の健康を害さない範囲で）
たとえば自分はサーバサイドしか作りません、だからフロントエンドもネットワークもインフラも全然知りません…という状態だと自分の成長はストップしてしまうし、強みもなくなってしまいます。（ていうかそもそもそんな人はエンジニアとして長くやっていけないので……）
自分の範囲からちょっとはみ出して、グレーゾーンから知識や経験を広げていくと、そのぶん他の人よりも成長できます。
「なぜ？」を大事にして課題発見できるようになる
新人の頃は「与えられた課題を教えられた手順通りに解決する仕事」が多いかもしれませんが、エンジニアであればいずれ「自分で課題を見つけて自分で改善できる」ようになっていかなければなりません。（エンジニアに限った話ではないと思いますが）
とはいえ、何の疑問も持たずにぼーっとすごしていると問題なんて見つかりませんよね。
たとえば、毎日退社前に15分かけて日報を書いていたとします。何にも考えずに毎日書いていると「何が問題なの？」って感じだとは思いますが、「もっと日報に書ける時間を短縮して早く帰れないだろうか？」と考えて（課題）「退社前に一から書くのではなく日報に書く内容を業務の合間にメモしておく」（改善策）だけでも、立派に自分で課題を発見して、改善策の実施につなげられていますよね。
問題・課題というのは、目的・理想と現状のギャップに気付いたときに発見できるものです。
手元の仕事に対しても「視点を変えて課題点を見つけ、改善策を考えてみるくせ」をつけておくと、実際に大きな問題に遭遇したときにも対応しやすくなります。
PDCAを回して経験から学びまくる
ある開発プロジェクトに3年参加した人が10人いたとして、全員が同じくらい成長しているかというと、それは違いますよね。むしろ同じ仕事に取り組んでも、全然成長しない人もいれば、驚くほど成長できる人もいます。
これ、私は業務に対して受動的ではなく能動的に取り組めるかどうかにかかっていると思っています。すべてを受け身にとらえていると、得られるものはありません。
普段の業務における経験に対しても、主体性を持って分析し、次回もっとうまくやるにはどうすればいいか？を繰り返し考えながら仕事していくのが大事なんじゃないいでしょうか。
前述の目標ともつながりますが、「自分の行動に対する目標を決め」「それを達成できるように行動し」「結果どうだったのか、達成できたらどこがよかったのか、できなかったら何が悪かったのか」を分析すると、確実に次につなげていくことができます。
健全な心身の維持において大事なこと
思いやりをもって行動する
なんか道徳の授業みたいになってきましたが、この仕事に関して言いたいのは「相手の立場になって考えてみるのが重要」ということです。
たとえば、同じシステムにかかわる人でも、発注者や実際のユーザー、コードを書く人とプロジェクトをマネジメントする人では、考えることも役割も違いますよね。
例えば「ユーザー的にはこうしたほうが使いやすいだろうな」「営業だったらこう考えるだろうな」「この機能を一人で担当するのは大変だろうな」などなど……自分本位の言動ではなく、相手の役割や考えにも想像力を働かせてみましょう。
これは道徳的な話ではなく、こういった想像を続けていると物事を俯瞰的＆客観的に見られるようになってきて、仕事をスムーズに進めたりトラブルなく管理したりするのに役立ちます。
「人が何を考えているのかよくわかんない」という人は、いろいろな立場の相手の言動をメモって後から「どうしてこのような言動をとったのか、背景には何が考えられるか」を考えてみたり、近くにいる優しい先輩に聞いてみたりするとだんだんわかってくると思います。
人間は自分本位な生き物ですが、当然ですが会社も世の中もエンジニアだけで形成されているわけではありません。いろいろな人がいろいろな役割で働いているから成り立っています。相手の立場や役割をおもんぱかろうとしてみると、世界が変わって見えるはずです。
体調管理に気をつける
一文で言うと、よく寝て、よく遊び、しっかり食べて適度な運動をしましょう。そして何より、頑張りすぎて体調を崩してしまう前に休みましょう。
いろいろ言ってますが私も前職にいた頃、仕事もプライベートも急激に忙しくなってぶっ倒れてしまった経験があります。休みましょう。（二回目）
ギノ（paiza）には変態健康オタクのエンジニアもいて、彼が先日このブログでも健康に関する記事を書いていたので興味のある人は読んでみてください。私も一部参考にしています。オオバコ水（泥）は飲みませんが。
paiza.hatenablog.com
まとめ
今回書いてみたことは、もちろん私個人の経験によるものなので当てはまらないものもあるかと思いますし、会社によってできること・できないこともあると思います。
そのへんは取捨選択していただければと思いますが、一応は割と汎用的な内容を書いたつもりなので、新人エンジニアの方にとって、参考になる項目が一つでもあったなら幸いです。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
