プロジェクトのタスクの見積もりは距離もしくは負荷を数値にする

　新卒と呼ばれる社会人から、ややベテランと言われる社会人になりました。高校生の時、一生食べていけるように手に職をつけたくてエンジニアを目指し、最近プロジェクトマネージャーのようなこともしてます。

　新卒エンジニアの頃はアサインされた(振られた）タスクの見積もりの「み」の字も出来てなかったです。いつも最速で理想的な手順で出来た場合の見積もりを行って、タスクの中の壁に盛大にぶつかって、遅延報告をしてメンターや先輩に呆れ顔されてました。
　当時、まだチームのことがわからない状態で、チームに既存で存在する複雑なプログラムの改修をアサインされてました。きっと、期待が大きかったのでしょう。(その後、鬱になったのはまた別の機会に書きます）

　では、最適なタスクを見積もりとは？
　今日は答えの一つを論じようと思います。

　タスク見積もりで使う数値の意味はさておき、見積もりを行う観点の一種はいかの3つです。

1. 「最も理想条件で終わる場合」

2. 「経験的に最も頻出する条件で終わる場合」

3. 「最も最悪条件で終わる場合」

　この観点で出せと言われても、経験が浅いジュニアには難しいかもしれないですが……。

　また、一般的に見積もりを出せを言われれば、「明日まで」など、時間的な表現を行います。見積もりの数値的な意味は時間ですね。

　見積もりを出す際はおそらく、各自の経験から来る推測を元に相対的に出しているでしょう。「メールを返すのに10分だった」「些細なバグを直すのに2時間だった」……そんな感じでしょう。

　人間は絶対評価よりも相対評価がどうやら得意らしいです。なので、経験が浅い人は別のタスクを引き合いに、見積もりを出して、依頼者に提示するのが正確に近いかもしれません。

　見積もりの数値の別の意味は、距離と負荷です。距離と負荷はほぼ類似なので負荷とここでは表現します。
　これは前述した経験から推測による相対評価で出すのは同じです。
　私個人はこの負荷としての見積もりの表現を推します。

　※ 前提として、納期を守るというのを念頭でお願いします。
　雇用されている人であれば、1日の業務時間は大体8時間でしょう。時間の流れは誰しも平等ですので、もしも、見積もりを時間で出した場合は業務時間の間に入るように見積もり時間を分けるでしょう。
　時間の流れは平等ですが、業務は不平等です。同じメールチェックでも1日に来るメールや返すべき返信の量、相談時間、MTG、レビュー、実装……etc。まだ全ての業務時間を平等なコンディションで乗り切れることは多くはないでしょう。
　1日に取れる時間を加味して、4時間の見積もりの仕事を1か月後……と見積もるのは不安定さを感じますし、アサインする側も戸惑います。(実際1ヶ月後といいつつ、2、3日で作るんですが笑）

　ここで、負荷で表してみます。負荷が3とします。
　この3の判断は、基準を置いて作ります。

　例としては、「1年ぶりに触るが見知ったプログラミング言語のシステムの軽微な改良」を10と置きます。この基準に対して相対的にアサインされた仕事を3を評価します。

　次に1日、1週間など短い期間で自分がどれぐらいの負荷を対応出来るが計測していきます。
　※ 他の人が日に100の負荷を片付けられるが、対して自分は……と卑下しないでください。人それぞれです。
　1日に対応できる負荷でいつやるか決めます。
　……時間と変わらない？そうですね。一番のメリットは対応出来る負荷を別の指標として使えることです。

　前述したように時間の流れは変わらないです。仮に雇用されている人が「今日のコンディションは最悪だから、5時間の業務しかできない」と面と向かって、言えるでしょうか。しかし、対応できる負荷であれば、「今日の業務量的に20ポイント(負荷数)分の業務を行う」と表現すれば、コンディションを反映した正直な数値になると思います。

　同じ時間の流れでも、定量的に示した対応出来る負荷数を使うことにより、精神的なプレッシャーを感じずに見積もりを表現出来ると思います。

　以上から、私は負荷数でタスク見積もりをするのが良いと思います。

　……ちなみにこれは、アジャイルという概念を持ったスクラムというプロジェクトマネジメントの一部です。対応出来る負荷数はベロシティと呼ばれます。興味がある方は、そちらを調べてみてください。