スタートページ主張・講演 マーフィーの法則(vol.2)はじめに・目次

Murphyology on Information Technology (vol.2) 2000s

09 プロジェクト管理

予算は削られ納期は短く、要件は猫に目のように変更される。プロジェクトマネージャのストレスはたまるばかりだ。それでもプロジェクトマネージャはITrの人気職種だ。


納期管理(2008/10/22)

経営環境の激変や競争の激化から、情報システム開発の短期化・納期の厳守が重要になってきた。また、ソフトウェア開発における工事進行基準の適用によって、進ちょくの把握も重要になってきている。
 しかし、エドワード・ヨードンの『デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか』が示しているように、リスクを考慮しない納期設定は深刻な状況になる。

発注者は納期は絶対だというが、実際に納期が遅れてもさほど問題にならない
 大規模プロジェクトでは、納期が遅れるのはむしろ通常である。
 それでも何とかやっているのだ。本当に納期が絶対ならば、早期にプロジェクトを開始すべきなのに、納期に間に合わないころになってからスタートする。
 スタートしてからも、発注者のニーズはいつになっても確定しない。
事前にリスクを考慮してスラック(余裕、サバ)を設定すると、リスクが発生しなくてもスラックはなくなる
 発注者と受注者の間には不信感がある。「努力目標1年、リスクを考慮して最長1年半」などというと、何ら努力もせずに半年が過ぎてしまい、努力目標と必須目標が同じになってしまう。それが分かっている発注者は、「1年厳守」をいい渡す。
 そのカラクリを知っている受注者は、「厳守」を「努力目標」と解釈して、1年半の裏スケジュールを作る。さらに、それを知っている発注者はサバを読み、納期を8カ月という。
着手時期が遅れても納期は絶対である
 プロジェクトの提案では、システム稼働時期を「来年4月1日」のようにカレンダー日付で示すことが多い。それは業務の都合からも必要である。
 ところが、メンバーの人選やニーズの確定など、発注者側の都合でプロジェクト着手日が3カ月遅れても、稼働時期は「来年4月1日」のままである。
進ちょく状況報告での用語
・順調です → 大きなリスクがあるが気付いていない
・まずまずです → 何かトラブルが起こっている
・やや遅れています → 納期遅延は必須な状況
・努力しています → トラブル対応で四苦八苦
・遅れています → 壊滅的状態
プロジェクトの進ちょく度の表示は、後工程になるに従い小数点が多くなる
系:プロジェクト進ちょく度は、一様な増加曲線にはならない
 進ちょく度の報告では、50%完成→75%→91%→95.5%となり、最終段階では99.9%とか99.98%などとなる。「九合目は道半ば」というように、99.98%だといっても、後0.02%の時間で完成するのではないことは、誰もが知っている。
 それでも、進ちょく度が次第に大きくなるのならよいのだが、進むに連れて「振り出しに戻る」ことが発覚し、完成までに要する残時間が増大する。すなわち、進ちょく度が下がることもあるのだ。
トラブルを解決するための時間はあるが、テストする時間はない
 これは昔からいわれていた言葉であり、いまさらいうまでもあるまい。
 中には、インクリメンタル開発だとして、トラブル解決を「第二次」として予定する開発方法論もある。
納期と品質には互換性がある
 納期を厳しくいえば、手を抜くので品質が悪くなる。
 一般に発注者は納期は重視するが、品質は納入されるまで関心を持っていない。それで、実施後トラブルが発生し、真の納期が大幅に遅れるのである。

リスク管理(2008/12/11)

プロジェクト運営において、リスク管理が重要なことはいうまでもない。ところが、実際にリスク管理を実施するには、多くの阻害要因がある。リスク管理のリスク管理が必要なのかもしれない。

リスク管理は大人のプロジェクトマネジメントだ(デマルコ/リスター)
 バラ色のプロジェクトを描いて猪突(ちょとつ)猛進するのは子どもだ。大人は状況をよく観察して、トラブルが起こったときの対策を、あらかじめ検討しておく必要がある。
リスク無視は身の保全に役立つ
 では、どうしてリスク管理が行われないのか?
 無謀な猪突猛進は果敢な挑戦のようにも見えてカッコいい。「困難だから立ち向かうのだ」「やればできる。必勝の信念が大切だ」といえば立派に見える。「勇将の下に弱卒なし」の錯覚により、メンバーの士気も高まる。それで成功することもある。失敗し玉砕しても「努力はした。運が悪かった」と評価される。
 それに対して、リスクを指摘するのはプロジェクトそのものへの反対意見だと受け取られる。「そんなことをいうと、この案件は通らない」「マイナス思考は敗北主義だ」「メンバーの士気をくじくな」と非難される。
 懸念したリスクが現実に発生して失敗したとき、リスク重視者が先見の明があったと評価されることはない。「あいつが、あんなことをいうから、実際に起こってしまった」といわれる。
リスク探索が不十分なことによるリスクを重視せよ
(ヨイショと口に出せばギックリ腰にはならない)
 気付いたリスクは発生しない。致命的なインシデントになるのは、事前に気付かなかったリスクである。
重要なリスクは無視される
 「プログラム作成の遅れ」や「ハードウェアの性能が不十分」などは、リスクリストに掲げられる。ところが、「社長交替」「ベンダ倒産」のようなプロジェクトそのものに深刻な影響を及ぼすリスクは、リストに掲げられることすらない。
リスクを重視すると、カンと度胸の決定が求められる
 多数のリスクを列挙し、その影響を多様に検討すると、プロジェクトの費用対効果のバラツキが大きくなる。そのような状況で合理的な意思決定をするのは困難である。
(少なくとも行政では)リスクの発生確率は0か1の値だけになる
 リスクの大きさは「リスクの発生確率×リスクが発生したときの損失」で評価される。ところが、発生確率も発生損失も客観的測定が困難なので、この公式は実際には役立たない。
 住基ネットの反対派は、リスクの発生確率ではなく発生可能性を追及している。賛成派も法令があるから発生しないという。すなわち、発生確率は1か0の値だけになる。
 住基カードの普及率は1%にもならないが、その主な理由は個人情報漏えいの危険である。年金制度や交通監視カメラ(Nシステム)に比べれば、住基カードの記載情報漏えいによる発生損失は小さいであろう。それなのに、個人情報漏えいの観点から年金制度を見直せという議論は行われていないし、監視カメラの撤去運動もない。
トラブルは連続して発生する
トラブルを解決しようとすると、トラブルはもっと深刻になる
・デュープレックスシステムで主系がダウンしたときは、きっと待機系が立ち上がらない。
・ベンダに連絡すると、ほかのシステムを発注したベンダがやってくる。
・ファイルを待機系に移したときは、元になるファイルは数世代以前のものである。
 なお、この「連続して発生する」という法則は本質を誤っており、「第1番の問題を取り除くと、第2番が昇進する(ルーディのルタバカの法則。ワインバーク)」のだという説もある。
リスクマネジメントの基本は、スケープゴートを設定することである
 リスクが発生したとき、その被害を最小に抑えることが大切である。「社長がTVカメラの前で頭を下げ」て、原因を「情報システムの不備」とするのが一般的である。

合併システム(2008/02/26)

最大リスクの一つである企業合併を対象にする。企業合併などに伴うシステム合併では、情報システム構築の遅れや準備不足によるトラブルが話題になる。それを回避するために、IT部門がとるべき対策とは何だろうか。

情報システムの重要性は、合併時に認識される
系:合併時の代理戦争に巻き込まれるな
 情報システムは仕事のやり方を規制する。
 合併時にどちらの情報システムにするのかは、「どちらの仕事のやり方を採用するか?」の問題であり、「どちらが業務の主導権を握るか」の問題なのである。そこで、利用部門は自社システムを採用するように、IT部門に圧力をかける。
 また、これまでの主要ベンダから、各社のシステムを採用するような働き掛けがある。これを機会に参入を図る新ベンダもいる。各社がIT部門に直接、あるいは経営層を通して間接的に働き掛けてくる。
 双方のIT部門は、自社システムの欠点を知っている。合併では予算が十分に得られるので、これを機会に抜本的な再構築をしたいと思っている(時間があればの話だが)。それなのに、外部の圧力によって代理戦争を強いられ、心ならずも自社システムが優れていると主張する。
 代理戦争をしている間に、抜本的に再構築をする時間が失われ、どちらか一方に片寄せすることになる。勝った側の情報システムが、実は欠点だらけということはすぐに分かる。これにより、双方のIT部門に不信感が生じる。このような状況でシステム構築をしたら、トラブルが起こるのは仕方がない。
システム合併では、新CIOに期待するな
 合併時には、主要人事での駆け引きが付きものである。社長がA社ならば副社長はB社、営業がA社なら経理はB社というように、○勝○敗のバランスが重視される。
 CIOの重要度は低いし兼任が多いので、他業務の都合で人事が行われる。最終段階でのバランス調整によって、初めてCIOが決定する。そのCIOが、旧会社でのCIOである確率は低い。
 すなわち、かなり後になってから、どちらのシステムも知らない(ITそのものを知らない)素人が、両社のITを担当することになる。だから、新CIOの指示を待っていたのでは、合併システム構築のスタートが遅れ、合併の足を引っ張ることになるのは目に見えている。
シノニム・ホモニムの呪い(バベルの塔)
 倉庫、出荷基地、デポ、在庫場所などが、同じものなのか違うものなのか。「支店別売上」というとき、支店には本社直売部は入るのかどうか。「見本納入」や「他支店転送」は売り上げに加えるのかどうか。これらがベンダが業務を理解するのを妨げる。しかも、上流工程でその誤解に気付くことはまれで、帳票が印刷されてから気付くことが多い。
 これらの用語・概念は、仕事のやり方の象徴である。各人が自分が用いている用語・概念の採用を主張する。それが部門をまたぐシステム、企業合併での統一システムに時間がかかり、トラブルが発生する原因になる。
合併システムの第2次システムは実現しない
(今日できることを明日に延ばすな)
 一般に合併システムでは、費用は比較的潤沢であるが、要求機能はあいまいで、短期間に実施することが要求される。そこで、重点を絞り込んで、取りあえず動くものを第1次システムとして構築し、その後落ち着いた時点で、理想的な第2次システムを検討しようと考える。
 ところが、第1次システムでのトラブル対処に忙殺されること、合併後の変更への対処に振り回されることなどにより、なかなか第2次システムに取り掛かれない。取り掛かれるようになったときには、そのための費用が得られない。
合併システム成功のカギはIT部門の団結にある
 合併システム検討でモタモタしていると、上記のような外部からのノイズが増大する。外部が事の重要性に気付かない間に、両社のIT部門が相談して既成事実を積み重ねておくのが成功の秘訣である。
 システムを片寄せするのか新規に開発するのか、ハード構成をどうするのか、両社の用語の対応表作成と統一案などは、外野がいなければ案外短期間に作業できる。
 外部が騒ぎ出す前に両社のトップに共同案を示し、お墨付きを得ておくことにより、余計なトラブルに巻き込まれるのを回避することができる。

次へ進む