タスクの見積もりとスケジュール作成は仕事をする上で必須のスキルです。しかし、具体的にはどのようにすれば見積もりをすることができるのでしょうか？なんとなくで工数を出していまっていないでしょうか。
見積もりとスケジュール
見積もりとは何かを正しく理解しましょう。
これどれくらいでできそう？
一週間くらいですかねぇ
おそらくこれは見積もりではありません。
見積もりでは全タスクと工数を洗い出す必要があります。
工数とは規模のことです。あるタスクの全工程にかか時間が8時間だったとしましょう。工数が8時間です。もし、他にもタスクを抱えていて、1日に4時間しか作業できないのであれば、工数が8時間のタスクを終わらせるために2日必要です。工期が2日ということになります。これがスケジュールです。
コミットメントというものもあります。
コミットメントは予算、期間、品質の組み合わせです。品質を高めるためにはリソースを増やしたり期間を増やしたりする必要があります。
見積もりの方法
見積もり作業は大きく分けて二つのステップに分かれます。
- タスクに分解する
- 分解されたタスクの規模を算出する
です。
分解
タスクの分解のやり方は、テンプレートを作っておくのが良いです。
例えばウェブ系の実装を担当することになった場合、
- 画面の実装
- コントローラーの実装
- モデルの実装
- ビューの実装
- テストの実装
- インテグレーションテスト
- テーブルスキーマの作成
- ログの実装
- ドキュメントの作成
などです。他にもインフラ関連の作業や開発基盤系のタスクなどもあると思います。
算出
規模の算出は過去の実績をもとに算出するのが確実です。この方法を取るためには記録をとっておく必要があります。
記録をとっていたとしても類似したタスクが無いことも多いです。
次に取れる方法としては、プランニングポーカーの要領で見積もる方法です。この方法では平均的な難易度のタスクを選んで、それをもとに相対的な難易度を割り振るという方法です。難易度には1,2,3,5,8,13,21のようにフィボナッチ数列を使うことが多いです。
13とか21は、見積もり時点で詳細が分かっていなかったり調査が必要なものです。
作業時間ではなく難易度（相対的な値）で見積もるのは、作業時間は作業者のレベルによって見積もりに違いが生じるためです。
Tips: 見積もりのコツ
見積もり作業は不確実性を減らす作業です。
どんな時に不確実性が高い状態のものに対して不確実性を小さくすればいいのです。では、不確実性が高い状態はどんな状態でしょうか。
- 細かい仕様が決まっていない 不安です。
- 使ったことのないミドルウェアを使う 不安です。
- アルゴリズムが正しく動くかわからない 不安です。
- 外部サービスとの連携はうまくいくだろうか 不安です。
これらに対してひとつずつアプローチしていきましょう。
仕様が決まっていなくて不安ならば、きちんと要件定義をしましょう。
ミドルウェアは使ってみましょう。チュートリアルを理解しているのとしていないのでは作業感の見積もりに大きな違いがあります。アルゴリズムはテストを書いて検証しましょう。
スケジュール化
見積もったタスクをもとにしてスケジュールを作成します。
スケジュールを作成するというのは、タスクの作業をカレンダーに載せる作業です。
まずは先に非稼働時間を設定します。休日・祝日、有給、定例会議などは作業ができないので先に除外します。
次に稼働率を考えます。実際にプロジェクトに割ける時間はどれくらいあるでしょうか。他部署からの問い合わせに対応したり、困っている人を助けたり、レビューをしたりなど割り込み作業が発生することは確実です。これらの割合を考えて、稼働率を算出できるようにしておきましょう。
単一のプロジェクトしか持っていなければ70-75%、プロジェクトを掛け持ちしていれば40%などのように決めます。
次に、振れ幅を考えましょう。x月y日にリリース完了しますというのスケジュールには無理があります。x月y日に完了する確率が100%であると言っているのと同じです。実際にはx月y日に完了する確率は75%である、だったりそんな感じです。
そこでほぼ確実に完了するであろう期間を考えて、最短工期と最長工期を出しましょう。最短工期を出して、最長工期はその1.5倍にするなどで十分かと思います。
スケジュール管理
スケジュールは常に更新する必要があります。
日次の更新
タスクの進捗状況を確認してアップデートしましょう。
0% 未着手
25% 着手中
50% 最低限動く状態になっている
75% レビューを依頼している
100% 完了
などのような粒度が良いでしょう。
遅れているタスクは現在以降に配置しなおします。
週次の更新
全体の工期を見直します。残りの期間に終わりそうでしょうか。
常に遅れが発生しているのであれば、そもそもの見積もりを全体から見直す必要があるかもしれません。
突発的に遅れた場合は、稼働を調整したり、タスクの優先度を組み換えれば十分かもしれません。
遅れる原因の分析
遅れる原因①：曖昧な要件
良い仕様書は重要です。
多くの場合、仕様書の作成者がすべてを考慮できなかったことが判明します。設計や開発をはじめてから問題が発覚して、仕様に問題があるせいだとわかります。
遅れる原因②：要件の変更
途中で仕様が何度も変更されるのも困ります。
実際の開発がはじまる前に十分なモックアップを作成しましょう。開発してから手戻りするのは最悪です。
遅れる原因③：コンテキストスイッチ
途中で取り組むタスクを変更するのは億劫です。手を止めて別のタスクに移るのも、追加で別のタスクをやるのも認知的なコストは大きいです。
一度に二つ以上のことをやらないようにしましょう。相手にも理解してもらう必要があります。よいマネージャーは、エンジニアがひとつのことに集中できるように、障害となるものを取り除く責任があります。
参考
