はじめまして、21卒サーバーサイドエンジニアのS.Aです。
コロプラのサーバーサイドエンジニアにはインフラや社内ツールの開発などいくつか役割がありますが、私はサーバーサイドエンジニアの中でもアプリケーションの開発を担当しており、現在は新作ゲームの開発を行っています。
この記事では新卒の私が約1年働いて体感した
- コロプラの特徴
- サーバーサイドエンジニアの日常
- 働く環境
の3点について紹介していきたいと思います。
コロプラの特徴
私がコロプラの1番の特徴だと感じる部分はズバリ「職種に関係なく意見し合う文化」です。ゲーム作りに欠かせない各分野のプロフェッショナルたちが、職種に関わらず気になった点を徹底的に議論し、より良い作品を作り上げていきます。コロプラにはさまざまな職種のプロフェッショナルたちが関わっていて、さまざまなメンバーがそれぞれのこだわりを持って日々ゲーム作りに取り組んでいます。以下はコロプラで働くゲーム作りに関わる職種を大きく分けた分類です。
etc.
この「職種に関係なく意見し合う文化」を象徴する場面が企画のキックオフミーティングです。キックオフミーティングでは先ほど挙げた多種多様なメンバーが企画に対してガンガン意見を言い合います。さまざまな役割をもつメンバーが専門領域から見た企画の実現可能性や実現不可能な場合の代替案を提案します。それだけではなく、職種に関わらず、企画自体の意図について質問したり、ユーザー目線からみた企画内容の楽しさについて意見を交わしながら気になる部分を全て洗い出します。こうして議論を重ねていくことでユーザーにとって新しく楽しい体験を提供することができます。
この文化はプロジェクトの質だけではなく、私個人にもプラスに作用していると感じています。なぜなら、良いものを作り上げたいという気持ちに溢れている人たちに揉まれることで、業務へのモチベーションを高い状態で保つことができるからです。また、多種多様な背景を持ったメンバーとの刺激的なコミュニケーションは、自分の視野を広げてくれて、人としての成長を促してくれる点もプラスに作用していると感じる一つの理由です。
ここまで書いてきたように、コロプラにはユーザーに新しい体験を提供するチームのクリエイターとして、それを実現するゲームクリエイター/エンジニアとして挑戦できる環境があると私は感じています。
サーバーサイドエンジニアの日常
1日のスケジュール
下の表は私のとある1日のタイムスケジュールです。基本的には自分の担当している機能の実装に時間を費やすことができてますが、間にいくつか予定が入っています。自分の担当業務については働く環境のパートで、他の予定については社内の情報を織り交ぜつつ引き続きこの章で解説していきたいと思います。
| 9:30-11:30 | 連絡確認 & コードレビューなど |
| 11:30-12:00 | 全体朝会 & エンジニア朝会 |
| 12:00-13:00 | 担当業務 |
| 13:00-14:00 | ランチタイム |
| 14:00-16:00 | 担当業務 |
| 16:00-17:00 | プレイ会 |
| 17:00-17:30 | サーバー夕会 |
| 17:30-18:30 | 担当業務 |
連絡確認
社内のチャットツールはSlackが使われていますので、業務のやり取りや事務的な連絡はSlackで確認できます。また社内向けに動画共有ツールがあり、全社的なメッセージや重要な連絡などは動画を用いて情報を共有しています。
朝会 / 夕会
朝会と夕会は基本的に毎日あります。これらのMTGはプロジェクトメンバーや自分のタスク共有の場となっていて、メンバー同士で持っている情報を同期する機会となっています。私のスケジュールにある「全体朝会」「エンジニア朝会」「サーバー夕会」はMTGごとに集まるメンバーが異なり、共有する内容も少し変わるため違った名前がついています。
全体朝会はプロジェクト全体で必要な情報をプロジェクトマネージャーから共有してもらいます。私の所属するプロジェクトでは在宅・出社含めて50人程度が集まります。共有内容はその時々でさまざまですが、マイルストーンまでの各タスクの進捗状況や新たなメンバーの紹介や、時には長期開発においてモチベーションを維持するためのコツなどさまざまな話が共有されます。
エンジニア朝会は各々のその日のタスクを共有する場です。私の今いるプロジェクトではクライアントエンジニアとサーバーエンジニアが集まって行っています。クライアントとサーバーは業務がかなり密接しているので、ここで誰がどのタスクを担当しているのか、自分の作業している対応がいつまでに必要なのかなどを確認しておきます。
サーバー夕会はサーバーエンジニアが集まってその日に行った作業を共有したり、翌日の業務連絡を行ったりします。このMTGには同じ職種のメンバーしかいないので、自分がその日の作業で詰まった部分などがあれば共有したり教えてもらったりすることもあります。
ランチ
コロナ以前にはプロジェクトチームでランチに出かけることがよくあったそうですが、ご時世的にもかなわないため、従業員の福利厚生として導入した「オンラインランチ会サポート」という制度を利用することができます。
出社・在宅問わずチームメンバーとのコミュニケーション機会の創出を目的とした制度で、申請をすればオンラインランチの代金を補助してもらえます。
プレイ会
プレイ会はゲームの中身も挙動もどちらも確認する機会となっています。プロジェクトメンバーが集まって開発中のゲームや機能を実際にプレイして、プレイした感触をプロジェクト内で共有したり、挙動がおかしいところはエンジニアに伝えたりします。このプレイ会でも職種関係なく意見を言い合う文化がきっちり機能しているように感じます。
1 on 1
これは先ほどのスケジュールには書かれていませんが、定期的に行っているのでここで紹介したいと思います。1 on 1は上長と定期的に対話し、現在の状況や課題、目標などについてざっくばらんに共有する時間となっています。上長によって異なるかもしれませんが、私は隔週に1回で30分ほど上長と話しています。1 on 1では話す内容は部下が決めることになっているので、自分の話したいことを好きなようにカスタマイズできます。私は自分の現状を把握してもらいながら、目標に向けてのアドバイスなどを得る機会として使っています。
働く環境
新卒のサポート
ここではプロジェクト配属後の新卒サポートについて書いていきます。実際にはサーバーサイドエンジニアは4月に入社してから約2ヶ月半は研修があり、最初から多くのサポートを受けているのですが、その模様については既に別記事が公開されているのでそちらをご参照ください。
colopl.co.jp
ブラシス制度
新卒のサポートとして一番大きな存在になるのはブラザー/シスターと呼ばれる存在です。職種に関わらず新卒は必ず1人ブラザーもしくはシスターと呼ばれるメンターについてもらってメンタル面やテクニカルな面など多くのことをサポートしてもらいます。特に私は細かいことで思い悩んでしまうことが多いので、その都度話を聞いてもらいスッキリすることで、より一層仕事に励むことができています。
また、ブラザー/シスターだけではなく同じプロジェクトのチームメンバーである先輩方はとても優しくて、忙しい合間を縫って私の質問に嫌な顔1つせず、私が納得するまで答えてくれます。私は昨年10月頃にプロジェクトを異動したので現在2つ目のプロジェクトに所属しているのですが、どのプロジェクトでもチーム全体として新卒を育てようという雰囲気を感じています。
人事の方のサポート
新卒担当の人事の方々には配属後も良い距離感でサポートをしてもらっています。月1の面談や半年に1回の成果発表会で困ったことや行き詰まっていることがないか見守ってもらっています。
個人的には月1の面談をかなり有意義に感じています。月1の人事面談では、自分の担当の人事の方と仕事の進捗具合や体調などについて話します。その方には社会人の先輩として、自分の現状がどう見えているのかを定期的に教えてもらっています。自分の所属しているプロジェクト外の人に対して、自分の忖度なしの現状を話すことで頭の中も整理され、やるべきことをしっかりと見据えることができます。さらにフィードバックを受けることで次の目標や方向性を見出すこともできます。
やってきた仕事
ここからは私がこの一年で携わらせてもらった業務について話していきます。任せてもらえるタスクはプロジェクトの段階やその人の技量によるところが大きいので、私の業務内容がまるっきり全て新卒1年目のタスクに当てはまるわけではありませんが、おおよそ業務内容を掴めるのではと思います。
管理ツールの開発
新卒かどうかに関わらず、プロジェクトに配属されてまず一発目のタスクは大体管理ツールの開発になります。管理ツールというのはゲームの運営に必要な機能が揃ったWebページで、ゲーム内のデータの閲覧やお知らせの更新など様々な機能が実現されています。
管理ツールの開発は、一般のゲームユーザーからアクセスはないものの、実際のゲーム運営におけるサーバーサイド開発の要素が一通り揃っているため、プロジェクト開発を把握していく過程でぴったりのタスクです。このタスクをいくつかこなしていくことで、データベースのテーブルの扱い方、プロジェクト内のコードの書き方、社内ライブラリの使い方などについて理解を深めていきます。
この段階での個人的な学びは「サービスの利用者について考える」ことがとても重要だという事でした。実はサーバーサイドエンジニアがUIまで作る唯一のタスクが管理ツールの開発です。管理ツールの利用者にはエンジニア以外の職種も含まれるので、エンジニアの通念ではなく一般的な利用者がこのページをどう利用するのかをより具体的に考える必要があります。
管理ツールの開発タスクを通して、良いサービスを提供するにはどんな小さなサービスでも個人の常識に囚われず、より具体的に利用場面や利用方法について考えることが重要だということを学びました。
既存機能の改修
既存機能の改修では実際にゲームユーザーに影響を与えるような変更を行います。ここからは管理ツールよりも厳密にデータを扱う必要があり、DBの負荷、トランザクションの挙動、 キャッシュ周りの実装、ユーザーデータの取り扱いなど気にしなければならないことが山ほどあります。PJ新規参入者ではわからないこともあるので、一人では考慮しきれない部分はチームメンバーにレビューしてもらったり、一緒に設計方針を考えてもらったりして最善を尽くして実装していきます。
本番へのデプロイの不安や緊張感を感じた後、自分の実装したものが世に出る達成感やユーザーの反応が返ってくる満足感が得られます。管理ツールの開発ももちろん重要な仕事の１つですが、このヒリヒリ感と充実感こそがゲーム開発の醍醐味ではないでしょうか。
イベント担当
管理ツールの開発や既存機能の改修を行って数ヶ月経過したあたりで、ゲームイベントの担当をさせてもらえる機会を頂きました。イベントは大体月2回程度で行われ、季節に合わせた期間限定アイテムの追加や重要アイテムの入手率UP、期間限定ログインボーナスなど様々な内容のものがあります。
イベント担当はその名の通り数ヶ月後にイベントが開催できるように必要な実装を行います。もちろんイベントの内容によっては実装が難しいものがあったりもしますが、それ以上に私が難しさを感じたのはイベントの内容をすり合わせて実装することやその期限を取り決めることでした。
イベント担当はイベント開始の数ヶ月前にキックオフミーティングに参加してゲームプランナーが持ってきた施策案のすり合わせを行います。その施策の内容に関して、「そもそもユーザーは満足するのか？」「実装なしで既存の機能で済むのか？」「サーバーの対応だけで済むのか？」「クライアントの対応も必要なのか？」「技術的にもしくは工数的に不可能な場合に代替案をどうするのか？」など多角的に話し合って、誰が何をいつまでにする必要があるのかなどを決めていきます。
私が難しさを感じたのは実装の工数の見積もりと実現可能性が低い場合の代替案の提案です。特に難しさを感じるのは代替案の提案です。これをするには企画の内容から企画の真の目的を抽出する能力に加え、プロジェクトの設計を把握して実装可能な提案を考える必要があるのでかなり難易度が高いと感じました。
私は配属されたプロジェクトや状況にも恵まれてイベント担当を任せて頂きました。新卒の私にはかなり骨が折れる業務でしたが、イベントが作りあげられていく様子を丸々経験することができゲーム運用の最前線を知るとても貴重で有意義な経験となりました。
新作タイトルでの開発
私は「管理ツールの実装」「既存機能の改修」「イベント担当」などを運用タイトルで行った後、新作タイトルに異動となり、現在はそこでメインとなる機能の実装を担当しています。
新作タイトルでは、ゲームの根幹となる機能の開発に携わることができるので「ゲームを作っている感覚」を非常に強く感じます。ですがその反面、ユーザーからの反応が得られないもどかしさを感じることが多いという難点もあります。また、「新しい体験を提供するための新たな機能を作ったぞ！」と喜んでいたとしても、ユーザーに遊んでもらえるのはまだ先なので歯がゆい気持ちになりますし、仕様変更などで開発した機能が削除される可能性もあるので、タフなメンタルが必要になる場面もあります。
また、自分の所属しているタイトルのプロダクトマネージャーは「ゲーム開発はマラソンです」とおっしゃっていて、新作タイトルの開発はその先の運用期間も含めるとかなり長丁場になるので、長期的な視点を持った開発が必要になります。長期的な開発は楽しい期間も苦しい期間もありますが、チームで協力し合いその波を乗り切るという熱い経験ができることも、新作タイトル開発の特徴の1つではないでしょうか。
個人的には業務で意識しなければならない部分が運用タイトルと少し異なっていると感じています。それは運用タイトルよりも新作タイトルの方が「変更しやすいコードを書く」ことをより強く意識する必要があるということです。新作タイトルの開発では大枠は決まっているが詳細部分までは決まりきっていない機能を実装することが多いので、抽象的に書ける部分は抽象的に書き、責務はできるだけ分離させて書くことをより強く意識することが必要になります。
運用タイトルでももちろん変更への強さを意識することは重要ですが、ゲームの開発段階の違いで重要視するポイントが異なっていて、運用タイトルではユーザーを飽きさせないために新たな体験を届けるスピードをより重視し、新作タイトルでは運用に入った時に新たな体験を提供しやすいように変更への強さをより重視するような傾向にあると私は感じています。
どちらも経験した上で、新作タイトルでの開発も運用タイトルの開発もコーディングで意識する部分やメンタルの保ち方が少し違う部分がありますが、私にとってはどちらも刺激が多くやりがいのある仕事に溢れていて日々学びの多い現場だと感じています。
