読者です 読者をやめる 読者になる 読者になる


ドラクエXとアジャイル

読み返してみて興味があったので、いくつか引用。

「ドラクエXのようなトリプルA級タイトルの開発スケジュールは最初から組み替えることが前提。イレギュラーな事案が発生するのは大規模開発では当然のこと。
 :
100名を超えるような大規模プロジェクトの場合、人数に比例したパフォーマンスを出すことは、ほぼ無理だと言っていいだろう。荒木氏は「100名を超えると、個々のスタッフがプロジェクト全体を把握するのが困難になり、スタッフ間で食い違いが生じやすく、結果としてゴールを共有できない事態になりかねない」と指摘。
 :
開発期間中に生じるリスクを最小限にするには、作りながら細かく評価を行い、時には大胆な仕様変更をもいとわない姿勢がマネージャには求められる。実装と評価の短いスパンを繰り返しながら、不確実なゴールを少しずつ目に見えるようにし、ゲームの品質を高めるために、荒木氏はアジャイルを開発手法として選択した。

大規模だけど変更が入ることが前提となると、やはり短いスパンで少しずつ仕上げていくのが一番か。

で、実施する際に4つのポイントにフォーカスしたとのこと。
バッファをもたせる、というのは確かに重要。あとはどこまで見積もれるかがその人の手腕が問われるところ、か。
新規開発だと比較的人員を投入できることが多いのでその辺りの調整は柔軟にできそうだが、ジリ貧の運用や開発だとなかなかバッファを取ることすら難しいのが現実でもあるが。。

  1. 毎日15分のミーティング(スクラム … 状況が刻々と変わるゲーム開発だからこそ、毎日の手間を惜しまず状況確認を。スタンディングでもOK。イテレーションごとにオーダーを見直す習慣を
  2. 優先度にのっとったタスク管理(狩野モデル) … オーダーに優先順位を付け、ラストまでの工程を明らかにし、本当に必要なことに注力する体制を保つ。内製のタスク管理データベースを使ってWebベースでタスク管理
  3. バッファコントロールでリスクヘッジ(CCPM) … 実装タスクをかつかつに見積もると、バグの手戻りなどに対応できない。タスクを2点で見積もり、バッファを持たせる。バッファの減り具合でリスクを管理
  4. ロードマップ … 状況に応じてロードマップを書き換えながら進める。ロードマップは"人"ベースで作成。人員の移動などもロードマップで確認。ロードマップもバッファ管理で。スタッフに安心感を与えるためにもロードマップの公開/共有は重要