アイスブレイク
A：「これどれぐらいでできそう？」
B：（自分が集中して取り組めば…）「5日ぐらいですかね～」
スケジュール：今日～5日後
ちょっと待てーーーい！
B：「5日ぐらいとは言ったが、5日後にできるとは言っていない… それには私がもう1人必要です…」
みたいな開発現場小話、ありますよね？
この話にはツッコミどころが色々ありますが、最大のポイントは
「見積もりがコミットメントになっている」というところ。
今回は見積もりの不確実性の話です。
見積もりの不確実性
みなさんご存知、不確実性コーンですよ。
知らなくても大丈夫、要は「見積もりって上手くいかんよね」って言ってるだけです。
https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/
100%正確な見積もりなんて存在しない？
いえいえ、ここだけの話、ありますよ。
これ企業秘密なんですけどね。
見積もり期間中に実際に作ってしまう → なんと実際に掛かった時間だから100%正しい！
まあ見積もりにめちゃ時間掛かるんですけどね。半年ぐらい？
明日からレッツトライ！
コミットメント（約束）
冗談はさておき、見積もりって本来約束とは関係ないはずなんですよ。
でもなぜか約束＝コミットメントになりがち。
約束って破ると怒られるじゃないですか。
5日って言ったのに8日掛かってるやん、理由と対策を述べなさい、的な。
ふつう人間て怒られるの避けますよね？
（世界は広いので… 怒られるのが好きな人も… 居るかもしれないけれど…）
なのでみんなバッファを積むわけですね。
5日で終わると思うけど安全を見て8日、とか。
そうするとですね、、、見積もりがファットになるんですよ。
そしてみんなバッファを積むもんだから
マネージャー：「ふーん、みんなそんな感じだしそんなもんなんかなー」
と思うわけですよ、そして大体予定通り終わるんですよね
余裕を見たはずなのにぴったり終わる、あらふしぎ。
これマネージャーから見ると
- 予定通りスケジュールは進んでる
- メンバーが暇してるとかなくて無駄がない様に見える
何も問題がない。みんな幸せ。めでたしめでたし。
開発速度低下
誰も遊んでるわけじゃないのに開発スピードが遅い気がする。。。
そうそんなプロジェクトは「スケジュール通りの罠」にはまっています。
この罠、気づき辛いんですよね。
スケジュール通りで目標達成率100%ですからね。
誰も困らないし、何も問題ない（様に見える）
実際に俯瞰して見ると「ただ目標が低いだけ」なんですが、それに自ら気づくことは難しいのです。
※本人たちに自覚がない場合が多い
心理的安全性
何年か前に流行りましたねこの言葉
「ミスしても怒られたり罰せられたりする心配のない状態」のことです。
「心理的安全性を確保しましょう」とかそこら中で言われてます。
いまだに言われてるってことは、まだ確保されていないんでしょう。ツチノコですかね？
そもそもなんでバッファ積むかと言うと、みんな不安だからです。
心理的安全性が低いと言えます。
「予定が守れないことによるペナルティを回避したい」ということですね。
原因が分かっているなら簡単なことですよ、心理的安全性を確保すれば良いのです。
そうです「見積もりなんか間違ってもええやん」ということです。
。。。あれ？ちょっとニュアンス違うな。。。
「見積もりを間違えることはある（だって人間だもn）それを仕組みに取り入れて心理的安全性を確保すれば良いんじゃない？」です。
大切なのは「仕組み」です。
そんな仕組みを2つ紹介します。
CCPM
Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント
クリティカルチェーン≒クリティカルパスみたいな感じです（若干違いますが大体一緒です）
ざっくり言うと以下のような感じです
- 各タスクはぎりぎり50%の確率で達成できる見積もりを立てる（アグレッシブな見積もり）
- タスクをクリティカルパスで並べプロジェクト期間を合計する
- プロジェクト期間の50%をプロジェクトバッファとして後ろにくっつける
※この達成確率50%とかは結構感覚です。
元の見積もりから2割ぐらい削るとか、5割削れば丁度良いとかいう無茶な理論もあります。
この手法の面白いところは「プロジェクトバッファ」という概念を作り
「各タスクは遅れても良い」としたことで心理的安全性を確保した点です。
遅れた(見積もりがブレた)場合、全体のバッファを削ることによりプロジェクトが進行していく、そんな手法です。
CCPMの肝は
- クリティカルパスを早く完了させる計画を建てること
- それにより問題の早期発見＆対処をする時間を確保すること
- それら全てを見える化すること
結局のところCCPMのバッファとは従来と同じ「時間」です。
ただバッファの積み方を工夫しているという一種のマジックですね。
マジックですが、意外と「締め切りがある」と「遅れても良い」という効果は大きいです。
まあでもウォーターフォールの一派です。なんていうか管理的な側面が強いですかね。。。
ウォーターフォールだとみんな守りに入るから、遅れても良いんだよというアメを与えて無理やりアグレッシブにさせてる、みたいな。。。
これは大規模プロジェクト向きで、短期プロジェクトには向きません。
もともとバッファそんなにないので、「大変」から「めちゃ大変」になるだけです。。。
アジャイル
アジャイルの見積もりは「時間という概念から独立」しています。
このタスクは「何日掛かる」ではなく「他のタスクと比べて相対的にどれぐらい」です。
それをストーリーポイントと呼びます。
例：タスク○○はタスク△△に比べて倍ぐらい大変そうだから13ポイントだね
結局「このタスクが何日で終わるかなんて人によるやん？」ということ。
誰がアサインされるかどうか分からない段階で時間を見積もる意味ないやん？、という現実的思考。
大切なことは、一定期間(スプリント)に、チームとしてどれだけのタスクをこなせるか(ベロシティ)。
1スプリント100ポイントのタスクをこなせる実績があるなら、次回もそのぐらいの計画を立てれば良いのです。
アジャイルの見積もりに対する考え方ははっきりしてます。
「どうせ見積もりなんて色んな要素でブレるんだから時間かけても仕方がない」です。
ただ、短時間でも効果的な見積もりができる様に属人性を排除する工夫があって
- 時間ではなくストーリーポイントによる見積もり
- プランニングポーカー等のチームによる見積もり
見積もりがブレたときに責められる人はいません。みんなで見積もったんだからみんな悪いよね理論。
というよりアジャイルの理念が「間違えないこと」ではなく「間違えても迅速にリカバリできる」を目指しています。
（アジャイル ← アジリティ ← 俊敏性。これが全ての基本です。）
アジャイルのバッファとは「タスク自体」です。
優先度の低いタスクをやらないことにより見積もりのブレを吸収します。
アジャイルが重視するのは「経験」。ここが「仮説」を積み上げるウォーターフォールとは異なる点です。
間違えたこと、それは知見を得たということです。
次回(スプリント)に活かせば良いのです。
わりとすぐ来ます。来週です。
終わりに
ソフトウェアの特性上、開発には常に未知の部分が存在します。
世の中に存在しないから開発するのです。同じならコピーすりゃ良いんですよ。
（OSS使うとか、パッケージ製品導入するとかの意味です）
つまりソフトウェア開発は不確実性との戦いです。
どうやっても見積もりはブレがちで、それを形式上ブレていない様に見せるためにバッファを積んでしまう。
それがプロジェクト全体で見ると非効率を生んでしまうというパラドクス。
どうせ戦わなきゃいけないなら仕組みに取り入れてしまいましょう。