ウォーターフォール型開発モデルの問題点
ウォーターフォール型開発モデルの特徴は以下を前提としている点である。
- 前工程に間違いがない
- 作業項目やコストの詳細な見積もりが可能で、かつ詳細なスケジュールも可能
- プロジェクトに変化の度合いが少ない
- 事前に予測できなかった変化への適応は想定していない(せいぜい作業日数に余裕を持たせる程度)
実際にはウォーターフォール型開発モデルが適合しにくいプロジェクトもある。ソフトウェア開発(ゲームソフト含む)はその一つである。*1適合しにくい理由は以下の通り。
- 作業に創造性が求めらる
- 前例のない作業が多い
- 要求(成果物)が不明確な状態でプロジェクトが始まる
- プロジェクトの途中で要求(成果物)が変化しやすい
このようなプロジェクトに対応するため、反復型など様々な開発モデルが考案されている。ここでは反復型開発モデルの流れを汲むアジャイルソフトウェア開発(以降、アジャイル開発)について説明する。*2
アジャイル開発の概要
アジャイル開発の流れは概ね次のようになる(手法によって多少変わる)。詳細は各アジャイル開発手法を参照されたい。
- イテレーション(反復)と呼ばれる短い期間単位(1週間~1ヶ月位)で、リリース可能なソフトウェア(きちんと動作するもの)を開発する
- このイテレーションを何度も繰り返し、ソフトウェアを徐々に完成させていく
- 機能を積み上げて行くわけだが、必要に応じてリファクタリングも行う
- 無制限な仕様変更は許していない(芯から外れないように)
- このイテレーションを何度も繰り返し、ソフトウェアを徐々に完成させていく
- 1度のイテレーションで、計画、要求分析、設計、実装、テスト、文書化といった、ソフトウェア開発プロジェクトに必要な全ての工程を行う
- つまりイテレーションとは短期間のプロジェクトである*3
- テストを何度も行うため、ビルドやテストなど定型作業の自動化が必須となってくる
- プロジェクト進行尺度は実際に動くソフトウェアそのもので示す
- バーンダウンチャート(縦軸を残作業項目数、横軸を経過日数としたグラフ)やスプリントバックロググラフ(縦軸を推定残作業時間、横軸を経過日数としたグラフ)で大体の状況が掴める
- WBS、PERT図、ガントチャートのようなものは書かない*4
- タスクリスト(必要な機能の一覧表で優先順位を付けたもの)で代替する
- 優先順位の高い項目から開発して行く
- (タスクリストの)項目は1度のイテレーションで開発できる範囲内に収まっていること。*5収まっていなければ掘り下げ分解する
- イテレーション開始時、タスクリストから開発対象となる項目を切り出し、イテレーション終了時までに完成させる
- 残りのタスクリストは、プロジェクト期間中、随時更新される
- 期限が定められているなら、優先順位の低い項目を切り捨てることになる
- タスクリスト(必要な機能の一覧表で優先順位を付けたもの)で代替する
- その他、従うべきプラクティス(習慣、業務)を定めている
- 身軽さ(メンバーは5~10人程度)、密なコミュニケーション、チームの自律性を重視。シンプルさを重視
- 価値が高いドキュメントのみ文書化する
- 毎日、10数分程度の会議を行い、進捗報告する
- イテレーション開始時に(↑よりもっと長い)会議を行い、タスクリストの調整を行う
なお、最も普及しているアジャイルソフトウェア開発手法はSCRUM、SCRUMとXPのハイブリッド*6、XP(Extreme Programming)である。この内、SCRUMとXPは国内でも情報を入手しやすい。*7
アジャイル開発のメリット
- リスクが低い
- プロジェクト成功の可能性が高まる、生産性・品質が高まる、欠陥が少なくなる
- 現在のイテレーションのみ扱うため、進捗管理しやすく、予測精度も高まる
- イテレーションが短いため、パーキンソンの法則(与えられた日数をあるだけ使ってしまう人間の行動特性)や学生症候群(締め切り間際になってから仕事を始めてしまう人間の行動特性)も発現しにくい
- 早い段階から動作するソフトウェアを目で見て確認できるので、達成感を得やすい。フィードバックを引き出しやすい
アジャイル開発のデメリット
- アジャイル開発を理解していないリーダーに、アジャイル開発の指揮は困難
- 当たり前の話だが、事実、これが原因で失敗したプロジェクトはいくらでも存在する
- 大体どの手法でもアジャイル開発の経験者をリーダーに据えることを推奨している
- チームメンバー1人1人に様々なスキルが求められる
- 分野によって得手不得手がある程度ならともかく、○○専任といった縦割りチーム構成はアジャイル開発に不向き
- プロジェクト開始時、コストやスケジュールの確定が不可能
- 条件次第だが仕事を外注しにくい*8
ノベルゲーム制作におけるアレンジ案
案なだけで後は各チームでアレンジすれば良いだろう。
- 企画段階(企画、プロットやハコ書き、キャラ原案、設定…)までは従来と同じ方法で実施、実際の開発に入った段階でアジャイル開発に切り替える
- 予めメンバー全員でタスクリスト(必要な機能・素材の一覧表で優先順位を付けたもの)も作っておく
- タスクリストは、多少、大雑把で構わない(完全なものは予想できないし、イテレーション内に収まらないボリュームなら掘り下げ分解するだけのこと)
- 縦割りチーム構成となるため、作業ペースのバラつきは避けられない。バラついても作業が進められるよう、事前に作業内容をある程度まで詳細化した方が良い
- ノベルゲームはシナリオ中心のゲームである。シナリオが定まらないと他の作業も定まらない(進められない)。シナリオ以外の担当者が手隙になるのを防ぐ必要がある
- 優先順位付けはリーダーが行う
- タスクリストはシナリオ用、画像素材用、スクリプト用…などに分ける
- タスクリストは、多少、大雑把で構わない(完全なものは予想できないし、イテレーション内に収まらないボリュームなら掘り下げ分解するだけのこと)
- イテレーション期間は1週間、2週間、3週間のいずれか(一週間刻み)
- メンバー全員のリズムが取りやすい期間で
- 重要なのはリズムを変えない(イテレーション期間を変えない)こと
- 縦割りチーム構成は受容せざるを得ない
- 何でもできるメンバーがいるなら、それはそれで有難い話だが…
- テストの自動化はほとんどできないため、シナリオの分岐、演出の確認などはマンパワーに頼らざるを得ない
- 無償~安価で絞ると自動テストのためのツールはほとんどない(元来、GUIの自動テストは難しいもの)
- UWSCやEventGhostを使うくらいが関の山か。使える局面も限られるので大して役に立たない
- 無償~安価で絞ると自動テストのためのツールはほとんどない(元来、GUIの自動テストは難しいもの)
- インパクトの大きいリリース(例えば○○章が完成とか××ルートが完成とか)時、メンバー全員または第三者(メンバーの友人知人など)にクローズドで評価してもらい、フィードバックを得る
- あまり頻繁に評価してもらうと新鮮味が薄れ、飽きられるので注意
- メンバーに評価してもらう場合は、1週間くらい作業を中断するなど柔軟に対処したい
- 会議は2種類実施する
- イテレーション開始時
- (前回のイテレーション終了時にレビューを行い)タスクリストに項目を追加する、イテレーション内に納まるようタスクを掘り下げるなど調整を行う
- 毎日10数分
- 「前回から何をやったか」「発生しそうな/発生した問題は何か」「これから何をする予定か」を報告する
- 本業の都合で参加できない場合は、事前に出られないことをリーダーに報告する
- 毎日が無理な場合は、2~3日おきに会議を実施するなどメンバーの都合に合わせて調整したい
- イテレーション開始時
ここで重要なのは「ノベルゲーム制作でのボトルネックはシナリオである」ことである。立ち絵やイベント絵、BGMや効果音が少々なくても、演出が物足りなくても、コンフィグ画面が実装されていなくても、シナリオさえ完成してれば何とかプレイに耐えられる。*9
故に、どんな形であれシナリオが完結している必要がある。「序盤を完成させ、中盤を全て完成させ、終盤を全て完成させる」ような作業の仕方より、「○×ルートを最優先で完成させる」ような作業の仕方の方が良い。*10