あえて失敗させる、という手法
一年ほど前にとん挫した、基幹システム導入プロジェクトがようやく和解した。
契約途中に関わらず、発注先から契約解除通告を受け、そこから損害賠償だの、訴訟
だの一年近くやりとりを続け、ようやく和解が成立したのだ。
そこから、社内に「今回の失敗を次回に活かすレビュー」プロジェクトなる、不思
議なプロジェクトが発足し、関係者が集まり振返りと反省、今後の対策の議論が行わ
れている。そこまでは良い。しかし困ったことに何が致命的な失敗で、根本的な対策
は何か、という事がなかなか出てこないのである。
世間でいうと中規模の（弊社にしてみては大規模の）、よくある地方の中堅企業に
向けた基幹システムの導入プロジェクトである。言ったところでプロジェクトなので、
計画通りに、かつ、何一つの問題も起こらずに事が進んだわけではない。メンバーの
脱落に伴うスケジュールの遅延やリリース機能のバグなど、確かにトラブルは発生し
た。しかし都度、リカバリは真摯に対応してきている。
例えば、システムの運用開始後、重大なバグがありそのため発注先に被害が生じた
ので損害賠償を求められた。これならば話は分かる。そのバグが何故発生した、見過
ごされたかを検証してゆけばよい。しかし、開発途中の契約解除なので、そのような
被害が発注側に発生したわけではない。例えば契約時に重要な事項を偽っていたり、
隠していたり。また、反社会的な活動に関わっていたり。それだと、そもそもが契約
違反にあたるので判明した時点で契約解除を言い渡されても仕方ない。次回に活かす
云々以前の問題ではあるが、そのような事実があるわけでもない。ただ開発途中、試
験のためにリリースした機能の品質が悪く、プロジェクトマネジメント違反にあたる、
という理由で一方的に契約解除を通告されただけだ。
実のところ、基幹系システムの開発、導入に携わっていると、このような理不尽な
出来事は意外と多く遭遇する。今回ほど拗れたのははじめてであるが、システムを開
発しても使われることがなくお蔵入りになった案件は何度か経験した。納品後、数年
して、高額な開発費を使ったのにシステムが使われていない、と発注者から呼び出さ
れたこともある。我々としては契約を完了して代金を支払っていただければ問題ない
のだが、発注者側としては高い金を払って作ったシステムが使われていないとしたら、
文句の一つも言いたくなる気持ちはわからないでもない。「動かないコンピュータ問
題」などの記事を読むと、このような事例が多く掲載されているので、IT業界はまだ
この手の問題に対して、抜本的な解決策は見つかってないと思われる。
では何故、発注者が高額な開発費を使っても、結果使われないシステムが出来上が
るのか？
その原因のひとつに、発注者側の社内調整力が関係しているように思われる。基幹
系システムは全社共通で使うシステムであるため、関係各所と多くの調整が必要とな
る。各部門、現場、経営陣。どれも利害関係が異なるやっかいな調整事だ。基幹系シ
ステムの導入が決まると発注者側にもプロジェクトが設置され、開発・導入に向けた
諸事に対応してゆく。関係各所との調整も重要なタスクのひとつであるが、これがア
サインされた担当者や企業の成熟度によってかなり差がでる。
成熟度の高い大手企業などは、担当者に能力不足が認められた場合に自浄能力が働
き、増員や担当者替えが行われるが、成熟度の低い企業は例え担当者の能力が足りて
なくても代替員がいるわけではないので、その担当で突っ走るしかない。また、成熟
度の高い企業は利害関係が争う双方が、本来の目的を踏まえてお互いに譲歩しながら
進んでゆくのに対して、成熟度が低いとただ自分たちの言い分を主張するだけで調整
が一向に進まないということも起こりうる。
そして困ったことに、基幹系システムの開発・導入に関しての多くのことについて
受注者側が発注者側を支援することができるが、この社内調整に関しては受注者側が
関わることができないことだ。このことを理解していない発注者は意外と多い。
結果、どうなるか？
社内調整がうまくいかないと、仕様の増加、スケジュール遅延、コストオーバ、利
用拒否、様々な問題が発生してプロジェクトは迷走をはじめ、発注者側は高額なお金
を支払っている立場から、その不満を受注者側にぶつける。
体力のある大手SIerは、自社のソフト、パッケージ、ハード顧客をロックインし、
発注者側の丸投げを受け入れている。というか、発注者を飼いならしている。このよ
うな関係ならば、発注者側の社内調整なども代行して行うのかもしれない。すると当
然ながら発注者は、その分の（本当に）高額な費用を払い続ける必要がある。
しかし発注者側経営者も最近は気づき始めている。何故、自社のIT投資はこんなに
高額なにシステムは保守的なのだろうか、と。大手SIerはその大きさ故、保守的であ
る。新しい技術は積極的に取り入れようとしないし、顧客に提案もしない。でも巷に
はITの新しい技術や活用方法、成功事例が満ち溢れている。経営者は大手SIerからの
ロックオンから脱却し、コンペで新しいITベンダーを見つけようとする。そして新しい
ITベンダーは見つかるかもしれないが、発注者側のプロジェクトは丸投げ体質から脱
している訳でもなく、受注者側は新しいシステムの導入はできるが、丸投げを受入れ
切れず、前述の社内調整問題が発生。この三竦みがプロジェクトが失敗するシナリオ
ではないだろうか。
そう考えると、「今回の失敗を次回に活かすレビュー」プロジェクトで致命的な失
敗と根本的な失敗が何か、という答えが出てこないのもわかるような気がする。
今回の失敗は、夫婦間の離婚調停のようなものだ。夫婦、どちらかに借金や、DV、
不倫などの痂疲があれば別だが、その様な問題がなくても離婚問題は発生する。当事
者同士は双方に言い分や恨みつらみはあるだろうが、それは当事者の言い分であって、
第三者にはわからないし、どちらが悪いかも決めがたい。したがって、ある夫婦の離
婚問題が、別の夫婦の離婚対策につながるわけではない。ましてや、結婚する前から
離婚対策をするのもナンセンスだ。できることは、双方で離婚の危機に陥らないよう
普段から気をつけておくか、どうしても合わないことがわかれば、円満に離婚する道
を探るくらいである。
もう一つ、失敗しかかったにも関わらず持ち直したプロジェクトを経験したことが
ある。地方の大手企業の基幹システム開発・導入プロジェクトであったが、３ステッ
プ３年で計画されていたが第１ステップがうまくいかず、プロジェクトが暗礁に乗り
かけていたのだ。その事に気が付いた発注者側が自社側のプロジェクトメンバーを総
入れ替えし、強力な推進者をリーダに据えたのだ。そのとたんプロジェクトが回り始
め、予定通り３年で無事完走した。今にして考えると、それまで丸投げだった発注者
側が、第１ステップの失敗で本気になり、推進者を変えることで主体性が出てきたこ
とが成功の要因だと考えられる。現に発注者側社内調整は、（強権発動も含めて）す
べて新しい推進者で行っている。
さしずめ、仮面夫婦を続けていたが、どちらかが離婚を切り出すことでお互いの本
心に気が付き、再び協力し合って夫婦生活をつづけたという事であろうか...。
あえて、失敗させるという手法もあるのかもしれない。
それは、なるべく早い段階がよい。
失敗させることで、発注者側も丸投げ主義を脱却して主体性を持つかもしれない。
もし、離婚止む無しの場合でも、早い段階であれば双方の痛手は小さくて済む。
契約に縛られ、発注者優位の商習慣のなかで、受注者側がとるにはかなりリスキー
な手法しれないが。