タグ : チームワーク

アジャイルソフトウェア開発手法を同人ゲーム開発の参考にしてみる

前回の記事で少しばかり触れたのですが、今回の企画はアジャイル開発を参考にした手法で進めています。 そもそもアジャイル開発ってなんぞや、というと
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。
アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。 (Wikipedia)
これってスパイラルモデルやプロトタイプモデルとどう違うの? という点はこちら。
アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する(⇒反復型開発)。 この反復のサイクルを継続して行い、1つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に1つの小さな機能を追加する。 計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。 (Wikipedia)
システム一式を反復したりプロトタイピングを行ったりするわけではなく、各機能ごとに分解して、そのひとつひとつを組み上げていくようです。 ●アジャイル開発のメリット そもそもなぜ今回アジャイルを参考にしたかというと、企画者である三尾狐さんが「最初はごく限られたマテリアルで、後々にパッチでキャラクターやルールを追加していく形にしたい」と要望したことがきっかけでした。
  • 小規模なプロジェクトに向いている 全体のシステムを機能ごとに小分けし個体が動作する状態でレビューしていく手法は、大規模なシステムで行うと各機能の統合に破綻をきたしたり、工程の進行によって全体像がぶれてしまって使い物にならなくなる可能性があります。規模の小さいシステムでは、製作前にウェイトの重い計画で時間を消費するよりも、まずは動くものを組んでみるほうがスピーディに進行できます。
  • 小規模なチームに向いている 人数の多いチームでは情報の伝達やコミュニケーション、個々のトラブルに全体が柔軟に対応することは難しく、どうしても製作前に充分な計画と厳密な管理に沿うことが必要です。アジャイルは文書化よりもとにかく会話を行い、変化する状況に各々が俊敏についていくことを目的としているため、規模の小さいチームに向いていると言えます。うちのサークルも大人数なために計画性重視で回してきたのですが、2チームに分離して経験豊富なメンバーがフットワークの軽い状態に推移したため、採用を検討しました。
●アジャイル開発のデメリット 上に書いた事柄の逆にもこんな危険が。
  • 個々が経験、コミュニケーション能力、プロジェクト管理能力に長けていないと破綻する “小規模でフットワークが軽く”ということは、個々が対応しなければならないケースが激増します。大規模なプロジェクトでは自分はこの担当だからこれに特化していればいいわけですが、アジャイルになるとそうはいきません。 またドキュメンテーションよりも会話が重視されるため、意思疎通がうまく行えない場合はあちこちでちぐはぐな動きが見られるようになります。 同様に、個々は自分の作業だけを注視するのではなく 常に全体像を掴みながら自分の立ち位置や動き方を調整しなくてはなりません。誰々の作業がまだ終っていないから、という言い訳は通用しなくなりますね。
  • 協動せずに各自が好き勝手に行動する可能性がある カウボーイコーディングと言われますが、変化に柔軟であることと各々が好き勝手やることは全く異なります。上にも関係しますが、常に全体の連動を意識して動いていないと、足踏みの揃わない4人5脚のようになってしまうかもしれません。
  • 固執すると品質が劇的に落ちる 機能を何度か反復開発し、結果的に合わない時はばっさりと破棄してしまうことが必要です。ここまでやったんだから! これがないと次のアレが! と固執すると、結局最初からきちんと計画したほうが良いという状況になります。
●ゲーム開発にアジャイルを適用するメリット じゃあアジャイルをゲーム開発に適用するとどんないいことがあるんでしょう。
  • 同人サークルの形態に合っている 同人サークルは大抵数人、ゲームサークルでも4~5人と比較的少人数です。
  • モチベーションを維持しやすい 難解な書類よりも先に動く物や見える物が仕上がります。ビジネスや勉強でもグラフやチャート化すると意識が向上するように、目に見えるものが出来てくることはモチベーションの向上に繋がります。ゲーム開発はとにかくコツコツと根気よく作業しなくてはならないものなので、はっきり分かる進捗や成果物があると順調に進められる確立は高くなります。
  • 定期的にリリースでき、プロモーション効果も上がる 小刻みに成果物が出来てくるわけなので、その情報やデータを短いスパンでかつ小刻みにリリースすることができるかもしれません。ネタがあるということは、それだけ定期的にアクセスしてもらえる確率も高まります。
  • 開発が早い どこかで「WEBサービスはβのうちから公開しなさい」というフレーズを見たことがあるのですが、アイディアが古びたり先取りされないうちに出してしまえということだそうです。同人ゲームも絶対数が少ないだけに同じジャンルで被ると結構気まずいものです。
  • コミュニケーションの質があがる 各部についてレビューを繰り返すため、ミーティングの質は高まり各自のコミュニケーションも深まります。 監督や制作進行が中心に立って1対1の対応を繰り返すのではなく各々が対応しあうことによって、チームワークも向上するかもしれません。
  • 作ってみないと判らない事に対応できる ゲームはいざ動かして細かくチューンしてみないと判らない部分が沢山あります。アジャイルだと基本的な処理の上に「こんな機能はどうだろう」と提案したものを途中でくっつけていくことが出来ますし、 一つの機能開発を反復して品質を高めていくことができるので、実際に動かして効果を確かめつつ開発ができるメリットがあります。
とまぁこんなことを挙げてみました。 同人ゲームの場合はプログラマ以外にもイラストレーターやコンポーザーも入ってくるので、そのまんまアジャイルの手法を適用できるわけではありませんし、厳密にアジャイルの定義に沿っているわけではありません。しかし参考にしてみるのはなかなか面白いと思います。 では実際にどのようにアジャイルの手法を組み込んでみるのかはまた次回。

「プログラマーができる、制作現場に大切な事」

ベヨネッタ、バンキッシュなどを制作しているプラチナゲームズのプログラマブログに興味深い記事がありました。 プログラマさんじゃなかったとしても、チームやサークルで制作している方にはとてもためになる内容です。
無くてもできる物はどうするの? 無いと正直困ると言われた物だけ作ったりしていませんか?
と、最初にこのような問いかけが。 うーん、うちもよくあることです。言われてないからやらない、出来ないは多々ありますね。
プログラマーが作業いっぱいいっぱいで、無くても作業できる物なんて頼みに来るなオーラが出ていると、 他の人は、 「時間かかるけど、まぁできなくは無いからいいか。」 「別にそこまで必要でもないか」 となります。頼みにきません。これはとても残念な事です。
こういった物は、実は毎日時間を取られているんだけど気にしていない場合が多々です。 そういった問題に、プログラマーから歩み寄って欲しいと思います。
ですから、話をするなりしてそういう問題に対してアンテナを立てましょう。 「この作業みんな、本当にこのまま使ってるの?面倒くさいよなぁ。どう思ってるか聞いてみるか」 「そういえば、最近作業で面倒くさい事ってないの?」 「あぁ~これ面倒くさい。ツール作る時間無いし。フリーツールとかないかな?」 「あったら便利だけど。今自分に作る暇がない。ちょっと上司に相談しよう」
自分から改善を提案してみたり、提案するための情報や素材を探してみたりすることはとても大切ですね。
プログラマーから始めてみてはいかがですか? そうすれば、よりいい物を作る為の時間が生み出せるはずですよ?
と締めくくられていました。うん、ちょっと頑張ってみます。