『モンスターストライク』（以下、モンスト）運営において縁の下の力持ち的存在であるサーバチーム。今回は、先輩後輩対談のシリーズとして、新卒で配属されて2年目を迎えたサーバサイドエンジニアの岡住（写真左）と、上長でマネージャーの原田（写真右*）にインタビューしました。アグレッシブな性格を高く評価されている岡住は、どのような挑戦をしてきたのか聞きました。

*ご本人の意向により、顔の一部をお名前にちなんだスタンプで隠しています

趣味で始めたプログラミングが仕事になるまで

────まずは、お互いの第一印象を教えてください、

原田　初めて会ったのは、配属面談のときでした。第一印象は、穏やかそうな人（笑）。大人しいというか穏やかそうな人だな、と思いましたね。

岡住　私は、原田さんの人柄や印象よりも、話の内容の方が記憶に残っています…。いろんなことを深くまでズバズバと聞かれて、自分の弱い部分を再確認できる面談でした。

────どのような話をされたのでしょうか？

原田　入社前からすでに、アルバイトでプログラミングの経験があったそうなので、その仕事内容を聞きました。フロントだけなのか、裏側まで触ったことがあるのかなど、中途面接のような質問をした覚えがあります（笑）。

岡住　結構細かな技術の話をしてましたよね。学生時代はよくハッカソンに参加していて、エンジニアの方々と交流するうちに声をかけてもらい、サーバサイドエンジニアとして働く機会をいただきました。

────なるほど。プログラミングはどのような経緯で始められたのでしょうか？

岡住　小学生の頃にCGIゲームが流行ったのをきっかけにプログラミングに興味を持ちました。まともにプログラミングに触れたのは中学生の頃で、VBAを書いてみたりしていましたね。エンジニアになるのもいいな、と漠然と思っていたので、「得意かどうかはまだわからないけどやってみよう！」と、大学では情報工学科に進みました。

────小さい頃から好奇心旺盛だったんですね。大学ではどのような活動をされていましたか？

岡住　大学3年生のときに、研究室経由でアルバイトをさせていただいたのが、お金をもらってプログラミングをする初めての経験となりました。仕事としてプログラミングをするなら、ちゃんとやらないといけないと思ったのですが、スキルの習得は手探り。日々の積み重ねが自信につながったのだと思います。

転機となったのは、大学院の研究室で携わった観光アプリの開発。どうすればチームでの開発が上手く回って、良いプロダクトが作れるのだろうかと思い、UXを勉強してデザインをしたり、ユーザーテストをしてみたりと、一通りの工程を体験してみました。どの工程も面白かったのですが、やはり一番はプログラムを書くこと。それで、エンジニアになろうと決断しました！

手を挙げやすい雰囲気が成長の後押しに

────岡住さんの話を聞いて、サーバーチームとのマッチ具合はどのように感じられましたか？

原田　いろいろなものに触れてみたいと話していたことは、よく覚えています。サーバチームにとって、能動的な人は大歓迎なんです。というのも、モンストは、常に課題が湧いてくるような現場。ミドルウェアのバージョンアップから、リリースの際に発生した不具合の解消、企画やQAが使っているシステムツールの改修まで、日々多くの課題が出てきます。課題に取り組むのはスキルを身につけるのはもちろん、社内のメンバーと信頼関係を構築する良い機会でもあるので、サーバチームでは基本的にタスクのアサインは指名するのではなく、やりたい人を募ります。自分から進んで手を挙げられる人だと思ったので、活躍してくれるかもと思いました。

────岡住さんは、配属が決まった時はどのように思われましたか？

岡住　正直な話、ミクシィを志望したときは、まさかゲームに携わることになるとは思っていなくて（笑）。もともとゲームをプレイするのは好きでしたが、開発に携わったのは内定者アルバイトで新規ゲームに配属されたのが初めてでした。一般的なWebサービスとモバイルゲームはインフラ構成にはあまり違いはありませんが、ゲームはメンテナンスを入れる時にユーザーの動きを特に気にかける必要がありますし、ユーザーIDを生成するロジックも独特だったりすることも。自分が今まで触れてきた環境と大きく違っていて、知らないことに触れられるのが面白かったですね！　サーバチームに配属されたときも、不安よりもワクワクする気持ちの方が強くありました。

────前提がひっくり返されるようなことすらも、楽しめるのですね！　配属されて最初に担当されたタスクはどのようなものでしたか？

岡住　最初は、ゲーム内の簡単なエラーの修正や社内の管理ツールの改修など、初歩的な作業でした。

原田　最初にお願いしたタスクは、言ってしまえば簡単な作業なのですが、本番環境に反映されるまでの開発フローを知ってもらうため、まずは初歩的なところをきちんと覚えてほしかったんです。フローに慣れるまでは、コードを書くことより周りとの関係を築いたり、システムの構成を把握したりコミュニケーションの取り方を学んだりしてもらうことの方が重要。スキル的には充分でも、初めから大きな仕事を任せると、関わるメンバーも増えるのでコードレビューの返しが多くなってしまうこともありますし…

岡住　確かに入社したてにコードレビューでたくさんコメントがつくと、精神的にも消耗してしまうかもしれませんね（苦笑）

原田　コメントの仕方は優しくても、ちょっとギョッとしちゃうよね。それに、開発フローに慣れていないがためにミスを犯してしまうと「○○さんに依頼するのは心配」というイメージを引きずってしまいかねません。なので、初めの1〜2カ月はスキルを深めるよりも先に周りの人…エンジニアはもちろん、企画やデザイナーなど他部署の方々を巻き込む仕事へと徐々に広げるなかで「○○さんが担当されるなら安心」という信頼関係を着実に築いていくことが重要です。時間と労力がかかりますが、信頼を得ることが出来れば、本番環境にもアクセス可能になります。

岡住　なんとなく感じてはいましたが、そういう意図だったんですね（笑）。

原田　そうなんです。逆に、信頼さえ勝ち取ってしまえば、何でも挑戦できる環境でもあると言えるので、まずは土台をしっかり作ることに専念してもらいました。

────岡住さんからすると、内心は「もっと早く難易度が高い仕事をしたいのに…」というよなフラストレーションはありませんでしたか？

岡住　作業の合間に、Wikiやモンストのインフラ構成を読み込めたので、丁寧にインプットできたと思っています。データセンターの見学にも行きました！

────若手でも挑戦できるよう、その土台作りの時間もしっかりと用意されているのですね。岡住さんは、この一年間意識していたことや目標はありましたか？

岡住　一つ目は、原田さんもおっしゃっている通り、信頼関係を構築すること。二つ目は、積極的に挑戦してみることです。例えば、5月に実施された台湾版モンストのデータベースの入れ替え作業には、自分から手を挙げて担当させてもらいました。データベースの入れ替え作業は初めてでしたが、チームメンバーが一緒に手順を確認してくれるなどサポートを受けながら取り組みました。そうすると、6月には中国版モンストのショートメンテナンスも担当させてもらえることに。さらに、9月には日本版の本番環境に入れる権限もいただいて…と、一つのチャレンジから担当できる仕事の幅が広がったような感覚がありましたね。

原田　実績を重ねていくと、業務の幅が広がっていくシステムです（笑）。入社後半年で本番環境にアクセスできる権限を付与できるように、経験を積み、スキルを証明できるロードマップを敷くのですが、岡住さんは速いスピードでこなしてくれた印象ですね。難易度が高い作業にもギブアップすることなく、やり遂げたくれたことにも感心しています。

────新しいことに積極的に挑戦していく中でぶつかった壁や失敗談はありますか？

岡住　人気作品とのコラボの際に不具合を発生させてしまい、カスタマーサポートに報告が入ることがありました。実際に影響があったユーザーは数十人で、大規模な損害には至りませんでしたが、モンストはアクセス数やユーザー数が大きいので容易にトラブルを起こし得ることがわかりました。身が引き締まる一件で、今でも印象に残っています。

────モンストほど大きなサービスであれば、プレッシャーも大きいのではないかと思います。トラブルに対応する際は、焦りませんでしたか？

岡住 サーバーチームは、焦ることでパフォーマンスが下がってしまうことを認識しているので、こうしたトラブルの際も落ち着いている人が多いです。焦りは雰囲気として伝わって、不要な焦りを生んで更にミスを生み出しかねないので…。だからこそ、自分も安心して作業を進められましたね。

原田　企画のメンバーたちも私たちのことを信頼してくださっているので、例えば緊急メンテナンスを入れなければならないときも「サーバチームが言うなら本当にメンテナンスが必要なのだろう」と判断を任せてもらえます。これまで作り上げてきた信頼関係と実績の賜物です。

岡住　不具合を発生させてしまった場合には、企画メンバーなどチームメンバー以外にも共有しなければならないのですが、やはり自分からは連絡しづらくて…。そんなときは原田さんたちが矢面に立って共有してくださるので、続報は自分から出しやすくなります。モンストには多くの人が携わっていますが、実はサーバーチームは10人程度しかいないので、リソースの割り振りや他部署との調整にも苦労しないように動いてくれています。マネージャーやチームリーダーの皆さんは、チームを仕切るというよりも周りのエンジニアがパフォーマンスを発揮できるように手を差し伸べてくれているのだと実感しました。

・・・続きはこちら