IT導入・システム開発のプロジェクトは大きな事業計画の一つであったり、大きなITプロジェクトの一つであったりすることで、大きな流れに翻弄される

事業に対し大きな変化を起こそうというとき、ITを導入したり、システム開発により大幅な業務改善や効率化などを行おうとする前向きな計画はよくあります。

また、ITに着目したプロジェクトにおいても、企業の基幹システムとなると、販売・会計・物流・在庫管理・受発注・購買・顧客管理など様々な機能があり、すべてを同時に再構築するのではなく、一つひとつ行ったり、並行して行ったりと複雑に絡み合って進められることがあります。

一つのプロジェクトから見ると比較的小さなプロジェクトであったとしても、全体として大きなプロジェクトとして動いているということなります。

受注側は一つのプロジェクトとして、取り組んでいても、発注側としては全体の一つであり、当然全体を優先して考えています。

よって、全体として大きな部分が崩れてきたときには、個々のプロジェクトも崩れてしまい、関係も悪化せざるを得ない状況に陥ります。

事業の統合を目指したITシステム開発プロジェクトでは、業務の統合がうまくいかないとシステムの統合ができない

金属加工メーカーにおいて工場の統合が計画されました。2つの工場は似たような事業と全く異なる事業の両面がありましたが、統合によりお互いのよいところが発揮され、コストも削減できると考えられていました。

工場統合の計画に伴い、生産管理のシステム開発がスタートしました。

受注側はベンダーが請け負いました。

プロジェクト開始段階では要件定義を行い、多数のヒアリング行った結果、全体見積額が算出され、予算として承認され、進められました。

十分なヒアリングを行ったと思われていた要件定義でしたが、プロジェクトを進めていくうちに仕様変更が多く発生しました。ベンダーの品質不良もあり、テスト段階では発注側と受注側の関係がかなり微妙となってきました。

仕様変更の原因は、２つの工場業務を統合するにあたって、見えていなかった業務があり、システムに取り込むべきかどうかを都度議論の上対応してきたことによるものでした。
初期段階で比較的綿密に議論したはずでしたが、現場の担当がテスト参画することで、数多くの問題が発生してきました。

ベンダーは仕様変更に対し、費用請求をする決断をしました。発注側メーカーとしては、綿密に予算を立ててきたため、認めないとの意向を示しました。初期段階から委託してきたのだから、現場要望の仕様についても、ベンダー側でコントロールできるはずだという主張です。

そうこうしているうちに、発注側メーカーはプロジェクト中止を決断しました。ベンダー側の品質が悪いことでシステムが完成しない、ということで、未払金も支払わないつもりでした。

しかし本当のところは、裏で工場の統合はうまくいかず、中止することを決めていました。
システム開発プロジェクトは工場統合の計画に基づいて行われたのですが、結果的に工場統合がうまくいかずにシステム開発もうまくいかなかったということになりました。

それどころか、ベンダーの損害賠償請求により、未完成部分含めて支払うこととなってしまいました。

システム全体の開発を委託しても一部しか出来上がっていない

証券会社にて商品管理システムの開発を計画しました。このシステムは特定事業分野における基幹システムとなるものでした。
基幹システムの再構築としてベンダーに委託することになりました。

ベンダーはパッケージソフトの導入を提案し、その計画が認められ、IT導入プロジェクトが開始されました。

しかし進めていくうちに、プロジェクト範囲の認識差異があり、たびたび白熱した議論が取り交わされました。
発注側としては当該基幹システムの再構築を委託していましたが、受注側ベンダーはパッケージソフトの導入を主眼としたプロジェクトの認識となっていました。

要件としては、既存システムの業務および仕様を新システムに取り込み、既存システムから新システムに円滑に切り替え、新システムの運用が安定するところまでをプロジェクトの範囲とするというものであったことは、初期段階での議事録等からも明確でした。

ところが、ベンダー側当事者の中では、いつのまにか新たなパッケージソフトの導入するのみのプロジェクトとなっていました。
一見おかしなことのように見えますが、実はよくあることです。しかもこの事例は比較的大規模なプロジェクトです。

プロジェクトは進んでいくうちに意見の食い違いが発生し、パッケージに対するカスタマイズ要求も実現できない部分が多くなってきました。

とうとう発注側企業ではITシステムは完成していないとし、プロジェクトを中止しました。
受委託範囲の取り違いによって生じた認識相違は、結果ベンダーに問題がある、ということとなりました。

早期に認識の差異を埋め、体制も再構築して進めれば、予定どおり完成したかもしれません。

このケースにおいては、委託範囲が既存システムからの基幹システム再構築であったため、ITシステムが完成しなかったことによる既存システムの利用料や新システムの準備段階における広告費用等も含めて損害賠償の対象となり、ベンダーとしては大きな痛手となりました。

発注側企業においても、実現しようとした計画ができなかったことで、事業機会の損失は大きかったようです。

大規模ITシステム開発では複雑に連携しあうので難易度が高く、段階的契約でも全体として見る

金融機関は業務システムの開発を大手ベンダーに委託しました。大規模なシステムの一部として捉えられるITシステムの開発でしたが、一部と言ってもかなりだ規模と言えるものでした。

業務システム間は連携データが多く、それら周辺システムとも整合性と保たないといけないことに加えて、周辺システムの同時にシステム再構築を進めているものもある状態でした。

このような状況下ではIT導入・システム開発プロジェクトは難易度が高くなります。

そこで、ベンダー側としては初期段階から段階的に契約をしていくことで、確実に進め、リスクを低減させようとしました。

プロジェクトの後半である総合テスト段階で、大きな問題が発生してきました。

品質上の問題が多く発生したのと同時に、周辺システムとの連携において致命的な障害が発生していました。
周辺システムとの連携障害は、多くは設計段階にて周辺システムと仕様を取り決めておかないといけないものでしたが、取り決めが不十分であったため、大幅な改修が必要な欠陥が総合テスト段階で見つかってしまいました。

プロジェクトは立ち行かなくなり、一旦中止となります。

発注側と受注側ベンダーにおいては段階的契約を行っていたため、その段階では総合テストの契約となっていました。総合テストは未完成とせざるを得なくても、ベンダーとしては検収済みの契約についてはそのまま認められると考えていました。

ところが、今回のケースにおいては受託範囲全体における責任が受注側ベンダーにあるということとなりました。
段階的契約を行い、前工程が検収済みであったとしても、前工程の不備により後工程に影響を及ぼしたのであれば、全体の受託範囲において不備があったと捉えられたということになります。

周辺システムも開発中であり、難易度は高いものの、システム全体像を捉えて進めていかないといけない、という環境に適切に対応していかないといけなかった、ということとなりました。また、プロジェクト単体で見ても、時系列に段階契約になっていたとしても、この場合は一つの契約のように捉えられ、あくまでも一つの目的をもった全体のプロジェクトである、という認識のもと、当事者は取り組まないといけない、と解釈しなくてはいけないこととなります。

まとめ

事業を大きく変更する場合、ITシステムにおいて対応を求めることが多くあります。

ITシステムの導入や開発を進めていくにあたり、やはり単体で取り進められることは当然のこととして、事業変革や他のITシステム開発との関係も含めて、全体として計画・管理していくことが重要です。そうしないと、思わぬところでIT導入・システム開発プロジェクトが失敗に向かってしまいます。

一つの失敗は連鎖的に他の失敗にも繋がります。一つの不具合が他の機能に波及することもあれば、順序性を持ってプロジェクトを進めていたのに、後続のプロジェクトそのものが立ち上げられない、といったことも起こります。

受注側ベンダーがそのような状況下を認識の上で受託しており、ベンダー側に不備があったという事例がありましたが、発注側としては、全体の計画が崩れたこととなります。

よって、発注側として大きく計画を捉え、しっかりとコントロールしていかないといけないことに変わりはありません。