納期とは遅れるものだ：情マネ流マーフィーの法則（12）

経営環境の変化から、情報システム開発の短納期化が加速している。そんななか、どうやって納期を守っていけばよいのか。今回は納期に関する法則を紹介する。

[木暮 仁，＠IT]

　経営環境の激変や競争の激化から、情報システム開発の短期化・納期の厳守が重要になってきた。また、ソフトウェア開発における工事進行基準の適用によって、進ちょくの把握も重要になってきている。

　しかし、エドワード・ヨードンの『デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか』（日経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版になって帰ってきた！