#18_WFSでの内定者アルバイト体験談！
こんにちは。株式会社WFS所属、23新卒の新人サーバーエンジニアの檜垣です。
僕はグリーに新卒入社してWFSに出向しているのですが、入社する前に９ヶ月間（＋インターンとして１ヶ月）、アルバイトとしてサーバーエンジニアをしていました。
その間の仕事内容や感想などを赤裸々に語っていけたらと思います！
インターン時代（３月〜４月）
僕はグリーに内定する前に、現場で一ヶ月間インターンする機会をいただきました。
これはグリーに就職することを決意した上での一番大きなイベントだったと思います！
この時、大学が春休みだったため、週５、完全オンラインによるリモートワークで参加していました。WFSで今最も勢いのあるヘブンバーンズレッドのサーバーチームに配属され、２年ほど数人でのWeb開発をやっていた僕はここで勉強しつつ、少しでも爪痕を残してやろうと息巻いていました。
しかし、１００人を超える大規模開発チームの開発の勢いは物凄く、開発フローへの追従や初経験のPHP言語での開発、ひっきりなしに飛び交うslackのキャッチアップ、知見の無いインフラ構成のインプット、などなかなか思うようにいかず、苦しい思いをしました。
このままではいけないと思った僕は、チーム内外の色々な先輩に相談しました。そして今までの仕事に対する認識や意気込みがずれていることに気が付きました。
具体的には、僕は与えられた仕事をがむしゃらにやっていたのですが、それではだめで、「自分で主体的に行動する」「周りの人と積極的に交流する」「業務の周辺で使われている技術を深くまで知る」といったところが足りていなかったです。
このあたりを意識するようになると、周りの方の対応も変わり、とても仕事が楽しくなりました。これらは今でも実践していて、かなり身になっているなと感じています。
内定者アルバイト時代（６月〜３月）
無事グリーに内定し、引き続きWFSで内定者アルバイトとして働くことになりました。
大学の研究室と並行してだったので、基本週２でバイトしていました。
インターンで仕事への姿勢がある程度身についたので、それをふまえ色々な仕事をやらせていただきました。
アルバイトとして働いている中で、特にWFSのすごいなと思った点が４点あります。
いちプレイヤーとしてゲームを愛している
WFSの方々はみな、少しでもいいゲームをユーザーに送りたいという気持ちが強いです。
いちユーザーとしてヘビーに自社プロダクトを遊んで、その中で少しでもより面白く、より楽しんでもらえそうであればどれだけ大変でもやる！という意識を持った方が多く、いつも熱量を感じています。
やりたいことができる
例えば、エンジニアでも施策のプランニングに顔を突っ込んだり、他の自社ゲームと協力して全社的にゲーム自体や、業務フローなども改善していこうと動いている方も多くいます。
これはやりなさい、と決められたものではなく、個々人がなにをするのがゲームのため、ユーザーのためになるのかを考え、貢献できることならなんでもやらせてもらえる風土があります。
アルバイトでも正社員と対応が変わらない
WFSでは、外面でこの人がアルバイトだ！とか、正社員だ！とかがわからないようになっています。
そのおかげで、他チームの方と連携して仕事をする時に、この人はまだアルバイトだから任せられないな、とかいったことがなく、一人前として見ていただけたのはありがたいと思っていました。
いきなり重要な仕事を任せてもらえる
同じ扱いだけあって、アルバイトでも正社員と同じ仕事が割り振られます。
インターンでもそうでしたが、一ヶ月目からいきなり実際のゲームのコードを書いて、稼働しているゲームに埋め込まれたり、新規機能の実装を一部まかされたりもして、とてもやりがいがありました。
実際に、その新規機能が世に出て自分が書いた所が動いているのを見ると、感動を覚えましたね。
いきなりそんな未経験の新人が本番のコードを書いても大丈夫？と思う方もいらっしゃるかもしれませんが、実装する上で、PHPUnitによる単体・結合テストや静的解析ツール、コードフォーマッタなどを利用して一定のルールと品質担保をしています。
またQA（Quality Assurance）チームによる様々な実機動作検証フェーズもあるため、しっかり抜け漏れの無いように注意して実装するのは前提として、安心して実装することができました。
更に、ダブルチェック体制にて本番DBをマイグレーションしたり、本番のサーバーコードのデプロイをしたり（！）もしました。ミスすると一瞬でゲームが遊べなくなってしまうような大事なフローなので、メトリクスも落ち着いており障害無くデプロイできたのは安心しましたし、いちゲームプレイヤーとして、サーバーをこのように守っている人がいるからゲームを安心して遊べるんだな、と感謝したりもしていました。
細かい所を上げるときりがないですが、WFSは皆3Rを体現した方々だなと思っていました。
実際の仕事内容
APIサーバーの開発で主となるゲームAPIの説明については細かいところをお伝えできないので、それ以外で自分がやった内容を一部かいつまんで説明しようと思います。
1.AdminToolのマスタモデルを自動更新する仕組み
ひとつめは、AdminToolで使っているマスタデータのモデルを自動更新する仕組みの作成です。
背景・前提
AdminToolとは、WFSで使われているゲーム内のマスタデータやユーザーデータなどを管理して、ゲーム自体の管理やユーザーからのお問合せに対応するためのツールです。フロントエンドは React（Typescript）、バックエンドは PHP で実装されています。
ゲームのアップデートなどによってマスタデータは増えていくため、AdminToolもそれに合わせて更新する必要があります。
マスタデータはスプレッドシートで管理されており、プログラムに落とし込む時はCSV（Comma Separated Values）に変換して使っています。
いままでは、そのCSVに対してローカル環境でコマンドを叩くと自動でAdminTool用のマスタデータのモデルを生成するCLIを用いていました。
ですが、AdminToolを更新する人がローカルで各々手動で更新しないといけなかったためデータの不整合が起こったり、最新でなかったりと不便がありました。
やったこと
マスタデータから直接AdminTool用のマスタデータモデルを生成するCLIを作成し、それをJenkinsパイプラインで実行するようにし、さらに、Jenkinsビルドを毎日自動で行うように変更しました。
CLIはPython、Jenkinsパイプラインはgroovy、その他TypeScriptなどを使用しました。
結果
AdminToolのマスタモデルを手動で追加する必要がなくなり、よりAdminToolまわりのCI (Continuous Integration) が機能するようになりました！
2.DynamoDBの負荷を自動で調整する仕組み
ふたつめは、DynamoDBの負荷容量（以下、CU: Capacity Unit）を過不足無いように自動調整してくれる仕組みを作成しました。
背景・前提
このタスクをやろうと思ったのは、上長が現在あるプロダクトの改善点を上げてくださり、そのなかで一番面白そうだと感じたからです。
低いCUを設定していると、アクセスが急増した時にスロットリング（受信拒否してエラーを返す）が発生します。
高いCUを設定していると安全ですが、その分料金がかかります。
ですので、ユーザーの利用状況に合わせてCUを調整するのがベストといえます。
もともと自動調整のツールがあったのですが、ピークの後にすぐにCUが下がらなかったり、DynamoDBの前までの仕組みで１日最大９回までしかCUを下げられないという制約が緩和された（９回→２７回になった）ということもあり、既存のツールから乗り換えることが検討されました。
やったこと
今回僕が作ったツールは、定期的にDynamoDBの使用CU量をSARIMAXモデルで学習し、将来の使用量を予測し、AWS SDKからAPIを叩き使用できる上限のCU量を調整するというものです。
ツール全体はPython、AWS SDK for Python（boto3）、機械学習にはPythonのstatsmodelを用いて開発しました。
結果
学習の結果、このツールによって設定したCUの上限は使用量の100% ~ 130%程度に収まっており、実用に足る可能性が十分にありそうでした。
ただ、残念ながら効果検証や既存のツールとの比較、イベントなどの非日常な部分の考慮まではできていないので、実用するとなると多くの追加検証が必要そうでした。
結構気に入っているので、また時間があればやりたいなと思うタスクの一つです。
3.FCMでのpush通知をスケジューリングするツールの作成
最後は、Firebaseの機能である、FCM（Firebase Cloud Messaging）のAPIを使ってゲームアプリへのpush通知送信を簡単にスケジューリングできる仕組みを作りました。
背景・前提
いままではゲームアプリが入ったスマホに送るpush通知は、Web上のFCMコンソールから一つずつ手作業で送信していました。さらに、送信したい言語が複数ある（日本語、英語、韓国語、中国語など）と、言語ごとに作成しなければならないなど、運用コストが高い仕組みになっていました。
やったこと
FCM APIをGAS（Google Apps Script）から叩き、スプレッドシート上で管理できるようにしました。さらに、複数言語のpush通知を同時に設定できます。
時刻を設定しておくと、GASのTriggerで時間になったら一斉送信するように実装しました。
結果
今までのタスクと違い、完全に新規のシステムを導入することになったので、社内の各所の方に連絡したり、引き継ぎ資料や説明資料の作成、ミーティングの主催など色々な調整が必要でした。
これまでは実装ばかりしていたのでそこまで仕事上で他業種の方とコミュニケーションを取るといったことはなかったのですが、このタスクを通してエンジニアの方、QAの方、運用の方、マーケの方など色々な方との仕事の進め方が身に付いたなと思っています。
まとめ
僕はこのアルバイト期間を通じて、エンジニアとして技術面だけでない様々なことを学びましたし、色々な方とオンラインでもオフラインでもお話して人間として、社会人として成長できたなと思っています。
このブログを通して少しでもWFSの良いところが伝わればいいなと思っています！
この記事が気に入ったらサポートをしてみませんか？