オススメ機能
Twitter
お気に入り
記事履歴
ランキング
TOP
PC
Xbox
PS4
PSV
Switch
3DS
スマホ
女性向け
VR
ハードウェア
ハードウェア
レビュー
テストレポート
インタビュー
ムービー
ドライバ
ベンチマークレギュレーション
AC
アナログ
お気に入りタイトル/ワード

タイトル/ワード名(記事数)

最近記事を読んだタイトル/ワード

タイトル/ワード名(記事数)

LINEで4Gamerアカウントを登録
QRコードでLINEの4Gamer
アカウントを友達登録すると
月〜金の週5回,21時に厳選
ニュースをお届けします!
※購読にはLINEアプリが必要です
特集記事一覧
注目のレビュー
注目のムービー
印刷2010/08/23 10:00

インタビュー

CEDEC事前インタビュー:アジャイルで大規模開発? スクラムを使ったゲーム開発の可能性とは

ゲームリパブリック技術部部長 田中宏幸氏
 コンピュータというものが世に現れて以降,プログラム開発は常に重要な課題だった。現状のコンピュータの祖となるEDSACが登場して60年あまり,パソコンが登場して35年あまり,ゲーム機だとファミコンが登場して27年,その間に数多くのハードウェアが登場してきたものの,より重要だったのはどんなソフトウェアが動くかであったといえるだろう。産業としては,まだ数十年の歴史しか持たない分野ではあるが,ソフトウェア開発で方法論の蓄積は進んでおり,いかに効率を上げていくかという学問が「ソフトウェア工学」として成立している。
 そのなかの一つに「アジャイル開発」と総称されるものがある。
 「アジャイル」は「AGILE=俊敏な」,という意味。RPGのパラメータで「AGI」とあるときは,この単語の名詞形が使われている。一口に「アジャイル」といっても,XP(eXtreme Programming)やCrystal Clearなど,さまざまな流儀のアジャイル開発法が提唱されているのだが,小規模チームで迅速な開発を目指しているという点はほぼ共通しており,手法も似たようなものが使われることが多い。アジャイル手法の導入で劇的な効果をあげた例も多く報告されており,ソフトウェア開発では,一時かなりの話題になっていたトピックでもある。
 8月31日から開催されるゲーム開発者のイベント「CEDEC 2010」では,アジャイル手法の一つである「スクラム(SCRUM)」を使ったゲーム開発について,ゲームリパブリックの田中宏幸氏の講演が行われる。講演内容と関連して,ゲーム開発におけるスクラムの効用などについて聞いてきたので,さっそく紹介してみたい。


ゲーム開発が大規模になってきた

だからスクラムが注目されている


4Gamer:
 本日はよろしくお願いします。
 GDCなどでは数年前ぐらいからアジャイル開発に関する講演が出ていたのですが,日本ではまだ珍しいですよね。

田中氏:
 そうですね。とくにゲーム業界ではあまり聞かなかったのではないかと思います。

4Gamer:
 私のイメージとしては,日本のゲーム作りって,刀匠が刀を一本ずつ手作りしているような雰囲気があるんですよ。

田中氏:
 一子相伝みたいなところを込みで,そういう部分もありますね。

4Gamer:
 でも,アジャイルもそうですが,最近のソフトウェア工学って,なんかもう,生産手法としては効率追求で次元が違うところまで行ってますよね。

田中氏:
 確かに。とはいっても,日本の徒弟制みたいな感じでモノを作っているというのと,アジャイルなモノの作り方っていうのは,ぱっと見は違う印象なんですけど,このスクラムに関していうと,実はそこまで大きな違いはないかもしれません。

4Gamer:
 といいますと?

田中氏:
 もともとIT系ではウォーターフォール型開発っていうのがあったんですね。それは一番最初に仕様をきっちりと作って,それをそのまま上から下へ流すというやり方です。
 ただ,ゲーム作りって,昔からそういう作り方はしていませんでしたよね。ゲームというのは仕様が非常に曖昧で,実際に作ってみないと面白さが分かりません。ですので,日本のゲーム開発っていうのは,ちょっと作っては,みんなで確認してというのを繰り返していたんです。

4Gamer:
 もともと,小規模のループで回っていたと。

田中氏:
 そうです。基本的にアジャイル開発では「イテレーション」(反復の意)というものがありまして,要は,小さくモノを作って,それを顧客にプレビューしてもらい,意見をフィードバックしてっていうのを繰り返すモノ作りになります。これがITのほうで流行りだしてると。
 しかし,これはゲーム業界ではずっと以前からやっていたことなんですよね。逆にいままで,ゲーム業界でそういうやり方でやっていたものに,「やっと名前がついた」っていうのが私のイメージなんです。

4Gamer:
 なるほど。

田中氏:
 ただ,もともとゲーム開発は少人数でやっていたものだったので,少人数であれば,スクラムみたいなプラクティス(慣行,手法などの意)でやっていることを,普通のゲーム会社でも意識せずやっていたのですが,最近は開発が大規模になってきました。100名体制とかになってくると,途端に「管理,管理」みたいな話になってきて,むしろゲーム業界はウォーターフォール型開発に進む雰囲気になっているような気がします。
 100人を動かそうとすると,どうしても上から仕様がないと流れません。しかし,このスクラムという手法では,少人数のチーム編成を複数チーム作るんです。「スクラムチーム」というもので,1チームがだいたい10人ぐらいで,それぞれが成果を出していくと。
 さらに,それぞれのチームにはリーダーがいて,そのリーダー達でもスクラムチームを組み,全体的な情報共有とか,ゲーム全体の流れとか,顧客に対してのレビューとかを管理します。このようなやり方で,今までのゲーム制作を,より大人数に対応させるというのが,スクラムでの大規模開発の流れになります。

4Gamer:
 もともとアジャイルだったのを,大規模化に対応させると。

田中氏:
 そういう点では非常にゲーム業界との相性はいいんです。
 海外ではゲーム用のスクラムみたいなのもありまして,その手法を紹介した本も出てるんですね。いろんな成功例も出てきています。ここ最近だと,GDCでアンチャーテッド2がスクラムで作られたという講演がありました。
 日本でも100人規模でモノは作っていかないといけない。けれども,ウォーターフォールでゲームを作るわけにはいかないと。で,今までどおりの日本の開発手法では,太刀打ちできなくてどうしようということで,少しずついろんな企業の目が向いてきていると感じます。

4Gamer:
 なるほど。しかし,アジャイルというと小規模というイメージがありましたので,それを大規模開発のために使うというのは意外でした。

田中氏:
 今までの小規模開発であれば,今までどおりの手法で問題ないんです。それが大規模になると途端に厳しくなります。
 弊社でもPlayStation 3やXbox 360のタイトルを多数作っていまして,そうするとチームは100名規模になります。こうなると,「管理,管理」みたいになってしまって,それをなんとか打破したいと思い,こういう手法を学び始めたわけです。


スクラムでは,どんな管理が行われるのか


4Gamer:
 もともと,こういう手法は主にプログラマ用に作られたものだと思うんですが,ゲーム開発だとプログラマだけというわけではないですよね。アーティストがいたりいろんな部署があったりと。そういった部分にも有効なものなんでしょうか。

田中氏:
 はい,そこがXPとスクラムとの大きな違いです。XPのプラクティスで,一番有名なものというと,ペアプログラミングですよね。もともとXPはプログラマのものだと思います。
 このスクラムは,プログラミングから派生しているものではなくて,マネジメントから派生したものなんです。ですので,プログラマ専用のプラクティスというのは,ほとんどありません。
 例えば,スクラムでの有名なプラクティスを挙げてみましょう。

  • 朝会
  • リリース計画
  • イテレーション計画
  • バーンダウンチャート
  • レビュー会
  • 振り返り

 これらは,すべてプログラマ専用のものではありません。

4Gamer:
 バーンダウンチャートというのは聞き慣れないのですが。

田中氏:
 これは以下のような感じのものになります。

CEDEC事前インタビュー:アジャイルで大規模開発? スクラムを使ったゲーム開発の可能性とは

4Gamer:
 なるほど,進捗を示すものということですね。

田中氏:
 そうですね。このバーンダウンチャートは,スクラム専用というものではないんですけど,スクラムではこれを使うことが推奨されています。
 スクラムは「実測駆動」に重点を置いてます。つまり,自分のチームがどれだけの仕事量をこなせるのかは,実際に測定しないと判らないという事です。
測定の方法ですが,まず「主人公が敵を倒せるようにしたい」といった目標があるとします。


4Gamer:
 それは,短期的な目標ですか。

田中氏:
 そうです。イテレーション単位くらいの目標です。
で,その目標に対して,チームの中で細かい仕事単位まで細分化して,実際にこの仕事は何時間ぐらいでできるんだろう?というのを,みんなで考えるんですね。「俺,多分これ6時間でできると思う。お前どう?」みたいな形で。

4Gamer:
 それをやるためのタスクの分割も,チームみんなでやるわけでしょうか。

田中氏:
 それもチームのみんなでやります。時間の割り出しも,仕事の細分化も,管理職がやるより作業する本人達がやったほうが正確ですから。細分化した各仕事の作業時間が出せたらそれを合計し,過去,自分のチームが測定していた時間と比較して「イテレーション内でこの目標達成出来るよね」という感じで作業を進めていくわけです。

4Gamer:
 で,実測駆動というわけですね。

田中氏:
 そういうことです。そこでバーンダウンチャートなんですが,縦軸は先ほど出した仕事の合計時間になってます。各仕事はチケットみたいな形に全部切られていまして,仕事が終わったらその仕事分,時間を減らしていきます。この青いのが理想線で,それに対して今のみんなが遅れてるとか,進んでるかが分かり,最終的にチームがイテレーションごとにどれだけ仕事量をこなせるか測定もできるという仕組みです。

4Gamer:
 ちなみに,イテレーション間隔自体はどれぐらいで捉えていますか。

Clinton Keith著,「Agile Game Development with Scrum」,Addison-Wesley刊
田中氏:
 2週間から1か月ですが,ゲーム開発の場合だと,どうしても変化量が多いので1か月はちょっと長いという話をいろんな方から聞いています。
 私の読んでいるゲーム開発のスクラムの本(「Agile Game Development with SCRUM」)だと,例としては3週間という形で載っています。
 最初は1か月でやってみたけれど,レビューが遅くて厳しかったので,途中で3週間にしたと書いてありました。
 また,実測駆動といっても,一番最初のイテレーションでは,まだ作業時間が測定できていませんので,その場合は3週間でのミニマム,みんながなんとなくこれだけの仕事量ができるだろうという時間を出します。1日7時間を目安に働くとしても,メールがあったりミーティングがあったりで,みんな7時間フルでは働けません。そこで5時間あたりで見積もって,それをもとに実測駆動で,イテレーションをやっていくという流れになります。

4Gamer:
 なるほど現実的ですね。

田中氏:
 こういった管理手法も,別にプログラマ専用というわけではありません。
 また,それ以外にも,これは一番の特徴かもしれませんが,スクラムはコミュニケーションを非常に重視しています。
 先ほど挙げたスクラムのプラクティスリストでのコミュニケーション部分では,まず,朝会(あさかい)があります。これは「毎朝やる,立ってやる。15分ぐらいで短くやる」と。一週間に一度だとどうしても情報共有が遅くなってしまいますし,毎日1時間やってしまうと働く時間が短くなってしまうので,15分というのを目安として朝会ってのをやりましょうというものです。

4Gamer:
 これは,その日のタスクの確認とかそういうことが中心でしょうか。

田中氏:
 そうです。内容は決まっていまして,

  • 昨日なにをやっていたのか
  • 今日は何を作るつもりなのか
  • 現在抱えている問題はないか

この3点だけを全員で順々に言っていくと。みんながコミュニケーションを毎日必ずとって,きちんと状況を把握します。

 それ以外にも,イテレーション計画という,先ほど言った目標を仕事に細分化したりという部分もチームみんなでやります。バーンダウンも,やはりチームみんなで状況を計るので,コミュニケーションが取れます。
 あと「振り返り」というのもスクラムで重視している要素です。イテレーションの終わりに,必ずみんなで「今回よかったことはなにか」「今回悪かったことはなにか」「次にもう一回イテレーションになったときに,こういう風にしよう」みたいなことを確認するわけです。そういうコミュニケーションを取りながら,作業を改善していくというのもスクラムの特徴にもなっています。

4Gamer:
 イテレーション計画,リリース計画,振り返りあたりがイテレーションの前後で,あとは毎日って感じでしょうか。

田中氏:
 そうですね。バーンダウンは毎日ですし朝会も毎日ですね。あと「レビュー会」というのがあります。このレビュー会っていうのは,主要ステークホルダー,ゲームでいうと,まあディレクターさんとか,プロデューサーさんとか,上の人達とチームメンバーが集まって,今月できたものを全員で見て,現状と今後の方針を確認します。

4Gamer:
 それは複数チームでやっているときの各チームが集まる会みたいなものですか。

田中氏:
 そうですね。それぞれのチームが今回の作業内容を発表していきます。できればそれらがすべて合わさった遊べる形で発表するのが望ましいです。

4Gamer:
 確かに,これはマネジメント手法ですね。

田中氏:
 もともとスクラムっていうのは,野中郁次郎さんと竹内弘高さんという,現在は一橋大学の教授をされている方の書いた論文が起点になっています。この方は全然プログラマでもなんでもありません。もともと日本の製造業,ホンダやNECといった,もの凄く効率よくものを作っているモノ作りの現場をいろいろと調べ,それらで共通している要素をまとめあげた論文なんですね。それがアメリカの雑誌に載って,それをアメリカのケイン・シュエイバーという人が見つけ,「なるほど,じゃあこれをIT企業で生かしてみよう」と。
 こうして生まれたものですので,やはりマネジメントが基本になっています。
 そして,名前の由来も「スクラムのようにガッチリ組んで前に進む」ということが論文の中で書かれていまして。だから,(アメリカではマイナーなラグビー用語の)スクラムという名前になったそうです。なので,実はスクラムは元々日本人が考案したものが,アメリカに渡って,また日本に帰ってきているみたいな状況です。

4Gamer:
 ちょっと前に,アジャイルが大きく注目された時期の主役はXPでしたよね。その時期でも,アジャイルについて調べてみると日本だとスクラムを地道にやっているところがあって,最近調べても,日本だとスクラムが根付いているなという雰囲気がかなりありました。

田中氏:
 そうですね。

4Gamer:
 XPは,本当にプログラマ向けというか,あれはベストプラクティス(理由は分からないが,とにかくこうしたらうまくいく的な知識)中心ですよね。本を読むとほとんど宗教書みたいで面白いですが(笑)。

田中氏:
 スクラムにも若干,そういう宗教じみているところはあるんですけどね(笑)。
 海外でのアジャイル開発を見ますと,スクラムとXPのハイブリッド開発が22%,スクラムオンリーが49%,それ以外が29%となっています。ウォーターフォールに比べると全体的な規模は小さいんですけど,言い方を変えればアジャイル開発の中でスクラムが71%使われているわけです。海外でもスクラムの占める割合が多くなっています。
 日本では,やはりIT業界のほうが,そういうところは進んでまして,ゲーム業界にはマネジメントの波というのは,まだ小さいように感じます。ただ,どうしても,100名体制とかになってくるとマネジメントするしか方法がないので,今後は注目せざるえなくなるでしょうね。


日本のゲーム開発の現状と課題


UMLのクラス図とアクティビティ図の例(Sparx Systems「UML 2.0 Tutorial」より)
CEDEC事前インタビュー:アジャイルで大規模開発? スクラムを使ったゲーム開発の可能性とは
CEDEC事前インタビュー:アジャイルで大規模開発? スクラムを使ったゲーム開発の可能性とは
4Gamer:
 話は変わりますが,主に海外のソフトウェア工学とかだと,もう,みんなUML(統一モデリング言語。アルゴリズムやデータ構造,処理の流れなどを図の形式で表現するもの)を使って話をしているといった印象があります。GDCでもプロデューサクラスの人がUMLを持ち出したりと。日本のゲーム業界だとそのあたりの普及度はどうなんでしょうね。

田中氏:
 私自身は,UMLはそれほどやっていません。ただ,デザインパターン(主にオブジェクト指向でソフトウェアを作る際に,基本となる考え方をまとめたもの)みたいなものはゲーム業界でも数多く使われていますね。そのデザインパターンの為にUMLを使っているという話は時々聞きます。
 弊社でも,デザインパターンとUMLを使っているチームはありますね。ただ,業界全般的に流行っているかというと,そうではないと思います。
 
4Gamer:
 最近は,ゲームも相当大きくなってきましたし。

田中氏:
 そうですね。規模的には本当に大きくなってきました。予算もそうですし。

4Gamer:
 開発期間自体はやっぱり伸びているんですか?

田中氏:
 いえ,そこは伸びてないです(笑)。
 予算は増えて,人は増えてますけれども,期間は増えてはいませんので,そういう点でも昔より厳しいですね。ですので,やはりマネジメントに行き着いてしまいます。私はPCゲーム,PlayStation,PlayStation 2とやってきたんですけど,どれもゲーム開発は12か月から18か月が一般的なところで,今もやっぱり同じような感じですね。むしろ,それでマルチプラットフォームで同時リリースといわれるので,よりハードルが上がっているイメージがあります。一部の「トリプルA」といわれている,予算がもうケタ外れのタイトルは違うかもしれませんが。

4Gamer:
 それは,ごく一部でしょうね。海外だとハリウッドスタイルとかありますが,国内でやっているとこって,ほんの数社でしょうか。

田中氏:
 そうですね。日本だとプロジェクトソラさんが,1回のプロジェクトで人をだだっと集めて,終わったら解散みたいな作り方をしていると聞いたことがありますね。

4Gamer:
 ぱっと集めて解散というスタイルだと日本ではなかなか難しいでしょうね。

田中氏:
 難しいですね。
 これもちょっと嫌な話になっちゃうんですけども,どうしても今の日本のコンシューマ不況下では,他社さんと仕事の取り合いみたいな形になっているんですよね。そうなったときに,他社さんに価格などで負けるわけにはいかない。そうなってくると,社内での人月(生産コスト)では,割に合わないので,どんどん外注が増えています。とくに海外ですね。例えば,インド,タイ,ミャンマー,上海。伝え聞くところでは,人件費は日本の半額以下のようです。ゲームの主要部分以外,もう外注にしているってところが,大分増えているみたいですね。厳しい感じです。

4Gamer:
 アセットとか,そういうものについては結構海外でというのも聞いていますが。

田中氏:
 そうです。さすがにプログラムは難しいですが。だからまあ,ハリウッドスタイルとはちょっと話が違うのかもしれませんけど,いろんなところから人を集めてモノを作っているというのは,今の日本では主流といってもいいかもしれませんね。ハリウッドスタイルみたいなポジティブみたいな感じのものではないのがちょっと,アレですけどね。

4Gamer:
 クオリティよりもコスト面の追求で協業なのはちょっと残念ですね。

田中氏:
 ちなみに,そういう外注みたいな話になると,スクラムは苦手だったりします。

4Gamer:
 まあ,全然違うマネジメントになっちゃいそうですね。

田中氏:
 むしろウォーターフォールに近いような感じですね。

4Gamer:
 そうですね。たぶん仕様きっちり固めておかないと動かないんでしょうね。

田中氏:
 難しいと思います。ただ,離れた拠点でそれぞれスクラムチームを組んで,ゲームを完成させたという事例を聞いた事があります。レビュー会のときはテレビ会議などを使って,朝会も時差を考慮してと,すごい工夫をしてスクラムを成功させたそうです。

4Gamer:
 基本をそのままというわけではなくて,会社会社で,それぞれのスタイルでやってるわけですね。

田中氏:
 会社毎に文化や環境は違いますし,日本のゲーム会社は,とくに一子相伝みたいな独自文化がありますからね。

4Gamer:
 日本のゲーム開発のそういう部分は,どうしてもちょっと原始的だなあと思ってしまうのですが。海外のソフトウェア工学ベースだと,情報のオープンさや効率の追求の仕方が全然違いますよね。デザインパターンにしてもそうですし。

田中氏:
 それについてはAgile Japan 2010で野中先生も言及されていました。日本人は「暗黙知」が好きで,海外の人は「形式知」が好きだと。つまり,とくにを文章にしないで,一子相伝なのが暗黙知。で,一般的に自分達のやっているものを形式にして,そういうのをどんどん外に出していこうというのが形式知。海外では,そういう気質みたいのがありますよね。
 ただ,形式知だけではダメで,その形式知を暗黙知にするプロセスが非常に重要。つまり,スクラムでも,「スクラム」について知識を持っているだけではなくて,それを最終的なところで自分らの骨とか,血とか肉とかまでに落とし込んでないと,ただやっているだけでは成功しません。
 日本は保守的なんですけど,やると決めたら,そういうところまでガッツリとやろうというイメージがあります。欧米では,いろんなことをスラスラっとやって,「ダメだな。次行こう」みたいなイメージはちょっとありますけれどもね(笑)。まあ日本人の腰が重いのは確かでしょうね。慎重というのかな。

4Gamer:
 ちなみに,社内の開発でスクラムを取り入れると決めてから,すんなりといったんでしょうか。

田中氏:
 すんなりといいますか,うちの会社でも全体的にスクラムを取り入れているってわけではないんです。今は,1チームでまずはスクラムを始めています。私もやっぱり慎重だったりしますので(笑)。
 とくに,スクラムでは,コンセプトみたいなところとか,なぜ朝会をやるのか,なぜ振り返りが大事なのかとか,コミュニケーションが重要になってきますので,そういうところが非常に密になってないといけません。まずは,社内勉強会を開催しまして,「ちょっといいね」といってもらえたディレクターさんと個別で話をして,で,そのディレクターさんのほうで,ちょっとやってみましょうか,みたいな形で動いています。
 すでに,ある一定の成果が出てますので,ほかのプロジェクトにもこういうのをちょっとやってみたらどうですかと少しずつ広めています。
 やっぱりゲーム開発の上ではディレクターさんが旗振りですので,その人の賛同が得られない場合は無理にはオススメしてはいないです。きちっと賛同してもらえないと,逆効果になりますし。
 それと,向き不向きがあったりしますので,一概に全員が全員,スクラムをやったらいいのかっていうのは私としても疑問です。決して,昔からいう「銀の弾丸」ではありません。

4Gamer:
 GDCでは,毎回そういうセッションがありますね。

田中氏:
 あとは,大きなプロジェクトに取り入れるには,まだ少しステップを踏まないとなと思ってます。まず,スクラムの技術っていうのが,社内に根付いて,それぞれのリーダーさんがある程度やり方を分かってからでないと,大きなプロジェクトをやるのは厳しいでしょう。
 私も形式知の状態でスクラムを始めましたので,やっぱりやってみないと分からない部分が大きく,山ほどの失敗もあったりもします(笑)。そういうところをCEDECでお話しできたらと思ってます。そういった失敗話というのは,なかなかインターネットには転がってはいませんし。

4Gamer:
 失敗のパターン(アンチパターン)の話もソフトウェア工学だと結構ありますよね。

田中氏:
 ですね。
 ゲームならではの,プログラマのほうが少ない状態でのモノ作りという,ほかのIT系に比べると大分特殊な環境のなかだと,特に失敗談みたいなものはなかなかないと思います。
 他社さんがスクラムをやってみようかなと思ったときに,なにかこう道標,っていうと大げさですが,ちょっとしたTipsみたいな形で役に立てればと思ってますので,CEDECでは,前半はスクラムの概要などを,後半では実際にやってみての話をしたいですね。他社の人とも,そういった知識や経験などが共有できるような協力体制が取れるようになるとよいなと思っています。

4Gamer:
 CEDECでも,これまでプログラムとかテクニカルな部分で,そういう傾向があったんですが,マネジメントの部分まで出てくるとまあ一段進歩したなって雰囲気がありますね。

田中氏:
 そうですね。技術だけではなくてゲームの作り方という部分でも,協力し合い,競い合えるような風潮が少しずつ広がっていけばいいなと,私自身思っています。

4Gamer:
 頑張ってください。本日はありがとうございました。


 近年,ゲームの開発規模が大きくなっており,それに比例して開発コストやプロジェクト進行の難度が上がっている。そのような状況に対して,GDCやCEDECでは,ゲーム開発者がさまざまな知識を持ち寄り,それを共有する場を作り上げて徐々に成果を挙げてきている。
 しかし世の中を見渡すと,もっともっと大きな規模のソフトウェア開発を行っている分野もある。エンタープライズ系開発の世界ではそういったノウハウの集積を何十年も前から行っており,体系的な学問にまとめ上げている。今回の文中で何度も「ソフトウェア工学」と出てくるので,すでに食傷気味の人もいるだろうが,先人の知恵はいくらでも転がっている時代でもあるのだ。
 アジャイル開発は,ソフトウェア工学の成果の一つだが,仕様変更が多い案件に向いたノウハウを集めた開発スタイルであり,比較的ゲームとの親和性も高いのではないかと思われる。今回のインタビューで分かるように,スクラムは大規模開発にも適用できるということで,今後のゲーム開発スタイルの発展に大いに期待させられるものがある。
 「ゲーム開発でのアジャイルは銀の弾丸ではない」というのは,毎年のGDCの講演でくどいくらいに繰り返されているテーマである。もちろん,「アジャイルはダメだ」といっているわけではない。むしろ,釘を刺しておかなければならないくらいに効く手法であることの裏返しではないだろうか。

 2008年のの東京ゲームショウで,CESA和田会長が「もはや日本はゲーム業界のリーダーではない」旨を語ったのは印象的だったが,近年,ゲーム開発では海外に学ぶことも多くなっている。そんな中,日本で生まれ,海外で育ったスクラムは,ゲーム業界に逆輸入されようとしている。日本,および,ゲームと親和性が高そうで,なおかつ実績もある手法だけに,日頃プロジェクト管理に悩んでいる人は,この講演を聞いてみるのもよいのではないだろうか。

CEDEC 2010公式サイト

  • この記事のURL:
line
4Gamer.net最新情報
トピックス
スペシャルコンテンツ
注目記事ランキング
集計:10月18日〜10月19日