エンジニア組織メンバーに聞く。技術力向上のための取り組み

2017年にリリースした『アナザーエデン 時空を超える猫』(以下、『アナデン』)は国内で1,000万ダウンロードを突破し、2022年リリースのライトフライヤースタジオ × Keyによる『へブンバーンズレッド』(以下、『ヘブバン』)は“100万ダウンロード”を3日間で達成。

このようにライトフライヤースタジオでは、多くの方々に楽しんでいただいているコンテンツをリリースしてきました。

今回は、ライトフライヤースタジオのゲーム制作の裏側で活躍するエンジニア組織にフォーカス。ゲームの面白さやクオリティを技術面で支えるエンジニアが、どのような技術環境でゲームの開発に勤しんでいるのか。Studio本部 Technology Development部の役職者3名に聞いてみました。

紙谷 憲
Studio本部 Technology Development部 部長

2013年に入社。課金・認証基盤の開発・運用に従事し、その後CS・QAなど管理系部門のマネジメントや海外展開の推進を担当。2019年よりライトフライヤースタジオのエンジニアリング部門の責任者を務め、組織マネジメントを幅広く統括。

吉田 貴勝
Studio本部 Technology Development部 シニアマネージャー

2013年に入社し、サーバーエンジニアとしてネイティブゲームの開発・運用に携わる。現在はサーバーエンジニアの総括を担い、予算策定や人員コントロール、サーバーサイドのアーキテクチャの更新・運用などを実施。

西田 綾佑
Studio本部 Technology Development部 リードテクニカルディレクター

2014年の新卒入社。『アナザーエデン 時空を超える猫』など複数タイトル開発にクライアントサイドから携わり、現在はテクニカルディレクションや技術選定の側面から、複数プロジェクトに横断的に参画。カンファレンス登壇も多数。

エンジニアは開発と“技術の蓄積”が使命

── 100名以上のエンジニアが所属するTechnology Development部は、2020年4月にプロダクトごとの組織からセントラル型の組織に移行しました。移行の背景や、実際にどのような体制でプロジェクトに関わっているのかを教えてください。

紙谷 憲(以下、紙谷)『アナデン』リリース前のライトフライヤースタジオではプロダクトごとにメンバーを縦割りで配置して開発を進めていました。しかしながらこの体制だと、プロダクトが成功すれば技術は受け継がれるものの、終了した場合は技術がそこで途絶えてしまう。つまり技術継承がしにくいことに気付いたんです。
そこでエンジニア組織をセントラル型の組織に移行しました。セントラル型になっても、プロダクトごとにエンジニアをアサインする流れは変わりませんが、エンジニア組織のミッションを明確にして「ライトフライヤースタジオのエンジニアはこうあるべきだ」という意識を持ってもらうように、ことあるごとにメッセージを発信し続けました。
「ライトフライヤースタジオにとって最も重要なのはプロダクトの成功です。ただそれだけがエンジニアの仕事ではなく、ライトフライヤースタジオの技術を推進するエンジニアとして、周囲と連携しながら技術資産を組織に積み上げていくこと、それがプロダクト開発と同じくらい重要で、皆さんの評価にも繋がっています。」
つまり、技術資産を蓄積し、エンジニア間で共有するための動機付けがセントラル型組織の大きな目的だったと言えます。

── セントラル型の組織に移行して2年ほど経ちましたが、課題や今後改善したい部分はありますか?

吉田 貴勝(以下、吉田)エンジニア組織横断で共通システムをつくっても、それをそのまま各プロダクトに活かせない、というのが当初の課題でした。共通システムだけでは表現できないコンテンツがあるためプロダクトごとにアレンジを加える必要があるのですが、これがバグの原因になることもあって。

紙谷そうなんですよね。本音を言うと、ゲームごとに最適なシステムを個別でつくる方がベストではあります。ただこれだと、開発・運用コストが増えるので、事業的にもリソース的にも成り立たなくなる。
一方で、アレンジを加えずに全部のシステムを共通化してしまうとゲームの自由度の幅が狭まり、面白みが薄れてしまう。ライトフライヤースタジオは「ゲームのクオリティに妥協しないこと」を世に公言しているので、このバランスの取り方が難しくて、苦労した部分はありました。

西田 綾佑(以下、西田)紙谷さんや吉田さんが話すような問題に気付いて、途中から戦法を変えたんですよね。
運が良いことにライトフライヤースタジオは、3本同時に新規ゲームの開発が進んだタイミングがあったんですよ。そのとき、この課題を改善するために「3プロジェクトを同時期につくるけど、同じものはつくらない」と決めて。

── 「同じものはつくらない」とは具体的にどういうことでしょうか?

西田例えば、プロジェクトAはネットワーク部分、プロジェクトBはネットワーク以外の部分をつくるというように、ほかのプロジェクトでも使える部品を各々がつくるイメージです。コスト面を担保しつつ、技術的資産も溜められるだろうと。
ただ、この資産の共有・使用は強制ではありません。ライトフライヤースタジオのエンジニアは必要な部品を自力でつくれるような能力の高い人が多いので、「良かったら使ってみてよ」という、ゆるい技術連携の温度感をキープしました。だからこそ各プロダクトの開発に制約が出ずに、資産を溜めながら進められたのだと思います。

新しい技術を積極的に採用する

── 『アナデン』で注力した技術、そして、その後の作品『ヘブバン』で重視した技術を教えてください。

西田『アナデン』はいわゆる古き良きJRPGをかなり意識してつくったんですよ。昔ながらのRPGを追体験できるよう、『アナデン』特有のシステムもいくつか用意しました。
例えば、昔ながらに使われているスクリプト言語のLuaによって、プランナーさんが自由に街やミニゲームをつくれるようにしたり、フラグを変えて、キャラクターが1回目と2回目で違うことを話す分岐を容易に設定できたりするシステムですね。
また『アナデン』のゲームエンジンはCocos2d-xでしたが、『ヘブバン』からはUnityに移行し、『アナデン』でつくっていたオートセーブシステムやスクリプトシステムを新しくつくり変えた点も印象深いです。

── スクリプトシステムなどをつくり変えた経緯は何なのでしょうか?

西田『アナデン』のスクリプトシステムも優秀ではあったんですが、スクリプターの練度が必要なところもありまして。『ヘブバン』ではスクリプトを量産するためにチームの人員を増やす必要があったので、より直感的に能力を発揮できるような環境整備に注力しました。

吉田自分は、今西田くんが言っていたことをサーバーサイドで実現できるよう注力しました。
実は『アナデン』って、半年以上前のアプリバージョンでも普通に遊べるんですよ。そんなことができるサーバーアーキテクチャは珍しいと思うんですけど、それを実現するためにスキーマレスなデータベースであるAmazon DynamoDBを採用していたり。
『ヘブバン』はデータベースにGCPのCloud Spannerを新たに採用しています。Cloud Spannerはスキーマ変更の柔軟性が高く、Amazon DynamoDBで実現したスケール性も担保されているのが特徴です。またこれにより、イベントやゲームリリース時の大きな負荷が短期間にかかるタイミングにも耐えうる環境が整いました。
このように、『アナデン』でも『ヘブバン』でもタイトルの特性に合わせてフレキシブルに技術選定をしているから、大規模なトラフィックにも耐えられ、ゲームのパフォーマンスも保てるようになったのだと思います。

紙谷自分がメインで見ている「課金」のところで注力したのは、サブスクリプションへの対応です。
ゲームの課金方法といえば昔は、ゲーム内で有償コインなどを買い、それを消費するかたちが一般的でした。
現在はゲームにおいてもサブスクリプションの適用が一般的になったので、これを活用したマネタイズが可能になりました。そのため我々エンジニアには、OSごとの特性に合わせた基盤周りの開発が求められるのですが、それを『アナデン』で実践できたところは印象的です。

── 『アナデン』の開発で多くの技術が組み込まれたようすが分かりました。では、ライトフライヤースタジオならではの技術力についてはどのように考えていますか?

紙谷ユーザーの行動を分析し、プロダクト計画に反映するためのシステムを活用できているのが、ライトフライヤースタジオらしい技術の一つだと思います。

ライトフライヤースタジオではこれまでグループ共通のデータ基盤を利用していたのですが、サーバー費用や利便性の観点からGCPのBigQueryベースの、新しいデータ基盤を立ち上げました。

それで『ヘブバン』等のサービスリリースとともに運用をはじめ、プレイヤーのゲーム進捗がほぼリアルタイムで見えるようになりました。多くの人がどこで躓いているかが一目でわかるようになったので、ゲームバランスの改善にも寄与しています。

── 数字の分析はどのようにおこなっているのでしょうか?

紙谷Analysisグループのメンバーが主導して分析業務を担当しています。その情報をもとに、例えばユーザーの離脱が多い部分は、プロデューサーやプランナー陣と話し合いながら「この章をクリアできるよう、育成幅を充実させよう」などと議論しているのです。
これらは、データと組織を組み合わせたライトフライヤースタジオならではの技術だと思います。

西田先ほど、組織がセントラル型になりプロダクトを3本同時開発したことを話しましたが、そのおかげでゲーム開発に必要な部品がかなり揃ってきたと感じています。
次のプロダクトをつくる際には、蓄積している技術資産を見返しながら進行できるので、ネットワークやデータ管理など、工数を大幅に割かなくても済むようになりました。
つまり、開発者はゲームの面白さに注力する時間が圧倒的に増えると思います。これが、ライトフライヤースタジオが培った技術力ゆえの強みかなと。

定期的な振り返りが、技術選定の精度アップに貢献

── メンバーの技術力向上に向けて、現在取り組んでいることや、これから実施したいことを教えてください。

吉田もともと講習やイベントの情報をシェアするコミュニケーションは活発なんですよ。例えば、ミドルウェアのバージョンアップひとつにしても、「この変更にどう対応しよう?」という議論をすることもあります。プルリクエストによるコードレビューや議論も積極的ですね。
今後は、社内での大きな勉強会などで技術の共有をより図っていきたいです。

西田現在取り組んでいることとしては、プロダクトをリリースした後のエンジニア同士の振り返りです。
先述の通り、3本同時にプロダクトを開発しリリースしたわけですが、リリース後の落ち着いたタイミングで、開発に関わったエンジニアを全員集めて技術について話し合いました。
3本同時開発で共通部品を揃えたとはいえ、全部が同じ技術選定をしているわけではなく、それぞれにバリエーションを持たせています。ひとつの技術トピックに対して良かった点や悪かった点、苦労した点を振り返り、ドキュメント化しています。
良かったものは次のプロジェクトでも積極的に活かし、悪かったものは減らしていく。この繰り返しにより技術選定の精度も高まってきています。そういう意味でこの振り返りは、エンジニアの技術力向上に寄与していると思います。

変化をおそれない組織へ

── 最後に、ライトフライヤースタジオのエンジニア組織として目指す方向、技術的な展望を教えてください。

紙谷ゲーム業界に所属している人から評価される組織を目指していきたいですね。
エンジニアは業界的に不足していて、ある意味引く手あまたな職種のひとつです。そうした状況下で自分は、「他社でももちろん活躍できるけど、あえてライトフライヤースタジオでゲームを開発したい」とメンバーに思ってもらえるような組織をつくる責任があると思っていて。
2022年4月時点では100名近くのエンジニアが在籍していますが、より多くの人が輝けるよう、常にエンジニアが成長でき、ゲームづくりにコミットできる環境を整備していきたいですね。

吉田サーバーサイドでは、大きなユーザトラフィックやゲーム体験をよりよくするための技術選定は引き続き積極的にチャレンジしていきます。例えば、“メンテナンスを入れずに、どれだけユーザーのニーズを満たせるか”を追求できればと。
既存のシステムについても良い新しい技術に乗り換えることもいとわない。プロダクト・ユーザー・開発者にとって新しい価値や体験を届けられる人、新しいものにもチャレンジできる人が集まった組織を目指していきたいです。

西田振り返ると、『アナデン』ではJRPGのつくり方を学び、『ヘブバン』ではアドベンチャーゲームとRPGの融合にチャレンジし、グラフィックスを強化し、日々ゲームのクオリティを上げながらリリースし続けてきたと思います。
今後目指すべきは、プロダクトを出すたびに表現力を高め、ゲームのクオリティも上げる会社であり続けることだと思います。というより、そうなっていかなければならない。
ライトフライヤースタジオのゲームに対する期待もどんどん高まっているので、次に世に出すゲームはさらにクオリティをあげ、グラフィックスを強化し、プレイヤーの楽しみの幅も広がるものとなるよう技術を磨いているところです。
こういった期待に応えるための技術資産の蓄積をしつつ、楽しんでもらう工夫を惜しまない姿勢に共感できる人を増やしていきたいですね。

ライトフライヤースタジオでは一緒に働く仲間を募集しています

同じカテゴリーの記事