🏃‍♂️

【体験談】エンジニアに転職すると担当する仕事【未経験者でもやっていけます】

2022/06/05に公開

未経験

「未経験でWeb系エンジニアに転職したらどんな仕事をするの？
　全然イメージが沸かないから実際に未経験からエンジニアに転職した人の話を聞いてみたいです。」
「エンジニアに興味はあるけど、実際仕事に付いていけるか不安です。何かコツとかありましたか？」

今回はそんな疑問にお答えします。

【筆者について】
不動産会社で約3年間営業職を経験後、2020年4月に独学でプログラミングを学んで自社開発企業のWeb系エンジニアへ転職しました。
約2年間勤めた後、2022年5月に転職し、現在は渋谷の某メガベンチャー企業で働いています。
転職で100万円以上、年収は上がりました。
エンジニア歴はこの記事を書いた時点202２年6月で2年強です。

【この記事で分かること】

Web系企業にバックエンドエンジニアとして入社したら担当する一般的な仕事
私がエンジニアに転向後2年間で実際に担当した具体的な業務内容
仕事で苦労した点と乗り越えるために工夫したコツ

【前提】
この記事では、バックエンドエンジニアとして、Web系自社開発企業に入社した場合の仕事内容を解説していますので、
フロントサイドエンジニアやアプリエンジニア、SESや受託開発企業、SIerは仕事内容が異なる可能性があります。

また、一般的な話に関してはできる限り調べた上で書いていますが、基本的には私の実体験を元にしているので、この記事の内容が当てはまらない会社も当然あると思います。
その点もご了承ください。

エンジニアになると担当する業務

最初に担当するのは保守運用が多い

結論からお伝えします。
バックエンドエンジニアとして、Web系自社開発企業に業務未経験で入社した場合、
「自社サービス・システムの保守・運用業務の一部」
からスタートすることが多いと思います。

エンジニアの作業工程は大雑把に分けると、「設計」「開発」「運用・保守」の3つに分類されます。

設計：「どういう技術を使って、どういう構成でシステムを作ろうか」を考えて計画を立てる
開発：設計に沿って、システムを作って世の中にリリースする
保守・運用：作ったシステムをユーザーが安定して使えるように守り続ける
- 保守：システムに修正・改良を加える、トラブルが起きたら対応する
- 運用：システムを毎日動かし続ける、トラブルが起きないようにする

なので、最初に担当する「自社サービス・システムの保守・運用業務の一部」というのは、例えば、これらのようなタスクを指します。

既に動いているシステムの不具合の調査・修正
システムの簡単な改良
ユーザーへのサポート・お問い合わせ対応
定型化された作業（毎日実行されるプログラム（バッチ処理）の処理結果が問題ないか確認するなど）

最初にこのタスクを任される理由としては

業務を通じて、「自社のサービス・商品」について理解することができる
- サービス・商品内容
- お客様対応
- どこで利益が出ているか
- 技術的なシステム・インフラの構成やソースコードの内容など
マニュアル化されていることが多いので、
- 先輩がそれほど教えなくてもすぐに安定して仕事ができる
- 技術力が低くてもできる仕事が多い
緊急ではなく、かつ、簡単な修正が定期的に発生するため、
- 修正しても影響範囲が狭いのでリスクが低い
- 期限に余裕があるので新人が時間がかかっても問題ない

といったことがあげられます。

ここで大事なこととして、
必ずしもコードを書く業務ばかりではない
ということは覚えておいてください。

例えば、お客様からのお問い合わせの対応はメールなどでのテキストのやり取りが主ですし、
不具合の調査や修正にしても、ログやデータベースのデータ、ドキュメントを見たり、ググって調べたりする、
「調査」の時間が長いことが多いです。

このような業務を行う中で、
自社のサービスやシステム、開発手法に慣れていき、
分からないこと・知らなかったことを調べていく中で、少しずつスキルを上げていきます。

逆に「最初はやれない」仕事

これらのタスクは入社直後からメイン担当として任されることは基本的には稀です。
（開発現場の動きを知る目的で、新規開発プロジェクトのミーティングには参加する、くらいはありますが。）

新サービス・新システムの新規開発（特に設計）
インフラ・セキュリティに関わるタスク
データベースの中身をいじるようなタスク

理由は先程上げた理由の逆で、会社にとってメリットが少ないからです。
例えば、このような理由が挙げられます。

新サービス・新システムの新規開発（特に設計）
- 上流工程と言われる要件定義や設計はサービス全体に与える影響が大きいため、新人に任せるリスクが高い
- 手を動かす開発作業も、新規開発だとある程度の知識と技術力がないと振れる作業がない
- リリース日が決まっているなど、期限が厳しいことが多く、新人にゆっくり任せておく余裕がない
インフラ・セキュリティに関わるタスク
- インフラはシステムの屋台骨なので、万が一誤操作でインフラに問題を起こしてしまうとシステムが止まってしまう
- セキュリティに穴ができてしまうと、情報漏えいやサイバー攻撃などのリスクに晒される
データベースの中身をいじるようなタスク
- 誤操作をすると、お客様の情報が消えたり、システムが止まったりする危険性がある

その後、担当していく仕事

数ヶ月程度働いて、会社から「この仕事も任せても大丈夫」と判断されれば、少しずつ任せてもらえる仕事の内容と範囲が増えていきます。

どの仕事を担当できるかは、
会社の方針や、配属されたチームの開発状況、人員の余裕度合いなどにもよりますが、
本人の希望、それまでの仕事の出来栄えや、勤務態度、チームメンバーとのコミュニケーションの様子などから判断されることが多いです。
やりたいことがあるなら積極的に上司に伝えていきましょう。

とはいえ、先程「逆に最初はやれない仕事」でご説明した通り、希望した仕事を最初から何でもできるわけではありません。

担当していく業務には、ざっくりこのような段階を踏むことが多いかと思います。

保守運用の一部
↓
機能改良
　：サービス・システムの様々な機能の中で一部の機能をより使いやすく改良する(広い意味では保守の一貫)
↓
機能追加
　：サービス・システムに新しい機能を追加する
↓
新規開発
　：新しいサービス・システムを0から作る

勘違いしないようにお伝えしておきますが、
保守運用が簡単なわけでも、重要性が低いわけでもありません。
保守運用業務でも段階を経ないと担当できないタスクはあります。（セキュリティ管理やシステムのリプレイスなど）
また、新規開発が得意なエンジニアがもっとも優れているわけでもありません。

ただ、下に行くにつれて、

上流工程と言われる要件定義や設計が必要になるため、必要とされる経験やスキル、知識が増えること
仕事のクオリティがサービス全体のクオリティに直結し、ひいてはサービスが生む利益の多寡にも直結すること
プロジェクトに関わる人数が多くなり、チーム全体で動く力が必要になること

などから、会社としてもすぐには任せられないのです。

「じゃあ、具体的に何をすれば新規開発の仕事って担当できるようになるんですか？」
に関しては、
今回の「エンジニアになったら担当する仕事」とちょっと話が脱線してくるので、詳しい話は別の記事で解説しますが、簡単に言うと、
社内で信用をためて、
技術力と、新規開発をやりたい熱意をアピールすることが必要になります。

先程もお伝えした通り、新規開発系のプロジェクトは、技術力や経験、メンバーの協力が必要なので
「この人なら任せられる」と上司や周りのメンバーから信用されないといけません。

こういった信用は当然一朝一夕で得られるものではなく、少しずつ積み重ねていくものです。
そして、あなたが最初に担当したのが保守運用の仕事なら、まずはその仕事で結果を出すしか信用を積む方法はありません。
まずは目の前の仕事を真剣に取り組みましょう。
一応、新人でも信用を積む「ちょっとしたコツ」もあるので後ほどご紹介しますね。

新人エンジニアの業務の具体例

さて、ここまでで
「エンジニアになったら保守運用の仕事をすることが多いのはなんとなくはわかったけど、抽象度が高すぎて具体的な仕事内容のイメージが全然沸かないです」という人も多いと思います。
私自身も入社前にここまでお伝えした内容はなんとなくは知っていましたが、実際に自分がどういう仕事をすることになるのかは正直全然イメージできていませんでした。

なので、ここからは
具体的に私が実際に担当した業務についてお話したいと思います。
完全初心者でもイメージが沸くようにできるだけ専門用語は使わずに噛み砕いて説明します。

また、私が業務をしていた中で、

苦労した点とその克服方法
転職時に評価された取り組み

などを 【一言アドバイス】 としてご紹介しますので、是非参考にして、良ければ丸パクリしてください。

【前提：私が入った会社について】
従業員30名くらいのベンチャー企業でした。
自社のスマホアプリを7つ運営していて、時期にもよりますが、全体のユーザー数は3万人くらいだったと思います。
アプリ運営の担当チームは私を入れて、6名くらい。
一人はアプリエンジニアの方で、あとは全員バックエンドエンジニアでした。
私の半年くらい前に業務未経験で入った先輩エンジニアの方が2人いて、2人とも同じアプリチームで保守運用からスタートしていました。

【私が担当した業務一覧】
0.開発環境の環境構築
1.アプリのサーバー側の保守運用全般
2.サーバーのリプレイス作業
3.定例ミーティングの司会進行,議事録作成
4.自社アプリに新機能を追加する
5.先輩が主担当していた新規開発系のプロジェクトでのコードレビューとテスト

0.開発環境の環境構築

業務と言えるか微妙なラインですが、どの職場でも入ったら必ず最初にやります。

ただ、新人だと
「環境構築マニュアル通りにやっても（やってるつもりでも）、なぜかエラーになってマニュアル通りにいかない」
「そもそもマニュアルに書いてある作業内容が意味不明(知識不足が原因。マニュアルは悪くない。)」
があるあるで、割とつまづくことが多いかなと思います。
苦労することがあることを知っておいてほしかったので、一応0番目の業務として入れました。

基本的には新入社員用の環境構築マニュアルがあるはずなので、その通りにやるだけです。
マニュアルがなかったら先輩が教えてくれるはずです。

具体的な作業内容としてはこの辺がどの会社でも多いかと思います。

業務に必要なツール(Dockerやvscode、sourcetree、slackなど)をMacにインストールする
githubや会社のサーバーにアクセスするためのsshキー等の設定をする
DockerやVirtualBoxなどの仮想環境を使う場合は仮想環境を立ち上げる手順を覚える
githubからソースコードを落としてローカル開発に必要な環境を整える
AWSやデータベース、社内システムなど、業務で使うシステムのID、パスワードを上司からもらってログインする

1.アプリのサーバー側の保守運用全般

冒頭に「入社最初は自社サービス・システムの保守・運用業務からやることが多い」とお伝えしたが、私もまさに保守運用の仕事から始まりました。

色々やりましたが、一般的にも最初にやることが多いのはこの辺かなと思います。

システムの不具合の修正
簡単な機能追加・変更
バージョンアップ対応
ユーザーからの問い合わせの調査と返信

1つずつ説明しますね。

【システムの不具合の調査・修正】
私の最初の最初の仕事がこれでした。
大勢のユーザーが使うシステム・サービスというのは、たまにエラーが発生することがあります。
たとえば、私のいた会社はスクレイピングという様々なサイトから情報を集めてくる技術を使っていたのですが、
スクレイピングは収集元のサイトの構成が少しでも変更されると情報が取れなくなってしまうことがあるので、頻繁に修正が必要になります。

なので、私の最初の仕事は、
情報が取れなくなってしまったスクレイピングの処理を、情報が取れるようにサイトに合わせてソースコードを修正する、というものでした。

作業内容はこんな感じです。
一般的なバグの修正作業は大体この流れだと思います。^[1]

プログラムの実行中にエラーが起こると、エラー通知がメールで飛んてきて、エラー理由がログに表示されるようになっていたので、そのエラーログを見て、なぜ失敗しているのかの原因を調査する
：エラーログには、どこのコードでエラーが発生したのかや、どういうエラーだったのかが表示されているので、その発生箇所でどういうエラーが起こっていたのかを調べます
原因の推測ができたら、コードを修正する。
：スクレイピングのプログラムはRubyで書かれていたので、Rubyのコードを修正していました。
修正したら、ローカルでスクレイピングを実行して、期待通り情報がとれたら概ねOK
この修正によって、他の処理に悪影響が出ていないかを確認
修正内容を先輩に確認してもらう（githubへプルリクを出す）
先輩の確認で問題なければ、ステージング環境（本番前にテストをするための環境）に修正を反映して動作確認する
テストが問題なければ、本番環境にリリースして1週間程度様子を見る
様子見中に、バグなど修正が必要な箇所が見つかった場合は再度修正する。特に異常もなければタスク完了。

最初は簡単な修正から任されると思いますが、原因の調査やコードやデータベースの構成の理解に手間取って、簡単な修正でも最初は5〜7日くらいかかるかもしれないですね。
ちなみに慣れると簡単な修正であれば、数時間で修正完了してリリースまでいけるようになります。

１つのサービスでも裏で動いているシステム・サーバーはいくつもあります。
最初はその中のどれか１つのシステムの一部の調査や修正を担当すると思いますが、ある程度対応できるようになってくれば、そこから担当する範囲が広がっていくでしょう。
私も他のシステムのエラーの調査・修正や、クエリのチューニング^[2]、SSLなどの証明書の更新など、細かいものも含むと挙げきれないほどの様々な業務を経験しました。

【一言アドバイス】進捗は自分から報告しよう
超当たり前だと思われそうが、意外と忘れがちです。

その日の仕事終わりに、「今日はここまで進みました」「明日はこれをやるつもりです」と一言上司に報告するようにしましょう。直接でも、チャットでもいいと思います。

上司からすると、新人のあなたの仕事がどのくらい進んでいるかは全くわかりません。どこかで詰まっていないかも気になります。

そんな中、上司から聞かれてから答えるのと自分から一言報告するのとでは、「管理する手間が少ない」という点で、上司からの印象は雲泥の差です。
誰でもすぐにできることなので是非やってみてください。

【簡単な機能追加・変更】
「新機能という程ではない、ちょっとした追加や変更を加える」というタスクも最初にやることが多いです。

例えば、
・スクレイピングやAPIで取得するデータの種類を1つ増やす、とか
・画面に表示する商品の詳細情報を、今まで
「商品名」
「商品の説明」
「リンク」
だったのを
「商品名」
「リンク」
「商品の説明」に変更する、とかです。

慣れている人がやれば一瞬で終わる程度の作業なので、新しく入った人にチュートリアル的な感じでやってもらうのには丁度いいわけですね。

【一言アドバイス】①やり直しを減らそう　②目的を理解して応用しよう
「ゴール」と「タスクの目的」を必ず確認するようにしましょう。

ゴール「ここの部分が今こうなっているのを、こういう風に追加・変更すれば良いんですよね？」
目的「なんでこの機能変更を行うんですか？」
というように、
「そのタスクの完成形として自分が認識しているものが合っているか」と
「なぜこの機能変更を行う必要があるのか」を上司に確認するのです。

新人は分からないことが多いので、こういう修正をして、と説明されてもイメージできないことが多いです。
勝手にこういう指示だったんだろうで作業して後から全然違うとなったらやり直しの無駄な手間が発生してしまいます。
必ず上司との認識をすり合わせる癖をつけましょう。
2割できた時点で「まだ2割ですがこういう方向で合ってますよね？」と、方向性が合っているか確認する「2割確認」もとても有効です。

また、入社したばかりの頃はサービスやシステムの仕組みの全体像が見えていません。
その中でシステムのさらに一部の変更というのは正に「点」です。
なので、「どう変更するのかのゴールはわかったけど、そもそもなんでこの変更をするのかは分かっていない」という状態になりがちです。
きちんと目的を理解して仕事をするように心がけましょう。

目的がわかっていると応用が効きますし、自分で考えて仕事に工夫ができるようになります。
例えば、先程の商品の詳細情報の順番を変える例で、「この並び順だとユーザーからするとリンクが見つけにくいから」が変更理由だとすると、
変更を指示されたのはある１画面の変更だけだったとしても、他の画面でも同じ並び順の箇所があれば、
「こっちも直した方がいいでしょうか？」と自分から確認することができます。

【バージョンアップ対応】
そのシステムで使われているプログラミング言語やフレームワーク、ライブラリなどのバージョンをあげる作業です。
場合によっては大規模なソースコードの修正が必要になるため、ある程度仕事に慣れてきてからじゃないと関わらないと思います。

まずバージョンアップって何かについて説明します。

すでにプログラムを書いたことがある人は分かると思いますが、
プログラミング言語や、OS、ミドルウェア、APIなど、開発で使われるほぼ全てのツールには「バージョン」というものがあります。
「PHP 8.0」みたいな感じです。

そのツールを開発している人たちがそのツールをもっと新しくて便利なものにしようと日々開発してくれているので、
定期的に新バージョンがリリースされるんですね。
あなたが使っているアプリや、iPhoneとかAndroidも定期的に「新バージョンのソフトウェアへアップデートしてください」みたいなのが来て、アップデートすると新しい機能が増えたり画面がちょっと変わっていたりしますよね。
あれみたいなものです。

そして、各バージョンには「サポート期間」というものがあります。
「新バージョンリリースから3年の間に、そのツールにバグやセキュリティ的に弱い部分とかが見つかったら開発チームが修正するよ」というものです。
サポート期間は2,3年位のことが多いですね。

逆に言うと、2,3年経つと、セキュリティに問題が見つかっても修正されなくなるわけです。
（サイバー攻撃を仕掛ける側も年々技術力は上がっていくので、「昔は大丈夫でも今はセキュリティ的に弱い」というケースがどんどん出てきます）

なので、サポートが切れる前に、サポートが受けられる新しいバージョンのものにバージョンアップさせるのが望ましいとされています。
(とはいえ、そのサポートが切れた日から急に動かなくなる、というわけではないので、リスクはありますが、使い続けることはできます。
なので数年前からバージョンアップしないまま動き続けているシステムというのも会社によってはあります。)

システムを作ると、一度完成させたら終わり、ではなく、永遠にこのバージョンアップはついて回るのです。

では、バージョンアップって具体的に何をするのでしょうか？

バージョンの流れ

公式ドキュメントを見て、旧バージョンと新バージョンで何が変わるのかを確認する
自分たちのシステムで、そのツールを新しいバージョンに上げると、どこで問題が発生しそうかを調査する
影響がある箇所をどう修正すれば、今まで通りシステムは動くかを検討する
テスト環境で実際に修正してみる
テストして、問題ないか確認する
問題なければ本番にリリースする

プログラミング言語やAPIなど、各ツールには基本的にその開発元が発表している「公式ドキュメント」というものがあります。
例：PHP8系へ移行のためのドキュメント

　
これを見て、「アップデート後のバージョンではここが変わるんだな」を把握します。

ちなみに、上のリンクを見てもらっても分かる通り、新しいバージョンになると、新機能が増えたり、バグが修正されて便利になる一方で、
今まで使えた機能が廃止されて使えなくなることも多いので、会社のシステムがその機能を使っていた場合は、何かしら対応をしないといけません。
また、同じ機能でもコードの書き方のルールが変わることもあったり、
APIの場合は、帰ってくる情報の構成が変わったりと、色々影響が出ることが多いです。

それらを全部調べて、「うちのシステムのここは変えないといけないね」を把握するわけです。
もちろん結構面倒くさいです。

修正が必要な箇所をリストアップしたら、どう修正するかを考えて、実際に修正します。

修正したら、テスト環境でテストしてみて、ちゃんと今まで通り動くか確認し、確認できたらやっとリリース、というのがざっくりとした作業の流れです。

【ユーザー様からのお問い合わせの調査と返信】
ユーザー様からのお問い合わせ対応です。
私がいた会社のアプリはユーザー様から毎日大体3〜6件ほどお問い合わせが来たので、
そのお問い合わせ内容を確認して、返信していました。
お問い合わせ内容は「アプリの使い方が分からない」「アプリに登録した情報が表示されない」など様々です。
お問い合わせが来たら、データベースのユーザー様の情報や、操作履歴などを見て、
修正が必要なバグなのか、ユーザー様の使い方が間違っているのかを判断してユーザー様へ返信します。

修正が必要な場合は、先ほどの修正作業を行います。
修正に時間がかかる場合はアプリのお知らせ欄にメンテナンスのお知らせを出したりもしました。

「お客様とのやりとりは別の部署がやるけど、技術的に調査や修正が必要な場合は、エンジニアチームに回ってくる。回ってきたら新人が対応する。」
という体制になっている会社も多いかなと思います。

2.サーバーのリプレイス作業

リプレイスというのは、古くなったシステムを、機能は変えずに、新しいものに取り替えることを言います。

基本的に数ヶ月〜数年かける大規模なプロジェクトになることが多いため、ある程度仕事に慣れて、技術力が付いてきてからじゃないと関わらないと思います。
ジャンルとしては運用の一環になります。

バージョンアップ対応でもお伝えした通り、システムを運用していると、必ずバージョンアップなどのシステムの新陳代謝が必要になります。
一方で、「ユーザー数が増えて、アクセス数が増えてきたので大量アクセスが来ても安定してサービスを提供できるようにしたい」、「もっとスピーディーに新しい機能をリリースしてサービスを高速で改善できるようにしたい」など、「もっとこうしたい」という課題もだんだん増えてきます。
となると、「数年前に作った今のシステムの延長で改良を続けるより、いっそ丸々(もしくは一部だけでも)新しい便利な技術を使って作り直した方が長期的にみたら得なんじゃない？」という疑問が出てきます。
ここで出てくる解決策の1つがリプレイスです。

「このシステムを作ったときはこの言語とフレームワークとインフラ構成でも良かったけど、
今はもっと最適な構成があるし、正直古い技術になってきたから、思い切ってもろもろ新しくしようか」というわけです。

加えて、優秀なエンジニアほどモダンで価値が高いと言われる技術を使いたいと思っているため、古くなった技術を使い続けている会社は優秀なエンジニアを採用しにくくなると言われています。
技術トレンドに敏感な優秀なエンジニアを雇うためにも、会社のシステムの技術を新しいものに変えるリプレイスは先行投資として必要なのです。

続いて、「リプレイスのざっくりとした流れ」と「新人だった私は何をしたか」がこちらです。
要件定義や設計などの上流工程が多いので、先程もお伝えした通り、新人が関われる部分は限定されます。

現在のシステムの把握
　：(私のタスク)現在のシステムの仕様（の一部）を調べて報告する
リプレイス後にどういうシステムにするか決める（機能要件・非機能要件、技術選定、設計など）
　：会議に参加して新システムの仕様をなるべく理解する、できる限り意見を言う
誰が、どうやって作るか（開発体制）、スケジュールなど決める
　：上司が采配したので特になし（自分から「これやりたいです」といえればベターだったかも）
小さく作ってみて、テストする
　：先輩が担当していたので特になし
いけそうならさらに続けて作っていく
　：先輩が作成したマニュアルに沿って、テスト環境に実際にサーバーを構築していく（ECSとFargateがメインでした）
　：マニュアルも完璧ではなく、自力で調べて突破した箇所もいくつかあったので、テスト環境に構築するだけでも１ヶ月近くかかったと思います
テスト環境で確認テスト
　：テスト表示を作って、テスト環境用のアプリで実際に動作確認する（非機能要件のテストは殆ど先輩がやっていた）
本番環境でシステムを新しいものへ入れ替える（一気に全部ではなく、少しずつ入れ替えることが多い）
　：本番環境にもサーバーを構築しました。なお、サーバーの切り替え作業は先輩がやりました。
様子を見つつ、細かい修正があれば対応していく
　：エラーが出たら調べます。分からなければ先輩にヘルプを求めます。

【一言アドバイス】 休みに学習をするなら、「分かっていないこと」を潰そう
プライベートの時間を使ってプログラミングの学習をするのでれば、
少なくともエンジニア１年目は「業務の中で分からなかった点を潰すこと」を私はおすすめします。

具体的に言うと

アプリ・サービスでこのボタンを押すと、裏側のどのシステム（APIやWEBサーバー）にリクエストが送られて、どのデータベースから何の情報を取ってきて、どういうレスポンスで表側のアプリ・サービスにレスポンスを返しているのか（まずはざっくりとした流れだけでも可）
マニュアルに書いてあったからとりあえずそのまま打ち込んでいたコマンドが何をしているコマンドなのか
会議とかでよく聞くけど、なんとなくの理解で曖昧なままにしていた単語（API、ドメイン、SaaSなどなど）
などです。

なぜかというと、「業務で触れる機会があるのに分かっていないこと」を潰すのが、一番あなたを「楽にしてくれるから」 です。

私自身もそうでしたが、エンジニアになりたてで、一番辛いことの１つが、「仕事は期限までにやらないといけないのに、自分が何が分からないのかが分からないストレス」だと思うんですね。

「平日はそんなストレスで疲れてるのに、土日まで勉強したくないんですけど」については、気持ちは分かりますが、
そのストレスは誰かが解消してくれるわけではありません。
自分で対策しないとずっと辛いままです。
特にエンジニアなりたては自分のレベルと現場レベルとのギャップが大きいので、学ばないといけなくことが多くあります。
せっかく勉強するなら、まずは自分のストレスの原因を潰して、楽になれるように勉強しましょう。

プライベートを使うことに抵抗感があるなら、丸一日使う必要はありません。
気になったことを調べるだけならスマホで移動時間でもできます。
私は仕事中に気になった点や分からなかったことは、
個人アカウントのエバーノートに箇条書きでさっとメモしておき、業務時間内に調べられなかったら土日や隙間時間で調べるようにしていました。

3.定例ミーティングの司会進行,議事録作成

隔週で部のミーティングがあり、その司会進行と、議事録の作成を担当しました。

一般的にも、ある程度新人がチームの仕事に慣れてきたら、チームのミーティングの進行や議事録作成をその新人に任せる風潮はわりと多くの会社にあると思います。

私も司会になったのが、私がアプリのサーバー側の保守運用のほぼ全般を任されるようになったタイミングとほぼ同じだったので、
アプリに関する議論の投げかけや報告、連絡、相談もこの会議で行っていました。

【一言アドバイス】 「何か募集があったらすぐ手を挙げる」と決めておこう
定例ミーティングの進行と議事録担当ですが、
私の場合、「誰かやってくれますか？」と上司から公募があったので、自分で手を上げて進行担当になりました。

「なんで進んでそんな面倒くさそうな仕事を？」と思うかもしれませんね。

簡単に言うと、冒頭で少しお話した「信用を積むため」です。

あなたが面倒くさいと思った仕事は他の人も大体面倒くさいと思っています。
しかし、こういったあまり周りがやりたがらない仕事を、新人のあなたが自分から「やります」と手を挙げると、
まず間違いなく、周囲の人から「あの新人はやる気がある」と思われますし、
その仕事で誰かの役に立てれば、その人から感謝されます。
あなたがその仕事をやることで、他のメンバーは別の仕事に時間を使うことができ、生産性が上がります。
その姿は上司や会社も当然見ています。

この小さな積み重ねが信用に繋がります。
結果的に、上司に
「こういうプロジェクトをやってみたい」「リモートワークにしたい」「休みを取りたい」と
自分の希望を言う際にも、説得力が生まれ、周りからの理解や応援が得られるのです。

もしかしたら
「戦略的に良い人を演じている感じがして、偽善っぽくてなんか嫌だな」
と思うかもしれませんが、
もしそう思ったら実際やってみてください。
演じているのではなく、実際に仕事を受け持っているのでしっかり手間がかかりますし、チームメンバーの為になっているのです。
むしろ、こういった機会は「チームの役に立つ」チャンスであり、同時に「自分が信用をゲットする」チャンスだと思いましょう。

また、事前に自分ルールで「何かあったらすぐ手を挙げる」と決めておくのがポイントです。
実際に会議などで「誰かやりませんか？」と上司から聞かれたら、どうしても「やりたくないな」「不安だな」と思って
躊躇します。
「とりあえず手を挙げる」を決めておくことですぐに動け、すぐに動くからこそ、やる気をアピールできるのです。

「何か募集があったらすぐ手を挙げる」と決めておく、おすすめです。

4.アプリに新機能を追加する

アプリに新たな機能を追加するプロジェクトのサーバー側の開発全般を担当しました。

「新たな機能」というのは、例えば、カードの今月の利用金額をアプリからメールで毎月お知らせしてくれる「メール通知機能」などです。

最終的に４つのプロジェクトを担当し、詳しいことは言えませんが、最終的に会社に１０００万円以上の売上をもたらすことができました。

具体的にはざっくりこんな作業内容です。

データベースの新しいテーブルの設計や、サーバー側のプログラムの設計
完成までの工数の見積もり
設計書とスケジュール表の作成
実装
テスト表の作成とテスト
新機能リリースのお知らせの作成
リリースとリリース後の保守運用

不具合の修正や、簡単な機能追加は元々ある処理を少し修正するだけですので、基本的には大きく処理を変更することはありません。
一方、機能追加は、今ある処理の修正だけではなく、追加する機能用に新たにデータベースやプログラムを追加する必要があるので、新しく扱うデータをどういうふうにデータベースに保管するとデータを使いやすいかや、どういうふうなプログラムの作りにすると今後も保守運用がしやすいか、などといった「設計」が必要になります。

ちなみに、機能追加は基本的に今動いているシステムの上に、新しくプログラムを追加する形なので、完全な０から作るわけではありません。
そのシステムがPHPで書かれていればPHPで新しいプログラムも書きますし、データベースもテーブルを追加する程度です。

一方、新規開発は０から新しいシステムをつくる作業です。
システムの土台となるインフラ構成やデータベースをどういう構成にするかはもちろん、言語・フレームワークに何を使うか、開発体制(設計書はどういうフォーマットで書くか、テストコードは書くか、コードの書き方のルール(インデントはタブかスペースかなど)、書いたコードはレビューするかetc...）をどうするか、も考えて決めていきます。
当然、土台となる最初の設計が悪いと、後の開発全体に悪影響がでます。

冒頭で新規開発系のプロジェクトはすぐには担当できないとお伝えしましたが、
私も機能追加のプロジェクトを最初に任せてもらえたのは、入社から10ヶ月後のことでした。

当然、プレッシャーもありましたし、分からないことだらけでストレスもかかりましたが、
だからこそ、エンジニアとして技術力が上がったのも、この機能追加系のプロジェクトの間でした。

この会社に在籍していた間に、エンジニアとして一番大きな成果を上げ、一番技術的に成長したのはまさにこの「機能追加」だったのです。

5.コードレビューとテスト

コードレビューというのは、簡単に言うと、
書いたコードに間違いがないかやもっと良い書き方がないかを、コード書いた人とは別の第三者がチェックして指摘することです。
チーム開発では取り入れられていることが多いです。

私のいた会社は、先輩後輩関係なく、コードレビューをする文化があり、私も先輩や後輩が書いたコードのレビューやテストを担当していました。

コードレビューをすることで、こんなメリットがあります。

「こういう書き方もあるんだ！」など、チームで知識を共有でき、チーム全体の技術力の向上が見込める
タイプミスや条件分岐の抜け漏れなど、コードに間違いがないかを早めに発見しやすい
プログラムの処理の流れをコードを書いた本人以外も把握できるので、改善のための議論や保守運用がしやすくなる

「先輩のコードを後輩がレビューするの？」と思われたかもしれないですね。
コードレビューをするためには、
システムの仕様を理解し、どういうコードが「良いコード」なのかをある程度理解していないといけませんので、
基本的にはエンジニア歴の長い人かチームリーダーのポジションの人がやることが多いと思います。

ただ、人手不足の会社や部署だと、私のように先輩のコードレビューやテストを任されるケースもありますので
やることもあるというのは覚えておいてください。

【一言アドバイス】1年経ったら最低１回は「リーダブルコード」を読もう
「リーダブルコード」という「エンジニアになったら必ず読んでおこう」とよく言われる、「良いコードとはどういうコードか」について書かれた有名な本があるのですが、私はコードレビューをするために初めてその本を読みました。

この本を読む前もコードは読み書き両方していましたが、
「どういうコードが良いコードなのか」という知識がなかったので、なんとなく既存のコードを真似して書いていました。
しかし、この本を読んだことで、明確な基準ができ、「こういう読みやすいコードを書こう」と意識できるようになりました。
少し読みづらい点もありますが、評判通りの良い本だと思います。

先程お伝えした通り、エンジニアになったたらまずは「分からないことを潰すこと」を優先するべきだと思いますが、
その段階はできれば１年以内には終えて、１年経ったら「理解を深める」「ベストプラクティスを知る」という勉強に移れると良いでしょう。
その時は、あなたも是非リーダブルコードを読むことをおすすめします。

まとめ

今回はエンジニアになると担当する業務についてお伝えしました。
今回の内容をまとめます。

仕事内容編

最初に担当するのは保守運用が多い
具体的には、システムのの不具合の調査・修正や簡単な機能追加など
コードを書く業務ばかりではない
すぐに新規開発の仕事を担当するのは難しい
新規開発を担当していくためには社内で信用をためて、技術力をつけていく必要がある

アドバイス編

マニュアルの改善にトライしてみよう
進捗は自分から報告しよう
①やり直しを減らそう　②目的を理解して応用しよう
休みに学習をするなら、「分かっていないこと」を潰そう
「何か募集があったらすぐ手を挙げる」と決めておこう
1年経ったら最低１回は「リーダブルコード」を読もう

参考になれば幸いです。

エンジニアになってみたいけど勉強法が分からないなぁという方はこちらの記事で解説していますので是非見てみてください。

今後も、私の実体験を元に、稼げるエンジニアを目指すために必要な情報を発信していきますのでよろしくお願いします。

お読みいただきありがとうございました！

脚注

「テストコード書かないのかよ！」や「設計書ないの？」というツッコミがありそうですが、少なくとも弊社にはなかったです。
ベンチャー企業はとにかくサービスを早くリリースして、ユーザー数を増やし、収益を安定して確保できる段階までサービスを育てることを優先しますし、少人数で開発をするので、
「設計書は作っていないし、テストコードも書くルールがない」という会社は多いと思います。 ↩︎
データベースに対する命令するための言語をSQLといい、命令文をクエリと言います。
データベースの大量のデータの中からほしいデータを検索する際や、大量のデータをデータベースに保管する際に、クエリを使って「こういう条件に合致する情報を全部ください」「これらのデータ保管して」とデータベースに命令するのですが、
クエリの書き方やデータベースの設定（インデックス）によって、その命令を実行完了するまでにめちゃくちゃ時間がかかってしまうことがあります。
（コンピュータの処理は0．0何秒の世界なので、実行完了まで数秒かかっていたらそれはもう「時間がかかっている」という扱いになります。）
これをすぐ終わらせられるように「クエリの書き方やデータベースの設定を変更して調整すること」をクエリチューニングといいます。 ↩︎