※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

前文

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開発から遠ざかることがあったとしてもかまわないと考えます。