初めてのスケジューリング

こまつ みつのり(Mitsunori Komatsu) 2007-10-08 21:32:24

ある程度仕事をこなしてくると、上司から、「あなたの担当作業についてスケジュール出してください」と指示されることがあるかと思います。私も新人の頃、初めてのスケジュール作成を行いましたが、そのときはとても混乱しました。だって、未来のことは確実にはわかりませんよねぇ。さらに、自分の作業についてなので「こんなに余裕をもったら、パフォーマンス低っ!と驚かれるかなぁ」とか「でもスケジュールをオーバーしたら怒られるかなぁ」と余計に気持ちがブレまくりです。実際のところ自分の能力を信じて短めにしたらオーバーして怒られましたが…

そんな私も大人の階段を上りながら幾つかの方法や理論を知り、まともな(全体的に見ると大はずれしない)スケジュールを出せるようになってきました。もちろんどのような状況・環境でも上手くいくとは限りませんが、ここで簡単に紹介したいと思います。

1.分割して数える

ソフトウェア見積り―人月の暗黙知を解き明かすを読んで、体にしみこむように理解できた数少ない方法の一つ。まず、できるだけ作業を分割しましょう。たとえば「単体試験」という作業も「試験仕様書を作成」や「UnitTestを書く」作業と「テスト実施」に分けられると思います。さらに正常系のテストと異常系の試験にも分割できそうです。「単体試験は何日で終わる?」と考えるより、それぞれの作業毎に見積りを行い、その合計を出すほうが難易度は下がります。また統計的に一つ一つの見積りはどうしてもブレがでてしまうそうですが、複数の見積りの合計とすることでブレを少なくすることができるらしいです。

2.見積りはある程度悲観的に

これも1の本からなのですが、実験的に、様々な見積りについての最短予想と最長予想時間を見積もらせた上で、最有力の予想時間を出してもらったところ、その自信のある見積りは全体的に最短予想に近づく結果となったそうです。ちなみに実際に作業してもらった結果は最長予想のほうに近づいていたと記憶しています(ちょっとうろ覚え&本が手元にない)。私の経験からも、見積もりは自然と楽観的になっていく傾向があると思います。だって上手くいかない状況って想像したくないですもの… また、上司やお客様に伝える際、慣れるまでは「上手くいかない可能性」を挙げることに抵抗がありますしねぇ。でも、そこで必要以上に楽観的になると、結果的に余計迷惑をかけてしまうことになりかねません。そして起こりうるリスクは何故か確実に起こるものです。その辺りを踏まえて、想定されるリスクを適切に組み込めるよう客観的な視点を保ってください。

3.バッファーの結合

前回のエントリーでお話したTOCででてくる考え方なのですが、本題に入る前に「バッファー」という言葉について補足をしておきます。具体的には「スケジュール上発生しうるトラブルに対応するための保護期間」であり、「上手くいけばXXX作業は5日で終わるけど、スケジュール遅れにならないように、トラブルがあったときのために3日多めに見積もっておこう」という場合の3日間にあたると考えて頂きたいと思います。

まず、例えばAAA, BBB, CCCという作業があり、それぞれリスクを踏まえた上で見積りを以下のように出したとします。

・AAA作業⇒見積り:8日

・BBB作業⇒見積り:12日

・CCC作業⇒見積り:4日

・合計⇒24日

このとき各作業のバッファーは、どの程度のリスクに対処できるように算出しているのでしょうか?一般的には「それぞれの作業について、遅れが発生しないよう確実に見積もる」ことが多く、かなり高い確率でスケジュールを守れるようなバッファーを算出するそうです。上記見積りも同様の考えで算出しているとすると、作業で遅れが発生することは殆どなさそうですね。しかし…そんなにしょっちゅうトラブルが発生するものでしょうか?

TOCでは「それぞれの作業が50%程度の確率でスケジュール通り進むよう見積り、全ての作業の後ろに全体のバッファーを置いたほうが良い」としています。再びAAA, BBB, CCC作業を例にとると、以下のようになります。

・AAA作業⇒見積り:5日

・BBB作業⇒見積り:8日

・CCC作業⇒見積り:3日

・全体バッファー⇒4日

・合計⇒20日

それぞれの作業がスケジュール通り進む可能性は五分五分ですので、途中で遅れが発生する可能性は高いのですが、その遅れは全体バッファーで吸収することになります。さてさて、こうするメリットは何でしょうか?

3〜1.学生シンドローム対策

学生の頃「試験への準備期間が十分あるにも関わらず、試験間際になって準備を開始する」といった経験をしたことは無いでしょうか?鉄の意志をもっている方以外は、多かれ少なかれ同様の経験があるかと思います。TOCではこの現象がプロジェクトでも同様に発生し、十分な余裕時間があっても最終的にそれを消費してしまう傾向がある、としています。これまた身に覚えのある方は結構いらっしゃるかと思います(私もたまに…)。スケジュール上、五分五分の線が引いてあると、その線に合わせて動き始めるようになるので、本格着手を早めることが期待できます。自分に甘めな方に効果的です。

3〜2.完了判断の甘さ対策

こちらはTOCではなく、私個人の経験から来ているものです。作業完了の基準が明確でなかったり、開発者の成熟度にもよるのですが、「AAA作業完了しました。BBB作業に移ります」と報告があっても、成果物をレビューしてみると全然完了していないケースがあります。当然その場合は、引き続き当該作業を行うことになりますが、そのタイミングを早めることができるので、致命的な状況に陥りにくくなります。

バッファーの結合に関しては、TOCでは他にも幾つかのポイントがあるようですが、個人的には上記3〜1、3〜2が自分にしっくりくる考え方です。結果的に、全体バッファーは各作業バッファーの単純な合計でなく、その半分〜三分の二程度になることが多く、効率のよい開発につながると思います。

以上、プロジェクト管理者だけでなく、作業担当者レベルでも実施できるような考え方や手法を紹介してみました。全部一度に試すと大変なので、じっくり自分にあったやり方を探してみてはいかがでしょうか?

あともう一つ。プロジェクト全体の中で自分の作業がクリティカルパス(そこが遅れるとプロジェクト全体が遅れてしまう)に含まれているかどうか、察知できる嗅覚を身につけてください。そして、もしクリティカルパスに含まれている場合は、スケジュールを準拠できるか確認し、難しい場合は全力でその作業が遅れないようにしましょう(スケジュール調整の相談など)。自分の作業がプロジェクト全体の遅れに直結すると、肉体的&精神的に非常にこたえますので… 本当に危険な場合は遠慮なく周りを巻き込みましょう(しょっちゅうだと困るけど)。

最後にTOCについて補足。前回今回のエントリーではプロジェクト管理的な手法としてTOCを使っていますが、もともと経営・会計的な観点で用いることが多いようです。

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。

SpecialPR

  • 「奉行シリーズ」の電話サポート革命!活用事例をご紹介

    「ナビダイヤル」の「トラフィックレポート」を利用したことで着信前のコール数や
    離脱数など、コールセンターのパフォーマンスをリアルタイムに把握するに成功。詳細はこちらから

  • デジタル変革か?ゲームセットか?

    デジタルを駆使する破壊的なプレーヤーの出現、既存のビジネスモデルで競争力を持つプレイヤーはデジタル活用による変革が迫られている。これを読めばデジタル変革の全体像がわかる!