オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

エンジニアとして新卒入社してから取り組んだこととエンジニアを目指す人に伝えたいアドバイス

f:id:allabout-techblog:20210324104454p:plain

昨年に引き続き、オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒月間2021」を開催します。

第二弾は、オールアバウトのメディアやCMSの開発を担う部署に所属している@hideがお送りします。

1. はじめに

私は以下のスペックで、エンジニアとしてオールアバウトに新卒入社しました。

  • 大学時代にProgateでHTML、CSSPHPはやった
  • Laravelで簡単なメモアプリを作ってHerokuにデプロイしたことはある
  • Gitはほとんど使ったことがない
  • Docker、Kubernetesは言葉だけ知っている
  • ネットワーク等のコンピューターサイエンスに関する知識はほぼ無し
  • 大学は非情報学部
  • 実務未経験

このような境遇の大学生が新卒でエンジニアとして入社したら、どんな部分に苦労を感じるのか。また、困難を乗り越えるためにどのようなことに取り組んだのか。アドバイスを交えつつご紹介していきます。

少しでもこれからエンジニアを目指す方の参考になれば幸いです。

2. 開発チームに配属されてから取り組んだこと

まずは、これまでやってきたことを振り返ります。

4〜6月はビジネスマナー研修・エンジニア研修に取り組み、7月から現場に配属されました。

7月:APIのリニューアルに伴う各アプリの修正対応

最初に取り組んだ仕事は、「会員基盤APIのリニューアルに伴う各アプリの修正対応」です。

作業自体は定形的で単純なものだったのですが、そもそもAPIへの理解が曖昧だった(名前しか知らなかった)ので、「APIって何?」から入る必要がありました。

ローカル環境で以下のようなcurlコマンドを叩いて、APIの基礎的な概念を体感的に覚えた記憶があります。

curl -H "NAME: sample" -d "id=180&sample_id=1" -X POST 'localhost:9010/api/sample'

また、この頃は、今まで自分が書いてきたコードと業務レベルのコードとのギャップに苦しみました。 今となっては当時の感覚は思い出せませんが、暗号を読んでいる感覚だった気がします。

さらに、コードの追い方も分からなかったので、先輩のコードの追い方を参考にしつつ徐々に感覚を養っていきました。

8月:Batchのリニューアル

APIの後は、会員基盤で利用しているBatch(あらかじめ決められた一連の処理を実行するアプリ)のリニューアルに取り組みました。

こちらも例に漏れず「Batchとは何か?」から入る必要があったので、先輩に教えてもらいつつ、少しずつBatch周りの概念を理解していきました。

具体的には、「cron(時間指定して処理を実行する仕組み)」「crontab(Batch実行時間のスケジュール管理を行うコマンド)」「cronjob(Kubernetesでcronと同じフォーマットで実行する処理を指定する仕組み)」等について学びました。

さらに、この改修では、バッチの実行方法として、「cronjobにLaravelのコマンドを指定して実行する方法」を取ったため、「Laravelで特定の処理を実行するコマンドを作成する方法」についても学習しました。

9〜2月:会員基盤のリニューアル

9月から2月は会員基盤本体のリニューアルに取り組みました。

開発内容としては、「リポジトリの作成 -> 設計 -> 実装 -> テスト -> デプロイ」まで、アプリ開発の全ての工程を経験することができました。

技術的にも、今まで知らなかった数多くの技術や機能に触れることができました。以下に代表的なものを列挙します。

  • Laravel・PHP
    • Event
    • GateとPolicy
    • サービスコンテナ
    • Cookie、Sessionの扱い方
    • コレクション
    • デフォルト認証方法の差し替え
    • メール送信
    • 画像アップロード
    • TDDで開発
    • データプロバイダ
    • Mockery
    • PHPの組み込みメソッド多数
    • Trait
  • JavaScript
    • Laravel Mix
    • Cropper.js(画像アップロード処理)

また、個人的なトピックとしては、この頃モニタや椅子を新調して仕事の環境がかなり整いました。(オールアバウトではこの一年原則リモートワークです)

3. 一年間の仕事を通して得た技術以外の教訓

一年間の仕事を通して、技術はもちろんのこと、仕事に対する「姿勢」や「マインド」についても数多くの学びを得ることができました。

今回は中でも印象に残っているものをご紹介します。

  • 影響範囲を考えることの重要性
  • 相手をイメージすることの重要性
  • 自発的に動くことの重要性
  • 自分の意見を伝えることの重要性

影響範囲を考えることの重要性

仕事においては、全ての作業に対して「影響範囲」が存在します。

そして、実行する作業によってその「影響範囲の広さ」は異なります。

例えば、開発環境のDBの影響範囲は、あくまで自分の開発環境内のみです。 いくらデータを適当に削除したところでなんの影響もありません。

しかし、本番環境の場合は、その動作の可否がビジネスの利益に直結します。 それこそ数分止まっただけで数百万円規模で利益を逃すこともありうるのです。

私はこの一年間、様々な場面で、(時には失敗もしながら)「影響範囲を考えることの重要性」を実感してきました。

これからも「何か作業を始める前にはその作業の影響範囲を考える」ことを習慣にしていきたいと考えています。

相手をイメージすることの重要性

この一年、仕事および開発の中で「相手をイメージすることの重要性」を実感した場面が数多くありました。

例えば、仕事中のコミュニケーションだと、自分の意図が思うように伝わらなかったり、開発の場合だと、想定していた動き以外の動作をユーザーがしていたためにバグが生じてしまったりなどです。

そして、なぜこのようなことが生じてしまったのかを考えた結果、「持っている情報の非対称性」が原因だと気が付きました。 要は、「自分と相手では見えている景色が違う」ことへの認識が甘かったのです。

我々は、年齢も経験も知識も全く異なる相手同士で仕事を行っています。 そんな中で、自分の考えがさも当たり前かのように振る舞っていたら、必ずどこかで「ズレ」が生じます。

その「ズレ」を最小限に押さえて業務を円滑に進めるためにも、相手と自分の持っている情報の非対称性しっかりと意識した上で、「いかにそのギャップを抑える活動をするか」を考え、実行することが重要だと学びました。

自発的に動くことの重要性

社会人になったら、全てにおいて「自発的に動く」必要があります。

例えば、技術の習得についてもそうです。

学生の頃は、必要な知識を身に付けるためのリソースは、学校側が「教材」や「宿題」という形で用意してくれていました。つまり、完全に「受動的」でも必要な知識が身に付く仕組みになっていたのです。

しかし、社会に出たら違います。

必要な知識を自分で判断・選定して、自分で教材を選択して学ぶ必要があります。つまり、完全に「自発的」な姿勢が求められるのです。

特にエンジニアの場合は、常に技術のアップデートが求められるため、「自発的に学ぶ姿勢」が無ければあっという間に取り残されてしまいます。

この辺の学びに対する意識の切り替えを早い段階でできたのは良かったです。

自分の意見を伝えることの重要性

何かを学んだり習得したりする上で、「素直になる」ことはとても重要です。何でもかんでも自己流を貫いて天邪鬼になっていたら、成長速度は遅くなってしまいます。

しかし、仕事においては、なんでもかんでも素直に返事をする「yesマン」になってしまうと不都合が生じることがあります。

なぜなら、「素直になること」は「妥協」に繋がる恐れがあるからです。

例えば、プルリクエストなどは、先輩の実装に対してレビューをする必要があります。 このとき、「先輩のだから大丈夫」とか「ちょっと気になる所あるけどまあ良いか。。」と軽い気持ちで承認を押すと、それが元でバグが発生することに繋がりかねません。

大切なのは、「摩擦を生じさせない」ことではなく、「より良いプロダクトを作ること」です。

もちろんプルリクエストだけではありませんが、自分の意見がある場合は、それが先輩の意見と異なっていたとしても積極的に主張することが重要だと日々感じています。

4. 「分からないことが分からない」状態を脱するために取り組んだこと

次に、仕事を進める上で直面した困難と、困難を克服するために実践したことをまとめます。

プログラミングの経験が浅い状態で入社した際にぶつかる壁(困難)は、なんと言っても「分からないことが多すぎる」ことです。

私も業務に入ったばかりの頃は、本当に分からないことだらけで苦労しました。 特定の何かが分からないというより、「何が分からないか分からない状態」だったのです。

そして、そんな状況を脱するために私が意識・実践したのは以下の5つです。

  • 敵を分割する
  • 考えても分からなければ聞く
  • 日報を書く
  • 本を読む
  • 自分で作ってみる(手を動かす)

敵を分割する

問題の解決方法が分からない場合は、「敵を分割すること」を意識しました。

例えば、「Laravelでアプリを作ってリリースする」というゴールを設定した場合、いきなり取り掛かろうとしても何から手を付けていいか分かりません。

そこで、以下のように手順を分割するのです。

  1. リポジトリを作る
  2. システム設計・DB設計をする
  3. Dockerで開発環境を作る
    • docker-compose.ymlを作る
    • Dockerfileを作る
    • PHPApache等の設定ファイルを作る
  4. ComposerでLaravelをインストールする
  5. ユニットテストが動くようにする
  6. 〇〇の機能を作る
  7. 画面テストをする
  8. 本番環境用の設定ファイルを作る(ApachePHP
  9. デプロイ用のDockerfileを作る
  10. Kubernetesマニフェストファイルを作る
  11. CircleCIの設定ファイル(.circleci/config.yml)を作る
  12. リリース(デプロイ)する

さらに、実際に取り組む際には、それぞれのタスクをより細かく分割していきます。 要は全てにおいて「より小さく・よりシンプルに」考えるイメージです。

私はこの考え方を意識するようになってから、より一人で解決することのできる問題の幅を広げることができました。

考えても分からなければ聞く

いくら考えても分からないものは分かりません。

そのため、どうしても分からない場合は先輩に質問するようにしていました。

ただし、なんでもかんでもすぐに質問して良いわけではありません。 単純に先輩の時間を奪うことに繋がりますし、「ちゃんと自分で考えてないのかな?」とも思われるからです。

そのため、質問をする際には、「最低〇分は考える」など自分なりのルールを儲けていました。

また、質問内容も「自分はこう思うのですが、〇〇さんはどう思いますか」のように、なるべく自分の意見も添えて質問するようにしていました。

日報を書く

私は業務を開始してから、毎日の日報を継続しています。

これにより、以下の効果を得ることができました。

  • アウトプットによる知識定着効率の向上
  • インプットのトリガーになる
  • 見返したときに自信になる
  • Vimの操作に慣れた)

アウトプットによる知識定着効率の向上

日報に日々の学びを書くことにより、理解が曖昧な部分をそのままにしなくなるため、知識をより着実に身に付けることができました。

また、インプットだけでなく「アウトプット」の機会が作れたのも記憶の定着には有効であったと感じています。

インプットのトリガーになる

日報があることにより、業務中でも「学び」に対する意識を高めることができました。

また、業務外でも「日報に書くネタ作り」がトリガーとなってインプットの機会を増やすことができました。

見返したときに自信になる

日報を積み上げることは、「自分が学んだ内容を可視化する」ことと同意です。

そして、その積み上げた量の多さは、そのまま自分の「自信」に繋がります。 要は、「昨日よりも前に進んでいる」実感を持つことができるのです。

これは自分に対する精神安定剤としては非常に有効だったと感じています。

Vimの操作に慣れた)

これはおまけですが、私は日々の日報をVimCLIで使うテキストエディタ)で執筆しています。

これにより、基本的なVimのコマンドはマスターでき、また、開発中でもVimの操作に戸惑うことはほぼなくなりました。

ただ最近はVimの知識がアップデートできていないので、今後は少しずつ知識を増やしていきたいと考えています。

本を読む

よく分からない事象に対しては、「本を読む」ことにも取り組みました。

特に意識的に読んだのは、自分の中でイメージが掴みにくかった分野。例えば自分の場合だと「ネットワーク」「Kubernetes」周りです。

実務ではそれらの技術の「使い方」は学ぶことができます。

しかし、「概念的な部分」をじっくり学ぶ時間はありません。そのため個人的に勉強する必要がありました。

業務で学べることはもちろん多いです。 しかし、それだけでは足りなかったり偏りが出たりする部分もあるので、本等で知識の補填をすることは重要だと感じています。

自分で作ってみる(手を動かす)

いくら知識を取り入れたところで、それらを実際に使わなければ、「使える知識」とはなりません。

そのため、学んだ知識は「実際に使ってみる」ことも同時に意識しました。

例えば、PHPのメソッドを学んだ場合はphp -aで動かしてみて動作を確認する。Kubernetesを学んだなら、実際に自分でGKEにアプリをデプロイしてみるなどです。

これにより、確実にイメージできる範囲を広げることができました。

技術を学ぶには、やはり「自分の頭で考えて手を動かす」が一番の方法であることを実感しています。

5. これからエンジニアになろうとしている人へアドバイス

最後に、僭越ながらこれから実務未経験でエンジニアになろうとしている人へアドバイスを書きます。

具体的には、一年前の自分に対して、「入社前にやっておいて良かったこと」および「入社前にやっておけば良かったこと」をまとめます。

少しでも参考になれば幸いです。

  • タッチタイピングの習得は必須
  • コンピュータサイエンスやWebの基礎知識は事前に学んでおいた方が良い
  • プログラミングの基礎は事前に学んでおいた方が良い
  • 自宅の作業環境は早めに整えておこう
  • 心の準備:一年目はしんどい
  • でも、少しずつできることが増えていくのは楽しい

タッチタイピングの習得は必須

この記事を書くにあたり、私が入社前にやっておいて良かったことを改めて考えてみました。

もちろんProgate等でプログラミングの基礎を学んでおいたのも良かったのですが、一番やっておいて良かったと思ったのは、「タッチタイピングの習得」です。

なぜなら、タッチタイピングがある程度できたことによって、「技術の勉強のみに集中する余裕」を作れたからです。

もしタッチタイピングが全くできない状態で入社していたら、コードや文章を書くのに時間が取られて、アプリ開発や技術の勉強に集中できていなかったと思います。

タッチタイピングの練習方法としては、e-typing寿司打等のサイトがおすすめです。ゲーム感覚でタッチタイピングを身に付けることができます。

また、タッチタイピングの練習をする際の注意点は以下の三つです。

この3点を意識して練習を積めば、数週間〜1ヶ月くらいである程度はできるようになると思います。

私自身も大学3年の頃までは全くタッチタイピングができませんでしたが、上記のポイントを意識して練習したことにより、1ヶ月程度である程度タッチタイピングを習得することができました。

コンピュータサイエンスやWebの基礎知識は事前に学んでおいた方が良い

エンジニアとして働く上で、最低限のコンピューターサイエンスおよびWebの知識は必須です。

私はこの辺りをほとんど勉強することなく会社に入ったため、かなり苦労しました。

大学の情報学部や専門学校等で学んだ人は勉強する必要はありませんが、学生時代に全くコンピューターサイエンスを勉強してこなかった人は勉強しておくと良いでしょう。

今回はおすすめの本を数冊ご紹介します。

【改訂5版】図解でよくわかる ネットワークの重要用語解説

【改訂5版】図解でよくわかる ネットワークの重要用語解説

下の3つはより初心者向けの書籍で、図が豊富なのでイメージも掴みやすいと思います。

プログラミングの基礎は事前に学んでおいた方が良い

当たり前ですが、入社前に最低限のプログラミングの知識は身に付けておいた方が良いです。

オールアバウトの場合だと、PHPをメインに使用しているので、事前にProgate等でPHPの基礎を学んでおくと良いでしょう。(別の会社の場合は、その会社で使用している言語を勉強しておく)

また、余裕がある場合は、言語だけでなくその言語のフレームワークも勉強しておくと、何もしてないよりはスムーズに業務に入っていくことができます。

Laravelの場合だと、公式ドキュメントでも良いですが、以下の書籍などは初学者でも理解しやすいのでおすすめです。

PHPフレームワークLaravel入門 第2版

PHPフレームワークLaravel入門 第2版

自宅の作業環境は早めに整えておこう

出社して働く場合は問題ないのですが、コロナ等の影響によりリモートで働く場合は、自宅の開発環境を早めに整備するようにしましょう。

具体的には、「ネットのスピード」「モニター」「椅子」はケチらない方が良いです。特にモニターに関しては、あるのとないのとでは業務の効率が違います。

私の場合はこれらの準備を全くしないでリモートワークに入ってしまったため、最初の頃はかなり苦労しました。

なるべく入社前にこれらの環境を整えておくと、スムーズに業務に入ることができるでしょう。

ちなみに私は以下のモニターを使っています。高さ調整が可能で画質もいいので非常に使いやすいです。

心の準備:一年目はしんどい

経験が浅い状態で入社するエンジニアにとって、正直、一年目はしんどいです。

ここでの「しんどい」の意味は、「技術のキャッチアップに苦労する」ということです。

もちろん、キャッチアップのスピードには個人差があるので、スムーズに業務を覚えて活躍できる方もいるとは思います。

しかし、私も含めて大抵の場合はそうはいかないでしょう。

なぜなら、覚えなくてはならないことがあまりに膨大だからです。

例えばオールアバウトの場合だと主に以下の技術群を用いており、これら全てについてある程度の知見を持つことが求められます。

さらに新卒エンジニアの場合は、技術的なキャッチアップに加えて、「新社会人」としても覚えなくてはならないことが沢山あります。

例えば、会社で用いているツールの使い方や文章の書き方、ビジネスマナー、仕事をこなす上での考え方などです。

確実にキャパオーバーになる場面は出てくるでしょう。

ネット上では、「エンジニアは誰にでもできる」「エンジニアは簡単」「エンジニアは楽に稼げる」等の誇大広告が散見されます。

しかし、現実はそう甘くはありません。実際は常に知識の習得やアップデート、勉強が求められる泥臭い仕事です。勉強を継続できない人は確実についていけません。

「エンジニアは楽」「誰でも簡単にできる」と思っている人は今のうちに認識を改めておきましょう。そうすることで、エンジニアになる前と後でのギャップを減らすことができます。

でも、少しずつできることが増えていくのは楽しい

先ほど、「一年目はしんどい」と書きました。これは心構えとしては間違いなく持っておいた方が良いです。

しかし、もちろん楽しいこともあります。

それは、なんといっても「常に成長を実感できる」ことです。

未経験で入社した場合、分からないことやできないことは膨大です。しかし、その分できることも日々確実に増えていきます。学びが無い日がないので、知的好奇心が毎日確実に満たされる状態です。

私自身も、この一年で本当に多くの技術的および社会人として働く上での学びを得ることができました。

もちろん苦しいこともありましたが、その経験の全てが今の自分の礎になっていると感じています。

6.まとめ

この記事では、私が新卒でオールアバウトにエンジニアとして入社してから取り組んだことと、その中で得た教訓をまとめつつ、これからエンジニアを目指している方へのアドバイスも書いてみました。

この記事が少しでもこれからエンジニアを目指す方の参考になっていれば幸いです。

最後まで読んで頂きありがとうございました。