ソフトウェア見積り
https://images-fe.ssl-images-amazon.com/images/I/41ISjzPazVL.jpg
基本情報
書籍名: ソフトウェア見積り 人月の暗黙知を解き明かす
ページ数: 417
金額: Kindle 3400円+税
発売時期: 2006/10/10
出版社リンク: 不明
ステータス
本の概要
米ソフトウェア業界の第一人者にして、『Code Complete』をはじめ数々の名著で知られるスティーブ・マコネルの待望の最新作。今度は「見積り」を語ります。コスト、スケジュール、工数、品質 … 思いどおりにいくことはまずないプロジェクトの見積り。その裏にある誤解や思い込みを、118のヒントと18の公式を使って解き明かします。「90%確かとはどのくらい確かなのか？」「多すぎる見積りと少なすぎる見積りはどちらがよいか?」「精度と正確さはどう違うのか？」などの身近な話題から、軽快に見積りの本質に迫る知的な面白さは抜群です。ますます冴え渡るマコネルの筆を堪能してください。
本の感想
いままでの見積経験上なんとなく分かっていた（けど人にうまく説明出来ない）ことが体系的に説明されていて非常によかった。
お勧めの読者
ソフトウェア開発の見積りが難しいと感じている人
高すぎる、安すぎる、の根拠を求めている人
見積もった期日に作業を終えられていないと感じている人
期日の見積は無理だと考えている人
扱っている分野
良かった部分を抜粋
https://gyazo.com/9c7e7257935c82a10cdb69a63d4c5012
https://gyazo.com/10048c2ec46cbb554df030e443728b58
表4-3: 見積から一般に見落とされるソフトウェア開発アクティビティ
https://gyazo.com/51ee7c2a82102c04d79ac0588cf2b802
9-1-3: 最良ケースと最悪ケース
https://gyazo.com/f41a6f3c0b0d5fe830566dc545410f86
最初の「一点見積り」と、「最良ケースと最悪ケースの見積り」とを比べると、一点見積りの合計11.25日は、最悪ケースの18.25日より最良ケースの10.5日に非常に近い。また、機能4の見積りを調べてみると、最良ケースと最悪ケースの両方とも、最初の一点見積りよりも大きい値である。最悪ケースについてくまなく考えるうちに、最良ケースにも必要な追加作業が明らかになる場合があり、それが見積り値を大きくするのだ。最悪ケースについてあらゆる場合を考えるとき、すべてが悪い方向に進んだらどれだけ時間がかかるか、私なら開発者に聞いてみる。最悪ケースの見積りでも、真の最悪ケースよりも楽観的な場合が多いものだ。
--スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (Kindle の位置No.2305-2311). Kindle 版.
マーキング
位置No. 552
プロジェクト責任者：プロジェクトに要する期間の見積りは、5か月です。 経営幹部：5か月だと？ オレの説明を聞いていなかったのか。このソフトウェアは、展示会に間に合わせるために3か月で開発しなければならないと言っただろう！
位置No. 581
このプロジェクトの所要期間は14週間である」というように、ソフトウェア見積りは、通常、ある1点（シングルポイント）を特定する数値で表される。このように単純化しすぎた一点見積りは、意味を持たない。なぜなら、そのシングルポイント自体の確率が考慮されていないからだ。一点見積りが示すのは、図1-1のように、そのシングルポイントだけが唯一可能な結果であるという確率である。
https://scrapbox.io/files/6614ad29fe3cc90025b8fb23.png
位置??
プロジェクトの完了は、全体として確率分布に従うことになる。つまり、完了する確度の高いものとそうでないものがあり、分布の中央に位置する集団が最も確度が高いことになる。図にすると、プロジェクトの分布は、図1-2に示すように一般的にベル（釣鐘）型の曲線になる。
https://scrapbox.io/files/6614ad686c7b870025545fa2.png
しかし、確率が中央値（平均値）周辺に対称に分布するという仮説は、正しくない。なぜなら、プロジェクトがうまくいくことには限界があるからだ。分布の左側のしっぽは、ベルのように曲線が伸びた形でなく、切り詰まった形になるはずだ。ただし、プロジェクトがうまくいくことには限界があっても、うまくいかない方は限界がない。そのため、確率分布は右側に極端に長くしっぽが伸びた曲線になる。 図1-3は、ソフトウェアプロジェクトが完了する正しい確率分布を示している。
https://scrapbox.io/files/6614ad93f91421002469d10c.png
位置??
自分がコミットメントを置くところは、見積りの幅の中で楽観的な方でも悲観的な方でも、あるいはその間のどこでもかまわない。大切なのは、自分のコミットメントが幅のある見積りの中でどこに位置するかを知り、それに応じた計画を立てることである。
位置No. 617
重要なことは、明示するしないにかかわらず、あらゆる見積りには確率が含まれているという事実である。確率を明示した見積りは、良い見積りと思ってよい。
位置No. 630
位置No. 788
位置No. 1340
位置No. 1347
前のプロジェクトよりも今回のプロジェクトの方が、生産性が高いだろう。
位置No. 1348
前のプロジェクトではうまくいかないことがいろいろあったが、今回のプロジェクトでは、それほど多くの失敗をしないだろう。
位置No. 1350
難航するプロジェクトについてたくさんの教訓を学んだ。その教訓のおかげで、今度は初めよりもずっと早くプロジェクトを終わらせることができるだろう。
位置No. 1425
即興の見積りは、プロジェクトチームが犯す最も一般的な過ちの1つ
位置No. 1546
「規模の不経済」は、その逆だ。ソフトウェアでは、システムが大きくなるほど単体コストは大きくな> る。 位置No. 1627
もしもプロジェクトが、図5-6の示す各カテゴリで最低ランク（右側の斜線の棒）にあるなら、各カテゴリで最高ランク（左側の網掛けの棒）にあるプロジェクトに比べて、22倍の総工数が必要になる。
位置No. 1652
インタープリタ言語で作業する開発者は、コンパイラ言語で作業する開発者に比べて、おそらく2倍ほども生産的である
位置No. 1670
その分野で非常に低いスキルを持つチームによるプロジェクトが、その分野で非常に高いスキルを持つチームによるプロジェクトの1.51倍の総工数を要する
位置No. 1742
小規模なプロジェクトは、「平準的要員割り当てモデル」（プロジェクト全体を通して同じ人数のチームで作業するモデル）を使用することが多い。
位置No. 1771
進化型納品プロジェクトは、要求が「ほとんどすべて未定」から「ほとんどすべて確定」まで、自由な範囲で事前に定義できる
位置No. 1775
ステージ別納品は、構築の主要部分が始まる前に要求の大部分を定義しようとする方法だ
位置No. 1863
できるときはいつでも、まず数えよう。数えられないときは、計算しよう。判断だけに頼るのは最後の手段だ。
位置No. 1893
統計上、平均値が意味を持つには、最低でも20項目のサンプルが必要
位置No. 1906
位置No. 2022
位置No. 2305
一点見積りの合計11.25日は、最悪ケースの18.25日より最良ケースの10.5日に非常に近い。
位置No. 2318
最良ケースと最悪ケースの見積りを作成して、起こり得るすべての範囲の結果について考えるきっかけ
位置No. 2442
ソフトウェア開発は、着実な詳細化のプロセスである。これは、プロジェクトが先に進むほど見積りの粒度が細かく分解されることを意味している。
位置No. 2474
3つ目のタスクにはもう少し多くの問題があり、その日のうちに終わらせることができなかった。翌朝にさっと片付けられると考えて、その日は終わりにする。ところが翌日、一日が終わる頃になってようやくそのタスクを終え、その日にやるはずだったタスクには手をつけることさえできなかった。そして、その週の終わりには、まるまる1つ分以上のタスクが予定より遅れてしまった ——。
位置No. 2492
開発者は、一点見積りを提供するように頼まれると、無意識に最良ケースの見積りを提示することが多い。
位置No. 2499
10個のタスクをすべて予定どおりに終わらせるには、4分の１を10回掛け合わせなければならないから、0.000095％、つまり約100万分の1の確率だ。
位置No. 2711
見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積りの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積りの価値を下げてしまう。
位置No. 2871
ストーリーポイントを工数やカレンダー時間に換算する方法について、補正の準備をすることができる。これは「ベロシティ（速度）」と呼ばれる 位置No. 2911
技術系ではないステークホルダーは、「不確実性のコーン」の広い部分にいる間に、プロジェクトのスコープについて決定を下そうとする（または下さなければならない）ことが多い。優秀な見積り作成者なら、コーンの広い部分にいる間は精度の高い見積りを提供するのを断る。セールス部門やマーケティング部門のスタッフはこう言うだろう。「どのくらいコストがかかるかわからないのに、その機能がほしいかどうかなんて、わかるわけないだろう？」 優秀な見積り作成者は、こう答える。「もっと詳しい要求作業が終わるまで、どのくらいコストがかかるか言えません」。ここで、両者は行き詰ってしまう。
位置No. 2921
「 Tシャツのサイズ分け」という見積りアプローチ
Tシャツのサイズ分けを使用すると、プロジェクトの初期に不要な機能を除外する決定が下せる。その結果、それらの機能を「不確実性にコーン」の中に持ち込む必要がなくなる。
位置No. 3118
80％から90％へ移るとき、工数が急に大きく増加する
位置No. 3200
位置No. 3241
位置No. 3310
複数の見積りが一致したのに、ビジネスターゲットが一致しなかった場合は、見積りの方をを信頼しよう。
位置No. 3334
しかし通常、見積りを吟味するのは、見積りを抑えたいときであることが多い。言い換えると、吟味することによって見積りを下げようとする下向きのプレッシャーがかかるのだ。これを相殺するような上向きのプレッシャーを持つ要素はない。
位置No. 3405
位置No. 3412
実際に経験したことのある部分を除いて、見積り全体が正確であるとは考え
動機、価格
入手日: 2018/9/23
入手金額: 1836円 （Kindle版が半額セールだった）
入手フォーマット: Kindle
入手動機: 良い見積方法を体系立てて説明している本を人に紹介したかった
動機は満たされたか: はい
関連リンク