納期とは遅れるものだ:情マネ流マーフィーの法則(12)
経営環境の変化から、情報システム開発の短納期化が加速している。そんななか、どうやって納期を守っていけばよいのか。今回は納期に関する法則を紹介する。
経営環境の激変や競争の激化から、情報システム開発の短期化・納期の厳守が重要になってきた。また、ソフトウェア開発における工事進行基準の適用によって、進ちょくの把握も重要になってきている。
しかし、エドワード・ヨードンの『デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか』(日経BP刊)が示しているように、リスクを考慮しない納期設定は深刻な状況になる。
情マネ流マーフィーの法則その64
発注者は納期は絶対だというが、実際に納期が遅れてもさほど問題にならない
大規模プロジェクトでは、納期が遅れるのはむしろ通常である。
それでも何とかやっているのだ。本当に納期が絶対ならば、早期にプロジェクトを開始すべきなのに、納期に間に合わないころになってからスタートする。
スタートしてからも、発注者のニーズはいつになっても確定しない。
情マネ流マーフィーの法則その65
事前にリスクを考慮してスラック(余裕、サバ)を設定すると、リスクが発生しなくてもスラックはなくなる
発注者と受注者の間には不信感がある。
「努力目標1年、リスクを考慮して最長1年半」などというと、何ら努力もせずに半年が過ぎてしまい、努力目標と必須目標が同じになってしまう。
それが分かっている発注者は、「1年厳守」をいい渡す。
そのカラクリを知っている受注者は、「厳守」を「努力目標」と解釈して、1年半の裏スケジュールを作る。さらに、それを知っている発注者はサバを読み、納期を8カ月という。
情マネ流マーフィーの法則その66
着手時期が遅れても納期は絶対である
プロジェクトの提案では、システム稼働時期を「来年4月1日」のようにカレンダー日付で示すことが多い。それは業務の都合からも必要である。
ところが、メンバーの人選やニーズの確定など、発注者側の都合でプロジェクト着手日が3カ月遅れても、稼働時期は「来年4月1日」のままである。
情マネ流マーフィーの法則その67
進ちょく状況報告での用語
順調です | → 大きなリスクがあるが気付いていない |
---|---|
まずまずです | → 何かトラブルが起こっている |
やや遅れています | → 納期遅延は必須な状況 |
努力しています | → トラブル対応で四苦八苦 |
遅れています | → 壊滅的状態 |
情マネ流マーフィーの法則その68
プロジェクトの進ちょく度の表示は、後工程になるに従い小数点が多くなる
情マネ流マーフィーの法則その69
プロジェクト進ちょく度は、一様な増加曲線にはならない
進ちょく度の報告では、50%完成→75%→91%→95.5%となり、最終段階では99.9%とか99.98%などとなる。「九合目は道半ば」というように、99.98%だといっても、後0.02%の時間で完成するのではないことは、誰もが知っている。
「九合目は道半ば」は極端であろう。一般に、1000.5=10、1000.75=32というように、実際の進ちょく度(%表示)=100報告の進ちょく度(小数点表示)と換算すると、実際の進ちょく度に近くなる。
それでも、進ちょく度が次第に大きくなるのならよいのだが、進むに連れて「振り出しに戻る」ことが発覚し、完成までに要する残時間が増大する。すなわち、進ちょく度が下がることもあるのだ。
情マネ流マーフィーの法則その70
トラブルを解決するための時間はあるが、テストする時間はない
これは昔からいわれていた言葉であり、いまさらいうまでもあるまい。
中には、インクリメンタル開発だとして、トラブル解決を「第二次」として予定する開発方法論もある。
情マネ流マーフィーの法則その71
納期と品質には互換性がある
納期を厳しくいえば、手を抜くので品質が悪くなる。
一般に発注者は納期は重視するが、品質は納入されるまで関心を持っていない。それで、実施後トラブルが発生し、真の納期が大幅に遅れるのである。
著者紹介
▼著者名 木暮 仁(こぐれ ひとし)
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」(日科技連出版社)、「もうかる情報化、会社をつぶす情報化」(リックテレコム)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している
- 情マネ流マーフィーの妖誤集〜その3
- 情マネ流マーフィーの妖誤集〜その2
- 情マネ流マーフィーの妖誤集
- 情報科学の法則を復習しよう
- 社会科学法則の「情マネ流マーフィー」への適用
- 自然科学法則の「情マネ流マーフィー」への適用
- コンピュータが発展すると人間はバカになる
- バグとの長い長い付き合い
- なぜソフトウェアの部品化/再利用は進まないのか?
- “バカ・マジメ”をメンバーに入れるな!
- なぜIT部門は提案できない/しないのか?
- ユーザーニーズを基にシステムを作るな
- 成果の出ないIT戦略
- IT技術者、どう評価する?
- 何かが足りない日本のIT教育政策
- 電子政府の研究はIT推進の教科書として最適だ
- 日本にはびこる素人CIO
- IT部門の戦略部門化は矛盾だらけ
- なぜIT部門アウトソーシングがうまくいかないのか?
- IT部門の社内的地位が低い“本当の原因”は?
- 役に立たないグループウェア
- ユーザーの過度体裁愛好症が問題だ
- ユーザーの過度依存症とIT部門の没我的愛情症
- ああ、上司と部下の悲しいすれ違い
- IT系アンケート結果は信用できない
- “クラウドコンピューティング○×”の寿命
- 羊頭狗肉のIT用語、誇大表示を告発する
- そして、歴史は繰り返す − 2度目は喜劇として
- ITエンジニア今昔物語
- “リスク管理のリスク管理”が必要だ
- 納期とは遅れるものだ
- ITの効果とはプロジェクトの効果だ
- 費用対効果を追求することで出銭が増える愚かさ
- そもそも、IT計画が実現すること自体が奇跡だ
- 経営者にITの費用対効果を説明するのは難しい
- ERPパッケージの不思議あれこれ
- 合併時の代理戦争には気を付けろ!
- ないものねだりのRFP
- 標準化にメリットはあるのか?
- システム開発の可視化で何が見える?
- 「他人のふんどし指向アプローチ」を考える
- マーフィーの法則がIT版になって帰ってきた!
Copyright © ITmedia, Inc. All Rights Reserved.