软件开发工期估算系列(2)——今でも簡単に適用できる30年以上前の見積もり技法
2011-06-16 22:26
447 查看
http://monoist.atmarkit.co.jp/mn/articles/1106/16/news009.html
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
前回からお届けしている“見積もり・シリーズ”では、「見積もりの目的(正確に見積もるだけでは不十分)」「見積もりの具体的な方法(精度を上げるため、少なくとも2つ以上の方法で見積もる必要がある)」「見積もりの応用(見積もり値に合わせる制御と再見積もり)」「見積もりの調整(状況に応じて開発量とスケジュールを再見積もりしなければならない)」について、具体的に解説していきます。
シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、
昔の見積もり=現在の見積もり
である場合がほとんどです。
※注1:『人月の神話(The Mythical Man-Month:Essays on Software Engineering)』(1975年、1995年、2002年)/フレデリック・P・ブルックス Jr.(著)、滝沢徹ほか(訳)/ピアソンエデュケーション(出版社)
1963~1966年、IBMは「OS/360」の開発に取り組みました。これは、本格的に仮想記憶を採用したメインフレーム用のOSで、有史以来、人類が経験したプロジェクトの中で、圧倒的に複雑で巨大なソフトウェアだといわれています。全部で5000人年を超える人月を投入したので、現在の金額にして約600億円もかかったことになります。ピーク時には、1000人以上のエンジニアが開発に従事したそうです。単純計算で、開発ステップ数は50MLOCを超えるでしょう。現在、最も複雑怪奇なソフトウェアといえる携帯電話用のプログラムでおよそ10MLOCもありますが、それよりはるかに巨大なプログラム規模だったのです。もちろん、記述言語は全てアセンブラでした。
当時は、“ソフトウェア工学”という言葉さえなく(注2)、「どうすれば高品質なプログラムを安く・早く開発できるか」という課題を手探りで模索していました。今なら、5000人年もかかる超巨大プロジェクトは、立ち上げた3秒後に壊滅しますので、誰も立ち上げようと思いませんが、当時はソフトウェア工学が未熟な時代だった故に、力任せに進めたのでしょう。OS/360は、ビジネス的には大成功し、IBM発展の基礎を築きましたが、ソフトウェア開発の面から見るとかなり厳しい状況であったことが想像できます。同書の行間から、何の武器も持たず素手で恐竜に立ち向かい、何万人もの犠牲を出しながら恐竜と格闘するような悲惨な様子がにじみ出ています。
1975年、この巨大ソフトウェア開発のプロジェクト・マネジャーだったブルックスが、プロジェクトで起きた不可解な現象、大事件、失敗から得た貴重な教訓・法則を回想し、臨場感溢れる筆致でつづったのが『人月の神話』です。その内容は、30年以上たった現在でも、そのまま当てはまるものが少なくありません。
※注2:「ソフトウェア工学」が初めて出版物に登場したのは、1968年のNATOの会議でした。“Engineering”は、日本語にすると、必ず(あるいは、自動的に)“工学”と訳されますが、私の経験ですと80%の確率で“開発”と訳す方が適切です。
以下に、見積もりに関するブルックスの法則を紹介します。
これは極端な例なので、36人投入すれば1カ月でできるとは誰も思わないでしょうが、6人×8カ月=8人×6カ月と考える人は少なくありません。発注側はもちろんのこと、ソフトウェア開発を担当するプロジェクト・マネジャーでさえも、この“交換”が可能だと考えている人はたくさんいます。開発期間を10%以上短縮することは、長時間残業では対応不可能で、ましてや、「やる気があれば何でもできる!!」といった“根性論”は論外です。
従って、開発期間を50%短縮するには、人員を4倍に増やす必要があります。すなわち、
となります。ここで注意すべきは、1.開発期間を半分にすると、コストが2倍になること、2.品質が悪くなることの2点です。
開発期間を半分にすると、コストが2倍になるだけでなく、品質も最悪になります。これは、30年以上前に指摘されていることです。従って、「それでも、開発期間を半分にしたいのか?」という議論になります。実際、この“30年以上前の法則”をキチンと理解して適用しているプロジェクト・マネジャーはほとんどいないと思われます。まずは、「開発期間の短縮は“ものすごく大変”であること」を十分認識する必要があります。
次回、“見積もり・シリーズ”第3回では「見積もりの基本知識」について解説します。お楽しみに! (次回に続く)
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
前回からお届けしている“見積もり・シリーズ”では、「見積もりの目的(正確に見積もるだけでは不十分)」「見積もりの具体的な方法(精度を上げるため、少なくとも2つ以上の方法で見積もる必要がある)」「見積もりの応用(見積もり値に合わせる制御と再見積もり)」「見積もりの調整(状況に応じて開発量とスケジュールを再見積もりしなければならない)」について、具体的に解説していきます。
シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、
昔の見積もり=現在の見積もり
である場合がほとんどです。
最初で最後の超巨大ソフトウェア開発プロジェクト
度々、本連載で、フレデリック・ブルックス著の『ソフトウェア開発の神話(第2版から「人月の神話」)』(注1)を取り上げていますが、今回もこの“永遠の名著”から始めたいと思います。関連商品 |
---|
人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))Amazon.co.jpで買う |
1963~1966年、IBMは「OS/360」の開発に取り組みました。これは、本格的に仮想記憶を採用したメインフレーム用のOSで、有史以来、人類が経験したプロジェクトの中で、圧倒的に複雑で巨大なソフトウェアだといわれています。全部で5000人年を超える人月を投入したので、現在の金額にして約600億円もかかったことになります。ピーク時には、1000人以上のエンジニアが開発に従事したそうです。単純計算で、開発ステップ数は50MLOCを超えるでしょう。現在、最も複雑怪奇なソフトウェアといえる携帯電話用のプログラムでおよそ10MLOCもありますが、それよりはるかに巨大なプログラム規模だったのです。もちろん、記述言語は全てアセンブラでした。
当時は、“ソフトウェア工学”という言葉さえなく(注2)、「どうすれば高品質なプログラムを安く・早く開発できるか」という課題を手探りで模索していました。今なら、5000人年もかかる超巨大プロジェクトは、立ち上げた3秒後に壊滅しますので、誰も立ち上げようと思いませんが、当時はソフトウェア工学が未熟な時代だった故に、力任せに進めたのでしょう。OS/360は、ビジネス的には大成功し、IBM発展の基礎を築きましたが、ソフトウェア開発の面から見るとかなり厳しい状況であったことが想像できます。同書の行間から、何の武器も持たず素手で恐竜に立ち向かい、何万人もの犠牲を出しながら恐竜と格闘するような悲惨な様子がにじみ出ています。
1975年、この巨大ソフトウェア開発のプロジェクト・マネジャーだったブルックスが、プロジェクトで起きた不可解な現象、大事件、失敗から得た貴重な教訓・法則を回想し、臨場感溢れる筆致でつづったのが『人月の神話』です。その内容は、30年以上たった現在でも、そのまま当てはまるものが少なくありません。
※注2:「ソフトウェア工学」が初めて出版物に登場したのは、1968年のNATOの会議でした。“Engineering”は、日本語にすると、必ず(あるいは、自動的に)“工学”と訳されますが、私の経験ですと80%の確率で“開発”と訳す方が適切です。
見積もりでの「ブルックスの法則」
同書でブルックスは、「遅延プロジェクトに人員を投入すると、さらに遅れる」のような意外性とインパクトのある箴言(しんげん)をたくさん残しました。これが、いわゆる「ブルックスの法則」で、30年以上たった現代のソフトウェア開発でも、そのまま当てはまるものが少なくありません。以下に、見積もりに関するブルックスの法則を紹介します。
(1)工数の「人数」と「月数」は交換可能ではない
通常、開発量を見積もるとき、工数(人月)を予測し、その人月からコストを算出します。しかし、この人月が“くせ者”で、「人」と「月」は交換可能ではありません。例えば、例:
3人 × 12カ月 ≠ 36人 × 1カ月これは極端な例なので、36人投入すれば1カ月でできるとは誰も思わないでしょうが、6人×8カ月=8人×6カ月と考える人は少なくありません。発注側はもちろんのこと、ソフトウェア開発を担当するプロジェクト・マネジャーでさえも、この“交換”が可能だと考えている人はたくさんいます。開発期間を10%以上短縮することは、長時間残業では対応不可能で、ましてや、「やる気があれば何でもできる!!」といった“根性論”は論外です。
(2)開発要素の短縮が10%以内の場合、他の開発要素をそれだけ増やす
ソフトウェアの開発要素とは、「人数」「期間」「コスト」です。10人×10カ月のプロジェクトを9カ月で完成させるには、コスト、あるいは、人数を10%増やす、すなわち、11人に増員する必要があります。単なる長時間残業や休日出勤だけでは対応できないことに注意すべきです。(3)開発要素の短縮が10%以上の場合、「n2分の1の法則」を適用する
デスマーチ・プロジェクトのように、開発期間を半分以下に短縮されたプロジェクトに適用できるのがこの法則です。開発期間をn%短縮したい場合、人員をn2分の1増員すべきというものです。従って、開発期間を50%短縮するには、人員を4倍に増やす必要があります。すなわち、
例:
12人 × 12カ月(144人月) = 48人 × 6カ月(288人月)となります。ここで注意すべきは、1.開発期間を半分にすると、コストが2倍になること、2.品質が悪くなることの2点です。
1.開発期間を半分にすると、コストが2倍になる
上記の例の場合、投入人員が4倍になるので、工数は2倍、当然、コストも2倍になることを明確に意識する必要があります。それ以前に、開発期間を半分にすることは、ほとんどのプロジェクトで不可能でしょう。この理論的な理由は、以降の連載で解説します。2.開発期間短縮すると、品質が悪くなる
品質を確保するには“時間”が必要です。正常機能やエラー対応処理の検証は、大勢のテスト要員を投入すれば期間短縮が可能でしょうが、組み合わせテスト、タイミング関係、長時間連続稼働などは、時間がかかります。「そこを何とかするのが、プロジェクト・マネジャーとしての君の責務だろう!!」と上司に言われても、テストの実施方式をいかに工夫しても、品質確保にはある程度の時間が必要です。開発期間を半分にすると、コストが2倍になるだけでなく、品質も最悪になります。これは、30年以上前に指摘されていることです。従って、「それでも、開発期間を半分にしたいのか?」という議論になります。実際、この“30年以上前の法則”をキチンと理解して適用しているプロジェクト・マネジャーはほとんどいないと思われます。まずは、「開発期間の短縮は“ものすごく大変”であること」を十分認識する必要があります。
次回、“見積もり・シリーズ”第3回では「見積もりの基本知識」について解説します。お楽しみに! (次回に続く)
相关文章推荐
- 软件开发工期估算系列(5)——規模見積もりの王様「LOC見積もり」 ~見積もりの基本技法 その2
- 软件开发工期估算系列(4)——勘・経験・度胸による「類推法」 ~見積もりの基本技法 その1
- 软件开发工期估算系列(3)——見積もり値の「幼虫」「サナギ」「成虫」
- 软件开发工期估算系列(1)——正確な見積もりはデスマーチ・プロジェクトを救うか?
- 软件开发工期估算系列(7)——規模見積もりの女王様「FP見積もり」【後編】(内附FP简易算法示例)
- 软件开发工期估算系列(6)——規模見積もりの女王様「FP見積もり」【前編】
- 嵌入式底层软件开发学习系列之六软件工程
- SaaS系列介绍之十四: SaaS软件开发分析
- 敏捷开发生态系统系列之四:计划跟踪II(自组织团队-开发团队自己估算-PO挑战估算-同行压力)
- 为什么软件开发工期预估都不靠谱
- 软件工程系列-软件开发的需求分析
- 敏捷开发一千零一问系列之二十一:怎样写设计?(教育软件案例)
- 为什么软件开发工期预估都不靠谱
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 系列目录
- 基于Azure的软件部署和开发系列沙龙
- 【雨松MOMO】Android 软件开发与游戏开发1 至 32系列博文大合集
- 影响软件开发时间估算有哪些方面
- 敏捷开发生态系统系列之四:计划跟踪II(自组织团队-开发团队自己估算-PO挑战估算-同行压力)
- 项目规模估算失准 软件开发成空中楼阁
- 更新完畢[轉]31個iPhone软件开发实例教程, 此系列教程幾乎全部使用Utility模板