「GAgileとは」の編集履歴(バックアップ)一覧はこちら

GAgileとは」(2008/01/13 (日) 05:45:32) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*前文 GAgileとは、「柔軟性」を特徴としたゲーム開発手法のひとつです。 GAgile(読みはガジャイル、もしくはジー・アジャイル)を用いることによって、柔軟な開発を行うことができ、 プロジェクトが混沌とした状況になることを防ぎ、より健全な状態で作品のクオリティを上げる事ができます。 現在のゲーム開発の多くの現場では、プロジェクトのコントロールを失い、 統率が取れないことによってデスマーチ化し、メンバーの士気は低下、 その結果、クオリティの低下や人材の流出がいたるところで起こってます。 このような状況を生み出してしまう原因を考えてみると、 細かい理由は多岐に渡りますが、プロジェクトのマネジメントが甘いことが共通の大きな原因としてあるのではないでしょうか。 しかし、「ゲームデザインについて」の論議は頻繁に行われる中、 「ゲーム開発におけるプロジェクトマネジメント」という視点での論議は、 ほとんど行われていないのが現状です。 そこで「ゲーム開発におけるプロジェクトマネジメント」の具体的な方法として、 GAgileという開発手法を打ち立てていこうと考え、このサイトにまとめました。 現在ゲーム業界には“開発手法”という考え方が浸透してませんが、 業界に開発手法があると、次のような利点があると考えられます。 -知識が蓄積される。 -学習しやすくなる。 -改善のきっかけを与える。 -「プロジェクトマネジメント」というものを意識し、業界の中で議論が生まれる。 GAgileはあくまで数ある開発手法の一つですが、このような現状を打破し、 業界に開発手法について論じ合える場所を提供できればと考えて創り出したものです。 よって、読み手の皆さんが既に実践していることも多く含まれてると思いますが、 まとめるという意味も含めて基本的なことも記してあります。 GAgileは、GAgile自体を「みんなで成長させていく」というスタンスを取ってます。 これは私自身にすべてをわかるほどの経験がないことと、 現状の各個人・各企業のやり方が大きく異なっていて情報を集めようにも集められないという理由です。 なので、「協力してもいい」という方がいましたら、どんどん感想を送っていただければと嬉しいです。 (文中では言い切っている場合でも、実は自信がない場合もありますので……(笑)) ※現在はまだ仮構築中ですので、サイト正式公開後にお願いします *GAgileの目的 GAgileの目的は、次の4つです。 -ゲーム開発の体系的な手法を確立する -クオリティの高い作品を短期間で提供する -柔軟な開発を行う -毎日が充実して過ごせる環境を作る **ゲーム開発の体系的な手法を確立する 体系化することで、「知識の蓄積」「学習の場を与える」「改善のきっかけを作る」「プロジェクトマネジメントの概念を意識させること」を目的としています。 ***知識の蓄積 現状、業界では開発手法が存在しないため、 各個人や各企業内でトライ&エラーによって培ってきた知識が存在するだけにすぎません。 知識の共有もあまり行われないので、そこで得た知識は閉じられており、それは非常にもったいないことです。 原案となる知識(=GAgile)があれば、それをみんなで洗練していくことで、 ゲーム開発におけるプロジェクトマネジメントの知識を蓄積することができます。 ***学習の場を与える 体系的な開発手法がないために、ゲーム開発におけるプロジェクトマネジメントを学ぼうとしても、簡単に学ぶことができません。 方法としては、その分野が充実しているIT方面から学び、そこからゲーム流にアレンジするなどですが、 この方法を取るにはIT業界の前提知識と努力が必要になってきます。 通常そこまでの労力をかけることはなく、 結局学ぶ意思はあっても実行に移すことなく終わることがほとんどでしょう。 GAgileは最初からゲーム開発を対象とした開発手法なので、 この手法が確立されれば「ゲーム開発におけるプロジェクトマネジメント」を学ぶ場を提供できることでしょう。 ***改善のきっかけを作る ある程度自己流(自社流)のプロジェクトの進め方ができてしまうと、 「今までこれでやってきたから」という理由で立ち止まって考えることなく、 その方法を使い続けてしまいがちです。 このような場合にも体系化された手法を知ることで、 自己流(自社流)の方法を見直すきっかけが生まれることでしょう。 ***プロジェクトマネジメントという概念を意識するようになる なぜ現状の業界にこのような体系立った手法がないかというと、 ひとつに「プロジェクトマネジメント」という概念が業界で意識されていないという理由だと考えられます。 原因は「そんなもの必要ない」という意見から、 「プロジェクトマネジメントって何?」というところまでさまざまだと思います。 昔は確かにプロジェクトマネジメント的な視点は必要ありませんでした。 しかしそれは、最初から最後まで気合で乗り切ることができ、ソフトを出せば売れるという時代の話です。 現在は規模の大きいプロジェクトも増え、 プロジェクトの大小にかかわらず開発が複雑化してきています。 そのような時代だからこそ、プロジェクトに秩序をもたらすプロジェクトマネジメントの概念が必要なのです。 ただし現在IT業界にあるプロジェクトマネジメントをそのまま導入しても、 あまりいい結果にはならないでしょう。 それはゲーム開発に即したものではないからです。 だからこそ、ゲーム開発におけるプロジェクトマネジメントが、GAgileが必要なのです。 **クオリティの高い作品を短期間で提供する GAgileの目的の一つは、クオリティの高い作品を短期間で提供することです。 私たちは年々予算や期間が厳しくなる中、それでもクオリティの高いものを提供していかなくてはなりません。 それを実現する方法は2つあります。 一つは「慣れ」による時間短縮とクオリティアップ。二つ目は「プロセスの見直し」をすること。 一つ目の慣れは非常に効果があります。ただ、いくつも欠点があります。 テンプレートに載せられる業務ならそれに頼ることもアリかもしれませんが、 常に新しい作品を作り出していく私たちには「慣れ」による効率化は限界があるでしょう。 また、人材の流動の激しい業界でもあるため、これに頼り切るのは難しいところがあります。 すると、二つ目の「プロセスの見直し」が必要になってくるわけです。 「プロセスの見直し」つまり「プロセスの効率化」は、必要なことは残しつつ、無駄を省いていくことです。 この“必要なことは残しつつ”という面が厄介です。 さらに場合によっては、必要なことは残しつつ、足りてないものは追加する必要もあるでしょう。 (たとえばコミュニケーションエラーが頻発している現場であれば、  プロセスの追加や考え方の改革が必要となってくるはずです) GAgileはまさにこの部分を目的としており、GAgileの思想・各種プラクティスによって 「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開発から遠ざかることがあったとしてもかまわないと考えます。 ----
*前文 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開発から遠ざかることがあったとしてもかまわないと考えます。 ----

表示オプション

横に並べて表示:
変化行の前後のみ表示: