# アジャイルな見積もりと計画づくり

## なぜ計画づくりに失敗するのか

### 現実として
- プロジェクトの３分の２近くは、コスト見積もりを大幅に超過する
- プロダクトのフィーチャの６４％は、めったにあるいはまったく利用されない
- 平均的なプロジェクトは予定スケジュールの２倍以上かかる

### 失敗する５つの理由

**1. フィーチャではなく作業を計画している**
ガントチャート、WBSで作業を管理すると、作業がチームの進捗の測定基準になる。顧客にとって、作業の完了には何の価値もない。

また、計画時に以下の事実を考慮していない。

- 作業は早く終わらない
- 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する（パーキンソンの法則）
- スケジュールの遅れは先へと伝わる
- 関連する作業がすべて終わってのみ早く作業が着手できる。逆にひとつでもうまくいかないとすぐ遅延につながる
- 作業は独立しない
- ソフトウェアの一つ一つの作業は独立していないところが多い。今回は遅れたけど、次は似たような作業だから挽回できるということをよく言うが、似たような作業というのは似たように遅れる要因も潜んでいるということを理解すべき。

**2. マルチタスク化が遅れを助長する**
- 従来型の計画づくりがうまくいかない理由の一つにマルチタスク化がある。個人が３つ以上作業を並列して進めると生産性が下がる
[マルチタスクは脳に悪い｜やめれば仕事の生産性が40%アップする](https://www.toritemi.com/multitasking-brain)

**3. 優先順位の順にフィーチャを開発していない**
- 開発に都合のよい優先順位になってしまう（作業の効率を第一優先にしてしまう）。期日が近づくと価値あるフィーチャを削ってしまうこともある。できたものがフィーチャ単位になっていない。

**4. 不確実性を無視している**
ありとあらゆることに不確実性が存在するが、その見積もりが適当。（例えばバッファ１０日間とか）。不確実性を低減させるには、短いイテレーションを作業するのがよい。これは過去の不確実を未来の計画に反映することができる。
[リスクと不確実性の違い](https://fukuokatomotake.com/archives/475)

**5. 見積もりがコミットメントになっている**
見積もりは確率だが、コミットメントは確率ではない。コミットメントは日付であらわされる。通常、チームがコミットメントを求められる日付とは、その日に作業が完了する確率が１００％に満たない日付だ。チームがそのような日付に対してコミットメントするには、事前にさまざまなビジネス上の要素やリスクを検討しておかねばならない。チームにはそのための機会が与えれるべきであり、いかなる見積もりも暗黙のコミットメントになってはならない。
[見積りとコミットメントは分けよう](https://www.ryuzee.com/contents/blog/3102)

### 話し合ってみよう
- フィーチャではなく作業を基準に計画をたてるとどんな問題が発生するだろうか

(上がった意見)
→期限守るのが目的になりがち。
→オーナーが何を求めているのか意識する必要がある。
→ウォーターフォールだとユーザービリティ向上のような提案がしづらい。そのためフィーチャ目線で考えるのが難しくなる。
→声を上げてもややこしくなったりするからどうしても妥協してしまう
→アジャイルだと自分の提案が通りやすい（変更容易性）。そのため当事者意識が高まりやすい。
→自分の提案が認められると成功体験ができモチベーションも高まる。

- あなたの周囲では見積もりとコミットメントは同じだろうか。その場合にはどんな問題が起きているだろうか。どうすればこの誤解を解けるだろうか

(上がった意見)
→見積りは期間だけでなく金額もだすし、ある程度のコミットメント前提で書いているため、見積もり結果＝コミットメントになってしまっているのが現状。
→変更が許されない空気になってしまっている

- あなたのプロジェクトでマルチタスク化はどんな影響を及ぼしているだろうか。どうすればマルチタスク化による悪影響を軽減できるだろうか。

(上がった意見)
→TODOリストなどを作成してやるタスクを明確にしている
→ロケーション意識するのも大事（静かな場所でやるなど）
→細切れの時間より、まとまった時間が必要
→複数案件もってる人は打合せだけで一日終わってしまったりする。