組み込み系を専攻していた僕がWEBの会社に新卒入社して生き抜くために実施した6つのこと

はじめに

気がつけば今年も四分の一が終わり、少しずつ春の足音が聞こえてきましたね。
この時期は環境が大きく変わる人も多く、特に新社会人になるみんなは「楽しみ」だったり「不安」だったりとそわそわしているに違いありません。
僕も14卒のエンジニアとして今の会社に入社したのですが、この時期は不安でいっぱいでした。

この記事はなんなの？

学生時代、組み込み系を専攻していた僕が、WEBの会社に新卒入社して生き抜くために

• 「学生時代から社会人になって変えたこと」

を綴っています。

入社当時の僕のスキルセット

• 「C言語の基本的な構文がわかる」
• 「Javaを少し触った事がある」

本当にこのレベルでした。
学生時代は組み込み系を専攻していたこともあり授業が「回路設計」「ハードウェア設計」中心だったのでWEB系のスキルは殆ど無かったのです。

「こんなスキルセットで本当にやっていけるのだろうか…？」「仕事についていけるのだろうか…」と不安になっていた事を覚えています。
そんな僕がWEB業界でエンジニアとしてやっていくために、実施した**「6つ」**のことをその時の心境だったり、その際に読んだ技術書だったりをご紹介しながら綴っています。
拙い文章ではありますが、少しでもみなさんの不安の解消、参考になる箇所があれば幸いです。

インプット量をとにかく増やした

学生時代

恥ずかしながら、殆ど技術書を読まず、授業も受動的に聞いている事が多かったです…。
技術書なんて読まなくてもググれば大抵出てくるし、授業でわからない箇所があってもそのまま…。
今思えば本当にもったいない事をしてました。

社会人になって

社会人になって一番大きく変化したなーと思うのが学生時代に比べてインプットする量が圧倒的に増えたことです。

全然読んでこなかった技術書を読むようにした

入社前に会社から幾つかの技術書をいただいたのですが、学生時代全く読んでこなかった癖が抜けず、入社後もデスクに陳列していました。
そんな状況を見かねた先輩が

先輩「この技術書ずっと綺麗なままだけど読まないの？」
僕  「そうですね…。読んでみます…。」
先輩「絶対この技術書は絶対読んだ方が良いよ。俺も読んだけどめっちゃ良い技術書だったよ」

と先輩に指摘されてやっと僕は重い腰を上げ、その技術書を読みました。
その技術書はプログラミングの基本的なことが丁寧に解説されており、「学生時代習わなかった事」や「そもそも気づきもしなかった事」が解説されていました。
この「そもそも気づきもしなかった事」に気づけた事が僕の中では非常に大きかったのです。
今まで解らない事はググッて何とかしていたのですが、それって結局知ってる範囲でしか知識がつかないんですよね。
それが技術書を読むことで知らない範囲を知ることが出来たのは僕の中で大きな発見でした。
後述で幾つか技術書を紹介するのですが、まずは技術書を読むきっかけを、早めのうちに掴む事が出来たのは本当に良かったです。(先輩有難うございます！)

勉強会に参加するようにした

社内・社外の勉強会に参加することで、普段の業務だと「気づきもしなかった事」を発見できたり、「考え方」をインプット出来る機会が非常に多くなりました。
また、他社の事例を聞くことでより視野を広げるきっかけになることもあります。(開発手法など)

社外の勉強会に参加、交流することで人脈を広げることも出来るので勉強会に参加する(特に若手のうちは)ほうが良いと感じました。

まとめ

• 技術書読むことで知らない範囲を知ることが出来る
• 勉強会で「考え方」や「他社の事例」を聞くことで視野を広げる事が出来る

アウトプットする機会を増やした

学生時代

学生時代はインプットすることはあれど、アウトプットすることは殆ど無かったです。
正直大人数の前で話すのは苦手だったし、記事なんて書いたことありませんでした。

社会人になって

アウトプットすることのメリットとしては

• 思考を整理出来る
• フィードバックを得られる
• 自分のスキルセットをアピールする事が出来る

などあると思いますが、入社当時は「怒られたらどうしよう…」「誰も見てくれなかったらやだな…」みたいな不安があって中々アウトプット出来ませんでした。
でも、これじゃ学生時代と何も変わらないと思い、まずは一記事Qiitaに投稿してみました。

Qiitaにとりあえず一記事投稿してみた

「まずは何かアウトプットしてみる！」ということでQiitaに記事を投稿しようと思いました。
はじめての記事は一番最初に任された仕事にしてみたのですが、全然纏まらなかったんです…。
それって自分自身もまだ完全には理解しきってなかったってことなんですよね。
それでも何とか書き終えた時には、自分の中でも大分整理されて人に説明できる程度にはなっていました。
それが自分の中では大きな発見で、アウトプットしようとすることで思考整理されることを身を持って実感しました。

今思えば早いうちにQiitaに投稿しておいて本当に良かったと思います。そこから色々アウトプットしてみるきっかけになったので。

勉強会を開催してみた

一記事Qiitaに投稿してからアウトプットすることの敷居がガクッと下がったので次は勉強会を開催してみました。
元々弊社では勉強会が盛んに行われているのでそれほど勉強会をやることの敷居は高くなかったです。

はじめての勉強会は新卒研修で学んだ、ネットワーク周りを題材に開催しました。
実際に発表した際にスライドです。 WEBページを表示するまで

発表を終えると先輩方からのフィードバックだったり、感想が貰えたので勉強会をやって本当に良かったと思います。

まとめ

• 自分のスキルセットをアピールする事が出来る
• 記事、勉強会の整理をしていく中で思考が整理され、より理解が深まる
• フィードバックがもらえる事が多いので、今後の改善に繋げられる

気軽に相談出来る「斜め上」の先輩・上司に悩みや不安を相談するようにした

*「斜め上」というのは別職種、別事業部を指してます。

学生時代

学生時代はあっても同じ学部の先輩と話す程度で、「斜め上」の先輩はいなかったです。

社会人になって

入社当初は
「何をやってもうまくいかない…」「先輩にめっちゃ迷惑かけてる…」「こんな調子で大丈夫なのだろうか…？」と不安になるものです。(僕もめっちゃなりました)
そんな時は誰かに相談したいものです。
「悩みを聞いてもらう」「フィードバックを貰う」事が一番なのですが、同じ事業部だったり同じ職種の人には相談しづらいこともあるかと思います。(逆に怒られたらどうしよう…なんて余計に不安になったり…)

そんな時は下記を実施して悩みや不安を解消していました。

「斜め上」の先輩に色々相談に乗ってもらった

斜め上の仲の良い先輩を社内に作ることで普段相談しづらいことでも気軽に話すことが出来ました。
特に年の近い先輩だと、どんな些細な事でも相談できたので本当に助かりました…！

別事業部の部長に面談を「強制的」に実施してもらった

弊社は2年目までの新卒に月一でメンター面談というのをやっていただいてます。
この「強制的」にというのが以外と重要で普段はなかなか相談出来ない些細な事でも、強制的に時間を取って面談する事で気軽に話すことが出来ました。

上記のように「斜め上の先輩」に相談したり、「強制的に相談する時間」を作って貰いましょう。
一人で抱え込むのが一番つらいです…。悩みがあったら直ぐに相談できる相手を見つけておいて損はないはずです。

まとめ

• 一人で悩まず誰かに相談する
• 気軽に相談できる「斜め上」の先輩を見つける
• 「強制的」に面談をする時間を取ってもらう

誰が読んでも読みやすいコードを意識するようにした

学生時代

学生時代は「作品を作ることがゴール」になる場合が多かったので、「とにかく動くもの」を作ることを再優先にしていました。
また、基本的に自分の担当した箇所は自分しか触らないので「自分が判るコード」をとにかく書いていました。

社会人になって

大きく変わった点としては

• ゴールが完成させることから運用させる事になった
• 他の人も触る事を想定したコードを書くようになった

という点です。つまり管理・保守をする必要があり、他者が読む事を想定してコードかく必要があったんですよね。
上記のようなコードを書けるようになるために、下記を実施・意識してコードを書くようにしました。

リーダブルコードを読む

http://blog.mmmcorp.co.jp/blog/2015/06/12/readable_code/
言わずと知れた必ず読んだほうが良い技術書リーダブルコードです。
まずは、この技術書を読むところから始めました。
どれだけ良いコードを書くことが大切なのかこの技術書を読むとよくわかります。
コードの質を担保するには？等のどの言語を触るにしても必ず必要なスキルを解説しているのでかなりおすすめです。

先輩のコードを読んでみる

良いコードを書けるようになるために、先輩のコードをひたすら読みました。
変数名の付け方だったり、複雑なロジックの書き方だったり、コメントの付け方だったり…と、とにかく先輩**「癖」**を盗むことをしてました。
それを自分の書くコードに落とし込む作業を繰り返しているうちに、だんだん意識しなくても自然と先輩の「癖」を身に付けることが出来ました。

コードレビューをしてもらう

ひたすらコードレビューをしてもらってフィードバックを貰うようにしました。
フィードバックを貰うことで、見落としていたバグだったり、自分では考えも付かなかった実装方法のアドバイスを頂けたりします。
特に入社当時は必ずレビューをしてもらうようにしてました。

命名をわかりやすくする

変数名だったりメソッド名だったりと名前を付ける機会は多いと思いますが、学生時代は「まあ自分が判ればいいっしょｗ」
と滅茶苦茶な命名をしてました。

滅茶苦茶な変数名

int a = 1;
char b = "a";

これが社会人になっても癖で残っていて、先輩に注意された事を覚えています…！

適切な命名が出来る用になるために

まずは、技術書、参考サイトを読んで適切な命名の法則を覚えました。
今回は僕が特にお世話になった参考サイト・サービスを紹介します。

参考サイト

モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう
命名する際の動詞、名詞、形容詞の使い分けなど、かなり詳しく解説しているのおすすめです！

サービス

[codic: プログラマーのためのネーミング辞書](https://codic.jp/engine"codic: プログラマーのためのネーミング辞書")
どうしても命名が思いつかない！って時はこのサービスを使わせていただいてます。
キャメルケースだったり、スネークケース等の出力方法を決められるので重宝しています！

リファクタリングしてみる

ある程度「良いコードが何か？」がわかるようになってきたら、積極的に既存のシステムをリファクタリングしてみると良いです。
リファクタリングをすることで今後システムの修正が入っても楽に内部構造を改善すること事が出来ます。
また、リファクタリング手法を覚えること = 良いコードを書けるようになるなので、積極的にやって損はないです。

リファクタリング手法を学ぶために読んだ技術書

弊社のメディアは主にRubyで開発しているので、リファクタリング:Rubyエディションを読んで勉強しました。
Rubyエディションですが、どの言語にも共通するリファクタリング手法が丁寧に解説してあるので、リファクタリングをやる機会があったら是非一読することをおすすめします！

まとめ

• 社会人になってから保守・運用・第三者が読むコードを意識するようになった
• 良いコードの基本を知るために「リーダブルコード」を読んだ
• 先輩のコードを読んで、自分のコードをレビューしてもらった
• ある程度力がついたところで既存のシステムを積極的にリファクタリングするようにした

あらゆる分野のエンジニアリングに興味を持つようにした

学生時代

今思い返すと…「授業で学んだこと」以上の事は勉強してませんでした…！
手の届く組み込み系の勉強で満足していて「あーコレ面白そうだな…でもWEB系よくわからないし…」
となかなか踏み出せずにいました。

社会人になって

入社直後、僕が一番興味を持ったのはインフラ周りでした。
とにかくコマンドラインを叩くのが格好良く見えて、まさに「エンジニア」って感じがしたんですよね。
その時の僕は「インフラめっちゃ面白い！よし！このままインフラエンジニアになろう！」

っておもってました。
そんなことを思っている時、たまたま上司と飲みに行く機会があってそのことをうちあけてみると、こんなアドバイスをいただけました

上司からのアドバイス

今はインフラが一番向いてるって思うかもしれないけど、まだ他にも技術は沢山あるよ。
本当に自分が向いてる技術を見つけるなんて早くても2、3年はかかるもの。
今はとにかく色々技術に触れて色々なことを勉強しなさい。
そのうえで自分が進む道を決めても全然遅くないよ。

と仰っていました。
この言葉が僕の中で凄い納得感があって、今でも大切にしています。

幸いなことに弊社はいろんな技術に触れることが多かったので、それもあって色々挑戦してみました。

インフラ周りを触ってみる

元々一番興味があったので引き続きここの勉強は続けました。
自宅にあった使ってないパソコンを使ってサーバを建てたり、EC2のマイクロインスタントでサーバを作っては壊して、作っては壊してを繰り返してました。（最初の1年間は無料なのでめっちゃ遊んでました。）
これを繰り返しているうちにコマンドラインの操作にも大分慣れ、仕事でサーバを弄ることがあってもそれほど怖くなくなりました。

WEB開発をしてみる

弊社はメディアを軸に事業を展開しているので、WEB開発をする機会は自然とありました。
Rubyを使ってメディア、API開発を行う中で、

• HTML, CSS, JavaScriptを使ったフロント周り
• MySQL, PostgreSQL, MongoDBを使ったDB周り
• RSpecを使ったテスト周り

と、いろいろな技術をかなり集中的に鍛える事が出来ました。

アプリ開発をしてみる

学生時代一番興味があったのがアプリ開発。特にAndroidアプリ開発に興味があったので改めて勉強しました。
アプリ開発することになると、必ず必要になってくるオブジェクト指向。
まずはここを習得すべく参考サイトや技術書を読みました。特に下記の技術書はかなり良かったです。

オブジェクト指向でなぜつくるのか

Javaのオブジェクト指向がゼッタイにわかる本

二冊ともかなりオブジェクト指向について丁寧に解説してくれているのでかなり理解を深めることが出来ました！

ある程度オブジェクト指向が身に付いたところでアプリの作り方を勉強しました。
実際に開発するのが早い！ということで手を動かしながら開発を進め詰まったら技術書を読む。というスタイルで勉強しました。
また、より理解を深めるために勉強会を開催しました。

実際に勉強会をやったときの時の記事です。
http://tech.basicinc.jp/Programmer/2015/08/28/android/

まとめ

• まずは食わず嫌いせずに色々な技術に触れてみる
• インフラ周りはトライアンドエラーを繰り返して身につけた
• WEBアプリはメディア・APIを作って習得した
• アプリ開発はまずは基本となる「オブジェクト指向」の取得。あとは作りながら習得した

サービスを「成長させる」ことを意識するようにした

学生時代

「自分でサービスを作りたい！」という思いでエンジニアになろうと思ったのですが、「サービスを成長させたい！」というところまでは正直考えられてなかったです。
学生時代の僕は「サービスを完成させること」がエンジニアリングのゴールだと思っていたんですよね。

社会人になって

「サービスは作って終わり」じゃないことを身をもって実感しました。
作って終わりじゃなく、そこからどう**運用・保守していくのか？**また、どのようにマーケティングすればユーザ様はサービスを使ってくれるのか？
を考える必要がありました。せっかく作っても誰にも使われないことほど悲しいことはないですもんね…。そんな思いもあってマーケティングの勉強するために技術書・参考サイトを読み漁りました。
その中でも僕が特におすすめしたいのが、

ferret

自社メディアで恐縮なのですが、WEBマーケティングを習得するのに最適なferretというサイトを使って勉強しました。
WEBマーケティングのノウハウが集約されており、このサイトを一通り読めばかなりWEBマーケティング力が身につくようになってます。
僕は初心者だったのでまずはカリキュラムを全部やりました。カリキュラムは戦略の立て方・競合調査から始まり、SEO、リスティング広告の打ち方などWEBマーケティングに必要なノウハウを網羅しているので、カリキュラムをやるだけでもかなり力を付けることが出来たと思います。これだけ充実していて全て無料で使えるのでマーケティングの勉強をするには本当にオススメのメディアです。

いちばんやさしい新しいSEOの教本

ferretである程度網羅的に学習したところでよりエンジニアリングに直結するであろう「SEO」を深掘りするために読んだ技術書がこちらの「いちばんやさしい新しいSEOの教本」です。
こちらの技術書はセミナー感覚で読み進めることができ、自然とSEOについて理解することが出来ました。また、業種ごとにオススメのサイトマップを紹介しているので、どんなメディアを作るにしてもかなり参考になると思います。

この2つをやるだけでもかなり力が付きました。

でもそれってエンジニアがやる仕事じゃなくない？

って思う人もいるかもしれなせん。勿論ディレクターの方が日々の数字を追いかけて施策を考えていくのですが、その施策をやる意味がわからないとどうしても「やらされてる感」が出てしまいます。逆を言えばその施策をやる意味が判れば納得感もあるし、もっと言えばエンジニアサイドから何か提案出来るかもしれません。
なので「エンジニアだから開発だけしてればいいやー」なんて思わずに、積極的にディレクション側にも絡んで行って良いと思います。

「エンジニアリング + WEBマーケティング力」を備えている人材は「グロースハッカー」と呼ばれているのですが、こんな人材になれたら最強だと僕は思います。

まとめ

• 社会人になるとサービスを作ることがゴールじゃなくなる
• 「ferret」「いちばんやさしい新しいSEOの教本」を読んでWEBマーケティングを学んだ
• エンジニアでもマーケティングスキルがあれば納得感を持って仕事がしやすくなる

さいごに

ここまで読んでいただき本当に有難うございます！
入社してからの2年間を振り返りながら記事を書いたのですが、改めて「いろいろやったなー…」としみじみしております…。
上記で偉そうな事を言っていますが、僕自身もまだまだ未熟者です。躓いて心が折れそうになることもあるかもしれません…。
そんな時はこの記事を読んで今現在の心境を思い出そうと思います…！
最後になりますが、僕がエンジニアとして上を向き続ける為に意識していることを綴ってこの記事を締めたいと思います。

自分の将来を意識しよう！

これから長い時間を仕事に費やす事になります。
毎日やる仕事が「辛い…」「苦しい…」だけだと寂しいですよね…。そうならない為にも

• 自分が将来どうなりたいか？

を常に意識する事が大切です。

自分の将来を意識できれば

• 小さなタスクでも「このタスクは将来やりたいことのココに繋がる！」 と目標がもてる
• 自分は何がしたいのか明確に主張出来る

などが出来るようになり目標に向けて能動的に動けるようになります！

最初は辛いけどその先は絶対楽しくなる！

ゲームでもなんでもそうですが、上手く出来ないと面白くないですよね…。
それでも、続けられるのって上手くなれば楽しくなることを知っているからだと思います。
仕事も一緒です。
新社会人でいきなりなんでも出来る人材なんてそうそういないです。
まずは、いっぱい失敗して、いっぱい経験しましょう！！
最初は辛いかもしれないけど、少し辛抱すればその先は絶対に楽しくなるはずです！

以上です！最後までお付き合いいただき有難う御座いました！