約束すると開発が遅れる

約束は開発を遅らせる - Mitsuyuki.Shiiba

• 運が良ければ1ヶ月、6割の自信で2ヶ月で終わるタスクがある場合
• チームの外から見積もりを聞かれた場合に、6割の自信のものを答えるわけにはいかない
  • 同じ物作りプロセスを経験していない人は見積もりの分散を小さく誤認するから
    • 
      • Aさん「50%の確率で2ヶ月で終わる」
      • Bさん「なるほど、じゃあ3ヶ月もあれば90%確実だな」
      • Aさん「いや、そうじゃない、90%確実なコミットメントが必要なら6ヶ月だ」
    • 関連 分散が異なるのでは？　分布形状が異なるのでは？
• 9割確実な見積もりを出そうとすると調査コストがかさむ
  • これは当然のこと
    • 多種多様な「起こりうる遅延原因」を事前に全部調査してどの程度遅れるか見積もるので。
      • YAGNI原則に反する
    • リスク回避のために「必要ないかもしれないものに対して事前に支払っている」のだ
      • 保険と同じ
• 根本的な原因はAとBで見積もりの分散が違うところ
  • これ自体が悪ではない、分散の小さい見積もりが必要なケースはある
  • Bが分散の大小に無自覚な場合、分散が大きくて良いところでも小さい分散を求めて無駄に保険金を支払うことになる

@golden_lucky: 約束すると開発が遅れる、まじで実感を伴うんだけど、そう明言してしまうと単なるジンクスかもしれんとも感じられるくらいの微妙な実感で、でもこの文章を読むとやっぱりジンクスじゃないんだと思える。いい文章だ

• @torus: @golden_lucky コミットメントとモチベーションの維持という点で、この記事で紹介されていた「2点見積もり」というのが良さそうな気がしてます。拡大画像 スクウェア・エニックス オープンカンファレンスレポート（後編）

  • 

• @golden_lucky: @torus 過去に自分が編集した本にも2点見積もりみたいな話は出てきたなあ、と思い出してました。ただ、こういう話って、見積もりを受ける側の意識が変わることが前提なんですよねえ（そして往々にしてそれがむずかしい…）

@natsutan: @golden_lucky くまとワルツ思い出しました。 結局見積もりが約束になるのと、後からスケジュール調整する気が無いのが問題化と。 @golden_lucky: @natsutan さらにいうと、後からスケジュール調整が認められにくい空気、もしくは、認められないかもしれないと思わせる空気、なんですよね。そういえばデッドライン(書籍)とかにもそんな話があった気がします。

事例

@voluntas: 約束すると開発が遅れる - 西尾泰和のScrapbox https://t.co/n2gO0zSjGZ これは正しいので、事前に頂いた要望の期間で実現できるかどうかの調査をします。まずは調査期間のお金くださいって感じで仕事受けてる。

• @voluntas: 調査期間で指定された期間で実現可能かを調査するので、お互い安心。調査にお金払える企業としか取引しなくて良くなる。いいことずくめです。