システム導入の目的は忘れられる
ところが、現実には、そうしたことが全くできていないプロジェクトも多く、私が調停を担当する事件の中にも、システム導入の目的が全くベンダに伝えられていないどころか、ユーザ内部でも、すっかり忘れられたまま、要件定義書や、ひどい時には設計書を最上流文書として、プロジェクトを進めたようなものもあります。
本来、システムの要件や設計は、導入の目的を達成するために作られるものですから、目的なしにプロジェクトを進めたところで、できあがるのは、経営に何のメリットももたらさない無用の長物となってしまいます。(運よく経営寄与するシステムができたとしても、それは、ただの偶然です。) これでは、何百万円から何十億円というお金をドブに捨てるようなものです。
今、この記事を机に座って冷静に読んでいる読者の皆さんの中には、「目的が大事って、そりゃ当り前でしょ」と感じられる方もいらっしゃるかもしれません。でも、実際にプロジェクトが始まると、様々なタスクやトラブルの処理に追い立てられる中、ユーザの担当者もベンダも、視野狭窄に陥って、”遠い過去” に合意した”システム導入の目的”など、設計書や定義書の下に埋もれたまま見向きもされなくなってしまうというのも良くある話です。
“バックオフィスの生産性を向上させる”という目的が定義されているのに、最新技術を駆使した作りにこだわるあまり、オペレータに複雑な操作を強い、かえって事務工数が増えてしまったり、”ビックデータを利用してお客様のニーズに応える” と言ってもSNSやTwitterでのつぶやきしか取り込めず、一番肝心な販売店でのお客様の声を生かせない、それでも一応ビックデータには違いないと、導入効果の少ないシステムを抱え込むことになってしまったり、といったことが実際にはよくあるものです。
なぜ、忘れられるのか
しかし、システム導入の目的が忘れられてしまう原因は、本当に前述したようなメンバーの作業状況だけでしょうか。導入の目的を模造紙に書いてプロジェクトルームに貼りだし(これはこれで有効な手段だと思いますが) 、毎朝、全員で復唱すれば、目的に合致しないシステムの導入は防げるものでしょうか。
私が裁判所や現場で見聞きしたトラブル事例を振り返ってみると、原因はそれだけではないようです。目的が忘れられてしまう、あるいは軽んじられてしまう最大の原因は、その定義や書き方の曖昧さにあります。
例えば、上述したような目的を良く見ると、実際の改善ポイントがボヤけています。”バックオフィス” とはどこで、どんな作業や処理が非効率であるのか、この目的定義では分かりません。同じようなことを意図していたとしても、「オペレータの操作を簡略化して処理時間を短縮する」と書けば、システムにおいて、どこが重要な要件になるのか、すぐに分かります。“ビッグデータ”と言っても、それだけでは、どんな声をどこで拾うのが効果的なのか分かりません。アンケート結果なのか、SNSなのか、Twitterなのか、あるいは、その全てが揃わないといけないのか、そのあたりをハッキリさせずに”ビックデータ”という言葉だけが一人歩きすると、結局なんの役にも立たないシステムを作ってしまうことになります。「販売店でのお客様と声とSNS、Twitterの情報を取り込んで…」など出来る限り曖昧さを排除して目的を定義しておけば、結果は変わってきます。
“目的の曖昧さ” に関する裁判の例
しかし、残念なことに、世のシステム導入プロジェクトの中には、こうした曖昧な目的を定義して、結果的に、とん挫するものが少なくありません。今回は、そんなシステム導入目的の曖昧さに関する判例についてお話したいと思います。
【目的の曖昧さに関する裁判の例】
(東京地方裁判所 平成22年12月28日判決より抜粋・要約)
あるユーザ企業が、以下の目的で基幹情報システムの刷新をITベンダに依頼して行ったが、プロジェクトは使用したパッケージソフトの不具合やシステムテストの難航によりとん挫した。
<プロジェクトの目的>
① 販売・購買業務の効率アップ
② ＣＲＭの基盤作り
③ 社長・役員に会社の全ての業務が正確に見える『見える経営』
ユーザはシステム導入の目的実現のために契約を締結したにも関わらず，多数の不具合があったとし，債務不履行又は瑕疵担保責任に基づいて約1800万円の損害賠償を請求した。
さて、いかがでしょう。この連載ではいつも、記事の序盤に事件の概要を問題提起のような体で書いてから、答え合わせのように判決の内容を書いていますが、今回、この記事を最初から読まれた方には、判決がどのようものであったか、想像がつくのではないでしょうか？さっそく、答え、いえ判決を見てみましょう。
