見積もりの技法 デスマを屠る技術(1)

見積もりの技法 デスマを屠る技術(1)

2018年の夏頃に社内勉強会で発表した資料です。

88ad4f75d7c84fcf560bb6205c52e8c1?s=128

dnskimo

July 27, 2018
Tweet

Transcript

  1. 見積もりの技法 デスマを屠る技術(1)

  2. 突然ですが

  3. この部屋にはいくつの椅 子がありますか?

  4. 0個

  5. 1〜5個

  6. 6〜10個

  7. 11〜20個

  8. 16〜20個

  9. 21個以上

  10. 正解は

  11. 自分がなぜそう思ったの か?

  12. 見積もり方は3種類

  13. 3種類の見積もり方 • 数える • 計算する • 判断する

  14. なんとなくイメージで 判断する

  15. 一列分の椅子の数 ✕ 列数 数える 計算する 数える

  16. 全ての椅子を数える 数える

  17. 数える>計算する>判断する 正確 >>>>>>> 不正確

  18. 判断 = 直感・経験則 = 主観

  19. 主観に基づいた見積もり は失敗する

  20. 楽観主義者達の結託 • エンジニア:作ったことがあるので(自分は能力が あるので)、短期間で作れるはず • マネージャ:顧客の要求を満たせるので、短期間 で作れると嬉しい • 顧客:安く(早く)済むので、短期間で作れると嬉し い

  21. エンジニア リーダー マネージャ 顧客

  22. 楽観的な見積もりは誰に も止められない!

  23. 楽観的な見積りは開発経 験が足りないせい?

  24. NO!

  25. 経験豊かなエンジニアほ ど直感の見積もりにバイ アスがかかる

  26. 主観に頼らない、客観的 な見積もりの手法が必要

  27. 推測するな計測せよ エンジニアの精神

  28. ソフトウェア開発の世界に は難しい課題と戦うため の様々な技術がある

  29. 設計の技術、DBの技術、 インフラの技術、セキュリ ティの技術、etc...

  30. 見積もりにも技術がある

  31. 見積もりの技術 = つくるものの大 きさを客観的に計測する技術

  32. 大きさ = 時間 or 規模 人月・人日 ???

  33. 時間の見積もりは難しい

  34. 時間の見積もりが難しい要因 • 1人日とは? • プログラマの生産性はピンキリ • 一日に作業に集中できる時間は不明瞭 • 企業の文化による影響(MTGの多さ、割り込みの 多さ、雑音など)

  35. 1日で終わりそうな作業 は、1日では終わらない

  36. 規模の見積もりなら?

  37. 規模の見積もりが難しい要因 • 規模=コード量? • 技術選択による影響(言語、フレームワーク) • 腕のいいプログラマほどコード量は減る

  38. 相対的なポイント見積もり

  39. https://www.slideshare.net/Ryuzee/scrum-8048905

  40. https://www.slideshare.net/Ryuzee/scrum-8048905

  41. https://www.slideshare.net/Ryuzee/scrum-8048905

  42. 絶対的な大きさより相対的な 大きさほうが直感が働く

  43. 直感 = 判断では?

  44. はい。

  45. ただし、その判断の結果 から実測値を作れる

  46. 手順1. いくつかのタスクに ポイントをつける

  47. タスクにポイントをつける例 • 小さいタスク:1ポイント • 中くらいのタスク:3ポイント • 大きめのタスク:5ポイント

  48. 1ポイント = 何人日になる かは考えない

  49. 手順2. 残りのタスクにポ イントをつける

  50. タスクにポイントをつける例 • 小さいタスクの二倍くらいのタスク:2ポ イント • 中くらいのタスクと同じくらいのタスク:3 ポイント

  51. 大きすぎてサイズ感がわ からないタスクは分割する

  52. 一人で考えない。チーム で考える。

  53. プランニングポーカー

  54. https://www.atware.co.jp/blog/2015/3/31

  55. https://www.dreamstime.com/stock-photo-planning-poker-also-called-scru m-consensus-based-gamified-technique-estimating-mostly-used-to-estimat e-effort-relative-image73614147

  56. プランニングポーカーの利点 • 個人の主観によるバイアスがかかりにくい • チーム全体で決めるので納得感が出る • サイズが膨らむ要因に気づきやすい

  57. 手順3. イテレーションを回 してタスクを可能な分だけ 完了する

  58. 客観的な計算に使える実 測値が生まれる!

  59. ベロシティ =1イテレー ションで完了したタスクの 合計ポイント

  60. 完成までのイテレーション 数 =すべてのタスクの合 計ポイント ÷ ベロシティ

  61. 必要な日数 = 完成までの イテレーション数 × イテ レーションの日数

  62. タスクの作業時間(人日) については一度も判断し ていない!

  63. イテレーションを回す毎に 実測値が増える=見積も りの精度が上がる

  64. 注意事項1

  65. タスクの「完了」とは、完了のこと である

  66. 「8割終わった」は半分も 終わってない

  67. テスト・実装・リファクタリン グ・マージまでやって完了

  68. 注意事項2

  69. 見積もりは交渉可能なもので はない

  70. 人の願望によってビルの 高さは変わらない

  71. 人の願望によってタスクの 大きさは変わらない

  72. 見積もりの技術 = つくるものの大 きさを客観的に計測する技術 再喝

  73. 客観的なデータには交渉 の余地がない

  74. 客観的なデータに対して 願望を持ち込まない強い 意志が必要

  75. それでもどうしても希望日 にリリースしたいと言われ たら? それはまた次回以降

  76. 注意事項3

  77. ベロシティは目標にするもの ではない

  78. タスクのポイントを大きめ に見積もれば、簡単にベ ロシティは上がる。

  79. プレッシャーをかけるとポ イントの割り振りにバイア スがかかる。

  80. ベロシティはあくまで計測 の道具。正確に測れなくな ればなんの意味もない。

  81. None
  82. 実作業に入る前に見積も りを求められたらどうすれ ばいい?

  83. ファンクションポイント法

  84. ファンクションポイント法 • 永続化するデータの項目数 • データの入出力の処理の数 • それらの数に所定の係数をかけて合算する 数える 計算する 数える

  85. 絶対的な規模の見積もり

  86. ファンクションポイント法のメリット • プロジェクトの早い段階(画面設計後)に見積もれる • 全てを相対ポイント化するより短時間でできる • 過去のプロジェクトと比較ができる

  87. 手順1. 完了したプロジェク トのFPを求める

  88. 手順2. 完了したプロジェク トの人月を調べる

  89. 1人月あたりの平均FP = FP ÷ 人月

  90. 手順3. 今回のプロジェクト のFPを求める

  91. 必要人月 = 今回のプロジェクトの FP ÷ 1人月の平均FP

  92. ファンクションポイント法のデメリット • ロジックの複雑さを考慮していないので精度が低い • エンジニアの能力差を考慮していないので精度が低い • 過去のプロジェクトの記録がなければ使いづらい

  93. 万能な見積もり手法は存 在しない 捨てるべき幻想

  94. 状況に応じて手法の使い 分けが大事

  95. まとめ • 見積もりは技術 • 推測するな、計測可能にせよ • 人月を求めるために、まずは規模を見積もる • 見積もりの結果は交渉の余地なし •

    ベロシティのノルマを設けるのはダメ絶対!