「GAgileとは」の編集履歴(バックアップ)一覧に戻る

GAgileとは - (2007/11/20 (火) 04:02:14) の編集履歴(バックアップ)


GAgileとは、「柔軟性」を特徴としたゲーム開発手法のひとつです。
GAgile(読みはガジャイル、もしくはジー・アジャイル)を用いることによって、柔軟な開発を行うことができ、
プロジェクトが混沌とした状況になることを防ぎ、より健全な状態で作品のクオリティを上げる事ができます。

現在のゲーム開発の多くの現場では、プロジェクトのコントロールを失い、
統率が取れないことによってデスマーチ化し、メンバーの士気は低下、
その結果、クオリティの低下や人材の流出がいたるところで起こってます。
ものづくり系の現場ではよく起こることかもしれませんが、それにしても多すぎます。
これにはさまざまな原因があるかと思われますが、
原因の一つとして、体系だった開発手法が存在しないことが挙げられます。
そう、ゲームデザインを扱ったものはいくつもありますが、
ゲーム開発手法を扱ったものはほとんど存在しないのです。

開発手法があると、次のような利点があると考えられます。
  • 知識が蓄積される。
  • 学習しやすくなる。
  • 改善のきっかけを与える。
  • 「プロジェクトマネジメント」というものを意識し、業界の中で論じ合うことができるようになる。

GAgileはあくまで数ある開発手法の一つですが、このような現状を打破し、
業界に開発手法について論じ合える場所を提供できればと考えて創り出しました。

既に実践していることも多く含まれてると思いますが、
まとめるという意味も含めて基本的なことも記して行きました。
今の状況を振り返るという意味でも役立つはずですので、
ぜひ一通り目を通していただけると幸いです。

GAgileの目的

  • ゲーム開発の体系的な手法を確立する
  • クオリティの高い作品を短期間で提供する
  • 革新的な作品を作り出す
  • 毎日が楽しく過ごせる環境を作る

ゲーム開発の体系的な手法を確立する

主に上で書きましたが体系化することで、知識の蓄積・学習の場を与える・改善のきっかけを作る・
プロジェクトマネジメントの概念を意識させることができます。
それぞれについて、もう少し詳しく考えてみましょう。

知識の蓄積

現状、業界ではこのようなものが存在しないため、
各個人や各企業内でトライ&エラーによって培ってきた知識が存在するだけにすぎません。
知識の共有もあまり行われないので、そこで得た知識は閉じられており、もったいないことになっています。

この状況を打破すべく、現在示されている知識(=GAgile)をみんなで洗練していくことで、
ここにゲームプロジェクトマネジメントにおける知識を蓄積していくことを想定しています。

学習の場を与える

体系的な手法がないために、ゲーム開発におけるプロジェクトマネジメントを学ぼうとすると、
いま私がやっているようにIT方面から学び、そこからゲーム流にアレンジするなど、
その業界の最低限の前提知識と努力が必要になってきます。
通常そこまでの労力をかけることはなく、
結局学ぶ意思はあっても実行に移すことなく終わることがほとんどでしょう。
このように、学習面でも体系化するというのは役に立ってきます。

改善のきっかけを作る

ある程度自己流(自社流)のプロジェクトの進め方ができてしまうと、
「今までこれでやってきたから」という理由で立ち止まって考えることなく、
その方法を使い続けてしまいがちです。
すると、最初の時点で無駄を含んでいた場合、それを改善することなくすごすことになります。
また最初に無駄が少なかったとしても、時代は早いスピードで流れているため、
どんどん時代に即しない形になっていきます。
(そしてそれらは、従う人間のテンションを奪っていきます)

このような場合にも新しい体系化された手法に触れることで、
自己流(自社流)の方法を見直すことができるはずです。

プロジェクトマネジメントという概念を意識するようになる

なぜ現状の業界にこのような体系立った手法がないかというと、
ひとつに「プロジェクトマネジメント」という概念が業界で意識されていないという理由が挙げられます。
原因は「そんなもの必要ない」という意見から、
「プロジェクトマネジメントって何?」というところまでさまざまだと思います。

気合で切り抜けられ、しかもそれで売れていた時代ならいざ知らず、
現在はプロジェクトの規模も大きくなりましたし、
小規模プロジェクトも悪い意味のデスマーチを繰り返しています。
そのような時代だからこそ、プロジェクトに秩序をもたらすプロジェクトマネジメントの概念が必要なのです。

ただし現在一般にあるようなプロジェクトマネジメントをそのまま導入しても、
「ほら見ろ上手くいかないじゃないか」といわれるが落ちでしょう。
それはゲーム開発に即したものではないからです。
だからこそ、ゲーム開発におけるプロジェクトマネジメントが、GAgileが必要なのです。

このような体系だったものがあることで、「プロジェクトマネジメントって何?」という人に存在をアピールし、
業界内でGAgileという原案を元に論じ合うこともできるようになります。
(共通に理解している原案がない限り、論じ合うことも難しいですから)

新しい価値の発見

上で挙げた中にはありませんでしたが、体系的にまとめることでもう一つ期待できることがあります。
それは新しい価値(手法)の発見です。
一つひとつは既にわかっていることでも合わせて俯瞰してみると、
全く新しい何かが見えてくるということはどの場所にも見られることです。

この今はまだ見ぬ新しい価値が、もしかしたら業界の常識を変えるかもしれません。


クオリティの高い作品を短期間で提供する

GAgileの目的の一つは、クオリティの高い作品を短期間で提供することです。
私たちは年々予算や期間が厳しくなる中、それでもクオリティの高いものを提供していかなくてはなりません。
それを実現する方法は2つ思いつきます。
一つは「慣れ」による時間短縮。二つ目は「プロセスの見直し」をすること。

一つ目の慣れは非常に効果があります。ただ、いくつも欠点があります。
テンプレートに載せられる業務ならそれのみに頼るのもありかもしれませんが、
常に新しい作品を作り出していく私たちには「慣れ」による効率化は限界があるでしょう。
また世代交代もありますし、人材の流動の激しい業界でもあるため、これに頼り切るのは難しいところがあります。

すると、二つ目の「プロセスの見直し」が必要になってくるわけです。
「プロセスの見直し」つまり「プロセスの効率化」は、必要なことは残しつつ、無駄を省いていかなくてはなりません。
この“必要なことは残しつつ”という面が厄介です。
さらに言うと、必要なことは残しつつ、足りてないものは追加する必要もあります。
(たとえばコミュニケーションエラーが頻発している現場であれば、
 プロセスの追加や考え方の改革が必要になってくるでしょう)

GAgileはまさにこの部分を目的としており、思想・各種プラクティスによって
「GAgileを導入したことで無駄が減ってクオリティもあがった」と言われることを目指します。


革新的な作品を作り出す


毎日が楽しく過ごせる環境を作る

実はこれが一番重要なのかもしれません。
GAgileを実践しても、修羅場はくるでしょう。これはものづくりの現場では避けられないでしょう。
ただ、「無秩序な修羅場」を「秩序ある修羅場」に変える効果はあるはずです。
「無秩序な修羅場」とは、いつ終わるかもわからない中、メンバーが浪費しながら進んでいく修羅場です。
逆に「秩序ある修羅場」とは、目標がはっきりと見えていて、メンバー自ら進んで動くような充実した修羅場です。

GAgileの構成

GAgileは、次の3つから成り立っています。
思想
GAgileの根本的な考え方であり、これを元にプラクティスを構築してあります。
必須プラクティス
GAgileを導入する際に、できる限り採用を推奨するプラクティスです。
選択プラクティス
プロジェクトに合わせて選択するプラクティスです。

GAgileの範囲

GAgileは開発手法・プロジェクトマネジメントの観点からまとめたものなので、
ゲームデザインについては、範囲としません。
また、日本と海外でゲーム開発の体制が若干違いますが、
GAgileは日本のゲーム開発現場での採用を前提としています。

元になったAgile開発

GAgileは名前にも入ってるように、ITソフトウェア業界のAgile開発(それと、それに属する開発手法)を参考にしてます。
Agile開発(アジャイルソフトウェア開発)とは、IT業界のソフトウェア開発において、迅速かつ臨機応変な開発手法の総称です。
Agile開発は、次の4つの価値で定義されてます。
  • プロセスやツールよりも、個人と対話を優先する
  • 包括的なドキュメントよりも、動作するソフトウェアを優先する
  • 契約の交渉よりも、顧客との協調を優先する
  • 計画に従うよりも、変化への対応を優先する
この柔軟さ・コミュニケーションを重視した特徴がゲーム開発に適しているため、
それを元にゲーム流にアレンジしました。
この4つの価値は、GAgileでも変わりなく採用されており、GAgileの思想の元となってます。

しかし、あくまで参考にしているだけであり、
Agile開発のプラクティスでもゲームに適さないものであれば捨てています。
(あまりありえないとは思いますが、)アレンジが進むにつれ、
元のAgile開発から遠ざかることがあったとしてもかまわないと考えます。