新人Webエンジニアがはじめの一ヶ月でやったこと

はじめまして！株式会社dotDの野上です。2024年7月から開発チームに参加している新人Webエンジニアです。

私は異業種からエンジニアにキャリアチェンジしたため、IT業界のこともエンジニアの働き方も何も分からない状態からスタートしました。そんな私が、エンジニアとしてデビューしてはじめの一ヶ月をどう過ごしたのかを書いてみたいと思います。

エンジニアを目指している方や、これからエンジニアのキャリアをスタートする方の参考になれば嬉しいです。

一週間目

まずはパソコンのセットアップ

ドキドキの初日は、出社してパソコンを受け取るところから始まりました。まっさらなMacBookに、コミュニケーションツール、タスク管理ツール、開発に使うエディタやGit、Dockerなどを次々インストールしていきました。初日はこれだけで終わってしまった感じです。

MacBookを使うのは初めてだったので、逆側から開こうとしたり(アップルロゴは開いた時に正しい向きになるんですね！)、右クリックのやり方も分からなかったりして、これから大丈夫か...？と少し不安になりました。

プロジェクトのドキュメントを眺める

参加したプロジェクトには膨大なドキュメントがありました。ディスカッション資料や、プロジェクトの将来像、開発のルールなどなど…。
最初は読んでも内容がほとんど理解できず、とりあえずどんな資料があるのかざっと目を通した程度でした。実際に開発に関わるようになってから、必要に応じて該当資料を探して読み返すようにしています。

ミーティングを見守る

私が加わったチームでは、スクラムという手法でアプリケーションの開発を進めています。スクラム開発では密なコミュニケーションが求められるため、毎日ミーティングが行われます。

初日からミーティングに参加させていただきましたが、飛び交う言葉や、画面共有されている資料の内容など、全くついていけませんでした。一週間目は、ただ聞いているだけで精一杯でした。

timesで日報を書き始める

社内のコミュニケーションにはSlackを使っており、個人用のチャンネル「times」に日報を書くことにしました。これは本当にやって良かったです！今も続けています。
毎日やったことを振り返って、うまくいかなかったことはどう改善できるかを考えて書いています。自分で考えて改善していくことで、より楽しく真剣に仕事に取り組めています。

また、他にもメリットがあります。リモートワークが多い当社では、他のメンバーが何をしているのかが見えづらい面があります。
そこで、その日何をして何に困っているかをtimesで発信することで、先輩方に「あの新人は今日何をやっていたんだろう」と心配させずに済むし、頑張ってますアピールにもなるし、さりげなく助けを求める場としても使えます！

二週間目

環境構築を乗り越える

環境構築とは、自分のパソコン上でアプリケーション開発を行うための作業環境を整えることです。この環境を作らないことには何も始まらないのですが、これが最初の壁になりました。
手順書を見ながら、ライブラリのインストールやデータベースの準備を進めていきました。が、環境構築ではよくあることですが、ドキュメント通りにやってもなかなかうまくいきません。
先輩に助けていただいたり、ライブラリのバージョンを少しずつ変えて試したりしながら、二週間目の終わりにようやく環境構築ができました。

環境構築に二週間もかかってしまったことや、エラーを自力で解決できなかったことに少し落ち込みました。ですがこれでようやくコードを書く準備が整いました！

バグバッシュを楽しむ

バグバッシュとは、一定の時間内でアプリケーションを操作し、ゲーム感覚で楽しくバグを見つけるイベントです。この頃ちょうど複雑な機能の開発が終わったタイミングだったので、開発チームでバグバッシュをしようということになりました。
「バグだけではなく、気づいたことや気になることを何でも挙げてOK！」というルールだったので、私も気負わずに楽しく参加することができました。

ミーティングで議事録をつけ始める

一週間目はミーティングに全くついていけなかったため、自分用に議事録をつけることにしました。先輩方がどの資料を見てどんな話をしているかをメモして、分からなかったことは調べたり、教えてもらうようにしました。
少しずつですが、各ミーティングの目的やメンバーの役割、スクラム開発の進め方が分かってきました。

三週間目

初タスクを実施

三週間目に、フロントエンドのバグ修正のタスクをもらいました。ついにコードを書いていきます！
まずはバグの挙動を確認し、どのように修正すれば良いかを考えてからタスクに取り掛かりました。

実際の製品のソースコードを読むのはほとんど初めてで、ファイルの多さやコード量に圧倒されました。
とりあえずコードを読み始めたものの、どのファイルのどの部分を直せばいいのか、流れを追うまでに数日かかってしまいました。一つの処理が複数のファイルにまたがっており、追っていくうちに何を追っていたのか分からなくなることも…。
後から振り返ると、アーキテクチャを理解せずにコードを読もうとしていたのが問題だったと気づきました。

アーキテクチャの学習

アプリケーションが採用している「オニオンアーキテクチャ」の学習をしました。アーキテクチャとは設計思想のことで、アプリケーションの根幹となる部分です。これが分かっていないと、そもそものアプリケーションが目指すべき姿が見えていないことになります。アーキテクチャの学習はもっと早くやっておくべきでした。

アーキテクチャの考え方を学んだことで、ディレクトリ構成や各ファイルの役割が分かり、コードが読みやすくなりました。
入社前に、参加予定のプロジェクトや使用言語は教えてもらっていましたが、可能であればアーキテクチャも教えてもらい事前学習できていたら良かったと思いました。

四週間目

初コードを提出

前の週にもらったバグ修正のタスクにまるまる一週間かかってしまいましたが、ようやくコードを提出することができました。先輩にレビューしてもらい無事にソースコードに反映されたときは、とても嬉しかったです！

次のバグ修正タスクを実施

数個のバグ修正タスクをもらい、進めていきました。アーキテクチャの学習をしたことで、コードの流れはだいぶ追いやすくなっていました。次は機能開発のタスクにも挑戦してみたいと思い始めました。

ミーティングで発言できないことに悩み始める

ミーティングにはだいぶ慣れてきましたが、まだ聞いているだけのことが多かったです。
この頃から、ミーティングで発言できなかった話題を振り返るようにしました。ついていけなかった話をメモしたり、事前にミーティングで話されそうなタスクに目を通すようにしました。
それでも先輩方の議論にはなかなか参加できないのですが、些細な疑問でも良いので、とにかく声を出すように心がけました。

終わりに

まだまだ戦力にはなれていませんが、チームの一員としての実感が少しずつ湧いてきています。チームで協力して一つのアプリケーションを開発していけることがとても楽しいです！
魅力的なアプリケーションを開発できるエンジニアになれるよう、これからも精進していきます。