1. |
プロジェクトマネジャーの仕事は仕事を減らすことである |
・ |
日本の企業と欧米の企業の在り方で大きく違うのが仕事への考え方である。欧米のマネジメントは必要最低限の仕事で処理することで評価される。これをミニマム・リクワイアメント方式という。「Simple is the best.」である。それができるのは企業内で仕事を評価する基準が厳然として存在し、評価基準に準じた仕事をする人の評価が高い。 |
・ |
日本では多くの場合、曖昧な評価基準の中で組織が運営されている。したがって個人の自由度が高く、手当てが出なくても喜んで残業をし、今でも「多忙」をステータスと考える人々が多い |
・ |
Simple とは研ぎ澄まされた簡潔さを意味し、一種の美である。これは日本人が長年も求めてきたものでもある。Simpleが美になるためには、プロフェッショナルな感覚があってはじめて達成される。多くの不要な仕事を付加されたやり方は不細工である。 |
・ |
プロジェクトマネジャーが自分の仕事をシンプル化できるのはプロとして、本質を理解し、本質以外を切り落とす努力と勇気があるからである。
|
|
従来私はこの決断をプロマネの裏わざと考えていた。しかし、経験を積むに従いこれこそ本業であるべきと考えるようになった。
|
2. |
ITプロジェクトの発注者は複雑が好きで、自分の首を絞めて満足している。 |
・ |
Simpleと正反対なのが日本のIT産業である。契約で決めた仕事量を2とする。プロジェクトが始まり、プロジェクトの進行に伴い、仕事量が4に膨れ上がる。これでは赤字のプロジェクトになると、受注者のプロマネは努力し、2まで引き摺り下ろす。すると現場の利用者は更なる要求を出し3にまで再度要求を増やす方向で進める。これをITプロジェクトの2−4−2−3の法則と呼んでいるそうだ。 |
・ |
ここには4つの大きな問題があることを、発注者のプロジェクトマネジャーは理解しなければならない。 |
@ |
契約が決まってから、2が4になりながら、追加金額なしで実行できないことは自明の理である。にもかかわらず国内では実行されている。このような日本的習慣を海外で実施したら日本人は信用されなくなる。海外で信用されない行為は国内でもやめるべきである。 |
A |
プロジェクトで変更が多く発生すると、当然工程が遅れ、危機に直面する。「ITの失敗学」の著者はこのような危機にたびたび乞われて問題解決を行っている。彼は納期を守るために、当面の解決策として、とりあえず2−4−2−3をやめて、2−4−2で納期を守り、その後時間をかけて顧客要求の3にする提案をする。多くの会社は同意してくれる。結果として2で納期が守られ、運転が開始され、システムは無理なく運用状態に入る。ここで面白い現象が起こるという。多くの企業は運用が順調に行われると3の要求をしなくなるという。 |
B |
次にAのケースが行われない場合を考える。当然3を実施させられる。ここでは「投資とその費用の回収という経済原則が適用される。即ちIT投資はシステムが運用されて、収益が発生し、投資コストが運用時の収益で回収できれば投資は成立する。
投資が予定の年月で回収できれば追加を認めることができる。ところが現実は予算以上の追加を認めない。一方受注者は競争に中で見積りを出しているから、無償できる追加を実施できる余裕などほとんどない。受注者のプロマネは赤字を認めてもらえないから品質の低下で対応せざるを得ない。システム構築で最も大切なことはシステムの品質であって、納期の遅れや、少しのコストアップは品質に比べれば小さな問題である。運用で儲かれば目的が達成されるからである。しかし、この大局的な正義が通用せず、決められたコスト、納期という目先的小さな正義がまかり通り、その結果品質の低下を招くが、ITの品質の低下は目に見えないから検査は通ってしまう。しかし品質の低下は運用コストの増加に繋がる。日本の保守費は意外に大きい。システムのリプレースが多いからである。日本のIT投資は投資効果を評価することがなく、経費で落としているからである。ついでに申し添えるが、日本のITベンダーは保守でプロジェクトの損失を回収しているのではないだろうか。これでお互い様かもしれないが、リーゾナブルという国際感覚から大きくかけ離れている。 |
C |
「変更管理」という日本語の魔術
欧米の変更管理は英語で表すと。「Configuration Management 」である。変更はプロジェクトにとって負の要素になるが、正の要素が全くない。変更がない方がよいが、仕方がないから変更する。ただし、変更に際しては当初考えた構成設計の思想に障害を及ぼさない範囲での変更を認めましょうという発想である。現在のように変更は自由で、その変更が確実に実施するための管理ではない。 |