第2回 「システム展開支援」サービスの背景（1）
こんにちは、エル・ティー・エスの忰田雄也です。
前回、第1回目のコラムで「システム展開支援」という仕事について、簡単にご紹介しました。
「システム展開支援」のサービスを簡単にまとめると、
- システム導入の目的をユーザーに知らせる
- 「ユーザー教育」を行う仕組みを構築する
- 「ユーザー教育」を実施する
- ユーザーがシステムを使えるようになるまでサポートする
この4つを行います。
4つすべてに共通することは、システム導入のサポートではあるものの、「対システム」ではなく「対ユーザー」のサービスである、ということです。
今回のコラムでは、対ユーザーのサービスとして「システム展開支援」が求められる理由・背景を書いていきたいと思います。
■開発が無事に終わればシステム導入は成功？
システム導入のプロジェクトが佳境を迎え、多少の問題はあるものの稼働は無事に迎えられそう……となった場合、そのシステム導入は「成功している」ように感じると思います。
開発側のシステムベンダから見れば、成功で間違いないでしょう。稼働後の保守・サポートは継続するとしても、「開発」が無事に終わっていれば「成功」でいいはずです。
それでは、ユーザー側から見たときはどうでしょうか？
システムの導入は、ユーザーにとって「目的」ではなく「過程」です。
「このシステムを導入することがプロジェクトの目的だ」というケースは少ないでしょう。
なぜなら、ユーザー側にとっての「システム導入」とは、「業務改善」「標準化」「競争力強化」などを目的としたプロジェクトの一部でしかないからです。
「プロジェクトの成功」は、システム導入の「効果が発揮され、その先の目的が果たされたかどうか」で判断されます。導入したシステムがとりあえず無事に稼働しているから……だけでは、成功か失敗かは分かりません（無事に開発が終わってない場合は失敗とすぐ分かりますが……）。
システム導入の効果を発揮するには、
- ユーザーにシステムを理解してもらい、
- 当初目的を果たすために正しい運用を教育し、
- その状態が継続されること
が必要です。
「開発」を主な作業とするシステムベンダが、開発に加えて上記3点をサポートするのは難しく（そもそもスコープに入れていないケースが多い）、結果としてユーザー側が対応しなければならなくなります。
しかし、この対応は簡単ではありません。
■エンドユーザーは「システムの変更」を喜ばない
現行システムがどうしようもなく使いにくい……などの理由がない限り、実際にシステムを使うエンドユーザーは「システムの変更」を歓迎しません。
なぜかと言えば、それは単純な理屈で「自分の仕事のやり方が変わる」からです。これは「一度覚えたことを、また覚え直さなければならない」という意識があるからです。
急激な変化にさらされれば、誰でも多少は「なぜ？ 」「必要なのか？ 」と感じます。その結果出てくる言葉は……システム導入にかかわる仕事をした誰もが一度は聞くセリフだと思いますが、「前のほうが良かった」「以前と違う」「分かりづらい」などなど……。
慣れているやり方から、知らないやり方に変われば誰でも最初は「分かりづらい」「前のほうが分かりやすい」と感じるでしょう。当たり前の反応です。
そして、この反応は時間が経てば新しいやり方に慣れるために沈静化していきます。
と、これだけで済めば良いのですが、実際はもう少し複雑です。
■目的は業務の標準化
最近の大規模システム導入では「自分の仕事のやり方が変わる」に留まらない変化が出てきています。
システム導入の目的が過去と現在で大きく変わってきているからです。
どういうことかと言うと、分かりやすい例として、
・現行システム：
10～20年前に作られたスクラッチ開発のシステム
・新システム ：
業務標準化、情報のリアルタイム化を目指しパッケージ導入
システムを実際に利用するエンドユーザーにとって、システム導入のイメージはいまだに「10～20年前に作られたスクラッチ開発のシステム」がほとんどで、新しいシステムが導入されれば、
・現場の負担が減る
・作業効率が上がる
・今より使いやすくなる
と、漠然と「新システムを入れれば今より良くなるはずだ」と思い込みがちです。
（実際にお客様からこんな言葉をよく聞きます）（特に、30代後半以上の方に多いです）
確かに、過去に行われた「業務をシステム化する」開発では、そのような面もあったかもしれません。
しかし、現在多く行われるシステム導入は、多くの場合「業務をシステム化する」ことを目的としていません。
現在のシステム導入は「業務の標準化」「情報のリアルタイム化」「企業の競争力強化」を目的としていることがほとんどです。
その結果、何が起きるかといえば、
- 業務をシステムに合わせて標準化
- 開発コストのかかる独自機能はカット
- システムで管理する情報が増える
特に、素早い経営判断が求められる現在では、判断材料とする分析レポートなどの出力のために、常に最新の情報が正しく入力されている必要があります。
結果として、システムを使うエンドユーザーの負荷は上がります。
「今より良くなるはずだ」と思っていたのに、実際は「慣れていないので分からない」上に「業務負荷が上がった」という結果になるわけです。
では、どうすべきでしょうか？
■導入の目的を伝えて期待値を下げる
画期的な解決方法は、残念ながらありません。
現場のエンドユーザーの反発は、どんな対策をしても起きるでしょう。起きるのであれば、その反発を最小限に抑えるための努力をするしかありません。
何もしなければ、エンドユーザーの「期待値（事前期待）」はコントロールできません。エンドユーザーの期待値は「業務がラクになるかもしれない」「システム化できていない部分が対応されるかも」など、どこまでも膨れ上がっていく可能性があります。
また、同時にシステム導入に不安感を持つエンドユーザーは「知らない」故に理由のない不安を募らせていきます。
このような、見えない「期待」や「不安」が解消されないまま導入が進むと、システムの「教育効果」や「正しい運用」は期待できません。必要なのは、正しく「認知」してもらい、自分の業務とひもづけて「意識」し、いずれは「興味」を持ってもらうことです。
まずは、エンドユーザーに以下の内容を伝えましょう。
- システム導入の目的・背景
- 導入を決定した経営層のメッセージ
- システムの変更により、業務がどう変わるか？
- システム導入に現場はどう関与するか？
伝えることが大事です。すぐに興味を持ってもらう必要はありません。伝えることで、正しく状況を認識してもらい、そしていずれは「やらなければいけない」という自覚を持ってもらう。そこから、システムの現場展開がスタートします。
■まとめ
今回は、「システム展開支援」が求められる理由・背景をテーマに、ユーザー側で対応する課題・アクションとなる以下について説明しました。
- システムの導入目的を果たす必要がある
- しかし、システム導入は簡単に受け入れられない
- そのために、正しく伝えることから始める
これら、ユーザーだけでは対応が難しいタスクを支援するのが、システム展開支援のサービスです。
次回は、「システム展開支援」が求められる理由・背景の続編として、プロジェクトに参加するシステムベンダ側、またプロジェクトそのものから見たシステム展開の課題について説明したいと思います。