最近行った見積りを上司から詰めに詰められ辛かったため、何かヒントを求めて読んでみましたが、自分がソフトウェア見積りについて何もわかっていなかったことを知ることができました。
見積りを行う前に読んでいたらどれだけ良かったかと悔やむ気持ちです。
次回見積りを行うときは本書の内容を参考に取り組んでみたいです。
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
ソフトウェア見積り 単行本 – 2006/10/7
- 本の長さ321ページ
- 言語日本語
- 出版社日経BP
- 発売日2006/10/7
- ISBN-10489100522X
- ISBN-13978-4891005221
この商品をチェックした人はこんな商品もチェックしています
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
登録情報
- 出版社 : 日経BP (2006/10/7)
- 発売日 : 2006/10/7
- 言語 : 日本語
- 単行本 : 321ページ
- ISBN-10 : 489100522X
- ISBN-13 : 978-4891005221
- Amazon 売れ筋ランキング: - 421,939位本 (本の売れ筋ランキングを見る)
- - 8,919位電気・通信 (本)
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
星5つ中4.5つ
5つのうち4.5つ
全体的な星の数と星別のパーセンテージの内訳を計算するにあたり、単純平均は使用されていません。当システムでは、レビューがどの程度新しいか、レビュー担当者がAmazonで購入したかどうかなど、特定の要素をより重視しています。 詳細はこちら
86グローバルレーティング
虚偽のレビューは一切容認しません
私たちの目標は、すべてのレビューを信頼性の高い、有益なものにすることです。だからこそ、私たちはテクノロジーと人間の調査員の両方を活用して、お客様が偽のレビューを見る前にブロックしています。 詳細はこちら
コミュニティガイドラインに違反するAmazonアカウントはブロックされます。また、レビューを購入した出品者をブロックし、そのようなレビューを投稿した当事者に対して法的措置を取ります。 報告方法について学ぶ
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2024年5月5日に日本でレビュー済み
Amazonで購入
2024年2月19日に日本でレビュー済み
大規模プロジェクトが主体の見積り方法である。非常にわかりやすく考察されており、訳についても特に違和感を感じなかった。プログラマよりはSIerのような、混沌としたプロジェクトのオーナーに読んでもらうと価値がある気がする。
2022年8月7日に日本でレビュー済み
Amazonで購入
見積りがいかに難しいかを説いてくれます。
PMや顧客の期待に応えようと少なめの見積もりを提示をしてしまう開発者に読んでほしいです。
多めの工数は間違っていないです。むしろ積極的に工数を盛っていこうという気持ちになり、気が楽になります。
PMや顧客の期待に応えようと少なめの見積もりを提示をしてしまう開発者に読んでほしいです。
多めの工数は間違っていないです。むしろ積極的に工数を盛っていこうという気持ちになり、気が楽になります。
2018年3月6日に日本でレビュー済み
Amazonで購入
本書は開発者やマネージャーを対象として、ソフトウェア見積りの正確性を上げるため、およびプロジェクトの特性を見積もるために有益なアドバイスを提供する。
例えば、以下のような内容。
■見積りとは: 「見積り」と「ターゲット」と「コミットメント」は別。
「ターゲット」は、実現したいビジネス上の目標を明文化したもの(例:年末までにVer.1をリリース)。
「コミットメント」は、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束。
「見積り」は、期間やコストを予測することだが、開発に影響を与える要素とコントロールとの間の相互作用として変わり得るもの。
これを念頭に置き、見積りを求められたときには、実際に見積りを行うのか、ターゲットの達成方法を尋ねられているのかを判断することが重要。
■良い見積り: プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積り。
■見積りの基本: 数えられるものは、まず数える。数えた結果は、専門家の判断によって調整すべきではない。
過去のデータを使用するときは、次のプロジェクトと前のプロジェクトが同じように進むことを前提とする(生産性の改善を期待しない)。
タスクレベルで見積もる場合は、長くても2日程度のタスクに分解する。
最良ケースと最悪ケースの見積りを作成し、最初の1点見積りがその範囲に含まれるか確認する(他にも最良/最悪を使う手法がある)。
■見積り誤差の要因と対策:
①プロジェクト自身に関する不正確さ
②プロジェクトを遂行する組織の能力に関する不正確さ
③プロジェクト内の混乱、ターゲットの変更
④見積りプロセス自体の不正確さ
誤差を減らすことは、プロジェクト内のばらつきを減らすことであり、それには各フェーズにおいて、する/しないことのコミットメントが必要である。
要求の増大による影響が大きいならば、見積りではなくプロジェクトコントロールによる対策が望ましい。
■過小見積りの悪影響: 計画の有効性の減少、後工程の品質問題、遅延した場合の想定外のアクティビティによる悪循環、等々。過小見積りは、過大見積りよりも深刻な問題を齎す。
当初読み始めたときは即効性を求めて具体的な見積り技法を期待して読んだ。
実際、様々な技法をどのように使うかも記載されているが、それ以上に、根本的なことに説明している箇所が参考になった。
例えば、数えられるものは数える、見積りは点ではなく幅である、見積りを正確に行う前に見積りを多くする(過小見積りを避ける)など。
会社としてのやり方に左右される部分もあるため、全て取り入れるのは難しいが、これらのことを意識して見積もりを行う態度がエンジニアに必要だと感じた。
開発見積りを行う人であれば誰にでもお勧めしたい。
例えば、以下のような内容。
■見積りとは: 「見積り」と「ターゲット」と「コミットメント」は別。
「ターゲット」は、実現したいビジネス上の目標を明文化したもの(例:年末までにVer.1をリリース)。
「コミットメント」は、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束。
「見積り」は、期間やコストを予測することだが、開発に影響を与える要素とコントロールとの間の相互作用として変わり得るもの。
これを念頭に置き、見積りを求められたときには、実際に見積りを行うのか、ターゲットの達成方法を尋ねられているのかを判断することが重要。
■良い見積り: プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積り。
■見積りの基本: 数えられるものは、まず数える。数えた結果は、専門家の判断によって調整すべきではない。
過去のデータを使用するときは、次のプロジェクトと前のプロジェクトが同じように進むことを前提とする(生産性の改善を期待しない)。
タスクレベルで見積もる場合は、長くても2日程度のタスクに分解する。
最良ケースと最悪ケースの見積りを作成し、最初の1点見積りがその範囲に含まれるか確認する(他にも最良/最悪を使う手法がある)。
■見積り誤差の要因と対策:
①プロジェクト自身に関する不正確さ
②プロジェクトを遂行する組織の能力に関する不正確さ
③プロジェクト内の混乱、ターゲットの変更
④見積りプロセス自体の不正確さ
誤差を減らすことは、プロジェクト内のばらつきを減らすことであり、それには各フェーズにおいて、する/しないことのコミットメントが必要である。
要求の増大による影響が大きいならば、見積りではなくプロジェクトコントロールによる対策が望ましい。
■過小見積りの悪影響: 計画の有効性の減少、後工程の品質問題、遅延した場合の想定外のアクティビティによる悪循環、等々。過小見積りは、過大見積りよりも深刻な問題を齎す。
当初読み始めたときは即効性を求めて具体的な見積り技法を期待して読んだ。
実際、様々な技法をどのように使うかも記載されているが、それ以上に、根本的なことに説明している箇所が参考になった。
例えば、数えられるものは数える、見積りは点ではなく幅である、見積りを正確に行う前に見積りを多くする(過小見積りを避ける)など。
会社としてのやり方に左右される部分もあるため、全て取り入れるのは難しいが、これらのことを意識して見積もりを行う態度がエンジニアに必要だと感じた。
開発見積りを行う人であれば誰にでもお勧めしたい。
2019年3月10日に日本でレビュー済み
Amazonで購入
プロジェクトは炎上するもの、プロジェクトマネージャは無茶なスケジュールを押し付けてくるもの、そういうものだと諦めてしまった開発者にこの本を勧めたい。
この本には、如何にソフトウェア開発のスケジュールが遅れがちであるか、その原因はなんであるかが明確に書かれている。それは開発に必要な作業を漏れなく計上する事が難しい事と、開発に関わる人間、即ち経営陣、プロマネ、開発者がそれぞれ「不可能だとは証明できない最短の納品日」を約束する動機を持っている事による。
さらにこの本では、ソフトウェア開発はソフトウェアの詳細に関わる決定の連続であり、何も決まっていないうちに見積もりを出すことは原理的に不可能である事が示され、ではどうやってプロジェクトの初期に見積もりを出したらいいのか、いわゆる「無茶ぶり」と付き合うための方法など、開発者なら日常的にぶつかる難問への著者なりの答えが載っている。それはプロジェクト初期に無理なスケジュールを出すのではなく、可能な正確さを表す幅のある見積もりを出し、スケジュールの短縮要望にはリリースの分割や不要な機能の削除など、「開発者の恒常的な残業」以外の選択肢をきちんと示す事である。
プロジェクトマネジメントを学んだことのない人がいきなりこの本を読んだら、間違いなく開発の進め方が大きく変わるだろう。自分は最近プロジェクトマネジメントの仕事を始めたのだが、この本がなければ、ソフトウェア開発の見積もりを出すことができなかったと思う。
かなり昔に書かれた本だが、素晴らしいと思う。
この本には、如何にソフトウェア開発のスケジュールが遅れがちであるか、その原因はなんであるかが明確に書かれている。それは開発に必要な作業を漏れなく計上する事が難しい事と、開発に関わる人間、即ち経営陣、プロマネ、開発者がそれぞれ「不可能だとは証明できない最短の納品日」を約束する動機を持っている事による。
さらにこの本では、ソフトウェア開発はソフトウェアの詳細に関わる決定の連続であり、何も決まっていないうちに見積もりを出すことは原理的に不可能である事が示され、ではどうやってプロジェクトの初期に見積もりを出したらいいのか、いわゆる「無茶ぶり」と付き合うための方法など、開発者なら日常的にぶつかる難問への著者なりの答えが載っている。それはプロジェクト初期に無理なスケジュールを出すのではなく、可能な正確さを表す幅のある見積もりを出し、スケジュールの短縮要望にはリリースの分割や不要な機能の削除など、「開発者の恒常的な残業」以外の選択肢をきちんと示す事である。
プロジェクトマネジメントを学んだことのない人がいきなりこの本を読んだら、間違いなく開発の進め方が大きく変わるだろう。自分は最近プロジェクトマネジメントの仕事を始めたのだが、この本がなければ、ソフトウェア開発の見積もりを出すことができなかったと思う。
かなり昔に書かれた本だが、素晴らしいと思う。
2016年7月24日に日本でレビュー済み
Amazonで購入
適当過ぎるIt業界。
作る側も、作らせる側も、適当過ぎる。
こういった、参考になる本が、もっと山の様に出てくるようになってほしい。
作る側も、作らせる側も、適当過ぎる。
こういった、参考になる本が、もっと山の様に出てくるようになってほしい。
2019年10月24日に日本でレビュー済み
Amazonで購入
見積もりの定義と目的から始まり、見積もりの傾向、誤差を生み出す原因や実践的な手法まで説明している。良書であった。
2018年9月30日に日本でレビュー済み
Amazonで購入
システム開発に関わる人全てが一回は読んでおいた方がいいです。
KKDのような原始時代の方法論で止まっている人には、無理矢理にでも読ますべきでしょう。
KKDのような原始時代の方法論で止まっている人には、無理矢理にでも読ますべきでしょう。