【CEDEC 2019】ゲーム開発におけるスクラム手法のメリット＆デメリットとは…ディライトワークスの新プロジェクトのスクラムマスターが語るスクラム導入のすすめ
9月4日～6日の期間、CEDEC 2019が、パシフィコ横浜で開催された。2日目にあたる5日、による講演「ゲーム開発におけるスクラムのすゝめ ～失敗は成功のもと～」が行われた。
本講演では、ディライトワークス技術部第2セクションにプログラマーとして務め、新規プロジェクトにおけるスクラムマスターを担当している畠山彰秀氏が登壇し、スクラム導入から試験運用の経過について発表した。
▲登壇した畠山彰秀氏。
▲本講演のアジェンダ。まずはスクラムについてのおさらいから始まり、スクラム運用の経過についての発表につながっていく。
▲畠山氏もアサインしている新ゲームプロジェクトのキービジュアル。発表時から、Unreal Engine 4を使ったiOS/Android向けのアプリであることが明かされている。
まずは講演を行なうにあたり、スクラムとは何かというところから畠山氏は話を始めた。スクラムについてのおさらいは「3つの定義」、「3つの理論」、「スクラムフレームワーク」という3点に分けながら話を進めていく。
スクラム開発とは、アジャイルソフトウェア開発手法のひとつであり、共通のゴールに向けてチームが一丸となって働くというものを指している。畠山氏はこうしたスクラムの定義を「導入は簡単でお金もかからない」、「理解もしやすい」、「ただし実践と習得が難しい」ものであると噛み砕いて説明している。
次にスクラムの理論について、プロジェクトで何が起きているかが見える「透明性」、正しい形で開発できているのかをチェックする「検査」、検査結果を踏まえてプロジェクトを正しい道に戻す「適応」という、3つの柱で構成されるとしている。
スクラムフレームワークを図式化したスライドを見せながら、おおまかな流れについても解説している。開発内容が決まってからは、デイリースクラムとして朝会を実施しながら開発を進め、最終日前後には成果物の確認や、振り返りを行なっている。これはあくまでも一例であり、この形式でないといけないというわけではない。
そもそも、畠山氏がスクラムに興味を持ち、導入を推進するに至ったきっかけは、担当プロジェクトでタスクや情報が見えにくい状況を打開するためだった。しかし、そのためには開発手法から見直す必要があり、新たな手法について悩んでいた畠山氏は、「かんばん開発方式」について書かれた書籍と出会う。
そこには、当たり前とも思えることが理論付けて説明されており、そのことに畠山氏は大きな衝撃を受けたそうだ。「かんばん開発方式」についての勉強を重ねていくなかで「スクラム」の存在を知ったことで、畠山氏はスクラム導入へと踏み出した。
▲この頃から、畠山氏は開発環境改善に注力するようになったという。
畠山氏は、自身が開発環境改善にのめり込んだ理由についても考察しており、自身が誰かと一緒に何かを良くしていくことが好きであり、人生設計においても開発環境に携わることを想定していたという経緯があったことに起因しているのではないかと推察している。
具体的に畠山氏が目指していた開発環境は、コミュニケーションが活発であり、クリエイターもユーザーも面白いプロジェクトを生み出せる環境。そして、楽境も苦境も共有できるような現場だという。
▲目標とする開発環境について、「プロジェクトに関わる人すべてが幸せになれる環境」とまとめている。
では「人が幸せを感じるのはどのようなときなのか？」を考えるところから、畠山氏の開発環境改善はスタートする。そのために、畠山氏はチーム全員にアンケートを取り、メンバーが感じる幸せの定義付けをしている。
しかし、当時のプロジェクトの状況を振り返ると、長期間の大規模開発、不可逆なウォーターフォール型であったこと、協力会社も多数あり、今から開発環境を大きく変えるのは現実的ではなかった。
そんな壁にぶつかっていた畠山氏だったが、まだ走り出したばかりの別プロジェクトへの異動が決まったことで、ここで開発環境改善にチャレンジすべきだと一念発起、スクラム導入について、上層部に直談判した。
新プロジェクトの開発環境の一部をここで公開している。前述した通り開発にはUnreal Engine 4を使用し、運用ツールは「JIRA」、「Confluence」、「Slack」、「Trello」等、見慣れたものを使用している。
ここからはスクラム導入にあたって、失敗したケースについて触れている。この数ある失敗例の中から「研修用資料」、「見えないタスク」、「バーンダウンチャート」、「議事録」についての問題について詳しい解説を行なっている。
ここから、問題の解決にどう取り組んだかについて話していくのだが、その前に畠山氏は、改善を行なうときの3つの決め事についても言及している。
「迷ったらスクラムよりチームを優先」という項目は、「スクラムのフレームワークに従う」という項目と矛盾しているようにも見えるが、これは試験運用であることを踏まえ、チームの効率を大前提としているからである。
失敗例のひとつ目は「チーム内でのスクラムの研修」だ。ここでは、スクラムについて子細な解説をするために、膨大な資料を作ってしまい、興味を持ってもらえなかったようだ。
▲実際に製作した資料の一部を公開している。
この問題を改善するためには、まず興味を持ってもらうため、8人でスクラム体制のチームを組み、紙飛行機を設計し、組み立て、飛ばすという工程を繰り返すという内容のワークショップを実施し、スクラムを導入した環境を体験してもらうことにした。
これによってスクラムへの理解は深まったので、次は実際にプロジェクトにテコ入れしていく段階に移る。まずは、担当者不在や放置されているチケットを整理し、1400件あったチケットを250件まで削減した。さらにタスクボードも可視化することで、全体のタスクが把握しやすくなっている。
スクラムにおいては、差し込み案件は本来無くすべきものなのだが、いきなり無くすと現場が混乱するため、まずは把握しやすい形を目指すため、こちらも可視化という方向で進めたそうだ。さらに、完了したタスクを可視化するためのバーンダウンチャートを導入することで、日々の進捗も見える化している。
しかし、ここまでしても「見えないタスク」が存在していた。その理由として、畠山氏は「チケット化のルールが曖昧だった」という問題点を挙げている。その改善策としては、チケット化に軽い制約を設けるという方法をとっている。
具体的には、ミーティングのチケット化をしないことであったり、ゲーム開発外の業務をその他タスクとして処理するといった内容だ。それと同時にワークフローを整備し、その他タスクを最低限のフローで回すようにし、課題に合わせたフローを使い分ける形にした。
ここまで、環境を改良してきているが、それでも「バーンダウンしない」という問題には誰しもぶちあたると畠山氏は言う。その原因となるのは「完成の定義が定まっていない」ことと「ひとつのスプリントに詰め込みすぎ」というふたつの要素をあげている。
様々な改良を施したものの、チーム内でこなせるタスク量を把握しきれていなかったことや、そもそも何をもって完成とするのかが曖昧になっていたため、完了しないタスクがでてきてしまったことで、タスクが減らないという状況に陥ってしまった。
▲初期のバーンダウンチャートもスライドに掲載されている。下の線が理想の線形であり、実際の消化量を示す線は上の赤いものとなる。
この問題については今も改善中であると畠山氏は公表した。その方法として、まずはチームの意識改善を推し進めているそうだ。自分たちが消化できるタスク量を把握し、試験運用であることを踏まえながら経験を積んでいく意識を持つ。そして、タスクの細分化について各々がしっかりとしたイメージを持つといった内容で、改善を進めている際中とのことだ。
▲こうした意識改善を進めていくうちに、バーンダウンするタスクが徐々に増え始め、バーンダウンチャートにも改善がみられている。
次に畠山氏が問題点として挙げたのが「振り返り内容が過去のものとなる」という点だ。現在、畠山氏のチームでは振り返りの手法としてKPT（Keep Problem Try）を採用しているが、その結果を写真に収めて共有しても、詳細な内容をあとから確認しづらいという問題が発生した。
そこで、活用しているツールが「Trello」であり、このツールによって振り返り内容の可視化に成功している。
▲ラベルの色分けや、レーンの分割によって、残存する問題や解決したタスクがわかりやすくなっている。
ここまでの講演内容を踏まえつつ、2ヶ月のスクラムフレームワークを実践してみた所感について畠山氏は言及を続ける。ゲーム開発におけるスクラムのメリットとして「チームの一体感が生まれやすい」、「週単位でのタスクが把握しやすい」、「改善を管理することでチームが前に進む」、「スクラムイベントとゲーム感覚の相性の良さ」、「情報が全員から見やすい」といったところを挙げている。
対して、難しい点として「まだ以前の開発手法に引っ張られがちである」、「タイトルの大きくなるとチームが増えてしまいスクラムマスターが不足する」、「クロスファンクショナルチームの運用は極めて難解」、「差し込みを無くしつつ面白さを担保する難しさ」といった点を挙げている。
今回の講演のまとめとして、畠山氏は「失敗しても次に活かすことで成功に導く」ことの大切さとともに、しっかりと自分の芯を持ち、迷ったときの指針にすべきものを決めておくべきだと主張している。
以上で、畠山彰秀氏による講演「ゲーム開発におけるスクラムのすゝめ ～失敗は成功のもと～」は終了となる。
（取材・文 ライター：宮居春馬）
