こんにちはAkatsukiのサーバーエンジニアとして8月24日から9月11日までの3週間参加させていただきました、飯田です。私がこの3週間でどのような事に取り組み、何を学んだのか、振り返りを書く事になりました。
Akatsukiのサーバーエンジニアってどんな事しているのか、またどういう環境なのか興味がある方はぜひ読んでいただけたらと思います。よろしくお願いします。
インターンの参加理由
まずインターン参加の理由から話していきます。
私がアカツキのインターン参加を決めた理由は「実際に業務をやりながら学べる」という事にありました。私は働いている環境を知りたいという思いがあり、 実際に社員のエンジニアの方と業務を通してやりとりできるというのは大変嬉しい事でした。
そしてもう一つ大きな理由としては、「やりたい事に取り組ませてもらえる」という事です。事前に何がやりたいかを何度も聞かれ、自分が関わりたい領域をきちんと話せば、それができるように取り計らってくださいます。面接の時からそんな感じで、ご縁があり参加させていただく事になりました。
ちなみに私がやりたいことは仕様の検討や設計をゼロから考えること、AWSに関するタスクでした。普段から開発する中で、自分の中に課題としてあったので取り組めたら良いなと思っていました。
インターンで取り組んだ事
私は「八月のシンデレラナイン」というゲームタイトルのサーバーエンジニアチームに配属され業務を行うことになりました。インターンでは合計５つのタスクに取り組みました。そのうち特に沢山学びがあった３つを紹介したいと思います。
その三つとは
・チーム評価ログを取りやすくする実装
・ECSデプロイ完了時に通知を送る仕組み
・デレストキャンペーン時のプランナー作業自動化の実装
です。
チームスキル評価込みのチーム評価を容易に取れるログの実装
最初にチーム評価に関して簡単に説明しますと、ハチナイにはチームを組んだときに４つの評価値をもとに総合値であるチーム評価というのを計算します。（画面下部）
ハチナイの分析チームはユーザーのチーム評価の値を分析に利用しているそうなのですが、チーム評価を取得するには、クライアント側との連携が必要になり、チームスキル評価の部分のみ独立して取得するというやや複雑なロジックが必要になっていました。そこでこのチーム評価のログデータを簡単に取れると、よりログの分析が簡単でやりやすくなるというのがチームからの要望でした。
クライアント側との連携があることから、クライアントエンジニアの方と相談し、容易に取れるような方法を新たに考え、より簡単に一括でチーム評価ログを取れるように実装してレビューしていただいた段階で沢山の質問が飛んできました。
・既存の実装にはログはログデータとして送信しているので、ログ専用のデータベースのカラムはない。その辺りはどう考えてますか？
・なぜその実装が良いと判断したのですか？
・他の実装案はどうだったのですか？
最初少し驚きました笑
確かに実装方法はいろいろありますがどうしてそれに決めたのか、何を判断根拠にしたのかなどをしっかりと考え抜いて言語化出来るかを見ているようでした。言語化を大切にされている文化なのだと感じました。考えていたこと・自分の中に持った明確な判断基準をきっちりと説明して、納得してもらえるようにして初めてOKをもらえることになります。
普段個人開発をしている人は何となくこっちの方が良いよね、みたいな感じで実装することもありがちだと思うんですが、実装方針に関してきちんと言語化することは非常に大事なことだなと気づきました。レビューする人や他の人が見ても、別の実装方法とのメリットデメリットの比較やなぜそういう実装に至ったのかを理解できますし、曖昧な部分をなくすことで考慮漏れも起こりにくくなります。きちんと説明できることは学びにもなりますし良いことしかありません。もちろん時間がかかるので、常にこういうことをしているわけではないそうですが、いつ聞かれても答えられるようにしっかり考えて自分の判断基準を持っておくというのは非常に大切な事だと思います。
質問は沢山飛んできますが、非常に優しい感じで、「良いとか悪いとかではなくなぜそうしたのか」という事をわざわざ強調して聞いてきてくださるぐらいなので圧迫感とかは皆無で非常にやりやすかったのも良かったです。
ECSデプロイ完了時に通知を送る仕組み
次に紹介する取り組んだタスクは、「ECSデプロイ完了時に通知を送る仕組み」です。ハチナイの開発にはAWSのECSが利用されています。現状は、機能を開発してデプロイを行ってから完了したかどうかをいつもAWSコンソールを見に行って確認して、正常に動いている事を確認してから検証をしているという状況になっていました。ECSのデプロイは、行ってから完了するまでの時間が起動しているインスタンスの数によって変わり、環境によって時間がかかる事もよくあり、いつ終わったかを確認するのは手間になります。これを普段チームでやりとりしているSlackでわかるようにしたい、という要望がありました。
実装に関する内容としては、AWS SDKというAWSから用意されているプログラムからAWSを操作できるライブラリを利用してECSのクラスターの状態を確認することができるので、それでデプロイが行われたらリビジョン番号が変わる事を利用してSlackに通知を送るという仕組み作りです。これ関しては良い感じのライブラリがあったのでそれを改良する事で対応をしました。
実装ベースの話まで落とすと、一定周期でAWSのAPIを叩いてECSクラスターの状態を取得し、リビジョン番号に新しい番号が出来て、一定時間内に現在のリビジョン番号が新しいリビジョン番号に遷移していればデプロイ成功の通知を、新しいリビジョン番号ができても一定時間内に遷移できていないならデプロイ失敗の通知を送るという感じです。
一定周期でAPIを叩くというように、常に起動させておく必要があるので、ハチナイで使われているEC2のサーバーの中にデーモンのプロセスとして登録し、インスタンスを立ち上げたときに自動で実行されるようにする事で、人手を一切介さないで良いようにしました。
ずっと正常に動いてくれていて良い感じです。好きなSlackの絵文字を設定して良いとのことだったのでこんな風になりましたが、もうちょっと普通のにしたら良かったなと後で思いました（反省）
AWSのIAMの権限に関することや、クラスター周りのことを調べる良い機会となり、結構詳しくなれたように思います。
デレストキャンペーン時のプランナー作業自動化の実装
最後に紹介するのは、「デレストキャンペーン時のプランナー作業自動化の実装」です。ハチナイのデレストには、定期的にキャンペーンがあり、キャンペーンによって主に次の3つ内容が変化します。
・消費元気が1/2になり、紹介文にキャンペーン中の文言が追加される
・ソウルストーンのドロップ量が増える
・秘奥義が取得できるようになる
現状これらの対応を行うために、プランナー陣の工数が大きくかかっているという事でした。どうやら作業手順が煩雑で、特定のプランナーに作業が属人化してしまっているということにもなっているようで、これらのキャンペーンによる変更をサーバー側のロジックで自動化しようということになりました。
これに関しては仕様もなにもなく要望でしかなかったので、まずはヒアリングを徹底的に行いました。プランナーの方が実際にどういう形で実現できると嬉しいのか、というところをもとに社内で使われている企画などを書くページに仕様書/設計書を作り、それをもとにプランナーの方と検証チームの方にも確認していただき、「要望通りの実現ができる仕様となっているか」「検証する際の問題はないか」というところを見ていただきました。
しかしここで問題が発生しました。確認が取れて仕様が決定した段階で、このキャンペーンによる表示の変更はサーバー側で全部生成しているわけではなく、一部クライアント側で保持して出しているということが判明しました。(自分の確認漏れです)
これによってクライアントエンジニアの方にも協力をお願いすることになります。と言っても仕様は自分が考えているので、クライアント側でどういう事をすれば実現できるかをちゃんと調べて設計して提案する形で相談をしていただきました。しかしその確認の途中、さらに問題が発生しました...(問題起こりすぎ)
秘奥義の表示部分が他のゲーム画面にも跨っており、影響範囲の見積もりが完全に誤っていたことが発覚。さらにこれによって他の問題も見つかることになります。
「このままでは実装に進めない」という状況になり、色々打開策を考えるも出てこず、他のエンジニアやプランナーの方に向けてヘルプを頼むことにし、皆さんの協力のおかげでなんとかインターン期間内での実現が可能そうな落とし所が見つかりました。
実装方針の修正ができたので、仕様書を再度作り直して、今度はプランナー・検証チーム・クライアントエンジニアの方々に見ていただきました。（10人近く見て頂いて確認を取るので、結構頑張りました。ページの枚数も凄いことに。）
各チームの方が見るに当たって、何が分かれば良いのか、どこを見たらすぐわかるのかなどをしっかりと考慮して作ったおかげあってか、一発でOKが出て分からないと突っ込まれる事も特になく、ようやく実装に着手できるようになり、この時点でインターンの終わりが目前に迫っていて大分焦って実装に取り組んでいました。なんとかテストまで書き終えてPRを出してレビューをもらうところまではできたのですが、時間が足りず完遂することまではできなかったので引き継ぎをお願いすることに...（悔しい）
途中で問題が起こったり、関わる人が沢山いて考慮すべきことが沢山あってひたすら考え続けていたという感じで、非常に多くの学びがありました。これはやはり業務をしているからこそならでは、というところもあると思うので、実装を完璧に仕上げることまではかないませんでしたが、自分で一からヒアリングして仕様を作って設計してというところを色んなチームが関わる中で、しっかりと考えて取り組めたのは凄く良い経験をさせてもらえたとなと思います。
このタスクでは沢山の学びを得られました。最初のタスクであったような言語化が必要なことはもちろん、仕様の検討に関して、「要求された方針だけで考えるのは”検討”とは言わない、全ての可能性を考えて最適なのを探すのが検討」という指摘があったことは深く印象に残っています。
インターンを終えて
まずは、3週間本当にお世話になりました！毎日が本当に学びの連続で、技術に関することだけでなく、エンジニアの姿勢というところまで沢山勉強させていただきました。上の話の中では出てこなかったですが、メンターについて下さった方が、私が困ったときに的確なヒントをくださり、教えてもらうのではなく、基本的に自分で考えて動き続けることができて本当に楽しく取り組み続けることができました。本当メンターの方の推察力と言語化力が凄すぎました。（どうしたらそんなに風になれるんだろう）
また、最初はヒアリングをあまり上手くできておらず、自己判断が多いところもありましたが、指摘をいただいて自覚でき、途中から直して取り組むことができました。インターン中での成長がはっきりと目に見えてわかるのが凄かったという風に仰っていただけたのも嬉しかったです。
本当に手取り足取り教えるのとは対極で、自分で考えて出したアウトプットに対するサポートという感じで接して下さって、自分には凄くあっていてよかったです。皆さんもとても優しくて、心理的なハードルを一切感じる事もなく気軽にきける環境で、リモートというのが全く気にならないぐらいでした。働いていて凄く楽しかったです。本当に素晴らしい環境で学べたことを嬉しく思います。アカツキの良さを沢山知ることができました。
最後になりますが、本当に3週間という長い間お世話になりました。ありがとうございました！
