開発日程表をつくるです

見ていただくとわかるのですが、結構余裕のあるスケジュールになっています。

スケジュール表

余裕あるスケジュールの理由は

• トラブル発生を見越す
• 仕様詳細が確定していないので、ある程度余裕をもたせる
• α版提出の段階で、方針転換や仕様変更があるかもしれない

というかんじで、いわゆる「バッファ」という奴です。

人月の神話とか読むとわかりますが、開発時のスケジュールは単純に「やばくなったら人増やせば良い」ではすまない事なんですよね。

マイルストーン毎に最適な人数とかスケジュールがありますんで、マイルストーン毎に工数見積もりをして、それにあわせた余裕をもったスケジュールを組まないと、ほぼ間違いなくコアラのデスマーチになる、と経験してますです。

スケジュール表からわかるスタッフの状態

あと、スケジュール表を見るとスタッフがどの程度具体的にプロジェクトを把握しているかがわかりますです。

詳細にわたってスケジュールがたっている人ほど、具体的に実現までの手法や工数の見積もりができていますです。逆にスケジュールが曖昧な人は、いまいち何をして良いのか仕様を理解していないのか、解決手法や実現方法を思いついてない事がわかります。どの作業も日数が均一なガントチャートになっている人は、工数の見積もりが曖昧な可能性がありますです。

なのでディレクターやプロデューサーはスケジュール表を見て、どのセクションに問題があるのかを早期に発見する事が可能で、早めに担当者に確認をとって作業を具体化させる手をうてるようになりますです。

今だと、プログラマーさん達が曖昧な所が多いので、仕様と開発方法について早急に打ち合わせをして方法や問題点を確認しなければなりませんです。

「色々あるけど上手い事やって」とか「そこはいい感じでよろしく」とか「じゃ、そーゆー事で」とか、フラグを立てれば立てる程、はまる数が増えますんで、極力フラグを立てないようにはっきりさせんといかんです。

フラグは嘘つかないです。

つづく