『アジャイルな見積りと計画づくり』第17章のコメント・疑問
第17章 不確実性に備えるバッファの計画 P.201～
1. フィーチャバッファ P.202～
「必須の要求を実現するために割り当てる工数は全体の70%を越えないようにする」！まさにそうありたいという気持ちと、それができれば苦労はないという気持ち。でも、こういう考え方で現実にあたるべきですよね。（ヤマモト）
2. スケジュールバッファ P.203～
2-1. 見積りの不確実性を反映する P.204～
n%の見積りを出すというのは、「n%の確率で達成できるとコミットメントできる見積り」であると。見積りポーカーをするときに、「じゃ、50%見積り ね」「今度は90%ね」とか言って、出てくる数字が違えば根拠を語り合ういつもの手法でやればいいのかな。また、これらも最初はあてづっぽうで、イテレー ションやリリースを繰り替えして経験を積むうちに上達して確度が上がっていくだろう、という理解でいいでしょうか？（ヤマモト）
P.207-208
バッファをタスク毎に個別に取らず全体に対して取るのは納得。その根拠にパーキンソンの法則や学生症候群を抑えられるとしたのはさらに納得。
まるで私のようなダメ人間というリスクをヘッジするには個別よりも全体でバッファを取るべきですね。（イザワ）
やはりある程度イテレーションをまわしてベロシティを計測しないと最適なバッファはわからないので、最初は多めに取るのも仕方がない？
例えば飛行機に乗り遅れるリスクを考えれば、初回は飛行場で多くの時間待っても次回から調整すればいいので。
もっとも、飛行機に乗り遅れることがリスクにならないなら、最初から50%見積もりの時間で挑むのもいいかもしれないですけどね。
つまりは試行錯誤重要ってことで（イザワ）
2-2. プロジェクトバッファの大きさを決める P.208～
P.208 「プロジェクト全体のスケジュールで必要なバッファは、3～100ポイントのストーリーが含まれている場合でも～」 P.61 のストーリーポイントによる規模の見積もりによると、作業規模として100倍の違いがある事になるが例え話としても如何なものか。 （Ｙｏｕ＆Ｉ）
P.210
計算した結果のバッファは切り捨てるか切り上げるか四捨五入かはチームとしてある程度イテレーションを回した上で決めるのかな？
それともバッファの数値に影響する？（例えば9に対しての±1と100に対する±1の重みは違うので）
ここ（水泳サイトの件）では切り捨てたけど、飛行機へ乗るための時間に対するバッファは計算したら52.4で、結果として53分にしているが。（イザワ）
2-3. より単純なバッファ計算方法 P.210～
2-4. バッファのガイドライン P.211～
「リーチのガイドライン」ってなんでしょう？ここに挙げられているふたつのポイントのこと？（ヤマモト）
自分も気になりました。本章でも唐突に言及される内容が出てきますねぇ。Critical Chain Project Managementという書籍の事のようですね。（Ｙｏｕ＆Ｉ）
がんばって探してみた
リーチ は、彼の本の中で (2004)、スケジュールバッファ、および、総プロジェクトコストバッファについて説明していますが、そこでは、バイアスに対処するために、最小プロ ジェクトバッファの大きさをクリティカルチェーンの25%に、また、最小コストバッファを総コストの10%とし、それに加え、分散の積和の平方根による方 法（SSQ方式、[SSQ：square root of the sum of the squares]）でバッファの大きさを決めるように勧めています。
※プロジェクトバッファ： プロジェクトのクリティカルチェーンの末端に置かれるタイムバッファ
※コストバッファ： プロジェクトのコスト合計推定予算値に含まれる予備費
(だんの)
バッファは20%以上は確保せよというのは経験則からかな？（イザワ）
3. 複数のバッファを組み合わせる P.211～
リスクはフィーチャに対してもスケジュールに対してもリソースに対してもありえるので、それぞれの側面に対応するバッファを組み合わせるというのは納得。
そして小さい数字にバッファを設ける難しさについて、
兼任よりも専任のほうが効果的であるのも納得。
兼任の場合リソースの割合を主となるPJのリーダとネゴしないといけない。
そして結果的に振り回されるのは実務者なのだから。
#でも実際はよくある話で職場が変わっても携帯で対応したり休出したりとか・・・（イザワ）
4. スケジュールバッファは水増しではない P.212～
P.212 「水増しとは根拠もなしに見積りに追加している時間のことだ」「スケジュールバッファはプロジェクトの安全を保つための余裕であり、個別マージンを取り除 いた見積合計に加えるものである」この説明では客先を納得させられない。水増し以外の何者でもない。（Ｙｏｕ＆Ｉ）
車間距離の単語を見て「渋滞学」を思い出しました。詳しくは知りませんが本には車間距離は40m開けろと。
プロジェクトも渋滞しないためにはバッファは必要だと思いますが、「顧客」」が絡むと難しいですね。
顧客は最短であったり、最高のものを要求する場合もありますから。
（もっとも、リスクが顧客側に起因する場合、それを盾にある程度交渉は可能ではありますが）（イザワ）
5. 使用上の注意 P.213～
P.213 「バッファ」という言葉自体が、場合によってはすでにもうNGワードな気がします。バッファを取り入れるのではなく、90％見積もりの方が導入しやすい事もあるのでは。（Ｙｏｕ＆Ｉ）
余談ですが、新人のころ、
「○○さんに対しては現実的な作業日数を言ってもいいが、××さんには予め積んだ日数を言えよ」と。
誰に報告するかでバッファをバッファとして見せるのか、隠すのかが大切だと思います。
（ん？すでにこの発想自体がアジャイル開発としてはよくないのかな？）
顧客から見ればバッファと水増しの違いを理解してくれるとは限りませんから。
（もっとも、そんな顧客だとアジャイル開発はそもそもできない？）（イザワ）
まとめ P.214～
この章の内容は、TOC(制約理論)のクリティカルチェーンプロジェクトマネジメントを取り入れた内容ですね。（角谷）