同人活動に役立ちそうな実験・創作・メモノート

前回の記事で少しばかり触れたのですが、今回の企画はアジャイル開発を参考にした手法で進めています。 そもそもアジャイル開発ってなんぞや、というと

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。 （Wikipedia）

これってスパイラルモデルやプロトタイプモデルとどう違うの？ という点はこちら。

アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1つの反復 (イテレーション) で1機能を開発する（⇒反復型開発）。 この反復のサイクルを継続して行い、1つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に1つの小さな機能を追加する。 計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。 （Wikipedia）

システム一式を反復したりプロトタイピングを行ったりするわけではなく、各機能ごとに分解して、そのひとつひとつを組み上げていくようです。 ●アジャイル開発のメリット そもそもなぜ今回アジャイルを参考にしたかというと、企画者である三尾狐さんが「最初はごく限られたマテリアルで、後々にパッチでキャラクターやルールを追加していく形にしたい」と要望したことがきっかけでした。

• 小規模なプロジェクトに向いている 全体のシステムを機能ごとに小分けし個体が動作する状態でレビューしていく手法は、大規模なシステムで行うと各機能の統合に破綻をきたしたり、工程の進行によって全体像がぶれてしまって使い物にならなくなる可能性があります。規模の小さいシステムでは、製作前にウェイトの重い計画で時間を消費するよりも、まずは動くものを組んでみるほうがスピーディに進行できます。
• 小規模なチームに向いている 人数の多いチームでは情報の伝達やコミュニケーション、個々のトラブルに全体が柔軟に対応することは難しく、どうしても製作前に充分な計画と厳密な管理に沿うことが必要です。アジャイルは文書化よりもとにかく会話を行い、変化する状況に各々が俊敏についていくことを目的としているため、規模の小さいチームに向いていると言えます。うちのサークルも大人数なために計画性重視で回してきたのですが、2チームに分離して経験豊富なメンバーがフットワークの軽い状態に推移したため、採用を検討しました。

●アジャイル開発のデメリット 上に書いた事柄の逆にもこんな危険が。

• 個々が経験、コミュニケーション能力、プロジェクト管理能力に長けていないと破綻する “小規模でフットワークが軽く”ということは、個々が対応しなければならないケースが激増します。大規模なプロジェクトでは自分はこの担当だからこれに特化していればいいわけですが、アジャイルになるとそうはいきません。 またドキュメンテーションよりも会話が重視されるため、意思疎通がうまく行えない場合はあちこちでちぐはぐな動きが見られるようになります。 同様に、個々は自分の作業だけを注視するのではなく 常に全体像を掴みながら自分の立ち位置や動き方を調整しなくてはなりません。誰々の作業がまだ終っていないから、という言い訳は通用しなくなりますね。
• 協動せずに各自が好き勝手に行動する可能性がある カウボーイコーディングと言われますが、変化に柔軟であることと各々が好き勝手やることは全く異なります。上にも関係しますが、常に全体の連動を意識して動いていないと、足踏みの揃わない４人５脚のようになってしまうかもしれません。
• 固執すると品質が劇的に落ちる 機能を何度か反復開発し、結果的に合わない時はばっさりと破棄してしまうことが必要です。ここまでやったんだから！ これがないと次のアレが！ と固執すると、結局最初からきちんと計画したほうが良いという状況になります。

●ゲーム開発にアジャイルを適用するメリット じゃあアジャイルをゲーム開発に適用するとどんないいことがあるんでしょう。

• 同人サークルの形態に合っている 同人サークルは大抵数人、ゲームサークルでも4～5人と比較的少人数です。
• モチベーションを維持しやすい 難解な書類よりも先に動く物や見える物が仕上がります。ビジネスや勉強でもグラフやチャート化すると意識が向上するように、目に見えるものが出来てくることはモチベーションの向上に繋がります。ゲーム開発はとにかくコツコツと根気よく作業しなくてはならないものなので、はっきり分かる進捗や成果物があると順調に進められる確立は高くなります。
• 定期的にリリースでき、プロモーション効果も上がる 小刻みに成果物が出来てくるわけなので、その情報やデータを短いスパンでかつ小刻みにリリースすることができるかもしれません。ネタがあるということは、それだけ定期的にアクセスしてもらえる確率も高まります。
• 開発が早い どこかで「WEBサービスはβのうちから公開しなさい」というフレーズを見たことがあるのですが、アイディアが古びたり先取りされないうちに出してしまえということだそうです。同人ゲームも絶対数が少ないだけに同じジャンルで被ると結構気まずいものです。
• コミュニケーションの質があがる 各部についてレビューを繰り返すため、ミーティングの質は高まり各自のコミュニケーションも深まります。 監督や制作進行が中心に立って１対１の対応を繰り返すのではなく各々が対応しあうことによって、チームワークも向上するかもしれません。
• 作ってみないと判らない事に対応できる ゲームはいざ動かして細かくチューンしてみないと判らない部分が沢山あります。アジャイルだと基本的な処理の上に「こんな機能はどうだろう」と提案したものを途中でくっつけていくことが出来ますし、 一つの機能開発を反復して品質を高めていくことができるので、実際に動かして効果を確かめつつ開発ができるメリットがあります。

とまぁこんなことを挙げてみました。 同人ゲームの場合はプログラマ以外にもイラストレーターやコンポーザーも入ってくるので、そのまんまアジャイルの手法を適用できるわけではありませんし、厳密にアジャイルの定義に沿っているわけではありません。しかし参考にしてみるのはなかなか面白いと思います。 では実際にどのようにアジャイルの手法を組み込んでみるのかはまた次回。

ベヨネッタ、バンキッシュなどを制作しているプラチナゲームズのプログラマブログに興味深い記事がありました。 プログラマさんじゃなかったとしても、チームやサークルで制作している方にはとてもためになる内容です。

無くてもできる物はどうするの？ 無いと正直困ると言われた物だけ作ったりしていませんか？

と、最初にこのような問いかけが。 うーん、うちもよくあることです。言われてないからやらない、出来ないは多々ありますね。

プログラマーが作業いっぱいいっぱいで、無くても作業できる物なんて頼みに来るなオーラが出ていると、 他の人は、 「時間かかるけど、まぁできなくは無いからいいか。」 「別にそこまで必要でもないか」 となります。頼みにきません。これはとても残念な事です。

こういった物は、実は毎日時間を取られているんだけど気にしていない場合が多々です。 そういった問題に、プログラマーから歩み寄って欲しいと思います。

ですから、話をするなりしてそういう問題に対してアンテナを立てましょう。 「この作業みんな、本当にこのまま使ってるの？面倒くさいよなぁ。どう思ってるか聞いてみるか」 「そういえば、最近作業で面倒くさい事ってないの？」 「あぁ～これ面倒くさい。ツール作る時間無いし。フリーツールとかないかな？」 「あったら便利だけど。今自分に作る暇がない。ちょっと上司に相談しよう」

自分から改善を提案してみたり、提案するための情報や素材を探してみたりすることはとても大切ですね。

プログラマーから始めてみてはいかがですか？ そうすれば、よりいい物を作る為の時間が生み出せるはずですよ？

と締めくくられていました。うん、ちょっと頑張ってみます。

  先日CyberCubeのサイトをリニューアルしたのですが、その直後にInternetExplorer8が正式リリースされてしまいました。 IE7で動作確認、ご覧の際は最新版をご利用くださいなんてフッタに書いちゃったのに、もう最新版はIE7からIE8になっているではないですか。参ったなぁ。 一応βからIE8は仕事用にインストールして使ってはいたんですが、出来るだけ正式版出るまで触りたくないんですよね、ブラウザって……。というか、ブラウザ対応自体がもうコーダーに取っては鬱陶しいものです。１個だけならどんだけ楽か。 とりあえず今は時間が無いので、そのうちIE8とFirefoxくらいには対応させたいと思います。 あと自分がChromeユーザなのでそっちにも対応させたいですね。前回のデザインはIE以外全滅でしたので、今回はある程度のブラウザに対応させていくつもりです。

 意外にゲーム制作には大量の書類が発生します。 企画書、設計書、仕様書、発注書、素材管理表、脚本をはじめ、細分化していくとキリがありません。 なかでも困るのが、制作が進むにつれどんどん書き込みが増える書類。 常に全員に最新版が行き渡ればいいのですが、誰がどのバージョンを持っているか管理して配布して、という作業はかなり大変です。 そこで、オンラインで共有・編集できる、GoogleDocsを試験的に使ってみました。 ブラウザ上で、WordやExcelデータを共有でき、編集もできる無償サービス。アカウントも、閲覧のみのユーザと編集できるユーザと分けられ、外部公開したい場合はファイルをWEBページとして公開することもできます。 共有方法は実に簡単。各スタッフにアカウントを取得してもらい、オーナーはそのスタッフに共有招待メールを送信するだけです。スタッフはその招待メールのリンクをクリックすることで、ファイル共有に加われます。 ファイルが更新された場合には、オーナーに「変更された」旨の通知メールが届きます。 エクセルデータを１つ置いておき、スタッフの作業ログ的なものにも使えそうです。 ただ問題は、Excelデータの場合1MBまでしかアップロードできないこと。 そして、画像は一度どこかのサーバにアップロードし、URLで外部リンクさせないと表示できないらしいことです。 今回はスクリプタ向けの仕様書を共有し、実際に制作に使用しているのですが、インターフェース（画面）の組み上げは、デザイナーがスクリプタ向けに指示するレイヤー構造のサンプル画像を見て行うのに、その画像のアップに手間がかかるようになってしまいました。 これじゃ普通に配布したほうが早いよ、というクレームが来ております。ううむ……。 原画さんやデザイナー向けの書類は、色々と制限に引っかかってしまいそうな予感がします。 結論： シナリオや内部設計書などには便利かもしれません。かといって、外部設計の画面遷移図のように、チャートの画像などが入ってくるとやっかいですが……。 とりあえず、プログラマとライターについてはこのままGoogleDocsの使用を継続することにしてみます。