アソビュー！のカレンダー | Advent Calendar 2023の17日目（表面）の記事です。
皆さんこんにちは。
寒い日が続いていますが、いかがお過ごしでしょうか。
最近気が付いたことがあります。自宅からジムまで自転車で移動しているのですが、ある日そのルートを散歩することがありました。歩いてみると、あら不思議。
「こんなお店があったのか、こんなでっかい家が建っているのか」と。
ゆっくりと移動したからこそ、これらの発見がありました。
人間速く移動しようとしがちですが、あえてスピードを落として生活するのも大事な気がします。
申し遅れました。アソビュー株式会社でフロントエンドエンジニアをしている髙木と申します。
今回は、文系学部出身の新卒が入社して行ったタスクと学びの話をさせていただきます。
技術的な詳細というよりかは、業務の進め方、学習の仕方、職場でのコミュニケーション方法などに重きを置いており、実務経験があまり多くない読者（特に学生）にとって有益な情報をお伝えできたらと思います。
はじめに
2023年4月に新卒としてアソビュー株式会社にエンジニアとして入社しました。
大学では情報系の学部で朝から晩までコードを書いていた、という訳ではなく、文系学部に所属しプログラミングとは無縁の学問を専攻していました。
留学中、ひょんなことからプログラミングに興味を持ちエンジニアを目指すことになったのですが、学部が学部なもので、プログラミングを行えるような授業はありませんでした。
となると、自分で学んでいくしか道はありませんでした。
できる限りプログラミングの勉強に時間を注ぎ、結果として内定をいただくことができました。
実のところ、入社して最初からプログラムを書く業務を行っていた訳ではありません。
どの会社にも「新人研修」があり、私もその一環でプログラミングとは関係の無い部署に約3ヶ月間在籍していました。
新卒研修
上記で述べた通り、入社後最初からコードを書いていた訳ではなく、観光戦略部（現在は観光戦略室）という、全国の地域の事業者様、地方自治体様と体験型観光商品の開発、販路開拓、販売をおこなう部署で研修を受けていました。
具体的には、地方自治体様との商談に参加させていただいたり、地方自治体様が必要としているデータの抽出や、出張にも同行させていただきました。
プログラミングには携わりませんでしたが、エンジニアとして、ひいては社会人として以下のようなことを学びました。
1. 自社サービスを理解すること
まず、エンジニア云々の前に、自分たちがどのようなサービスを提供できるのかを知っていなければ、本当の意味で顧客の課題解決などできません。
ビジネスの基本は顧客の課題解決であり、自社サービスをしっかり把握し、提供できること/できないことを理解していれば、顧客の根本的な課題解決を行うことが可能であると考えています。
2. チームで働くということ
一人で課題を解決することはほぼ不可能です。
協調性と自発性を持ち、チームで動き巻き込み巻き込まれ、協力し合うことで課題解決に近づくことができます。
エンジニアこそ、チーム力がもっとも求められる職種だと、今思います。
3. 学びを抽象化し、具体化すること
一番の学びです。研修期間、退勤後や休日にプログラミングを忘れないようコードを書いてはいたものの、自分がいた研修部署ではコードを書くことはありませんでした。
エンジニアとして入社したということもあり、研修の意味が見いだせなくなったこともありました。
しかし、どんなことにも学びはあります。
1つの学びを抽象化し、10の具体に落とし込むことで、実際にエンジニアとしてコードを書く際に役立ってくれています。
例えば、「自社サービスを理解すること」は、「その機能でできること/できないことを知る」とも言い換えられます。
それを具体に落とすと、「React.jsを扱う上でReact Hooksの知識は必要不可欠で、React Hooksでできること/できないことを知らなければ開発も進まない」と言えます。
どこかで学んだことは、違う領域で活用してくれます。
フロントエンド業務
新人研修を経て、ある大規模プロジェクトのフロントエンド業務に7月から携わることになりました。
当該プロジェクトのフロントエンドはTypeScript / React.jsで動いており、幸いにも自分がプログラミング独学時代学んでいたものだったので、先輩方のサポートもあり特段不安視することなく参画できました。
最初は簡単なバグの修正から始まり、次第にロジックを組む作業、まるまる1ページ作成、QAタスクなど多くのことをおこなっています。
とはいえ、最初から上手くいく訳もなく困難ばかりで、たった1つのタスクに時間がかかり他の作業が進まなかったことや、何度も修正し直したり、調べてばかりで手が進まないなど、挫折を味わうようなことが続きました。
とにかくフロントエンドの知識が足りていないことを認識し、身に付けるために「人のコードをよく見る」「真似る」ということを意識しました。
この2つを意識することで、ファイルの構成や流れ、また「このように記述すればこうなる」というように正しい原因と結果を知ることができます。
最初のうちに「こうすればこうなる」というデータをたくさん知っておくことで、新しいタスクをおこなう際に役立ってくれました。
そんなフロントエンド業務を行っているうえで、以下のようなことを学びました。
1. とにかく動かしてみる
参画した当初、これまであまり触ったことのないReact Hooksを扱うことがありました。
公式ドキュメントや参考になる記事を見て調べることに多くの時間を使ってしまい、結果としてタスクの進捗が悪くなってしまうことがありました。
使い方を理解しても結果的に進捗が悪くなっては元も子もないので、とにかく動かしてみるのが一番だと感じます。
全部を調べる必要はなくて、ちょっと調べたらまずは手を動かしてみます。
なにせフロントエンドは編集の結果をすぐブラウザにて確認することができるので、とにかく動かしてみて詰まったら調べて、また動かして、というようなことを繰り返していくことで、エンジニアとして成長できるのではないかと日々感じています。
2. 素直に聞く
「とにかく聞きにくい。」最初はそう感じてました。
チーム内に怖い人がいて、聞いたら危険な目に合うんじゃないか、そう思ったからではなく、「今忙しそうだな、、」「聞いたら迷惑になるかな」最初はそう感じていました。
ただ、自分がやるべきことは、助けてもらうことじゃなく、顧客の課題を解決するために開発を行うことであることを再認識し、チームメンバーとの1on1を組むことでまずは心理的な壁を取り除くことにしました。
業務とは関係のない雑談などをすることで心理的安全性が次第に担保され、今では、自分で考えても分からないことは素直にすぐ聞くようにし、タスクの進捗も改善されていきました。
3. Web API（以下、API）を理解する
当たり前の話ですが、欲しいデータがある場合は「これ欲しいです！」とリクエストを送らなくてはいけません。
しかし、独学で学んできた自分にとってAPIでどんなことができるのか、きちんと理解できておらず、そのため、タスクの進捗が悪くなることがあり、参画前にしっかりAPIについて理解を深めておけば良かったと思っています。
負荷テスト
フロントエンド業務に携わり始めて２ヶ月ほど経ったある日、新規サービスの負荷テストを担当することになりました。
そうです、フロントエンド業務と負荷テストのダブルタスクです。（これがなかなか大変、、）
負荷テスト自体は存在こそ知っていましたが、具体的に何をやったら良いかの前提知識すらなく、、
まずはScalaと負荷テストツールであるGatlingのキャッチアップから始まりました。
gatling.io
なんといっても最初は公式ドキュメントです。
公式ドキュメントには、ローカルでの実行方法もだいたい記載されているので、Gatlingをインストールし、簡単なシナリオを作成して負荷をかけ、実際にローカルで実行しました。
Scalaに関しては、シナリオの作成においてそこまで難しい記述はされないことが分かったので、実際にシナリオ作成したりChatGPTに聞いてコードを改善したりしていく中で、自然と少しずつ身に付いていきました。
キャッチアップ期間はだいたい1ヶ月ほどだったように思います。
実際の業務としては、まずQAエンジニアから具体的な負荷量の想定を共有してもらいます。
今回は利用者の同時アクセスにどのくらい耐えられるかが主な目的だったので、その手段として、APIの負荷量を測り、該当するAPIのリクエストやレスポンスを確認しながら、それに合わせて負荷シナリオをいくつか作成しました。
その後、完成したら実行する台数に合わせてcsvにデータを積み上げ実行し、負荷量をDatadogやArgo Workflowsを用いて測定などおこないました。
クラウド時代のサーバー監視&分析サービス | Datadog
Argo Workflows - The workflow engine for Kubernetes
具体的な負荷テストの内容については、こちらを御覧ください。
そんな負荷テストを行っていくなかで以下のようなことを学びました。
1. エラーメッセージから逃げない
エラーメッセージに答えは書かれていると思います。
負荷テストを実行し、エラーが出たらメッセージをさらっと読んで、この辺りが間違ってるんだなと勘違いし、関係のない場所を修正し無駄に時間を消費してしまったことが何度かあります。
エラー内容を読みもせず「だいたいこの辺りが間違ってるだろうな」という予測はやめ、しっかり読み、適切な修正をおこなうことがエラー解決の一番の近道だと感じています。
2. ネットワークタブを活用すること
「リクエスト投げてるのになんでレスポンスが返ってこないんだ、、？これじゃAPIの負荷量を測れない、、」なんてことが多々ありました。
これはフロントエンド業務で述べた「APIを理解する」に類似していますが、デベロッパーツールのネットワークタブからそのページで呼んでいるAPIを見ることができ、そこでリクエストボディやレスポンスを確認できるのに、当初私はネットワークタブの有用性を理解できていませんでした。
APIがエラーのレスポンスを返したら、ネットワークタブです。 正常に呼べていないAPIのペイロードを見て、適切なリクエストボディを確認。どこでどんなAPIを呼んでいるかの理解にも繋がるので、ネットワークタブを活用することの重要性に気付けました。
「デベロッパーツールの活用術」なんてタイトルでいつかテックブログ書いてみます。
3. バックエンドエンジニアに頼る
負荷テストはフロントエンド業務とは異なり、シナリオの設計やAPI周りについて考える必要があったため、どちらかというとバックエンドの知識が求められました。
基本的にはネットワークタブを確認し、APIのリクエスト/レスポンスを確認し作業をおこなっていたのですが、正しい形式でリクエストを送っているのにも関わらず、正常にAPIを呼べずタスクが止まることがありました。
そんな時、一時的に負荷テストにバックエンドエンジニアの方が参画してくださり、あれよあれよと止まっていたタスクが進み出しました。
APIを呼ぶ順番であったり、headerにセットする値やエラー時の対応、Datadogの見方、多くのことを教えていただき、その結果、タスクは進み無事シナリオを作成することができました。
異なる領域のものを担当する際は、その領域に特化した方に頼ることで物事は円滑に進んでいくと感じました。
まとめ
今回は文系学部出身の新卒が入社して行ったタスクと学びについて紹介させていただきましたが、いかがでしたでしょうか。
入社してから日々新しく、そして多くの事をおこなっています。そしてその分、多くの学びがあり成長へと繋がっています。
振り返ってみても、特に研修期間で学んだ3つのことが特に重要だと感じており、自社サービス及び組織を理解すること、チームで動くということ、1つの学びを他の場面で活かすこと、そういった「仕事をする上でのスタンス」や「ビジネスマンとしての基礎」を身につけることで、エンジニアとしての自分をさらに成長させてくれると感じています。
技術的な話はできませんでしたが、自分もエンジニアを目指し始めた頃、こういった類のテックブログを読み漁っては勉強や就活、入社してからの動き方を参考にしていました。
文系学部出身でこれからエンジニアとして就職する人、エンジニアを目指している人、そして日本のどこかにかつての自分と同じような人がいれば、ぜひ参考にしていただければと思います。
さいごに
アソビューではより良いプロダクトを世の中に届けられるよう共に挑戦していくエンジニアを募集しています。 カジュアル面談もやっておりますので、お気軽にエントリーください！ お待ちしております。
