システム開発を失敗させない“現実的な処方せん”とは？：失敗プロジェクトが常態化する開発現場（前編）（1/2 ページ）

昨今、大規模なシステム開発の現場において“失敗プロジェクト”が常態化していると聞く。“失敗プロジェクト”とは、目的そのものに到達できなかった、または、予算・期限を超過して終了したプロジェクトのことであるが、一体なぜ常態化するほど多くのプロジェクトが失敗してしまうのだろうか。

[瀬良征志（ブーズ・アレン・ハミルトン シニア・アソシエイト），アイティセレクト編集部]

　昨今の企業変革プロジェクトでは、システム再構築と不可分なケースが多い。システムが扱う領域は広範であり、経営企画部門、ユーザー部門、システム部門の誰が扱うべきかの境界も分かりにくくなっている。

　これらのプロジェクトにはビジネスとIT両方の知見が求められるが、そのような人材は常に不足している。当然、本分野における知識・経験の流通もいまだ不十分であり「システム再構築を伴う企業変革の推進」は、今後の大きな経営課題のひとつである。では、失敗プロジェクトにならないためには何をするべきなのだろうか。

「これくらいやってくれて当然」は伝わらない

　クライアントであるユーザー企業とITベンダーの互いへの期待と現実の力には明らかに大きなギャップが存在する。多くのギャップは「これくらいは当然先方でやってくれるだろう、という暗黙の前提に対する誤解」であるが、この些細な誤解が、後々の大きな失敗を招くことがある。

　ユーザー企業の役割についての明確な標準形はなく、各社各様とならざるを得ない現実はある意味当然である。「クライアントの状況に応じてサービスを提供することが、プロフェッショナルたるITベンダーの最低限の責務である」という正論と、それに対するITベンダーの現実の個別対応能力がかなり乖離していることが、この問題の解決を難しくしている。

　ITベンダーの実力は一朝一夕に向上するものではないため、いざプロジェクトの当事者となった場合には極めて現実的な対応が求められる。

　最も被害が大きくなるケースが「クライアント側のITスキル・体制がもともと脆弱であるため、その不足分を補う前提で、ITベンダー側に作業を委託する」場合である。当初はITベンダーも期待に応えるべく、最大限の努力を惜しむことはないだろう。

　ところが、設計・開発が進むにつれスケジュールや予算がタイトになってくると当初の約束をよそに、実際の現場担当者間に周知徹底されていなかったがために「通常では移行データの準備はお客様の作業です」のような、ありていの線引きが行われ、結果として現状の問題点が十分認識されないままプロジェクトが継続し、失敗への道を歩むことになる。

　このような事態にならないためには、提案を依頼する段階から、ユーザー企業側が“できないこと”、“ITベンダーへ期待すること”を、全担当レベルで正確に伝え続け、ITベンダー内に周知させる必要がある。多くの場合は、未然に失敗を防ぐことができるだろう。中には、その状況を理解しようとせずただ単にあるべき論をふりかざすITベンダー担当者が現れるかもしれないが、そのときは交代やむなしであろう。