バックエンドエンジニアに転職!実務1ヶ月目にやったことの全てをお伝えします

都内のITベンチャー企業でエンジニアをしているアトフジ(@ato_fuzi)です。

バックエンドエンジニアとして転職して1ヶ月経ちました。

自分自身の行動の振り返りも兼ねて、実務1ヶ月目でやったことを記録します。

カテゴリー別にまとめていきますので、興味のあるところだけ見ていただければと思います!

 

【この記事を書いた人】

銀行員を辞め2020年5月に都内ITベンチャーへ転職。PHP、Laravelを中心にバックエンドエンジニアとして業務に携わってます。

目次

入社初日にしたこと

入社初日はパソコンの設定、コミュニケーションツール、タスク管理ツールの登録、入社オリエンテーションで終わりました。9時半に出勤し、18時に終了した感じです。

MacBook proのセットアップ

なんと最新のMacBook Pro 16インチが渡されました。しかもメインメモリ16GBでSSDストレージ512GBと高スペックモデル。

思わすその場でググってしまいましたが、税込みで30万円弱。私みたいな駆け出しエンジニアに申し訳ない気持ちもありましたが、それ以上になんていい会社に入ったんだとテンションが爆上げでした。

セットアップは何も問題なかったんですけど、AppIDの登録がなぜかその日のうちには出来ず。

後日試したら普通に出来たので、原因は不明です。AppIDに入力したメールアドレスは当然会社で作って用意してくれていたgmailアドレスで設定。

G suiteのパスワード設定

今の会社に入社するまで知らなかったんですが、G suite(スイーツ)は業務効率化のツールとしてGoogleが有料で提供しているビジネスツールです。

どうやら会社が契約していて、社内のメンバーとしてアカウントを作ってくれているみたい。

多分月1,360円のプラン。ありがとうございます。

このパスワードを登録して実際に使って見たんですが、超絶便利で感動しました。

僕の前職が金融機関だったので余計にそう感じただけかもしれません。

G suiteの凄い所

1.カレンダーが共有できる

2.カレンダー上でMTGのアポが出来る

3.Googleドライブで書類を共有できる

4.オンラインMTG「meet」が使える

カレンダーが他人と共有できるので、自分と働く上司の予定がすべて分かります。しかもMTGのアポもカレンダー上から出来、アポイントする時にオンラインMTGのmeetのURLまで付いて相手に通知されるので、それだけでOK。

あとはGoogleドライブが便利です。初めて使ったんですけど、GoogleドライブはGooleドライブ上で作成できるGoogleスプレッドシートドというのがあります。officeのwordやexcelみたいなものです。

Googleドライブ上で書類を作成し、共有ドライブにアップするとそのドライブに登録になっているメンバーに共有ができ、さらにオンラインMTGの際には同時に編集が可能となる素晴らしいシステムです。

恥ずかしい話まだまだ使いこなせていないです。僕と同じように畑違いの転職をした方にとっては結構イメージしずらいと思うので詳しく記述しました。

Drop Boxの登録

こちらも知っていたけど使ったことがないサービスでした。

利用用途としては自分のパソコン上の容量がいっぱいにならないよう作成したファイルの保存場所として使えるツールですね。

もちろんファイルの共有は保存されている書類のURLを他人に送れば可能。個人的なファイルの共有はDropBoxで、オフィシャルな書類の共有はGoogleドライブと使い分けている感じですね。

スマートシンク」の設定をするかセットアップ時に聞かれます。おそらく会社であれば法人プランで加入していて有料プランのはずです。そうであれば「スマートシンク」の設定は絶対にありにしておきましょう。

詳しいことはここでは書きません。

チャットワークの登録

私の会社ではコミュニケーションツールとして「Chatwork」を使っています。

エンジニア界隈でよく使われているコミュニケーションツールで有名なのはSlackですよね。

どっちも使ったことがない私にとっては未知の領域でしたが、イメージとするとLINEのビジネスバージョンといったところ。

Chatworkで社内の特定の人に個別にメッセージを送ることもできるし、プロジェクト管理をするにはプロジェクトメンバーだけが共有できるチャットグループを立ち上げ、そこで情報交換をしたり進捗状況を把握できたり、社内全員が情報共有できるグループが存在しています。

「分報」を作成して、自分の所属するグループメンバー全員に「分報」への招待してください。

こんな指示が飛んできましたが、全然訳が分からずググりまくりました。

※調べた結果、これはググるとかではなく、社内でのルール的なものだったので、社員の人に聞いた方が早かった。

要するにやることは一つ、チャットグループを立ち上げそこに開発メンバーを招待する。

LINEのグループを作るのとまったく同じ要領です。

「分報」は日報(自分が一日でしたことの報告)を分けて報告する仕組みとのこと。

つまり、自分で作ったチャットグループに進捗報告とか作業報告、休憩や休み等を報告し、今自分が何をしているかというのを同じメンバーに共有できるためのチャット=分報

ということですね。これが初日で一番緊張し頭使った出来事でした。

世の中の進歩に付いていくのは大変ですね。

 

あとは、社内でつかる勤怠管理ツールの設定とか諸々を行い初日は完了。

それにしても、ツールの設定、全てが初めてで結構疲れました。

環境構築でしたこと

これも概ね初日に行ったことですが、これからエンジニアとして働くための下準備を済ませました。

Google Chromeのインストール

これはエンジニアとして必須のアイテムですね。

すぐにインストールし、社内でこれから使う各種ツールをお気に入りに設定したりしました。

各種ブラウザのインストール

自分が開発担当するシステムが社内ツールで、その社内ツールを使う方のパソコンがWindowsだったのでとりあえずMicrosoft EdgeとIE、FireFoxをインストール。

Homebrewのインストール

これもMacで開発していくためには必須のツール。

「MacOS用パッケージマネージャー」ですね。

参考までに、分かり易かったQiitaの記事のURLを載せておきます。

homebrewのインストール

Composerのインストール

これはすぐには必要なかったんですが、僕の入った会社だとLaravelを使っているのでLaravelのパッケージ管理ツールのComposerをとりあえずインストールし、パスを通すところまで行いました。

こちらも実際に参考にしたQiitaの記事のURLを載せておきます。

macOSにcomposerをインストールする

MAMPのインストール

今後、PHPで開発を行う必要があり、ローカルでの開発環境を構築する必要があったのでMAMPをインストールしました。

MAMPはインストールするだけで、ApacheとmySQLとPHPがセットでインストールできてしまうため超お手頃です。

PHPでローカルの環境構築をするならとりあえずMAMP入れといていいんじゃないかと思います。

MAMPについて詳しく知りたい方はこちらのテックアカデミーの記事が分かりやすくてお勧めです。

誰でもできる!MAMPのインストール方法【初心者向け】

設定に関してはQiitaの記事の方が詳しく紹介されてます。

【MAC】MAMP(フリー版)のインストールから初期設定+バーチャルホスト設定までをまとめてみた

初日はここまでやって終了。

PostgreSQLのインストール

私の会社は珍しくデータベースにPostgreSQLを使っていましたのでインストール。

MAMPはmySQLだけでなくPostgreSQLも使えます。

PostgreSQLのポート番号はデフォルトで5432です。

PHPでPDOオブジェクトを生成する際のhostにlocalhost、portに5432し、あとはdatabase名とユーザー名、パスワードも設定してあげればOKです。

エンジニアとしての仕事

はい、全然大したことはしてません。

入社1ヶ月目なので好きなようにやっていいよ〜状態でした。

社内ツールの開発

開発するのが社内ツールで、優先順位としては高くなく、上司もめちゃくちゃ忙しい様子だったのでほとんど自分の好きなように開発してました。

とりあえず上司が作っていたツールのコードをもらいコードの理解。

ファイル数4つ程からなるシステムだったので、理解するのはそんなに苦労せず。

上司から引き継ぎで言われたのが「エラー処理が甘い」「処理結果のモニタリングがしたい」「DBのバックアップ方法を検討したい」でした。

より具体的に、エラーとは?どんなモニタリングをする必要があるのか?DBのバックアップはバックアップファイルを出力する程度でいいのか?などを聞いたりして、その後は自分の思うように開発ました。

エラー処理

・try catch構文を使いエラー時の処理を記述

・DBのエラーモードをEXCEPTIONに設定

 

モニタリング

・1日の処理結果をメールで送信

・エラー発生時もメールで送信

・エクセルファイルに結果を自動的に出力(PhpSpreadsheet)

 

DBバックアップ

・pg_dumpでpostgreSQLのDB情報をバックアップファイルとして出力

これらのことを実装。

もちろん知らないこと多いので超調べまくってやりました。

ちなみに勉強になたのが「バッチ処理」という仕組み。

決まったサイクルで決まった処理を行うことをバッチ処理といいますが、今回のツールは毎分10分で同じ処理を繰り返すバッチ処理をしているツールでした。

バッチ処理の命令の方法はとっても簡単で、ターミナルで「crontab -e」と入力し表示されるファイルに、実際に処理するコマンドを入力するだけでできてしまうという。

勉強になりました。

以上のことを5月前半にやりました。

 

その後、実際にシステムを使っている人からの要望として「検索機能」「ファイルのインポート機能」が上がってきたのでそれらを実装。

検索機能については、オンラインスクール「ウェブカツ」をやっていた時に自身のアウトプットでめちゃくちゃ苦戦した経験があったおかげで割とスムーズに実装。

ファイルのインポートも「php csv インポート」と調べたらジャストの記事が出てきてコピペで終了。

後はツールのGUIが全く考慮されていない状態だったので、分かりやすくするためにcssを適当に書いたりしてました。

検索機能もインポートも終了して、何もすることがなくなってしまったため、勝手に「ユーザー登録機能」「ログイン機能」を実装。

こちらはウェブカツで習った事をそのまま書き写しただけです。

 

上司が「誰でも使える状態はよくないから、本当はあった方がいいんだろうなぁ…」

そんな事を呟いていたので、勝手に作ってしまいまいた。

 

ちなみに私がやったことが「上司の要望を十分に満たしているか」はまだ分かっていません。

6月にレビュー受けて、実際にリリースになると思います。

今からドキドキ。また結果報告します。

sshでAWSサーバーにアクセスする公開鍵を作成し上司へ渡す

社内ツールがAWSサーバー上で動作しており、今後私もAWSサーバー上にアクセスする必要があったため、上司から突然指示が飛んできました。

サーバーアクセスするための公開鍵作って私にください

上司、かなりできる方っぽく、私が自分でできるためのヒントをよくつけてくれます。

この時も公開鍵を作るためのコマンドもセットで指示してくれました。

ありがとうございます。

ちょうどウェブカツでインフラ部を受講したばかりだったので上司の要望にも理解ができました。

$ ssh-keygen -t rsa

このコマンドで公開鍵と秘密鍵を作成。

秘密鍵:id_rsa

公開鍵:id_rsa.pub

 

このうちの公開鍵「id_rsa.pub」をDropBox経由で上司に無事渡す事ができました。

ちなみにAWSサーバーにアクセスするためには、自分の持っている秘密鍵と、上司に渡した公開鍵とで認証しアクセスすることになります。

上司が公開鍵をASWサーバー上にアップしてくれたので、早速アクセス。

$ ssh -i “id_rsa” ユーザー名@IPアドレス

以上のコードでアクセスできます。

※id_rsaが存在しているフォルダ内の場合です。そうでない場合はid_rsaへの絶対パスを書く必要があります。

ユーザー名とIPアドレスは上司の方で管理しているので教えてもらいました。

しかしアクセスできず…

 

こちらに落ち度はないので、おそらく上司の設定ミスかなと思いました。

AWSサーバー上に公開鍵をおくとき、ファイル名を「authorized_keys」にし、ファイルの置き場所が .ssh/authorized_keys でなければいけません。

そのことについて、やんわりと上司に質問。

無事アクセスすることができました。

ファイル名をauthorized_keysにしてから送ればよかったなと反省…

この時が1ヶ月目で一番焦ったなぁ。

1ヶ月の反省点

間違いなくコミュニケーション不足である事を反省。

チャットワークの分報システムを全然活用できてなったです。上司にも他メンバーにも、自分が今何をしているか把握してもらうために、もっとうまく活用するべきなので、来月以降意識して取り組みたいと思います。

あと、リモートワークのせいもありますが、上司以外の社員の方とほぼコミュニケーションゼロです。こちらも来月以降はLINEみたいに気軽にアプローチしてみたいと思っています。

また、上司に気を遣ってしまい聞くべき事を聞けなかった点が一番の反省点です。

例えば今回、開発環境は勝手に自分のパソコンにインストールしたMAMPで行っていました。

これは一声「開発環境はどうしましょう?」と確認しても良かったのかなとも思っています。

あとは自分が書いたコードの確認方法です。これもコードを8割方書き上げた上で確認。

上司もそのへんについては決めてなかったらしく、相談した結果Githubアカウント作成し、Githubにコードをpushすることに。

githubはコードの変更点「差分」が確認できるので、差分が分かるようにして欲しいとのこと。

とりあえず本番環境で動作しているファイルをAWS上からコピーしてきてgithubへプッシュ。

その後、自分が書いたコードにcommit履歴で変更点が分かるように記述してひたすらプッシュ。

差分チェック=上司の書いたコードと僕が変更した部分を随時チェック

と決めつけていました。

しかしこれも後々確認すると

差分チェク=現在のコードとリリース後のコードだけでいい

とのことで、どうやらこまめにpushすることは求められていなかった様子でした。

・開発環境について

・コードの共有方法について

・githubのpush頻度について

このような開発する上での「条件・ルール」に関してはやる前にちゃんと確認し、共通の認識を持っておくべきだと実感しました。

最後に、やはり今まで働いていた金融機関という組織とITベンチャーという組織の違いにも相当直面しました。

前職では、自分が行う業務はほぼ100%トップダウンで与えられていました。

支店の目標→上司の目標→自分の目標→自分の行動

といった具合です。

この認識で働いているとギャップに直面すると思います。

今回社内ツールを作っていく上で、中心となるのは自分でした。

「自分が主導し社内ツールを完成させていく」という認識が必要で、その感覚を強く意識したおかげで、そのために必要な情報を聞き出したり、場合ににってはオンラインMTGを設定するといったこともできました。

金融機関では常に上司の意見や状況を伺っての仕事だったので、大分その辺が違う様子です。

 

今回は以上です。また随時更新していきますのでよろしくお願いします。

ツイッターもやっていて、実務でのリアルタイムな情報やブログの更新情報などもツイートしているので是非フォローお願いします。

ツイッターアカウント:アトフジ(@ato_fuzi)

よかったらシェアしてね!

この記事を書いた人

30歳未経験でプログラマーへ転職を目指しているアトフジです。

プログラマー転職のために勉強したプログラミング知識、転職体験談を中心に情報発信しています。

現職:地方の金融機関
趣味:資産運用、読書、漫画

目次
閉じる