ゲームにおけるアジャイル開発 ~GAgile~(予定)
http://w.atwiki.jp/gagile/
ゲームにおけるアジャイル開発 ~GAgile~(予定)
ja
2008-01-13T05:55:44+09:00
1200171344
-
GAgileの目的
https://w.atwiki.jp/gagile/pages/20.html
GAgileの目的は、次の4つです。
-ゲーム開発の体系的な手法を確立する
-クオリティの高い作品を短期間で提供する
-柔軟な開発を行う
-毎日が充実して過ごせる環境を作る
*ゲーム開発の体系的な手法を確立する
体系化することで、「知識の蓄積」「学習の場を与える」「改善のきっかけを作る」「プロジェクトマネジメントの概念を意識させること」を目的としています。
**知識の蓄積
現状、業界では開発手法が存在しないため、
各個人や各企業内でトライ&エラーによって培ってきた知識が存在するだけにすぎません。
知識の共有もあまり行われないので、そこで得た知識は閉じられており、それは非常にもったいないことです。
原案となる知識(=GAgile)があれば、それをみんなで洗練していくことで、
ゲーム開発におけるプロジェクトマネジメントの知識を蓄積することができます。
**学習の場を与える
体系的な開発手法がないために、ゲーム開発におけるプロジェクトマネジメントを学ぼうとしても、簡単に学ぶことができません。
方法としては、その分野が充実しているIT方面から学び、そこからゲーム流にアレンジするなどですが、
この方法を取るにはIT業界の前提知識と努力が必要になってきます。
通常そこまでの労力をかけることはなく、
結局学ぶ意思はあっても実行に移すことなく終わることがほとんどでしょう。
GAgileは最初からゲーム開発を対象とした開発手法なので、
この手法が確立されれば「ゲーム開発におけるプロジェクトマネジメント」を学ぶ場を提供できることでしょう。
**改善のきっかけを作る
ある程度自己流(自社流)のプロジェクトの進め方ができてしまうと、
「今までこれでやってきたから」という理由で立ち止まって考えることなく、
その方法を使い続けてしまいがちです。
このような場合にも体系化された手法を知ることで、
自己流(自社流)の方法を見直すきっかけが生まれることでしょう。
**プロジェクトマネジメントという概念を意識するようになる
なぜ現状の業界にこのような体系立った手法がないかというと、
ひとつに「プロジェクトマネジメント」という概念が業界で意識されていないという理由だと考えられます。
原因は「そんなもの必要ない」という
2008-01-13T05:55:44+09:00
1200171344
-
テーラリング
https://w.atwiki.jp/gagile/pages/19.html
テーラリングとは、現在のプロジェクトにあわせて構造を仕立て直すことです。
*プロセスのテーラリング
tbd.
//社内ルールとか。
//ワークフローをプロジェクトに適応するとか。
*プラクティスの選定
tbd.
//GAgileのプラクティス+チームのプラクティス。という形に。
//後者は体系化されてない場合が多いので、なかなか議論しづらいかもしれない。
*プラクティスのテーラリング
tbd.
----
2007-11-15T04:33:57+09:00
1195068837
-
ドキュメントより対話を
https://w.atwiki.jp/gagile/pages/18.html
tbd.
----
2007-11-15T04:34:54+09:00
1195068894
-
成長型思考
https://w.atwiki.jp/gagile/pages/17.html
tbd.
----
2007-11-15T04:35:08+09:00
1195068908
-
参考文献
https://w.atwiki.jp/gagile/pages/16.html
|アジャイルプロジェクトマネジメント|日経BP社|ジム・ハイスミス|
|成功する要求仕様 失敗する要求仕様|日経BP社|アラン・M・デービス|
----
2007-11-15T04:34:27+09:00
1195068867
-
GAgileとは
https://w.atwiki.jp/gagile/pages/15.html
*前文
GAgileとは、「柔軟性」を特徴としたゲーム開発手法のひとつです。
GAgile(読みはガジャイル、もしくはジー・アジャイル)を用いることによって、柔軟な開発を行うことができ、
プロジェクトが混沌とした状況になることを防ぎ、より健全な状態で作品のクオリティを上げる事ができます。
現在のゲーム開発の多くの現場では、プロジェクトのコントロールを失い、
統率が取れないことによってデスマーチ化し、メンバーの士気は低下、
その結果、クオリティの低下や人材の流出がいたるところで起こってます。
このような状況を生み出してしまう原因を考えてみると、
細かい理由は多岐に渡りますが、プロジェクトのマネジメントが甘いことが共通の大きな原因としてあるのではないでしょうか。
しかし、「ゲームデザインについて」の論議は頻繁に行われる中、
「ゲーム開発におけるプロジェクトマネジメント」という視点での論議は、
ほとんど行われていないのが現状です。
そこで「ゲーム開発におけるプロジェクトマネジメント」の具体的な方法として、
GAgileという開発手法を打ち立てていこうと考え、このサイトにまとめました。
現在ゲーム業界には“開発手法”という考え方が浸透してませんが、
業界に開発手法があると、次のような利点があると考えられます。
-知識が蓄積される。
-学習しやすくなる。
-改善のきっかけを与える。
-「プロジェクトマネジメント」というものを意識し、業界の中で議論が生まれる。
GAgileはあくまで数ある開発手法の一つですが、このような現状を打破し、
業界に開発手法について論じ合える場所を提供できればと考えて創り出したものです。
よって、読み手の皆さんが既に実践していることも多く含まれてると思いますが、
まとめるという意味も含めて基本的なことも記してあります。
GAgileは、GAgile自体を「みんなで成長させていく」というスタンスを取ってます。
これは私自身にすべてをわかるほどの経験がないことと、
現状の各個人・各企業のやり方が大きく異なっていて情報を集めようにも集められないという理由です。
なので、「協力してもいい」という方がいましたら、どんどん感想を送っていただければと嬉しいです。
(文中では言い切っている場合でも
2008-01-13T05:45:32+09:00
1200170732
-
用語
https://w.atwiki.jp/gagile/pages/14.html
**イ
-イラ(ira)
本サイトの造語。
バグではないが、ユーザーにわずらわしい思いをさせる不親切な仕様。
または、ゲーム的に面白くない仕様のこと。
**ウ
-ウォーターフォール(waterfall)
各工程を完全に終了後に次肯定へ移る、計画重視の開発手法。
最初に完璧に計画を立て、それ以降計画の変更は想定していないため、
仕様変更にかかるコストが高い。(よって、ゲームには向かない)
仕様変更が行われる可能性がほとんどないプロジェクトなら、
余計な見直しがない分、無駄がなく効率がよい。
工程がわかりやすく、見積もりがしやすいという利点もある。
----
2007-11-15T04:34:16+09:00
1195068856
-
アジャイル開発とGAgile
https://w.atwiki.jp/gagile/pages/13.html
tbd.
*ITとゲームの違い
ITの手法を参考にするに当たって、ITとゲーム開発の違いをまとめておきましょう。
言い換えれば、ITの手法がそのまま使えない原因ということになります。
主なものは次の要素です。
**求めるもの
ITが求めるのは「便利さ」。それに対して、ゲームが求めるのは「面白さ」です。
この違いが開発行程においてどう出てくるかというと、「面白さ」は「便利さ」よりも感覚的な部分があり、
実際に動かしてみて面白さを試してみることが必要になってきます。
よって、「テストプレイ」→「変更/追加」のサイクルがITよりも断然多くなるということです。
開発を振り返ってみても、特に開発後期は「テストプレイ」→「変更/追加」の繰り返しではないでしょうか?
**グラフィックとサウンド
リソースにおいてITとは全く違うのが、グラフィックとサウンドの重要度です。
IT開発の現場の人間(プロジェクトリーダー以下)を大きく分けると、
-プロジェクトリーダー
-SE(仕様設計)
-プログラマー
あたりになるのではないでしょうか。
(「アーキテクト」などの役職もありますが、ここでは大雑把に「SE」に含みます。
本職の方につっこまれそうですが……)
それに対してゲーム開発の現場の人間を大まかに分けると、
-ディレクター(プロジェクトリーダー)
-プランナー(企画・仕様設計・その他雑務)
-プログラマー
-グラフィッカー
-サウンドクリエイター
あたりになります。(会社によって名称の差異はありますが)
この二つで決定的な違いは、グラフィッカーとサウンドクリエイターの存在ではないでしょうか。
その二つのうちでも特にグラフィッカーに関しては、
工数的にプランナーとプログラマーを足した以上になるプロジェクトがほとんどです。
グラフィック素材は、インターフェイス系とゲームデータ系に大きく分けられます。
そのうちゲームデータ系の素材は、(大半のゲームでは)大量生産しなくてはなりません。
そのため、いくらGAgileが柔軟性を重視しようと、開発後期で「雰囲気を全般的に変えましょう」というのは、
(プログラムやバッチで対処できない場合は)対応できないでしょう。
これが、開発行程に大きく影響を与えます。
グ
2007-11-15T04:37:17+09:00
1195069037
-
履歴
https://w.atwiki.jp/gagile/pages/12.html
|2007/10/06|サイト作成|
----
2007-11-15T04:34:39+09:00
1195068879
-
memo
https://w.atwiki.jp/gagile/pages/11.html
*memo
test.
2007-10-06T22:49:02+09:00
1191678542