エンジニア生活：1ヶ月目

## はじめに
11月にエンジニアとしてのキャリアをスタートしてから、早いもので1ヶ月が経ちました。IT業界未経験からの挑戦で、多くの新しい経験をしました。この記事が、これからエンジニアとしてキャリアをスタートする方々にとって、少しでも参考になれば幸いです。

## 働いてみての感想
「初っ端から感想かよ！？」と思われるかもしれませんが、多くの方が実際に一番気になる部分だと思います。エンジニアとして1ヶ月働いてみての感想は、「不思議な感じ」というのが一番正直な表現です。

具体的には、ついこの間まで医療従事者として働いていたため、出社が当たり前の環境にいました。しかし、エンジニアになってからは、最初の数日間だけ出社し、その後はリモートワークに切り替わりました。自分の中では、1～2ヶ月は出社して仕事を覚えてからリモートが許されるものだと思っていたので、この変化には少し驚きました笑
現在、東京に住んでいるのですが、朝の通勤がないだけでこんなに楽なのか・・・と毎日神に感謝しています。。。🚃

また、エンジニアとして実際に会社に勤めているという事実が、まだ信じられない時もあり、たまに夢ではないかと思うこともあります。転職時の記事を読んでくださった方はご存知かと思いますが、私のエンジニアへの転職は決して簡単な道のりではありませんでした。しかし、結果的にエンジニアになれたことを素直に喜びたいと思います。

少し長くなりましたが、結論は**リモートワーク最高**ということです。👨‍💻

## 1ヶ月間の流れ
ここでは11月に勤務を開始してから、各週にどんなことをしていたのかを簡単に振り返ります。

### 1週目: 会社のルール説明&研修
1週目は、勤務にあたってのスケジューリング、会社のルール説明、連絡用ツールの使い方などの研修を受けました。また、Excelの関数式など基本的な操作についても学びました。

### 2週目: 参画案件の説明
2週目は、自分がアサインされる案件についての説明を受けました。使用する技術やデータの出力方法、最終的なゴールについて、アサインメンバーとコミュニケーションを取りながら学んでいきました。

### 3週目: 処理設計書の横展開
3週目は、先輩エンジニアと協力して処理設計書の横展開を行いました。この時期は特に大変でした。私は「要件定義」の段階では案件にアサインされていなかったため、各テーブルの定義や処理の詳細について理解していなかったので、まるで霧の中を航海しているような感覚でした。

### 4週目: HULFT Square、Amazon S3、Redshiftを使用したDB作業
4週目は、HULFT Squareでスクリプトを作成し、Amazon S3やRedshiftでSQLクエリを実行しながら、データがどのように格納されているかを確認しました。大規模なデータベースを操作する経験は非常に感動的でした。

## エンジニアとしての仕事の進め方
ここからは先輩エンジニアに教わった仕事の進め方について記載していこうと思います。
### 1.タスクを抱えたらマトリクスを作れ
マトリクス？マトリックス？みたいな某SF映画を思い出しそうになりますが、下の図を見ればなんか見たことあるな・・・となる人も多いかと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2956452/a85ab20a-4c2f-4b9a-0e90-a3d7da437a0c.png)

エンジニアになって気づいたのは、気がつけばタスクを大量に抱え込んでいることです。毎日の定例会議で次々とタスクが振られ、どれから手をつけていいのか分からなくなることがしばしばありました。この問題を先輩に相談したところ、「緊急度」と「重要度」のマトリクスを使う方法を教えていただきました。

タスクが割り当てられた際には、その**緊急度**（いつまでに完了すべきか）と**重要度**（プロジェクトへの影響の大きさ）を確認することが重要です。この習慣を身につけることで、手掛けるタスクが生産性の高いものなのか、それとも優先度の低い「ゴミタスク」なのかを見極めるようになりました。

### 2.タスク完了の見積もりを立てろ
医療業界で働いていた時には経験しなかったこの考え方は、大変勉強になりました。私はリハビリの専門職に携わっており、その時は前日にスケジューリングされた通りに業務をこなせばよかったのです。しかし、エンジニアの仕事は予期せぬ仕事やエラー修正が日常茶飯事であり、**バッファ**（時間的な余裕）を設けて仕事を進める必要があります。

例えば、処理設計書の横展開と前日に格納したデータの修正をタスクとして割り当てられた場合、以下のように見積もりを出します。

```タスクの見積もり: タスクの見積もり
処理設計書横展開: 1つあたり10分 × 10個 = 100分 + バッファ20分 ➡️ 合計作業時間120分
データの修正: 1つあたり5分 × 15個 = 75分 + バッファ15分 ➡️ 合計作業時間90分
```

このように見積もりを立てて報告することで、作業時間の終了を周知できます。

ここで重要なポイントは、**タスクに着手する前に見積もりを立てる**ことです。一見、最初に1つのタスクを完了させてから時間を算出する方が良さそうに思えますが、それは避けるべきです。人は自分の能力を過信しがちで、感覚的に作業を進めると予定より早く終わると考えがちです。しかし、実際には見積もりを立ててから作業を始めた方が、ゴールが明確になり、予定時間内に終わることで自分もチームも満足できます。また、見積もりがオーバーした場合は、自分の現在の能力を正確に把握し、今後の見積もりの精度を高めることにつながります。したがって、タスクに着手する前に見積もりを立てることは、自己の対応力を知る意味でも重要です。

---------------------------------------------------------

*「見積もりを立てる」と心の中で思ったならッ！その時スデに行動は終わっているんだッ*

*ｂｙ　エンジニアに転職したプロ⚪︎ュート兄貴*

---------------------------------------------------------

### 3.仮説思考で質問せよ
未経験からエンジニアに転職した人が最も苦労する点は、恐らく質問の仕方にあると思います。質問することには勇気が必要ですし、特に「ググれカス」という文化が根強い会社では、どの程度まで質問して良いのか判断が難しいですよね。しかし、質問しなければ解決できない問題も多くあります。

私自身、入社後2週目までは「わからないゲシュタルト崩壊」に陥っていました。この状態では、何がわからないのかさえわからなくなり、日本語での会話すら困難になってしまいます笑

そんな時、先輩エンジニアから教わったのが**仮説思考**です。仮説思考とは、限られた情報から最も可能性の高い結論を「仮の結論＝仮説」として設定し、その仮説に基づいて実行・検証・修正を行う方法です。この説明だけでは分かりにくいかもしれませんので、具体的な流れを説明します。

```仮説思考: 質問するまでの流れ
1. 自分に質問を問いかける。
　　　　　　　　　　　┗ なぜこれをやるのか
2. こうだと思ったから
　　　　　　　　　　　┗ 仮説思考
3. だからこうしようとした
　　　　　　　　　　　┗ 相違認識はないか
```

このような質問の仕方をすることで、お互いにどこまで理解しているのか、またどこから認識のずれがあるのかを瞬時に把握でき、結果として工数を削減することが可能になります。
幸いにも私が参画している案件の敏腕エンジニアの方々は皆優しいので、こちらの言語出力がうまくいってなくても、ものすごい推察力で汲み取ってくれてます笑

---------------------------------------------------------

*質問を質問で返すなあーっ!!*

*ｂｙ　ググれカス文化の強い吉良⚪︎影*

---------------------------------------------------------

## 働く上で必要な能力
働く前は、エンジニアはコードを書く能力さえあれば良いと思っていましたが、実際にはコーディング以前に必要な能力や知識が多くあることを実感しました。これは私がまだ1ヶ月しか働いていないための個人的な見解ですので、ご留意ください。

### ショートカットキー
私はプログラミングスクールで基本的なショートカットキーを学びましたが、実際の業務でExcelを多用する中で、知らないショートカットキーがまだまだ多いことに気づきました。**ショートカットキーを多く知っているほど、業務の効率化が図れます**。エンジニア転職を考えている方は、この知識を事前に蓄えておくことをお勧めします。

また、私の場合は会社からMacを支給されていましたが、プロジェクトの都合上、急遽Windowsに切り替える必要が生じ、キーボード操作の違いに苦労しました。そのため、可能であればMacとWindowsの両方のショートカットキーを覚えておくと、どんな環境でも対応できるようになります。

https://dekiru.net/article/18619/

https://support.microsoft.com/ja-jp/office/excel-%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89-%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88-1798d9d5-842a-42b8-9c99-9b7213f0040f#PickTab=Windows

https://support.microsoft.com/ja-jp/office/excel-%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89-%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88-1798d9d5-842a-42b8-9c99-9b7213f0040f#PickTab=macOS

### 連絡ツールの使い方
連絡ツールは毎日使うため、入社前にどのツールを使用しているかを確認し、基本的な使い方を学んでおくことをお勧めします。ツールによっては独自の使い方があり、慣れるまでに時間がかかることがあります。エンジニアとしては、情報を見やすく、わかりやすく、迅速に伝えることが求められますので、事前に使い慣れておくことが重要です。

また、**先輩エンジニアが他の人とどのようにコミュニケーションを取っているかを観察し、ブックマークしておく**と良いでしょう。後で見返して、似たような状況での返信の参考にするのが効果的です。

私の会社ではSlackを使用しています。以下のサイトを参考にして、Slackの使い方を学びました。

https://slack.com/intl/ja-jp/blog/transformation/how-to-use-slack-conveniently

### コードを読む力
スクールや独学で自作アプリを作っていた時とは異なり、他人が書いたコードを読む機会が格段に増えます。特に大規模なプロジェクトでは、テーブルやカラムの数が増え、複雑さが増します。新人エンジニアにいきなりコードを書かせることは、先輩エンジニアの監視下以外ではまだ少ないように感じます。そのため、コードを書く能力よりも、まずは**コードを読む能力を鍛える**ことが重要だと痛感しています。

他人のコードを読めるようになると、設計書の理解やクエリの横展開、応用が効くようになり、より専門的なタスクを任されるようになります。私自身も休日にはデータベースやSQLに関する本を読み漁り、現在の案件のテーブル定義を理解しようと努力しています笑
不思議なことに、11月初旬と12月初旬ではテーブル定義書や処理設計書の読み方が全く異なり、日々成長を感じています。これからも焦らず、楽しみながら学習を続けていきたいと思います。

### 英語力
実際に働いてみて感じたことの中で、これが最も重要だったかもしれません。会議で使われるカタカナ英語や処理設計書に記載されている処理名など、**プログラミングと英語は密接に関連しています**。確かにわからない言葉をChatGPTなどで調べればすぐに解決できますが、会話中に都度検索するのは時間のロスになります。また、英単語を理解しているだけで、どのような処理をしているのか直感的に把握できることも多くなります。

私自身、英語力の不足を痛感し、現在は勤務後に自主的にTOEICの勉強をしています。私が勤めている企業は留学などを積極的に支援してくれるので、2年以内に海外留学を目指しています。まずはTOEICを通じてビジネス英語の基礎を固めることが目標です。また、英語力を身につけることで、自分のキャリアにさらなる価値を加え、選択肢を広げることができると考えています。これからも英語学習に励んでいきたいと思います🇺🇸

## おわりに
ここまでお読みいただき、ありがとうございました🙇
たった1ヶ月の出社で、これほど多くのことを学べるとは思ってもみませんでした。

現在の案件が少し落ち着いたら、Salesforce系の資格や基本情報技術者、応用情報技術者の資格取得にも挑戦する予定です。次に振り返りの記事を書く頃には、エンジニアとしてだけでなく、人間としても成長していることを願っています。

エンジニアに転職してからは、知らないこととの遭遇が多く大変な面もありますが、新しい発見に満ちた毎日がとてもワクワクします。本当に良い仕事に出会えたと心から感じています。

それでは、また次の機会に👋