パーソルグループとSky株式会社は、sightを通してエンジニアの自分らしいキャリアを応援しています

失敗プロジェクトから学ぶトラブルを防ぐ極意【後編】──DX時代に身に付けたいプロジェクトマネジメント講座!#4

DX(Digital transformation)による激しい変化の潮流の中で、ITプロジェクトをいかに成功に導くか。その成否の鍵を握るのが、ステークホルダー・マネジメントだ。
「DX時代に身に付けたいプロジェクトマネジメント講座 #4」イベントレポート後編では、プロジェクトが頓挫したケース事例や対処法、ステークホルダー・マネジメントの重要性などについて、前編に続き、数々の大規模プロジェクトを指揮してきたアスカプランニング 代表取締役社長の永谷裕子氏に語っていただいた。

永谷裕子氏

最悪はIT紛争に至る失敗プロジェクト

前編ではステークホルダー・マネジメントの重要性について、お伝えした。ではステークホルダー・マネジメントに失敗し、プロジェクトが頓挫するとどうなるか。最悪のケースはIT紛争に行き着く。

永谷氏がIT紛争の話をするのは、7~8年前より東京地方裁判所で、IT紛争の調停委員を担当しているからだ。「IT紛争は年々、増えている」と永谷氏。ユーザーがベンダーを訴えるだけではない。ベンダーがユーザーを訴えるケースもある。

日経コンピュータ2018年3月1日号の記事によると、スケジュール、コスト、満足度の条件を満たしたプロジェクトの成功率は52.8%だという。建築や土木のプロジェクトではあり得ない数字の低さだが、「ITプロジェクトの成功率は、いろんなことをやってもなかなか上がらない」と永谷氏は話す。

永谷裕子氏

▲株式会社アスカプランニング 代表取締役社長 北海道大学大学院非常勤講師
永谷 裕子氏

MBA取得後25年近くアメリカと日本においてインターナショナル・プロジェクトに従事。現在はグローバル・プロジェクトマネジメントのコンサルタントや研修講師を務めている。PMP®、MBA、工学博士。

そんな中、今まで話し合いで解決できたことが、訴訟に発展することが増えたというのだ。永谷氏いわく、「ユーザー企業、またはベンダーが訴訟主となるケースは大きく3つある」とのこと。第一は納品されたシステムが瑕疵(設計仕様通りではないこと)の有無を争うケースだ。

第二にシステム開発の頓挫や遅延の所在がどちらかにあるかを争う。つまりベンダーにプロジェクトマネジメント義務、ユーザーの協力義務を軸に、この争いのどっちに責任があるのかを裁判で争うケース。第三のケースは開発したシステムの著作権の帰属を巡る争いである。

ユーザーの協力義務を争う判決事例も

ベンダーのプロジェクトマネジメント義務とユーザーの協力義務を争う判決で、一番影響のあったのは、2012年の日本IBMとスルガ銀行の争い。これはスルガ銀行が日本IBMを訴え、日本IBMに42億円の賠償が決定したというもの。理由はベンダーがプロジェクトマネジメントをちゃんと行っていなかったからだという。

第二審で要件定義の段階でのIBMの過失割合がかなり低くなったが、東京地方裁判所は、ユーザーとの間で合意された開発手順や開発手法は、作業工程などにしたがって開発作業を進めること、専門知識を持っていないユーザーによって開発作業を阻害する行為がされることがないよう、常にユーザーに働きかけること。

これらの行為を行う責任がプロであるベンダー側にある、つまりそれがあなたたちのプロジェクトマネジメントの責任ですよと裁判所は言っているのである。
「ベンダーが素人であるユーザーをうまくリードしていく義務があるということです」(永谷氏)

永谷裕子氏

では、ユーザーも協力義務とは何か。ベンダーがプロジェクトをリードできるよう、求められた資料を提供したり、インタビュー、面談に応じたりするという義務である。特に要件定義の段階では、ユーザーがタイムリーに情報を提供しなければ、ベンダーはシステム開発に着手できない。

ユーザーの協力義務が問われた有名な判例が、旭川医大とNTT東日本の争いである。旭川医大の主張は、システム開発が遅れた上、テストでプログラムが作動せず、完成していないというもの。

一方NTT東日本の主張は、システムは完成していたが、開発が遅れたのは、旭川医大が追加開発を仕様凍結後も際限なく要望したためというもの。旭川地裁は、NTT東日本に8割の責任があるという判決を出した。ところが、札幌高裁では判決が覆り、NTT東日本のプロジェクトマネジメント義務違反はなく、ユーザーに責任があることに。

なぜなら、要件をきっちりとりまとめてベンダーに伝えなかったからである。
「この判決により、プロジェクトの責任はほとんどの場合、ベンダーにあるという考え方から、ユーザーにも責任があるという流れが出てきました」(永谷氏)

ステークホルダー・マネジメントでIT紛争を回避

ではこのような紛争を回避することはできなかったのか。ここで永谷氏は1つの架空事例を紹介した。

原告は大手サービス会社のX社。新規事業拡大のため、役員の一人のAさんの決断で基幹システムの再構築を計画し、10年以上現行システム開発、保守、運用にも携わっていたY社(被告)に開発を発注した。被告Y社は情報処理サービスおよびソフトウェア開発などを目的とする中堅のITベンダーである。

基本設計、詳細設計はうまくいっていたが、プロジェクトの研修作業で不具合が頻出。Y社は増員するなど対応したが修復できず、プロジェクトは頓挫。そこでY社は要件定義まで立ち返るというリカバリープランを提示した。

だが、X社はそのリカバリープランは受け入れられないとして、プロジェクトの中止が決定。訴訟になったというケースである。

原告の主張:詳細設計(要件定義)の不備が原因で、プログラムの品質不良が生じた。プロジェクトの終盤でリカバリープランを提案され、突如期間延長多額の追加費用を求められた。一定の仕様変更、追加要望、保留事項があったのは事実だが、これが品質不良の原因ではない。

一定の仕様変更をちゃんとマネジメントするのがベンダーの責務。定例会でも保留事項の問題や開発スケジュールの遅延について説明を受けたことも、対策を協議したこともない。議事録も出てこなかった。

被告の主張:頓挫の原因は、要件定義作業の完了後も仕様の追加・変更を求められたこと。これにより、保留事項を解消できなかった。品質低下の原因は、原告がカットオーバーの延長はできないと要求していたので、開発ボリュームが増えたにも関わらず、要件定義工程に立ち戻ることなく、作業を進めざるを得なかったことにある。リカバリープランはA氏と共同で作成したもの。追加費用も原告の了解も得ていた。

「このようなケースでも、ステークホルダー・マネジメントをきちんとやっていれば、訴訟まで発展しなかったと思われる」と永谷氏。被告となったY社はX社のシステムを10年間メンテナンスしてきた。

永谷裕子氏

Y社は発注社であるX社がシステム開発に未熟であることが解っていた。長年の相互交流から、X社のステークホルダーのプロジェクトに対する期待値を特定し、Y社のステークホルダーをプロジェクトに巻き込む戦略的ステークホルダー・マネジメントを実施すれば、信頼関係を築く可能性を高めることができたと考えられるからだ。

要件定義はユーザーの役割ではある。だが、不慣れなユーザーをリードせずに成り行き任せの受け身の姿勢であったこと、長期的な付き合いから生じるなれ合いの関係からプロジェクトマネジメントのプロセスを適切に踏まなかったことが、プロジェクトの破綻を招いた一つの大きな要因である。

「その結果、顧客の信頼を失うこととなった」と、永谷氏は話す。

プロジェクトマネジメントを成功に導くカギは、ステークホルダー・マネジメントにある。それが改めて実感できる講演だった。

失敗プロジェクトから学ぶトラブルを防ぐ極意【前編】──DX時代に身に付けたいプロジェクトマネジメント講座!#4