システム導入の失敗は誰の責任か｜丸投げで決まっていたこと

予定の時期を過ぎても、システムが使える形になっていない。現場からは「前のほうが早かった」と言われる。ベンダーに文句を言うと「仕様が決まらなかったので」と返される。いったい誰の責任なのか、と考え始めている方に向けて書きます。

責任の所在を先に整理し、そのうえで、次に外注するときに失敗しないために発注側が決めておくことを並べます。

失敗の責任は、発注側にも最初からある

システム開発では、ベンダーにも発注側にも、契約書に書いていなくても負う義務があります。

ベンダーには「進め方を管理する」義務がある

IPA（情報処理推進機構）のコラム「情報システム開発のモデル契約書に目を向けよう」は、受注者（ベンダー）は専門知識にもとづいて開発を適切に進め、発注者が適切にプロジェクトに関与するよう働きかける義務を負う、と説明しています。プロジェクトマネジメント義務と呼ばれるものです。

つまり「お客さまが決めてくれなかったので」だけでは、ベンダーは言い逃れできません。決めてもらうよう働きかけるところまでが、ベンダーの仕事です。

発注側には「決めて、協力する」義務がある

同じコラムは、発注者は仕様の決定などを適時・適切に行い、資料の提供その他の必要な協力を行う義務を負う、とも書いています。協力義務と呼ばれるものです。

さらに、発注者が渡した文書（要件定義書など）に不備があって問題が起きた場合、その責任は文書を出した発注者にある、という整理も示されています。

お金を払って頼んだのだから、あとはプロに任せればいい。この考え方は、システム開発では成り立ちません。

丸投げで抜け落ちるのは、発注側の「決める」部分

丸投げとは、作業を任せることではなく、決めることまで任せてしまうことです。

画面の作り方や技術の選び方は、ベンダーに任せて構いません。任せられないのは、次のような「自社でしか決められないこと」です。

• どの業務を、どう変えたいのか
• 例外が出たとき、どちらのやり方を採るのか
• 現場の要望が割れたとき、誰が最終的に決めるのか

ここが空のまま契約すると、ベンダーは推測で作り、現場は「こうじゃない」と言い、追加の要望が積み上がっていきます。失敗の原因として後から挙がるものの多くは、この空白から生まれています。

外注する前に、決めることを1枚にする

失敗を防ぐ手は、契約書を厚くすることではなく、発注側の答えを紙1枚にしておくことです。

大きな要件定義書を書く必要はありません。中小の会社が外注する前に決めておくのは、次の三つで足ります。

一つめ：どの業務を変えるのか

「業務を効率化したい」では決まっていません。「受注の電話を受けてから、出荷の指示を出すまで」のように、始まりと終わりがある1本の流れで書きます。

業務が複数あるなら、最初に入れるのは1本に絞ります。全部を一度に変えようとすると、要望がふくらみ、どこで止めればいいのか誰にも分からなくなります。

二つめ：社内で誰が決めるのか

窓口の担当者と、最終的に決める人を分けて書きます。中小の会社では社長が決める人になることが多いはずです。

大事なのは、決める人がベンダーとの打ち合わせに出られる時間を、先に確保することです。忙しくて返事が遅れると、その間ベンダーは止まるか、推測で進めるしかありません。返事の遅れは、発注側の協力が足りていない状態そのものです。

三つめ：何が減れば成功とするのか

「システムが動いたら成功」ではなく、「この転記がなくなる」「この確認の電話が減る」のように、何が減るかで書きます。

ここが決まっていると、途中で出てくる追加の要望を「それは今回の目的に要るか」で判断できます。決まっていないと、どの要望も同じ重さに見えて、断る理由がなくなります。

途中で傾いたときに見る場所

うまくいっていないと感じたら、ベンダーを責める前に、3つの場所を順に見ます。

追加の要望が止まらない

現場から「これも入れてほしい」が続くのは、よくある失敗の入口です。旭川医科大学とNTT東日本の病院システムをめぐる裁判では、追加の要望が出続けたことが争点になり、2017年の札幌高裁の判決では大学側の責任が認められたと解説されています（@IT「旭川医大の惨劇」解説）。

要望を出すこと自体は悪くありません。問題は、「今回は入れない」と決める人がいないことです。一つめと三つめが決まっていれば、ここで線を引けます。

返事待ちでベンダーが止まっている

ベンダーからの確認事項が社内で何日も止まっていないかを見ます。決める人が打ち合わせに出られていない、窓口が判断を持ち帰るたびに社長の予定が合わない、という状態なら、原因はベンダーではなく社内の段取りです。

成功の基準がいつの間にか変わっている

最初は「転記をなくす」だったのに、いつの間にか「全部の機能をそろえる」になっていないかを見ます。基準が変わると、ベンダーは終わりのない作業を続けることになります。

大きい会社のやり方は持ち込まない

大企業には、システム部門があり、要件定義だけで数か月かける進め方があります。人手の足りない会社がそれをまねても、資料を作ることが目的になって、肝心の「決める」が進みません。

同じ「システム導入」でも、会社ごとに決める人も、変えたい業務も違います。紙1枚と、決める人の時間。中小の会社に必要なのは、その二つです。

「次の外注で何を決めておけばいいか」から、ご相談ください。今の業務の流れを並べて、どこから変えるかを一緒に絞るところから始めます。

「誰の責任か」より、何が減ったかを見る

すでに失敗してしまったとき、責任の割合を決めるのは契約と法律の話で、弁護士に相談する領域です。

一方で、次に同じことを繰り返さないために社内でできるのは、「システムが入ったか」ではなく「何が減ったか」で振り返ることです。

• 減らしたかった作業は、本当に減ったか
• 減らなかったなら、どの段階で目的がずれたか
• 決める人は、決めるべき場面に出ていたか

「システムを導入した」こと自体は何も意味しません。意味を持つのは、現場の手間がどれだけ減ったかだけです。そこから逆にたどると、自社が決めきれなかった場所が見えてきます。

今日からやること

よくある質問

システム導入が失敗したら、ベンダーに損害賠償を請求できますか。

契約の内容と、双方が義務を果たしていたかで変わります。ベンダーには進め方を管理する義務がありますが、発注側にも協力する義務があります。どちらにどれだけ責任があるかは個別の事情しだいなので、請求を考えるなら弁護士に相談してください。

要件定義もベンダーに頼んではいけないのですか。

頼んで構いません。ただし、要件定義を書く作業は任せられても、「どの業務を変えるか」「何が減れば成功か」を決めるのは発注側です。ベンダーが書いた要件定義書を読んで、自社の答えと合っているかを確かめる時間は必ず取ってください。

ITに詳しい社員がいなくても、外注はうまくいきますか。

うまくいきます。必要なのはITの知識ではなく、自社の業務を知っている人が「決める」役を引き受けることです。技術の判断はベンダーに任せ、業務の判断は社内に残す。この線引きができていれば、詳しい社員がいなくても進められます。

まとめ

システム導入の失敗は、ベンダーだけの責任ではありません。ベンダーには進め方を管理する義務があり、発注側には仕様を決めて協力する義務があります。

丸投げで抜け落ちるのは、発注側が決めるべき部分です。外注する前に、どの業務を変えるのか、社内で誰が決めるのか、何が減れば成功とするのかを紙1枚にまとめてください。

同じ失敗を繰り返さないために見るのは、責任の割合ではなく、現場の手間が何か減ったかどうかです。

関連して、外注せずに自社で作る場合の落とし穴は「ノーコードで失敗する会社の共通点」、入れたあとに道具が増えすぎたときは「社内ツールが乱立したときの片づけ方」、既製品が使われないときは「SaaSが使われない3つの理由」で書いています。