ゲーム開発の現場を組織改善してみた！ 1年間のLeSS導入の記録【CEDEC2021レポート】
2021.09.29
2021年8月24日から開催の日本最大のゲーム開発者向けカンファレンスCEDEC2021にアカツキのエンジニアリングマネージャー石毛 琴恵とフリーランスのスクラムマスター増田 謙太郎が登壇しました。
技術だけではなく、マーケティングやマネジメントまで幅広くゲーム開発にまつわる題材を扱うCEDECで石毛と増田が発表したセッションテーマは「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」。エンジニアではない方にとっては馴染みのない単語ばかりに感じますが、つまり「ゲームを開発する現場の組織改善」のお話です。
多種多様な職能を持った人材が同時に動き続けるゲーム開発の現場では、どのように組織がつくられ、業務を進行させているのか。今回はエンジニアではない方にもゲーム開発の現場進行や手法が分かるよう、登壇内容の一部をVOICE用に編集してレポートしていきます。
【目次】
1.開発手法「スクラム」と「LeSS」とは？
2.LeSS導入前の開発チーム と課題意識
・アカツキのゲーム開発プロジェクトでのチーム編成（LeSS導入前）
・課題意識と改善したいと思ったこと
3.自発的に改善を重ねられるチームになるために
・チームの固定化・PDCAサイクルの導入で学びを蓄積できるように
4.プロジェクトマネージメントの問題を解決するために
・ゲーム開発の問題「遅延」。そもそも計画を立てること自体が難しい
・「近くの的を狙う」「計画ではなく、プロダクトの状況に向き合う」
・開発プロセスの変更
・見積もり方法の変更
・マネジメントコストを下げるために必要なこと
5.ゲームはリリースして初めて、ユーザーに価値提供ができる
石毛 琴恵 Ishige Kotoe株式会社アカツキ エンジニアリングマネージャー
BtoB向けWebサービス開発やフリーランスEMなどの経験を経て、2020年1月にアカツキに入社。入社以来、アジャイルな開発プロセスの推進、組織の課題解決、自己組織化チームの実現をミッションとし、体制やプロセスの改善に着手。 アジャイル開発の経験は4年半ほど、うち3年ほどはスクラムマスターとして関わる。認定スクラムマスター(CSM)。
増田 謙太郎 Masuda KentaroSCRUMMASUDAR
フリーランスのスクラムマスター。お客様によりよいプロダクトを届けるため、アジャイル開発を通して、ものづくりをうまく取り組むという思いで、開発プロセスの改善支援、組織の改善支援、アジャイル開発の研修などを行っている。 認定スクラムマスター(CSM)。スクラム道関西運営メンバー。
1.開発手法「スクラム」と「LeSS」とは？
今回のセッションテーマの要である「スクラム」「LeSS」とは、簡単にいえばゲームなどの成果物を開発するための手法（フレームワーク）のひとつ。 ゲームに限らず、なにか大きなプロジェクトを動かすためにはこういったフレームワークがなにより重要です。セッションの中から詳しい解説を見てみましょう。
増田 スクラムとは3つの作成物、3つのロール、5つのイベントの最低限のルール設定で構成された、世界で最も使われている開発手法だといわれています。まずは、今回のセッションに関わるロールについて説明します。
スクラムにはプロダクトオーナー、スクラムマスター、開発チームと、大きく分けて3つのロールがあります。
クリックで拡大
増田 プロダクトオーナーはプロダクトバックログと呼ばれるプロダクトの機能のリストを管理しており、どういった機能を開発するのか、どういった順番で開発するのかを決定する役割です。
開発チームはプロダクトを開発するために必要なメンバーでエンジニアだけではなく検証など開発に関わるメンバーを指し、1チーム大体7名前後が良いと言われています。
スクラムマスターはスクラムがうまくいくよう支援する役割で、私はこのポジションを担当しています。
先程お伝えしたとおり、スクラムで一般的な開発チーム規模は1チーム3〜9名なのですが、私たちのチームは大所帯です。そのため、大規模スクラムフレームワークを採用する必要があったため、「LeSS」を採用しました。LeSSは全体でひとつのプロダクトバックログ、そして複数の開発チームを特徴としており、スクラムをシンプルに拡張したフレームワークと言われています。
クリックで拡大
2.LeSS導入前の開発チーム と課題意識
石毛 大前提の認識を合わせるために、アカツキのゲームを開発するチームについてお話します。まず、1つのゲームを作っている組織全体が「プロジェクト」と呼称されていて、大きく「新規チーム」「運用チーム」に分かれています。
新規チームはゲーム内の機能開発をするチームで、運用チームはすでにローンチしているゲームのコンテンツ運用、イベントの追加やガチャを更新したりするチームです。このあとのお話で扱うチームは今回LeSSを導入した「新規チーム」です。
石毛 新規チームの中にはディレクター、デザイナー、クライアントエンジニア、サーバーエンジニア、QA（検証）のセクションがあり、セクション別の縦割り組織の体制になっています。エンジニアリングマネージャー、プロジェクトマネージャーは新規チーム専任ではなく、プロジェクト全体を見ており、新規チームとも連携して業務を行うという構成です。
石毛 新規チーム全体の動きはこのようになります。グレーの矢印のように複数のバージョン（プロジェクト型）が並行して稼働しており、ディレクター（赤アイコン）がそれぞれのバージョンで何を、いつリリースするかの責任を持ち、ロードマップの策定や、仕様のレビューなどを行います。また、リリースする各機能の詳細についてもディレクターとデザイナー（黄色アイコン）を中心に決定します。
石毛 エンジニア、QA（緑アイコン）はそれぞれのバージョンのディレクターと連携しつつ、複数のバージョンに対応します。PM（青アイコン）は、プロジェクト進行において問題が起きた時に間に入り、情報を集め、ディレクターに伝えるというハブの役割を担っていました。また、外部チーム（グレーアイコン）とのコミュニケーションハブにもなっています。
石毛 実装、検証の具体的な流れは、図のようになっていました。「エピック」と呼ばれる職能郡別に開発を分けて実装を進めます。FF、CFというチェックポイントを事前に置いておいて、実装と検証が分かれている「ウォーターフォール」の形になっています。
FFは Feature Freezeの略で、「機能改修をこの日までに終わらせる」、CFは Code Freeze の略で、「新規・既存バグを含めた開発の終了と、全体の検証をこの日までに終わらせる」という日付です。
以上が導入前のざっくりとした状態ですが、私が入社した直後に感じたのは「構造が複雑になっているな」と。入社前からスクラムイベントを実施したり、PDCAサイクルを回していると聞いていたのですが、実際にデイリースクラムに出てみると想像していたものとは違い、参加人数が多かったり、複数のデイリースクラムに出る人がいたりと、全体像の把握に時間が掛かる、すごく難しい状況だと感じました。
しかし、一方でチームメンバーの行動を見てみると、すごくいいチームだと思いました。複雑な状態の中でも、リリースのためにそれぞれが自分がすべきことを考えて動いていて、セクショナリズム的な対立がなく、チームを大事にする文化が強かったからです。
大きなチームのなかで既にできあがった流れがあって、それを変えなければならないのはこれまでの私の経験にはなかったことだったため、改善するにあたっての難易度は、高いと思いました。しかし、前述の「チームを大事にする文化が強い」という部分に助けられ、気持ち的なハードルは「きっと大丈夫」と思えるまで下がりました。
課題意識と改善したいと思ったこと
石毛 複雑な構造の中で、メンバーが感じていた課題もありました。以下の2点です。
【自発的な改善を求めたい】
課題解決について、一部のメンバーに頼りがちになってしまったり隔週で振り返りをしてPDCAサイクルを回していたりしたものの、形骸化して機能しなくなってしまったということがあり、より自発的な改善を求めていきたい。
【スケジュール管理が大変だが、遅延する】
マネジメントコストが高くなってしまっていたこととスケジュールの終盤になってから遅延が発覚することが多い、ということがあるため、遅延を素早く検知し、スケジュール管理を楽にしたい。
これらを踏まえて、改善したいと思ったことがこちらです。
3.自発的に改善を重ねられるチームになるために
メンバーがそれぞれ自発的に動き、チームを大事にする文化もあり「良いチーム」と感じられるLeSS導入前の新規チームでしたが、構造の複雑化が進み、可視化された課題もある状況。これを改善しもっと良いチームにするのは一筋縄ではいかないはずですが、ここからは実際に石毛と増田が行ったことを見ていきましょう。
石毛 “自発的な改善ができる”を噛み砕くと「衝突を恐れずメンバーに課題を公開することができ、議論ができ、意思決定ができ、実行できる人やチームになること。」となります。つまり、まずチームの中で議論ができる状態にならなければいけませんが、そのためには、議論よりも低いレベルのコミュニケーション「気軽に話せる、相談ができる」状態を、まず達成する必要があります。実際に議論ができる状態になれるかはメンバー次第ですが、土台作りでサポートすることは可能です。
石毛 議論ができる状態にするために、めざしたのは「心理的安全性」の確保。そして自発的な改善を重ねられるチームになるためにめざしたのが「適切な責任」「チームで学びを積み上げること」です。そのために行ったのが、
・クロスファンクショナルチームの固定化
・PDCAサイクルの導入
です。
チームの固定化・PDCAサイクルの導入で学びを蓄積できるように
石毛 以前はエンジニア、QAは複数のバージョンに流動的にアサインされる状態でしたが、クロスファンクショナルなチームでの固定化を行いました。
石毛 これがどういうことかというと、PO（プロジェクトオーナー）チーム、開発チームABC、と分けた形になります。POチームは、PO、ディレクター、デザイナーで構成、開発チームABCはエンジニア、QA、スクラムマスターで構成しました。各バージョンへの対応は、比重の違いはあれど全てのチームが全てのバージョンに関わるようになっています。
1スプリントは2週間に定められている
石毛 さらに、先程のチームごとにスクラムイベントを実施するようにしました。LeSSの図でいうと、赤枠のチームを編成し、青枠のイベントを実施していく形になります。
クリックで拡大
石毛 チーム固定化・スクラムイベント実施により、「チームで学びを積み上げること」ができるようになりました。以前の流動的なチームではすぐにチームが解散してしまい、学びを根付かせるのが難しかったのですが、今回チームを固定化したことにより、課題が発生するたびにチームに学びを蓄積できるようになりました。
また、コミュニケーションにも大きな変化があり、「心理的安全性」にも影響がありました。具体的にはこのような変化です。
石毛 まずはシンプルな変化で、コミュニケーションの機会が増えたため相談や情報共有が増えました。これにより、検証項目をつくるときにエンジニアも一緒になって考えることができるようになり、検証チームだけだと負荷がかかる改善もエンジニアが一緒に解決できるようになりました。
さらに、もともと一部のエンジニアを中心に行われていたペア・モブでの作業が、チーム全体に広がる動きもありました。ペア・モブでの作業のメリットをメンバーが感じて実践してくれて、その結果タスクを属人化させず、レビュー作業の時間を削減することもできたのは想定外に良いことでした。（スライド2枚目）
4.プロジェクトマネージメントの問題を解決するために
チームの学びやコミュニケーションが大きく変わったことで、「自発的に改善を重ねられるチームになる」という目標に大きく近づいた新規チーム。ここからは「チーム」とはまた異なる視点で、「プロジェクトマネージメントの問題を解決する」ための取り組みを増田が紹介します。
ゲーム開発の問題「遅延」。そもそも計画を立てること自体が難しい
増田 改善したいことのひとつとして挙げている「遅延をへらす＆遅延を早く検知する」。そもそもこの「遅延」とはどういうことかというと、さまざまな要因がありますが「自分たちが立てた計画通りに、プロジェクトが進んでいないこと」です。では、「計画を立てる」ということは果たして簡単なことなのでしょうか？
増田 一般的に、スケジュールはプロジェクトの初期に立てるほど、ズレが大きくなりやすい、そして見積もる人と作る人が違うと計画通りに進められる難易度が上がるとされています。さらに、私たちの関わるモバイルゲーム開発を問題ドメイン分類フレームワークのひとつ「クネビンフレームワーク」に当てはめると、「カオスな領域」に属します。これは
・革新的なことが求められる領域
・正しい答えがわからないため、まず行動してから理解していくしかない
・既存の知識が役に立たないこともある
という領域です。そのため、過去のゲーム開発で得た経験をそのまま活かして新たなプロジェクトの計画を立てるのが難しいのです。
増田 その上、ゲームには作ってみないと分からないことがたくさんあります。綿密な計画を立てても、後から発見することが多く、それを改善していくことがゲーム開発では重要なのです。
このように複雑なゲーム開発においては、さまざまな問題が発生します。プロジェクトマネージメントの改善をする前には、「不思議な現象」としか言いようのないことがよく発生していました。
増田 不思議な現象その1としては、ディレクターが1日単位で管理しているにも関わらず、FFの1週間前にエンジニアから「間に合いません！」と告げられる現象です。
また、早く開発を完了させても、FFまでに時間があるためエンジニアのスケジュールの中盤に手持ち無沙汰になってしまうこともあります。FFのあとにバグチケットが発行されるため、どういう機能を開発していたか思い出す必要があり、大変です。（スライド2）
さらに、以前のバージョンに見つかっている既存のバグの対応がFF〜CFの間に限定されているため、修正の見通しが立ちづらいという問題もありました。FF〜CFの期間は忙しく、新機能のバグ対応が優先されるため、修正バージョンが以降のバージョンに送られ続けてしまうこともあります。
こういう状況のなかで私たちはどのように計画し、仕事を進めていけばよいのでしょうか？
「近くの的を狙う」「計画ではなく、プロダクトの状況に向き合う」
増田 そもそも、ゲームは完成しない限り、リリースすることができません。そのため、私たちは小さくとも“完成した状態”でのリリースをめざしています。
そのために必要なのは、最初に一度計画して終わりにすることではなく、計画をし続けることです。つまり近くの目標を狙い続け、精度の高い計画を繰り返し立て続けることが大事だと思っています。
増田 私たちがこのように計画を立てていくなかで、遅延を減らす、遅延を早く検知するために取り組んだことは「自分たちが最初に立てた計画ではなく、プロダクトの状況と残っている仕事に向き合う」ということです。
増田 具体的には、
・2週間（スプリント）ごとに”動くソフトウェア”で、プロダクトの状況を把握する
→2週間ごとに行うスプリントレビューの度に、機能が追加されたゲームを遊べる状態にして、開発がどこまで進捗しているか把握するということです。スケジュールを見るのではなく、実際にどこまでゲームが動くようになったかを常に把握し続けるようにしています。つまり、「近くの的を狙い続ける」ということですね。
・仕事をチケット化することで、“あと何をすれば完了するのか？”を見える化する
→これまでは新機能をまるごとエピックに依頼していたのですが、分割しチケット化するようにしたことで、残りの作業がわかりやすくなりました。
この2つに取り組みました。これに関連して実施したのは、開発プロセスと計画時の見積もり方の変更です。まずは開発プロセスの変更についてBefore/Afterをお伝えします。
開発プロセスの変更
増田 先ほど石毛さんがお伝えしたように、2020年まではエピックごとに機能を実装し、FFまでに実装を終わらせ、CFまでに単体テスト・総合テストの検証期間を設けていました。先ほどお伝えした「不思議な現象」が起きていたのはこのころです。
増田 2021年からはPBI（プロダクトバックログアイテム）、つまりエピックよりも小さな機能分で実装および単体テストをFFまでに行い、FFからCFまでは各プロダクトバックログアイテムを結合した状態で総合テストを行っています。
増田 この変更によってどう変化があったかというと、まず、大きな粒度のエピックからPBIに開発を分化することで、PBIの見積もり結果を使った「バーンダウンチャート」が使用できるようになりました。
バーンダウンチャートというのは、理想的な進捗だと右肩下がりのチャートになりますが、うまくいってないと下がりません。こうして仕事がどれくらい残っているかを見える化できるようになりました。これにより、FFの1ヶ月前には、どうしてもFFに間に合わせるのが厳しい機能をプロダクトオーナーに知らせることができるようになったのです。
増田 また、単体テストをシフトレフト（品質保証活動の前倒し）、つまりFFの前に持ってくることにより、不具合を早く発見し、早く修正する小さなサイクルを回せるようになりました。これによって、ゲームの品質をFF後の総合テストまでに積み上げることができるようになりました。
さらに、既存のバグの対応をバージョン開発開始時に計画し、計画の精度を上げることができるようになったため、既存バグの修正が以降のバージョンに送られ続けることが以前よりも減っています。
これらの変化によって、以前のプロセスで起きていた「不思議な現象」が起こりづらくなりました。
見積もり方法の変更
増田 続いて、見積もり方法の変更についてもBefore/Afterをお伝えします。
増田 2020年までの見積もり方法では、開発の途中に仕様が変わったり、実装する機能が増えても、最初に立てた「ロードマップ（バージョンにおける全体スケジュール）を作成するための人日見積もり」から納期が変わらないところが問題になっていました。プロジェクトを進めていくには、不安定な状況といえます。
増田 いまでは、見積もりを従来最初に一回だけ行っていた「ロードマップを作成するための人日見積もり」から以上にように3つの見積もりに分類する形に変更しています。
増田 これらの変更によって、事前のスケジュール調整ができるようになりました。相対見積もりの結果がバーンダウンチャートに理解できるようになったことにより、各バージョンのどの機能を優先して開発するかを考慮して進められるようになっています。
マネジメントコストを下げるために必要なこと
増田 続いて、改善したいことのひとつとして挙げている「マネジメントコストを下げる」について。マネジメントコストが高い状況とはどういう状況でしょうか？ 皆さんも経験があると思うのですが、やはり「ちゃぶ台返し」が起きる状況はマネジメントコストが高いですよね。このちゃぶ台返しが起こると大変なタイミングは？ それは開発の最後です。
増田 そこで、私たちは「開発する機能の中で集中するべき優先順位を決める」「変化を受け入れ、コストの低い状態をめざす」ことにしました。特に、“やらないこと”を決めることでプロジェクト終盤に計画がひっくり返りづらくなります。また、マネジメントコストは0になることはないため、プロダクト開発を通して得られた経験を重要視し、それを計画に組み込み続けています。
以上の2点の実践により、プロジェクト終盤で当初のリリース期日から大きく後ろ倒しをする必要がなくなり、マネジメントの負担は軽減しました。
5.ゲームはリリースして初めて、ユーザーに価値提供ができる
ここまで、アカツキの新規チームの改善のために行ったことをまとめてきました。今回のチャレンジを経て、チームの課題や意識は大きく変わったと増田は語ります。
リリースし、遊んでもらうことで初めてユーザーに価値提供ができるゲームの世界。アカツキの開発チームはこれからも「良いものを、みんなで、どんどん届ける」ことをめざしている、との言葉で石毛、増田はセッションを締めくくりました。
現在アカツキでスクラムを行っているのは、今回紹介したプロジェクトのみですが、Regional Scrum Gathering Tokyo（日本最大級のスクラムカンファレンス）への参加やCSM（認定スクラムマスター）資格取得の支援、希望者がスクラムマスターに立候補できる環境など、ほかのプロジェクトでもスクラムを推進できるような取り組みが行われています。
最後に、石毛と増田のふたりに、ゲーム作りにおいての組織づくりやプロジェクトマネジメントはどんな仕事か聞いてみました。
石毛 事業やミッション、プロダクトの成功のために必要な仕事だと思います。チームを大きく変えるのはとても大変ですが、 チームの動き方が変わってきた時にはすごくモチベーションが上がりますし、「より良くしたい」と思ってくれる人が増えてくるのはとてもうれしいことです。
増田 ゲーム開発はプレイヤーさんに「楽しい」「おもしろい」を届ける仕事ですが、できればそれをつくっている人たちにも「ゲーム開発は楽しい」と感じてもらえるような組織づくりの仕事かなと思っています。ゲームをつくっている人たちがやりづらいと感じていることを少しずつでも取り除いていきたいですね。
今回紹介しきれなかった部分も含まれる、スライドはこちら
【関連記事】偉大なゲームを作るために「変化に適応できる組織」を作る（前篇）
https://voice.aktsk.jp/5302/
【関連記事】【CEDEC2021レポート】ゲームシナリオの作り方「ライターズルーム」とは
https://voice.aktsk.jp/6608/
エンジニアブログ Akatsuki Hackers Lab
https://hackerslab.aktsk.jp/
アカツキのエンジニアチームでは仲間を募集しています
https://aktsk.jp/recruit/career/engineer/
CEDEC2021
https://cedec.cesa.or.jp/2021/
文/編集：大島 未琴
