システム構築に関わる以上、誰もがトラブルは避けたい。「要件定義はユーザーを入れてしっかりやろう」「事業とIT部門のコミュニケーションが大事」といった話は、はるか昔から叫ばれてきた。コンサルタントはプロジェクトマネジメント方法論を振りかざし、識者は「システム構築のトラブルを回避するためにはこうするべし」というTIPSを唱え続けている。
それでもIT業界には「システム導入プロジェクトの6～7割が納期遅延、予算超過、品質問題などのトラブルを起こしている」という通説があり、感覚値でもその程度の割合で事故が起きているのが現状である。きれいごとをいってもトラブルは回避できない。トラブルが起きる理由は実は水面下にあるからだ。
前回までに、最高情報責任者（CIO）を取り巻く環境の変化、ユーザー企業とSIベンダーが直面する現状、そして第三者PMOの重要性について解説してきた。今回は、PMOの必要性を改めて理解してもらうために、いったん視点を変えて、よくある「プロジェクトのトラブル」について、私の経験を踏まえながら追ってみたい。
初めてのトラブルプロジェクトレスキューは15年前
私がコンサルタントを職にして25年になるが、もともとはメーカーの情報システム部門SEとして社会人生活をスタートした。徐々に欲が出て、業務を知りたいとビジネスプロセスの中身に入り込み、それをシステム化して事業に貢献するようになった。
「こんなに喜ばれるなら、それを本業にしたい」と思い、当時まだ業界としてはマイナーだった外資コンサルティング業界に思いきって転じた。そこから、業務設計、システム設計、構築、導入という一気通貫のプロジェクト経験を積んできたのだが、お客様の依頼で、レスキュー隊長としてトラブルプロジェクトに初めて飛び込んだのは、コンサルタントになって10年ほどたってからだ。
それは、社員のスキル評価会議で休日出勤していた時のこと。オフィスをうろうろしていたら、当時の上司に呼び止められ、「お客様が打ち合わせで来社される。同席して」と言われた。快諾して席につくと、そこに現れたのは、大手製造業A社のCIOだった。「今進行中のシステム構築プロジェクトがうまくいかない。使っているグループ系列のSIベンダーX社では立て直せない。なんとかしてほしい」と彼は言った。
そのプロジェクトには、当時私が所属していたコンサルティング会社も業務設計で参加していたが、SIベンダーX社下で契約。お客様の要請は、「全社視点でのプロジェクトの立て直しをしたい。もっと前面に立って仕切ってくれ」というものだった。「わかりました、立て直しは彼（筆者）がやりますから」と上司は一言答え、そこからプロジェクトレスキューとしてのキャリアが始まった。
ふたを開けてみると、プロジェクトの注力範囲（スコープ）も予算もオーバーし、プロジェクト人材（人財）のスキルはミスマッチ、SAPのプロジェクトなのにX社にはSAPの知識がなく、プロジェクトマネジメント経験も浅かった。既存システムの連携相手となる別のシステム子会社とのコミュニケーションもまったくかみ合っていない。X社のSEはSEとして必死にて頑張ってはいるものの、そもそもプロジェクトとして成立する状態ではなかった。要はプロジェクトマネジメントが機能していなかったのだ。
急いで全体計画を見直してお客様に提示し、承諾をしてもらってPMOの役割で立て直しに入った。結局システムは無事稼働したが、稼働は半年遅れ、立て直しにかかった追加費用は最後、元請のX社が責任をとって負担することになった。
もとはと言えば、お客様がSI企業をしっかり選定していれば、こんなことにはなっていなかったかもしれない。X社も、無理に仕事を受けた結果、トラブルの末最後に費用を追加負担するという憂き目を見ることにはならなかっただろう。ではなぜこうなったかと言えば、もとをたどればX社の選定理由が、スキルの適性ではなく、「製造業A社のグループ会社だから」だったことに起因する。似たような話は、今も耳にしないだろうか。
