アジャイルな見積りと計画づくり：第2部：規模を見積もる「５章　理想日による見積もり」まとめ

理想時間と現実時間の乖離はなぜおこるのかをチームのみんなで話しあい、現実的な時間を見積もる能力を高めていくことが必要だと感じました。

理想日による見積り

理想日と現実時間の違い
- 「アメリカンフットボールの試合の長さは？」この質問への答えは「15分のクォーターが4回で合計60分間」かもしれないし、「だいたい3時間」かもしれない。どちらの答えも正しい。両者の違いは、理想時間を答えているのか、現実時間を答えているかにある。
- 理想時間とは、なにかをするのにかかる時間のうち、周辺的な作業を差し引いたものである。アメフトの試合は60分だ
- 現実時間は、時計やカレンダー上で経過した時間を指す。アメフトの試合の場合は、現実時間で3時間ぐらいかかる
期間の予測は現実時間よりも理想時間のほうが簡単かつ正確に見積もれる
- 今週末のアメフトの試合の長さを効かれても、理想時間でなら「60分」と即答できる。もっと精密な見積りが必要であれば、昨年度の時間を超過した試合を調べ、過去の平均から、今週末の試合の長さは62.3分だと答えることもできる
現実時間の見積りはさまざまな要素を検討する必要がある
- 昨年でいえば、2時間半で終わった試合もあれば、4時間以上続いた試合もあった。この違いは、怪我など偶発的な出来事によるものもあるが、反則の回数などのチームのプレイの流儀にも関係している。テレビで放送される試合は、コマーシャルの間はタイマーを止めるので余計に時間がかかる。天候のせいで試合が長引くこともあれば早まることもあり、どうなるかはチーム次第だ。理想時間で即答した見積りに匹敵する正確さで、現実時間による見積りをするには、これらの要素すべてを検討する必要がある
現実時間に対する計画
- テレビの番組表を見れば、試合は１時にはじまって４時に終わると書いてある。テレビ局が現実時間で試合を予測していることは明らかだ。テレビ局は私たちの知らないどんなことを知っているだろうか？いくつかある。まず、試合の進み具合に応じて、コマーシャルを増やしたり、減らしたりするように計画している。次に、たいていの試合は3時間前後で終了する。試合が早く終わったら、追加のコマーシャルやインタビューなどを放送して時間をつなぐ。延びた場合でも、試合を見たがっている視聴者であれば、15分や30分の番組を延長しても見るのをやめないだろう。番組表は４時までだかといって、４時ちょうどでテレビを消したりしない。逆に、試合に興味がない視聴者が４時から違う番組を見ようとしてテレビをつけたら、まだ試合をやっているということもある
テレビ番組表に書いてある放映時間は見積りに過ぎない
- アメリカ人は過去数十年にわたるアメフトのテレビ放送の歴史を通じて、試合の終了時間が正確でないことに慣らされてきたという事実がある。この点が重要である。アメフトのファンは試合の終了予定が4時だとしても、それが見積りに過ぎないことを経験から学んでいるのだ。試合の終了時間が4時15分になっても（8%の超過だ）、誰も驚かない。イライラしたり腹を立てたりはするかもしれないが、驚いたりはしない。では、ソフトウェア開発で同じようなことがおこったら、驚かれてしまうだろうか？

理想時間とソフトウェア開発

ソフトウェア開発による理想時間と現実時間のギャップはなぜ起こるのか
- それは、日常的に偶発する様々なオーバーヘッドのためだ
- 日々の仕事ではプロジェクトで計画済みの作業以外にもいろいろなことをやっている。メールに返事をして、ベンダーのサポートに電話をして、新しいアナリストの面接をして、２つの会議に出席して、という具合だ。
- 理想時間と現実時間の差異をもたらす理由を、さらにあげてみよう
  - リリース済みプロダクトのサポート
  - 体調不良
  - 会議
  - デモンストレーション
  - 私用
  - 電話対応
  - 緊急の割り込み作業
  - トレーニング
  - メール
  - レビューやウォークスルー
  - 候補者の面接
  - タスクの切替時間
  - リリース済みのプロダクトのバグ修正
  - マネージャとの面談
- 理想時間と現実時間が異なってしまう理由をさらに付け加えるとこんなデータがある。マネージャが割り込まれずに作業できるのは、平均5分間しかないということだ。平均的な開発者の割り込み頻度がマネージャの3分の１だったとしても、それでも15分に１度は割り込みがはりることになる
問題が起きるのは、マネージャなら誰もがするであろう質問をチームメンバーにしたときだ。つまり「どのくらいかかる？」と。チームメンバーが「5日間です」と答えたら、マネージャはカレンダーの５日後に赤い大きな丸をつける。しかしそのメンバーが本当にいいたかったことは「集中してできれば５日間だけど、他にもやることがいろいろとあるので、たぶん２週間くらいです」ということなのだ
ソフトウェアプロジェクトでは、作業の掛け持ちも理想時間と現実時間の差を広げる要因になっている。アメフトの選手がコーチならこんなふうに言われることはない。「おまえは試合中ずっと忙しいわけじゃないんだから、ホッケーの試合にも参加してほしい。この試合も重要なんだ」。作業を掛け持ちしているソフトウェア開発者は、２つ（あるいはそれ以上）のタスクを切り替えるために、多大な生産性を犠牲にしている。
ソフトウェアプロジェクトでは、ユーザーストーリーやその他のタスクを、理想日で見積もることができる。理想日で見積もるときには、以下のような前提を置く
- ストーリーに必要な作業だけを見積もる
- 作業に必要なものはすべて、作業の開始前に用意されている
- 途中で割り込みは発生しない

規模の見積りとしての理想日

理想日を使ってユーザーストーリーの開発からテスト、受け入れまでを見積もる場合には、チームの環境におけるオーバーヘッドは無視して構わない。１理想日は１理想日だ。オーバーヘッドを考慮しないので、理想日はストーリーポイントと同様、規模の見積りとみなせる。理想日の日数をベロシティで割れば期間の見積りを導出できる。このやり方はストーリポイントの場合とまったく同じだ

見積りは1つだけ

各ユーザーストーリーについての見積りに理想日を使う場合は１つだけにすること
- チームによっては、作業の担当者ごとに理想日をストーリーに割り当てているところもある。たとえば、あるストーリーの割り当てが、プログラマに２理想日、データベースエンジニアに１理想日、ユーザーインターフェース設計者に１理想日、テスターに2理想日といった具合だ。こうしたチームでは担当者ごとの理想日の数字を、ペンの色を変えてストーリーカードに書き込んだり、色違いの付箋に数字を書いてストーリーカードに貼りつけたりしている。ほとんどの場合、１つのストーリーに数字をいくつも記載すべきではない。これが私からのアドバイスだ。ユーザーストーリーのレベルで個々人の作業に注目してしまうと、チームが「全員一丸となって取り組む」という考え方を維持できくなる。
- ストーリーの作業担当者ごとにそれぞれの数字を出していては、リリースプランニングでの作業量が大幅に増えてしまう。各ストーリーで担当者ごとの作業量を見積もるなら、リリース計画に担当者ごとの作業量を含めなければならない。ということは、ベロシティと残作量も担当ごとで個別にトラッキングしなくてはならないのだ。
- 各ストーリーで担当者ごとの理想日を見積もるという手間をかけても、報われることはめったにない。ただし、それも必要とされる場合もある。
- 理想日による見積りでは、ユーザーストーリーの見積りを、みんなの理想日を合計した数字を使って表現した方が良い