四方山話/同人ゲームを完成させるためのヒント/CCPM編

ここではCCPM（Critical Chain Project Management）をベースに説明する。基本編の差分のみ書いている。*1

CCPMの概要

• TOC（Theory Of Constraints；制約条件の理論）に基づく全体最適化されたプロジェクトマネジメント手法
• 各タスクを保護するのではなく、プロジェクト全体（クリティカルチェーン）を保護する点、プロジェクトの遅れと進みを後工程に伝搬させる点が最大の特徴
• 従来の（基本編で紹介した）手法に較べ、約25%工期を短縮できる
  • 工期短縮（スループット）を重視している。一方、コストワールドの指標（例えばリソースの稼働率）は重視していない
• 人間の行動心理・行動特性にも配慮している

例えば、基本編で使ったガントチャートは、CCPMでは次のように変わる。

ポイント

WBSを作るところまでは基本編とだいたい同じ。厳密には基本編ほど詳細にタスクを分解する必要はない。*2

シングルタスク

リソース（もっぱら作業者）の重複をなくし、リソースのパフォーマンスを最大限に発揮させる。

• 作業者に複数の作業を同時並行させるより、１つの作業に集中した方が作業効率は上がる*3

クリティカルチェーン

「作業工程上の従属関係」と「リソースが限られているために発生する従属関係」の双方を考慮した上で、最も時間的に長く掛かるタスクの繋がりのこと。作業完了に要する期間を決定する。

• クリティカルパスからリソースも重複しないようタスクを配置したものがクリティカルチェーンと考えれば良い

プロジェクトバッファ

プロジェクトを保護するための時間的余裕は、全てクリティカルチェーンの最後に配置する。これをプロジェクトバッファと呼ぶ。*4

• 時間的余裕の量がスケジュール上に現れるので、現場の不信感を払拭できる*5
  • 同時にプロジェクト遅延時の危機感も共有できる。
• 各タスクはギリギリの日数（予定通り完了する確率が50%）でスケジュールする
  • 予定通り完了する確率が90%程度の日数で見積もってもらい、バッサリ半分程度（正確には56%か）に調整するというのも手だ*6
• プロジェクトの遅れも進みも後工程に伝播させる
  • もし、クリティカルチェーン上のあるタスクが１日遅れたら、プロジェクトバッファを１日消費。以降のタスクが１日後ろにずれる
  • 逆に、１日早く完了したら、プロジェクトバッファが１日増加。以降のタスクが１日前倒しされる
• プロジェクトバッファの日数はクリティカルチェーンの50%程度を見込む
  • あるタスクの遅れは別のタスクの進みにより打ち消し合うため、プロジェクトバッファをクリティカルチェーンの半分の日数にしても納期を守ることができる（中心極限定理）
  • 従来の手法に較べて約25%工期を短縮できる

合流バッファ

• クリティカルチェーンに合流するチェーン（タスクの繋がり）がある場合、合流の直前に時間的余裕を設ける。これを合流バッファと呼ぶ
• 合流バッファは、非クリティカルチェーンで生じる遅れから、クリティカルチェーンを保護する
• 合流バッファの日数は合流するチェーンの50%程度を見込む
• 合流バッファを挿入すると、クリティカルチェーンより非クリティカルチェーンの方が長くなることがある。このような場合、合流バッファを短くする、タスクの配置を見直す、リソースを追加するなどして、ギャップ（クリティカルチェーン上の隙間）を取り除く*7

バッファマネジメント

• リーダーは、このプロジェクトバッファ／合流バッファの残り日数を管理する
  • バッファの消費ペースが速ければ、プロジェクトに何らかの問題が発生していることが判る
• プロジェクトを遅らせる人間の行動心理・行動特性を抑止
• 仮にタスクが遅れてもバッファで保護できる

その他

• 納期に間に合う限り、タスクはなるべく遅く開始する
  • プロジェクト進行中、何らかの問題が発生して、そのタスクが無駄になる可能性もある。タスク開始のタイミングさえ誤らなければ問題ない
• プログラムマネジメントに関しても配慮がなされている*8

CCPMのメリット

• 働く意欲を引き出す
  • タスクを早く完了させるため、チームワークの活性化、ノウハウ伝達の活発化が促される
• プロジェクトの進捗具合は、プロジェクトバッファの消費具合で簡単に把握できるようになる
• 従来の（基本編で紹介した）手法に較べ、約25%工期を短縮できる*9

CCPMのデメリット

• 従来の手法とは考え方がかなり異なるため、導入の敷居が高い
  • リレーランナーカルチャー
    • 前工程から仕事が来たら直ちに着手し、終れば直ちに次工程に渡す組織風土の形成が必要（必要なリソースに対しては作業開始日を何日か前からマメに通知、遅れが発生しないようにする）
    • 仕事を外注するときも、早期完了したらボーナスを与えるなどしてリレーランナーカルチャーに染める必要がある
  • 計画より遅れても担当者を叱責するなどペナルティを与えてはならない（怠けていたのでもない限り）
    • 遅れは普通に起きることとしてプロジェクトバッファに織り込み済みなので問題ない
• 可能な限り完璧なスケジュールが求められる
  • CCPMは最短期間でプロジェクトを完了させることを目標としており、頻繁なスケジュール見直しを想定していない
  • ソフトウェア開発（ゲームソフト含む）のように、要求（成果物）が不明確な状態で始まるプロジェクト、要求（成果物）が途中で変化しやすいプロジェクトには不向き
• CCPMに対応しているプロジェクトマネジメントソフトが少ない
  • 例：Microsoft Projectでは有料のアドオンがある

ノベルゲーム制作におけるアレンジ案

案なだけで後は各チームでアレンジすれば良いだろう。

デメリットに書いた通り、CCPMはソフトウェア開発（ゲームソフト含む）には不向きなため、反復型開発モデルの要素を一部取り入れることで欠点を補う。ポイントは以下の通り。*10

• 企画段階（企画、プロットやハコ書き、キャラ原案、設定…）までは従来と同じ方法で実施、実際の開発に入った段階でCCPMに切り替える*11
• イテレーション（反復）と呼ばれる短い期間単位（１～３ヶ月位）で、都度、何をどこまで実現するか目標を定め、WBSに分解し、スケジュールし、実際に作業して行く
  • つまりイテレーションとは短期間のプロジェクトである*12
    • イテレーション期間は１ヶ月、２ヶ月、３ヶ月のいずれか（一ヶ月刻み）
  • このイテレーションを何度か繰り返し、ソフトウェアを徐々に完成させていく
• プロジェクトバッファ、合流バッファは多めに確保しておく（早期完了が優先事項ではないので）
  • プロジェクトバッファの日数はクリティカルチェーンと同じ～それ以上でも構わない。合流バッファも同様

用語

学生症候群

締め切り間際になってから作業を開始する人間の行動特性。日本では一夜漬け

悪いマルチタスキング

複数（特に３以上）のタスクを少しずつ万遍なく進めてしまうこと。思考の切り替えや段取りに余計な時間を消費するため却って所要時間が延びる上に、経験曲線効果も働きにくい

早期完了の未報告（ソフトウェアエンジニアリング症候群）

タスクが予定より早く終わっても報告することなく、納期になるまで次工程に引き渡さない人間の行動特性（その間、成果物の見直しや品質の向上などをして日数を使い切ってしまう）*13

パーキンソンの法則

仕事の量は与えられた時間を全て使い切るまで膨張する（第一法則）…が本来の意味。プロジェクトマネジメントの世界では、与えられた日数をあるだけ使い切ってしまう人間の行動特性を指す