GAgileとは、「柔軟性」を特徴としたゲーム開発手法のひとつです。 GAgile(読みはガジャイル、もしくはジー・アジャイル)を用いることによって、柔軟な開発を行うことができ、 プロジェクトが混沌とした状況になることを防ぎ、より健全な状態で作品のクオリティを上げる事ができます。 現在のゲーム開発の多くの現場では、プロジェクトのコントロールを失い、 統率が取れないことによってデスマーチ化し、メンバーの士気は低下、 その結果、クオリティの低下や人材の流出がいたるところで起こってます。 ものづくり系の現場ではよく起こることかもしれませんが、それにしても多すぎます。 これにはさまざまな原因があるかと思われますが、 原因の一つとして、体系だった開発手法が存在しないことが挙げられます。 そう、ゲームデザインを扱ったものはいくつもありますが、 ゲーム開発手法を扱ったものはほとんど存在しないのです。 開発手法があると、次のような利点があると考えられます。 -知識が蓄積される。 -学習しやすくなる。 -改善のきっかけを与える。 -「プロジェクトマネジメント」というものを意識し、業界の中で論じ合うことができるようになる。 GAgileはあくまで数ある開発手法の一つですが、このような現状を打破し、 業界に開発手法について論じ合える場所を提供できればと考えて創り出しました。 既に実践していることも多く含まれてると思いますが、 まとめるという意味も含めて基本的なことも記して行きました。 今の状況を振り返るという意味でも役立つはずですので、 ぜひ一通り目を通していただけると幸いです。 このGAgileですが、GAgile自体を「みんなで成長させていく」というスタンスを取ってます。 これは私自身にすべてをわかるほどの経験がないことと、 現状の各個人・各企業のやり方が大きく異なっていて情報を集めようにも集められないという理由です。 ですので、「協力してもいい」という方がいましたら、どんどん感想を送っていただければと思います。 (文中では言い切っている場合でも、実は自信がない場合もありますので……(笑)) ※現在はまだ仮構築中ですので、サイト正式公開後にお願いします *GAgileの目的 -ゲーム開発の体系的な手法を確立する -クオリティの高い作品を短期間で提供する -革新的な作品を作り出す -毎日が充実して過ごせる環境を作る **ゲーム開発の体系的な手法を確立する 主に上で書きましたが体系化することで、知識の蓄積・学習の場を与える・改善のきっかけを作る・ プロジェクトマネジメントの概念を意識させることができます。 それぞれについて、もう少し詳しく考えてみましょう。 ***知識の蓄積 現状、業界ではこのようなものが存在しないため、 各個人や各企業内でトライ&エラーによって培ってきた知識が存在するだけにすぎません。 知識の共有もあまり行われないので、そこで得た知識は閉じられており、もったいないことになっています。 この状況を打破すべく、現在示されている知識(=GAgile)をみんなで洗練していくことで、 ここにゲームプロジェクトマネジメントにおける知識を蓄積していくことを想定しています。 ***学習の場を与える 体系的な手法がないために、ゲーム開発におけるプロジェクトマネジメントを学ぼうとすると、 いま私がやっているようにIT方面から学び、そこからゲーム流にアレンジするなど、 その業界の最低限の前提知識と努力が必要になってきます。 通常そこまでの労力をかけることはなく、 結局学ぶ意思はあっても実行に移すことなく終わることがほとんどでしょう。 このように、学習面でも体系化するというのは役に立ってきます。 ***改善のきっかけを作る ある程度自己流(自社流)のプロジェクトの進め方ができてしまうと、 「今までこれでやってきたから」という理由で立ち止まって考えることなく、 その方法を使い続けてしまいがちです。 すると、最初の時点で無駄を含んでいた場合、それを改善することなくすごすことになります。 また最初に無駄が少なかったとしても、時代は早いスピードで流れているため、 どんどん時代に即しない形になっていきます。 (そしてそれらは、従う人間のテンションを奪っていきます) このような場合にも新しい体系化された手法に触れることで、 自己流(自社流)の方法を見直すことができるはずです。 ***プロジェクトマネジメントという概念を意識するようになる なぜ現状の業界にこのような体系立った手法がないかというと、 ひとつに「プロジェクトマネジメント」という概念が業界で意識されていないという理由が挙げられます。 原因は「そんなもの必要ない」という意見から、 「プロジェクトマネジメントって何?」というところまでさまざまだと思います。 気合で切り抜けられ、しかもそれで売れていた時代ならいざ知らず、 現在はプロジェクトの規模も大きくなりましたし、 小規模プロジェクトも悪い意味のデスマーチを繰り返しています。 そのような時代だからこそ、プロジェクトに秩序をもたらすプロジェクトマネジメントの概念が必要なのです。 ただし現在一般にあるようなプロジェクトマネジメントをそのまま導入しても、 「ほら見ろ上手くいかないじゃないか」といわれるが落ちでしょう。 それはゲーム開発に即したものではないからです。 だからこそ、ゲーム開発におけるプロジェクトマネジメントが、GAgileが必要なのです。 このような体系だったものがあることで、「プロジェクトマネジメントって何?」という人に存在をアピールし、 業界内でGAgileという原案を元に論じ合うこともできるようになります。 (共通に理解している原案がない限り、論じ合うことも難しいですから) ***新しい価値の発見 上で挙げた中にはありませんでしたが、体系的にまとめることでもう一つ期待できることがあります。 それは新しい価値(手法)の発見です。 一つひとつは既にわかっていることでも合わせて俯瞰してみると、 全く新しい何かが見えてくるということはどの場所にも見られることです。 この今はまだ見ぬ新しい価値が、もしかしたら業界の常識を変えるかもしれません。 **クオリティの高い作品を短期間で提供する GAgileの目的の一つは、クオリティの高い作品を短期間で提供することです。 私たちは年々予算や期間が厳しくなる中、それでもクオリティの高いものを提供していかなくてはなりません。 それを実現する方法は2つ思いつきます。 一つは「慣れ」による時間短縮。二つ目は「プロセスの見直し」をすること。 一つ目の慣れは非常に効果があります。ただ、いくつも欠点があります。 テンプレートに載せられる業務ならそれのみに頼るのもありかもしれませんが、 常に新しい作品を作り出していく私たちには「慣れ」による効率化は限界があるでしょう。 また世代交代もありますし、人材の流動の激しい業界でもあるため、これに頼り切るのは難しいところがあります。 すると、二つ目の「プロセスの見直し」が必要になってくるわけです。 「プロセスの見直し」つまり「プロセスの効率化」は、必要なことは残しつつ、無駄を省いていかなくてはなりません。 この“必要なことは残しつつ”という面が厄介です。 さらに言うと、必要なことは残しつつ、足りてないものは追加する必要もあります。 (たとえばコミュニケーションエラーが頻発している現場であれば、 プロセスの追加や考え方の改革が必要になってくるでしょう) GAgileはまさにこの部分を目的としており、思想・各種プラクティスによって 「GAgileを導入したことで無駄が減ってクオリティもあがった」と言われることを目指します。 **革新的な作品を作り出す GAgileは意見のフィードバックを短期間で行い、柔軟にプロジェクトを進めていくことで、 革新的な作品を作り出すことも目的としています。 ゲームであれば革新的な作品を作り出していこうというのは当たり間のことです。 しかし残念ながら一部が作業化してしまっている現場というのも少なくありません。 「承認を得るための書類」「無難な仕様」など、もっと工夫できるのにそれがなされていないのでは、 革新的な作品が生み出されることはないでしょう。 プロジェクトマネジメントというと、プロジェクトを「管理」することと考えがちで、 新たなイノベーションを起こすこととは無関係のように聞こえますが、 プロジェクトは「管理」するものでなく「導く」ものです。 メンバー全員で考えるべき場所で考え、必要な意見を必要なタイミングで吸い上げる。 これがプロジェクトを「導く」ということです。 このように革新的な作品が生まれるためのマネジメントの要素を重視し、 プロジェクトを「導く」のに必要なものを提供するのが、 GAgileの目的の一つ、「革新的な作品を作り出す」です。 **毎日が充実して過ごせる環境を作る 実はこれが一番重要なのかもしれません。 ゲームは人が作るものです。 それも一人で作るものではなく、チーム制作です。 そう考えると、チームメンバーが鬱々とした状況ではいい作品ができるわけがありません。 当然誰もそんな状況は望んでいません。 しかし現実にはチームとして上手くいっていない現場が数多く存在します。 それはなぜでしょうか? それを考えてみると、(メンバー間の人間的な相性などどうしようもない問題もありますが、) プロジェクトの状態が「無秩序な修羅場」になっている場合に、 チームとして上手くいっていないことが多いように見受けられます。 「無秩序な修羅場」とは、いつ終わるかもわからない中、メンバーが浪費しながら進んでいく修羅場です。 逆に「秩序ある修羅場」とは、目標がはっきりと見えていて、メンバー自ら進んで動くような充実した修羅場です。 この後者の「秩序ある修羅場」は、修羅場ながらもメンバーの気持ちは充実しているのが一番の特徴です。 GAgileを実践しても、修羅場はくるでしょう。これはものづくりの現場では避けられないものかもしれません。 ただしそれを「無秩序な修羅場」にするか、「秩序ある修羅場」にするかは選べる部分です。 プロジェクトは“人”でできてます。 これを忘れては、他の部分でどんなに上手くプロジェクトを進めたとしても上手くいかないでしょう。 GAgileはメンバーそれぞれが本当の意味でプロジェクトに参加し、 たとえ修羅場が訪れても毎日が充実して過ごせる環境を作ることを目的としています。 *GAgileの構成 GAgileは、次の3つから成り立っています。 :思想|GAgileの根本的な考え方であり、これを元にプラクティスを構築してあります。 :必須プラクティス|GAgileを導入する際に、できる限り採用を推奨するプラクティスです。 :選択プラクティス|プロジェクトに合わせて選択するプラクティスです。 *GAgileの範囲 GAgileは開発手法・プロジェクトマネジメントの観点からまとめたものなので、 ゲームデザインについては、範囲としません。 また、日本と海外でゲーム開発の体制が若干違いますが、 GAgileは日本のゲーム開発現場での採用を前提としています。 *元になったAgile開発 GAgileは名前にも入ってるように、ITソフトウェア業界のAgile開発(それと、それに属する開発手法)を参考にしてます。 Agile開発(アジャイルソフトウェア開発)とは、IT業界のソフトウェア開発において、迅速かつ臨機応変な開発手法の総称です。 Agile開発は、次の4つの価値で定義されてます。 -プロセスやツールよりも、個人と対話を優先する -包括的なドキュメントよりも、動作するソフトウェアを優先する -契約の交渉よりも、顧客との協調を優先する -計画に従うよりも、変化への対応を優先する この柔軟さ・コミュニケーションを重視した特徴がゲーム開発に適しているため、 それを元にゲーム流にアレンジしました。 この4つの価値は、GAgileでも変わりなく採用されており、GAgileの思想の元となってます。 しかし、あくまで参考にしているだけであり、 Agile開発のプラクティスでもゲームに適さないものであれば捨てています。 (あまりありえないとは思いますが、)アレンジが進むにつれ、 元のAgile開発から遠ざかることがあったとしてもかまわないと考えます。 ----