コンサルタントだろうがエンジニアだろうが、複数人で期限のある仕事をするとなると、タスクを振り分け、スケジュールを引いて複数のメンバーが、ひとつのゴールに向かって作業をするということが必要になります。この書き方は人それぞれだと思いますが、私はPMOも経験したこともありますので、どのような視点で引いているかを参考までに記載させていただきます。

目次

• タスクは細分化した上で、表記レベルを考える
• 作業難易度×ボリューム×担当者のレベルで工数を考える
• バッファーの有無もきちんと考えておく
• スケジュールの前半でスケジュールの立て方に問題が無かったかを検証し、必要なら最適化をする
• 担当者はぎりぎりまで設定しない

タスクは細分化した上で、表記レベルを考える

スケジュールなんて大まかにひいても問題ないわあとか、どうせ後で見直すことになるんだから適当にひけばいいんだぁとか、無能とはいいませんが、無責任な管理者は、スケジュールをかなりおおざっぱにひいてしまいます。

お客さんが言う、ゴールの期限、期日にあうようにスケジュールを引く。そうやって、デスマーチや、うつ病患者、パワハラ天国を作ってしまった、無責任な管理職は、そろそろ退出願いたいそんな時期かと思います。

さて、スケジュールを考える上で大事なのは、作業を細かく考えていくことです。

細かければ、細かいほどいいと思います。

というか、細かく考えなければ、想定外の作業ばかりで、見積もり根拠なんてかけないのですからね。開始段階で、細かく作業内容まで考えるのが設計者・開発者にもやさしいプロというものです。

例えば、ECサイトで商品の選択から購入までのシステムを考える時、画面がどれだけ必要かの数を考えます。処理の内容も数えます。

その作業をするにあたって、必要となる、データ調査や、既存設計書の読み込み調査、新技術の調査などがあるなら、それも別タスクにします。

そうやってタスクを細かく細分化した後で、初めて、スケジュールの記述レベルを考えることができます。

調査タスク、設計タスク、開発タスク。

WBSといったスケジュールの記載単位というのはそもそも作業を報告するときに必要な単位であることが多く、期限を守るための単位というのとまた違うところにあることが多いのです。

進捗での報告レベルでスケジュールをひこうとするのはわかりますが、中身の作業の量を大まかに見積もり、数字の裏付けのないスケジュールは、必ず破綻します。

さじ加減や自分は中身を理解していると、おおまかに見積もったスケジュールは後で効いてきます。

作業難易度×ボリューム×担当者のレベルで工数を考える

作業の工数を考えるとき、どのように考えればいいのでしょうか？

難易度３だから、工数は3日で。難易度１だから、工数は１で。のような引き方を多くの人はすると思います。

たしかにそれは正しかったのですが、果たしてそれが今後も通用するだろうか？というのが、私の最近の疑問です。

スケジュールというのは、ゴールがあるからひくのです。目的があるからひくのです。期限があるからひくのです。

そう考えたときに担当者の能力を考慮しなくてよかった時代はすでに終わっています。

うつ病が蔓延し、時短の方もいるし、おまけに人不足の時代で、スケジュールを考える時、担当者のレベルや状況も考えてスケジュールを引きます。

そうやってはじめて、スケジュールが間に合うかどうかが見えるわけです。

それがプロジェクトの本来の管理でもあります。

バッファーの有無もきちんと考えておく

私が初めてスケジュールをひいたころは、とりあえずバッファーは1週間入れろよ！って上司に言われたものでしたが、どんだけどんぶり勘定だったんでしょうか？

すでに書かせていただいた通り、スケジュールを細分化したときに、というか、細分化した時点で、どんな問題が出てくるのかが見え始めます。

担当者の休み、担当者の進捗がスキルアンマッチで遅れる、想定外の作業が入る。など

プロジェクトをやっていくうえで、見えないことがあるからこそのバッファーですが、何が見えてないか、見えてくるのかを考えて、バッファーというものは弾くべきであり、何も考えずにバッファーをひくのであれば、それは怠けてるだけではないでしょうか？

スケジュールの前半でスケジュールの立て方に問題が無かったかを検証し、必要なら最適化をする

スケジュールは工数の積み上げです。そして、工数の積み上げだからこそ、掛け算をすれば、すぐにスケジュールは見直されます。

1日で見積もった工数が、実際にタスクをやったら１．５かかったとなったら、1.5倍で等しく見積もる必要があります。

担当者はぎりぎりまで設定しない

担当者を最初の段階で割り振ると、でてくるのは自分以外の作業はやらないということです。