新卒3年目のWebエンジニアが1・2年目にやってきた7つのこと

この記事は[エイチームブライズアドベントカレンダー](https://qiita.com/advent-calendar/2017/a-t-brides)19日目の記事です。

筆者個人の活動としてGoogle Apps Script解説アドベントカレンダーもやっていますので、興味のある方は是非。
[Google Apps Scriptを実例交えて基礎からざっくり学ぶ Advent Calendar 2017](https://qiita.com/advent-calendar/2017/gas_beginner)

# はじめに　この記事について

新卒3年目ともなると、後輩エンジニアや新卒採用で会う学生から「1年目や2年目の頃って、どういうことされていましたか？」と聞かれるようになりました。（後輩は主に自身の行動の参考として、学生はその会社でどんなことができるのか知りたい、というのが意図でしょう）
ですが筆者は計画性があまり無く、その時々でできることを必死にやってきたので、あまり上手く受け答えできている自信が無いです…。

そこで、Webエンジニアとして正社員になってから今まで成長する為に**やってきたこと**や、**もっとやっておけばよかったなぁ**と思うことも交えつつ、3年目になって思うことをつらつらと書き連ねてみました。

7つのことと銘打っていますがタイトル詐欺で、今までの行動で説明しやすいものをピックアップしたら7つになっただけです。
前述の通りあまり計画性が無い筆者の為、事前に決めていたわけでも常に意識して動いていたわけではないです。

# Caution!!!!

<img src="https://qiita-image-store.s3.amazonaws.com/0/199678/d05836ef-f750-5f28-075b-3b5c819282b1.png" width="100">

**この記事の内容を、全て無条件に推奨するものではありません**。
会社や部署によって求められる方向性が異なるので、会社の求めている方向と、自身の行動の方向性について認識を合わせることが大切かと思います。

その為、書いてあることを額面通りに受け取るのではなく、ご自身に当てはめた時にどうなるか考えるきっかけに、少しでもなってくれると嬉しいなと思います。

# あんた誰よ

顔と体型から貫禄に定評のある、[エイチームブライズ](http://brides.a-tm.co.jp/)新卒3年目のWebエンジニアです。

新卒1年目：自社Webサービスの開発・運営（phpフレームワーク。主にフロント・バックエンドの開発）。夏頃に本番環境のroot権限をいただき、リリースを任せてもらうように。冬頃に社内の新規事業案コンテストに挑戦。
新卒2年目：1年目最後の事業案コンテストで提案した企画の開発・リリースを行う。冬頃から既存の自社Webサービス開発チームのリーダーとして役職・役割をいただく。インターンシップや新卒採用の面接官として、採用活動に携わる。
新卒3年目：チームとして成長していくこと・成果を上げること、チームマネジメントに苦戦しつつ日々奮闘中。

そんな私ですが、新卒として入社する1年半前（大学3年の夏、今から4年前）にWebエンジニアのアルバイトとして今の会社で働き始めた当時は、Webプログラミング歴1年弱ということもあり
「**php使えます！フレームワーク？？ってなんですか？**」
「**バージョン管理？subversion？git？知らない子ですね…**」
「**linuxコマンド？そもそもWindowsとMac以外触ったことないです**」
「**SQL？select * from ~~なら書けますよ**」
「**jQuery？調べながら書けます（ｷﾘｯ**」
という、我ながら壊滅的な技術力でした。（よく採用していただいたものです…:sweat_smile:）

一流のエンジニアにはまだまだ遠いですが、思い返すのも恥ずかしい当時から見るとだいぶ成長してきましたし、たくさんの挑戦の機会をいただいたなと感じます。

# やってきたこと

## その1．スピードを極める

![speed_fast_rabbit.png](https://qiita-image-store.s3.amazonaws.com/0/199678/70dd0d79-96d7-bdcd-1b02-9844a21c29a9.png)

エンジニアとして、必ず求められるものってなんでしょう？

企画力だとか課題解決力、ユーザー視点、コミュニケーション能力等と答える人も多いと思います。
それも間違いじゃないと思いますし、弊社でも全て大いに必要とされる能力です。

が、少なくともエンジニアとして、どんな業種・会社でも、どこに行っても共通で求められることは**アウトプットのスピード**だと思います。

### スピード向上によって得られる恩恵

スピードが早ければ、世の中に より早く価値あるものを提供できる。
スピードが早ければ、浮いた時間でテストを念入りに行えるので不具合を減らせる。
スピードが早ければ、プラスαの仕事をして、期待を大きく超えた感動を与えるものが作れる。
等…
（新卒研修の際に聞いた、弊社スーパープログラマの受け売りです）

早くアウトプットする為には言語やフレームワークに対する豊富な知識が必要。
少ないコード量で効率よくコーディングする必要があるので、必然的に高い技術レベルが要求されます。

### スピードの上げ方

プログラミングは大学に入ってから学びましたが、幸い小学生の頃からPCと共に生きてきたこともあり、タイピングスピードには自信がありました。あとは個々の作業のスピードアップ、コードリーディングやコーディングのスピードアップ。これは正直「ひたすら経験」かなと思います。

爆速エンジニアというテーマで、弊社グループ会社「エイチーム引越し侍」のWebエンジニアが[爆速エンジニアの勧め～まずは導入～](https://qiita.com/shgkt/items/4eebbde37c9bbbe25ea0)という記事を書いていますので、そちらも参考になると思います。

スピードや技術力が上がってくると、より難易度の高い業務も任せてもらえるようになり、以下に挙げるような行動を行えるだけの余裕も出てきました。

## その2．先輩のスキルを盗む

![computer_hacker_white1.png](https://qiita-image-store.s3.amazonaws.com/0/199678/b8632f1f-e35c-b825-b002-44752086afc4.png)

### スキルを盗む為にやっていたこと

弊社ではGitLab（OSS版GitHubのようなもの）のMerge Request（Pull Requestに相当）を使って、エンジニア2人ペアで双方のソースレビューを行っています。
ペア以外のエンジニアが出しているMerge Requestを見る義務は無いのですが、特に新卒1年目の頃は**自部署全てのエンジニアのMerge Requestを読んで**いました（エンジニアの詳しい人数は言えませんが、両手で数えられるぐらい）。
**先輩はどんな書き方をしているのか**、**そこに対してどんな指摘を貰っているのか**見て学びました。

また、弊社ではエンジニアの責任者が本番環境へデプロイ（リリース作業）する際、全てのdiffに目を通して品質の最終確認をするのですが、そのタイミングで自身も全てのdiffを確認して、責任者がどういった判断・指摘をするのか見て学んでいる時期もありました（今は、私がその最終判断をする役割をいただいています）。

最初はどちらもただ見て学ぶだけでしたが、理解が深まるにつれて、ペア以外のMerge Requestでも**気になった点をガンガン質問・指摘**したり、リリース時に横から補足の指摘ができるようになっていきました。

### 先輩のコードを読むこと

私の場合、技術書を読んでも具体的な活用ケースが想像しづらく、レビューで指摘されたミスを直すだけでは受け身になってしまうので（これら2つも、もちろん大切なことです！やりましょう！）、時間の許す限り先輩エンジニアのコードを読んでいました。
全員分は厳しくとも、特に「**この人のコード読みやすいな**」「**この人の指摘的確だな**」と思うエンジニアを参考にすると良いかもしれません。

そしてこれらのことは、「その1」の早さを体現して、やるべきことを終わらせているスピード感は必要だと思います。

## その3．見て見ぬふりをしない

![shingou_mushi.png](https://qiita-image-store.s3.amazonaws.com/0/199678/35095987-9220-385d-994b-e93ee89d89bc.png)

技術力も付いてきて余裕が出てくると、「もっとこうなればいいのにな」「自分だったらこうするのにな」と、チームの動き方や開発手法が気になってきました。

### 必ずしも自ら手を動かす必要はない

新卒1・2年目の時は、つい**自分が手を動かすことで解決しようと考えがち**でした。

「**1年目だから、チームに対して提言するなんておこがましい（角が立つ）**」みたいなことを考えたりしますよね。その謙虚な思考はあながち間違いではないと思います。

そして**「自分にできない」と判断すると、あたかもイコール「組織にとってできないこと」**だと勝手に判断して諦めていました。

そういう場面に出くわした場合はまず、上司に相談・提案をするようにしました。
「こういう理由から、こうした方が良いと思う」と伝えることで、その上司からチームメンバーに伝達してくれたり、更なる解決法のヒントをくれて、そのうち自らチームに発信できるようになっていきました。

一時期、非エンジニアの上司の元で仕事をしていたのですが、その時に「**上司を使え**」とよく言われたものです。当時はあまり意味を理解していなかったですが、今考えると納得です。

エンジニアであっても、**手を動かす以外に頭と口を動かすことも、立派な貢献**だと思います。
伝え方の**配慮は大切ですが、遠慮は無用**と割り切って働いており、それを認めてもらえる環境に感謝です。

## その4．積極的に仕事を取りに行く

![shigoto_tekipaki.png](https://qiita-image-store.s3.amazonaws.com/0/199678/9f3beaa7-203e-1480-889c-71018500f04d.png)

これも今までと同様、「アウトプットのスピードを早く維持できている」ことが前提になります。

私は日々の業務の中で、（社会人としては当然のことですが）積極的に仕事を取りに行くようにしていました。

### チームに対する依頼に即レス

弊社はエンジニア以外のスタッフも多数在籍しているので、日々エンジニアのメーリングリストには新規の開発依頼、不具合対応依頼等がたくさん来ます。
それに対し、（返答可能なものに対しては）真っ先に返信・対応をしていました。

結果として自身の経験・技術力だけでなくチームとしての解決スピードもアップしますし、「トラブルが起きた時に声をかけてみよう」という、非エンジニアからの信頼も少しずつ獲得できたように思います。

ただ、自らがリーダーの立場になると、以前よりミーティングや面接等で席を外すことが圧倒的に増えて即レスが難しくなってきました。
そういう時にメンバーが即対応してくれているととても助かるので、新人にこそできる仕事なのかなと思います。

### 不具合通知が来たらすぐ調査・対応

上記とケースと似ているのですが、弊社では当然のことながら、500系エラー等致命的なものに関しては自動で通知されるシステムになっています。
それに対してもなるべく早くレスポンスを返すことを心掛けていました。

また、入社当時は通知がメールで来る仕組みになっており気付くのが遅れがちだった為、Chatworkへの通知移行を推進・実装しました。
このように、知らず知らずのうちに依頼された業務をこなすだけでなく、「こういうものあると便利なので作っていいですか？」と自ら提案し機会を作ることが増えていったように思います。

## その5．インプットを増やし、アウトプットする

![cafe_nomad_man.png](https://qiita-image-store.s3.amazonaws.com/0/199678/c0c2f68e-002e-3b0b-225d-8afe0d898288.png)

「新しい技術が出たからとりあえず触ってみる」という、モチベーションの高いエンジニアは多いと感じています。
私は困ったことにあまりそういったモチベーションが上がらないので、素直に凄いなと日々尊敬しています。

### ニュースを見る

ベタですが、技術に関するネット記事はfeedlyで購読したり、Googleのトップニュースを読むことが多いです。
あとはなるべく毎日「ワールドビジネスサテライト」を見たり。自分の専門外である技術ネタも頻繁に取り上げられる印象です。

### 技術のインプットを欠かさない

私は「アウトプットする目的ありきでインプットする」方がモチベーション高く保てるタイプなんだろうな、と最近自覚してきました。
あくまでも技術は手段として、「こういうことを実現したいんだけど、それにはどういう手法を使えば良いのだろう？」と調べて学ぶことが多いです。

そして目標と手段が決まると、寝る間も惜しんで1日中パソコンに齧りついてプログラムを書いていたりします。
逆にそういった目標が見つからないと、数ヶ月間仕事以外でプログラミングをしないこともあります。

常にこういった目標を掲げていれば、今より更に技術レベルが上がっていたんだろうなと感じます。

### 非エンジニアと積極的にコミュニケーションを取る

定時を過ぎた後、たまに非エンジニアの席に行って喋ることがあります。
その会話の中で「正式に依頼するほどではないけど困っていること」を、我々エンジニアの技術で解決できることも多いです。

また、弊社は同じオフィスで別の事業部も働いている為、ゲームプログラマやデザイナー等の別業界で働く同期と会話をして技術や事業部の制度を参考にすることもあります。

（私は引きこもりなので滅多に行きませんが）積極的に社外の勉強会に行っているエンジニアも多いです。
このように外に目を向けて行動すると、結構新たな視点でのアドバイスをもらったり、アイデアが出てくることも多いと感じます。

## 6．絶えず挑戦する

### 自ら高い目標を掲げて実行する

![business_senryaku_sakuryaku_man.png](https://qiita-image-store.s3.amazonaws.com/0/199678/bf69a529-1916-f022-9fd0-47148e20b716.png)

一度ゴールを決めてしまえば、あとは走り出すだけです。
挑戦する機会があれば、自ら手を上げて挑戦するようにしていました。

現在も自身のアウトプット力を付けるために[Google Apps Scriptに関するアドベントカレンダー](https://qiita.com/advent-calendar/2017/gas_beginner)を一人で始めました。記事を書いていると、アウトプットすることでより理解が深まるなと改めて感じている今日このごろです。

好きな格言で**A Smooth Sea Never Made a Skillful Sailor（穏やかな海は良い船乗りを育てない）**という言葉があるのですが、困難な状況に身を置くことで成長ができるのかなと思います。

## 7．素直になる

![nouka_ase_fuku.png](https://qiita-image-store.s3.amazonaws.com/0/199678/819c1015-ffc5-d0c2-39a5-d7a0ded4d916.png)

さて、最後の項目です。
今回の記事を読んで、どう感じましたか？

「全部当然のことだからやっているよ」という方、お時間を取らせてしまい申し訳ないです。
「うちの会社はそういう風土じゃないから」という方も、当然いらっしゃると思います。

こういう時に「素直さ」が出てくるのかなと思います。
「確かにそういう見方もできる」「自分だったらこう活かせる」と受け止めて、自身の行動に変えられる素直さがあると成長が早いように感じます。

私は新卒研修で「全く素直じゃない」というお墨付きをいただいたので:sweat_smile:全く自信がありませんが…最近は少しマシになってきていると信じたいです。

# 終わりに

qiitaで似たような記事を探したのですが、新卒や事業責任者、CTOといった方の経験談は出てきても、案外新卒3年目ぐらいの記事が無かったので書いてみました。

振り返ってみると多種多様なことをやってきたと感じると共に、その挑戦ができる環境・周囲の理解があってこそだなと改めて感じます。
この場を借りてお礼申し上げます。いつも本当にありがとうございます。

現在は1・2年目とは大きく異なり、**いかに自分の手を動かさずに成果を出すか、メンバーに活躍してもらうか**等を日々考えて行動しています。
自分で手を動かすことは得意なのですが、全く違う能力が求められるので苦戦中です。また何か掴めたら、こういった内容の投稿をするかもしれません。

拙い文章ですが、ここまで読んでいただきありがとうございました。

# お知らせ

エイチームブライズでは一緒に活躍してくれる優秀な人材を募集中です。
興味のある方はぜひとも[エイチームグループ採用ページ](http://www.a-tm.co.jp/recruit/)（[Webエンジニア詳細ページ](http://www.a-tm.co.jp/recruit/requirements/career/lifestylesupport-webengineer/)）よりお問い合わせ下さい。

# 宣伝

繰り返しになりますが、筆者個人の活動としてGoogle Apps Script解説アドベントカレンダーもやっていますので、興味のある方は是非。
[Google Apps Scriptを実例交えて基礎からざっくり学ぶ Advent Calendar 2017](https://qiita.com/advent-calendar/2017/gas_beginner)

# 明日

エイチームブライズアドベントカレンダー19日目の記事は、いかがでしたでしょうか。
明日は同期のWebデザイナー、@nishio1873が「なにか書きます！」とのことです。
発信力の高い彼のことなので、きっとステキな記事を書いてくれるはずです。お楽しみに！