次回の社内勉強会では「見積について」やることになっている。
前回は座学だったが、１時間半もぶっ続けでは少々退屈した方もいると思うので、
次回はみんなで考えながら話しながらできるものを考えている。
次回のネタをメモっておく。
■参加者全員でプランニングポーカーをやるぞ！
- うちの会社の標準的な BSP 開発を例にとって、みんなで機能の抽出と、個々の機能のストーリーポイント見積をワイワイガヤガヤやれたらいいな。
- （10 名くらいだから）トランプは使わず、挙手でホワイトボードに書いていこう。
- BSP 未経験者は、どんなことをやったらいいのかわかるし。
- 社内で工数イメージの意識あわせもできる。
- スクラムのことを少し知ってもらうきっかけにもなるかな？
- 持ち時間 45 分でちょうどか、足りないくらい、だろうな。
- 説明には @kawaguti さんの「プランニングポーカー かんたんガイド」を使わせていただこう。コンパクトでちょうどよい。
が、見積のことは、いっぱい話したいことがあるのだ！ もう少し他のこともやりたい。
まずは、そもそも見積とはどういうことなのか、一体何をやっているということのか、見積りの正体とは！？
というあたりの話を一度しておきたい。見積手法より、まずはこちらだ。
こんなに怖い見積の話とかｗ、なぜ見積は当たらないのかｗ、みたいなタイトルで。
軽くまとめておいて、話ができなくても資料配布くらいしたいと思っている。
興味を持ってくれて、話を聴きたい、って言ってくれる人があればいい。
なので、ラフなメモ書きｗ。 (C)あきぴーさん
内容は、『ソフトウェア見積り―人月の暗黙知を解き明かす』の第１部から抜粋しよう。
社内勉強会では（コミュニティの勉強会と比べると）、個人の経験や考えを聴きたい、というよりは
一般論としては、世の中ではどうなの？ という要望が勝っているように感じる。
だから、説得力を持たせるために、本を使う等の「権威の力を借りる」のは大事なことだ。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■はじめに
100% 予想通りの見積りは、ありえますか？
図1-1を引用 ←こんなことないでしょ？
実際は「確率分布」に従う ←あくまで未来の予想なのだから
図1-3を引用
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■見積りの精度・正確さとは？
ソフトウェアの見積りは、
しばしば 100% あるいはそれ以上に不正確であることが、多くの調査でわかっている。
開発者が作る見積りは、一般に実際の工数よりも 20～30% 低くなる。
図3-3を引用
→ソフトウェア業界には過小見積りの問題がある
過小見積りは、ひとたび遅延が発生すると、プロジェクトをさらに破壊する。
⇒まず見積りをもっと多くすることから始める必要がある！
◇プレッシャーその１
経営者も、マネージャも、より早くかつより安くを確実に望んでいる。
顧客の期待値が見積り値に大きな影響を及ぼす、無意識のうちにそうした影響を受けている。
顧客やマネージャが見積りとビジネスターゲットの不一致に気付いた場合、
見積りやプロジェクトやプロジェクトチームに対して実際にプレッシャーをかける。
巨大プロジェクトの 75～100% で発生している。
⇒正確＝小さく、少なく ではない！
◇プレッシャーその２
スケジュールが極端に切迫している場合、そこでリリースされたソフトウェアは、
切迫していない状況で開発されたソフトウェアに比べて、約４倍もの欠陥が報告されている。
過度のスケジュールの切迫は、きわめて費用がかかり間違いの発生しやすいモジュールができる最大の原因であることがわかっている。
欠陥を最小限に抑えることを当初から目標の１つに掲げるプロジェクトは、
スケジュールに関しても最短を求める傾向にある。
ソフトウェアのエラーの約 40% はストレスによって引き起こされる。
⇒「締め切りのプレッシャーこそがソフトウェアエンジニアリングの最大の敵である」
「詰め込みすぎたスケジュールや不合理なスケジュールが、すべてのソフトウェアに最も破壊的な影響を与えている」
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■見積りはなぜ不確実なのか？
ソフトウェア開発とは、機能に関する全ての問題について意思決定をするプロセスである。
それぞれの決定がなされる方法が持つ不確実性が、ソフトウェア見積りの不確実性を引き起こす。
不確実性のコーン 図4-2
考えられる限り最良の正確な見積もり
適切に運営されているプロジェクトでさえ不確実性が内在することを表している。
→もっと悪くすることはいとも簡単だが、逆にもっと正確にすることは不可能だ。
考慮漏れ＝設計が不十分 →やってみなければわからないことがある
コーンが初期の広い部分では、有意義なコミットメントは不可能だ。
コーンが収束するのは、ばらつきを取り除くための意思決定をした場合だけだ。
⇒これらの問題に対処する最良の方策は、見積りではなく、より良いプロジェクトコントロールにある
⇒良い見積もりプラクティスを行えば、混乱したプロジェクトを正確に見積もれると思ってはいけない。
⇒コントロール不能なプロセスを正確に見積もることは不可能だ。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■見積り誤差はなぜ起きるのか？
見積り誤差の最も一般的な原因の１つは、必要な作業を入れ忘れることだ。
開発者は忘れずに見積りをした作業についてはかなり正確に見積もるが、
それでも必要な作業の 20～30% を見落とす傾向にある。
例）
非機能要求
メンバーの立ち上げ
メンバーの指導
マネージメントとの調整
インストール
顧客のインストールのサポート
ビルド
テストデータの作成
バグ修正作業
チューニング
質問への回答
デモ
計画や見積り
PC のセットアップ、ツールのインストール、及びそれらのトラブルシューティング
休暇、病欠、会社のミーティングやトレーニング
開発者の見積りには 20～30% の楽観的要因が含まれる。
「開発者によって作られる見積りが悲観的になるのではないかと恐れる必要はない。
なぜなら開発者は、常に楽観的すぎるスケジュールを生み出すものだからだ」
（Microsoft副社長 Chris Peters）
⇒即興の見積りはしないことだ。
直感と推測は、どちらもコストとスケジュール超過に関係する
※即興の見積りを避けることが、本書で解説する最も重要な点の１つでもある。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■見積りに影響するもの
→プロジェクトに影響するもの
（上位３つ）
・プロジェクトの規模→規模の不経済
最も小さいプロジェクトと最も大きいプロジェクトを比べると、生産性は 5～10倍も変わる
規模が大きくなるにつれて、工数も直線的にスケールアップしない、指数関数的にアップする
・ソフトウェアの種類（ドメイン（業種））
・人的要因
スキルや経験の有無、継続性（離職率）
→誰が行うのかわからなければ、正確に見積もることができないことを意味する
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
■まとめ的なこと
以下の登場人物で、絵にまとまるかな...。
- 予測
- リスク
- 見積り
- ターゲット
- コミットメント
- スケジュール
- コントロール
- 現実
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
先の本には、「見積をコミットメントにしない」と書いてはあるが、実際のところは
自分たちの見積で、納期も金額も決まってしまうのだ。
これでやると言っただろう、責任持って間に合わせろよ、となるのだ。
もちろん状況に応じてコントロールはするけども。
結果、それで納期や金額が変わってしまう方向になれば、「見積のときと話が違う」となりかねない。
だから、よくわかっているとは思うのだけど、
安易な見積はしない、自分たちを守るためにもっとよく考えないと、というのを
一度言っておきたい、と思うのだ。
＃コミットメント料が増えるよ、と言われそうだけどね。
