前回、WBS分解まで出来ました。この作業項目から作業工数を策定して、どのような作業順序などを決めていくかを説明していきます。


  • 作業工数策定
既に以前説明した通り、私は開発作業工数見積りの際に、順調な工数、標準的な工数、ハマッた場合の工数を提出するように、作業担当者に依頼しています。以下は作業項目毎に私が想定した作業日数となります。
プログラム工数1
リソース工数1
作業日程の策定にはエクセルを使います。グルーピングするため、共通とかタイトルデモとかのタイトルに相当する項目の日数は、数値入力せず =sum(..) で日数の自動加算値表示とします。上記の図では強調項目が自動計算に相当します。そのため、日数の加算設定は少しだけ細かい指定が必要となります。


  • 作業の危険地帯
プログラム工数の「ハマり」作業日数に赤い場所と黄色い場所があります。赤い場所は順調と標準に比べて、明らかに日数が追加されている項目です。この作業項目にはプログラマが何かしら不安を抱えいてる要素が存在する事になります。あるいは作業そのものが具体的に見えていないのかもしれません。いずれにせよ、これら作業項目は要事前調整項目となります。
危険地域
黄色い場所は、若干工数を大きく取っている項目です。これはプログラマがもしかすると手こずるかもしれないと警戒している様を表しています。このような警戒作業項目は順調を選択してはいけません。かといって、作業を申告通り大きめに取るのもオススメしないです。なぜなら余裕があると油断するのが人間だからです。
警戒項目
このような場合、私は赤い項目は標準より大きめに予定を取りますが、黄色の場合はほとんどが標準日数を採択します。これはプログラマが提示する日数には、かならずバッファが含まれているためです。順調とした日数でも僅かに大きめに出してきます。だからといって、予定をギリギリで立てろというワケではありません。そこで大事になるのが予備日の設定です。


  • 予備日
タイトルデモとか、パックマンとか、大きな作業項目がありますよね。その大きな作業項目毎に予備日を設定します。順調に開発が進めば、予備日はプログラマが自由にして良いという事にします。休んでも良いです。自由研究しても良いです。ただ、もしも予定が押した場合は、その予備日を使うよと話をしています。
予備日
結果としては、トータルでかなりの余裕を入れ込む事になりますが、作業に対してではなく、全体に対して予備日とする事で、プログラマのやる気を促進します。作業項目が余裕だと集中力は落ちます。でも、作業の節目に自分が好きに出来る時間があるとしたらどうでしょうか。

さらに、全体的に作業が押してきたときも、その予備日を使います。予備日を他の作業予定から移動してきたりするのです。この予備日というクッションで全体工数を可能な限り守るようにしています。また、予備日を早い段階で使い切るような事態になった場合は、最初の作業予定の策定に問題があったということなので、早い段階で見直しをかけます。それは、人を増やしたり、時間を増やしたり、仕様を削ったりです。

なお、グラフィックデザインやサウンドに関しては、予備日と記載せず調整と記載すると、皆さんから納得してもらいやすいです。


  • 作業日数を決定する
担当から提出された工数を元に、工数策定者(主にディレクター)がヒアリングを行い、作業工数を決定します。日数の決定では、ヒアリングの結果の印象や、自分の経験則も加味します。結果としては必ず提出された標準工数よりトータルでは大きくなります。それで良いと納得してください。これで、各所に安全を見越した作業工数割り当ての叩き台が出来ます。
調整後のプログラム工数
調整後のリソース工数
この決定した工数をさらに担当者に見てもらい、不安点や疑問点を事前に見てもらいます。その上で、全ての担当には、作業中にこの日数ではマズイと感じたときにはすぐに相談して欲しいと念押しします。作業が遅れる事より、遅れそうな事を報告されない方がお互い困るのだと、プロジェクトの開始時には何度でも説明します。

この時点ではまだ担当者は確定ではない事も伝えます。理由は後で述べます。ここまでの解説で作成したエクセル(ods)サンプルをご用意しました。グループ毎の日数加算の計算式辺りは参考になるのではないでしょうか。

次回、プロジェクト管理に続きます。