第3回 「システム展開支援」サービスの背景（2）
こんにちは、エル・ティー・エスの忰田雄也です。
このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容について紹介しています。
前回はシステム導入時に考慮すべき「導入目的の達成」に向けた課題と対応について説明しました。
今回は、システム導入時に必要な「教育」の課題について説明します。
システム導入にはユーザー教育が必須ですが、教育成果を出すにはシステムベンダ側・ユーザー側双方が持つ課題に対応していくことが必要です。
まずはシステムベンダ側の教育の課題から話を進めます。
■「ユーザー教育」はキャリアにならない
数年前、とあるEPR導入プロジェクトにユーザー教育担当として参画していたときの話です。
ユーザー教育担当は、私の他にシステムベンダ側から参画していたメンバー（仮にK氏とします）もいました。
K氏は与えられたタスクはきちんとこなすものの、あまりやる気が感じられません。気になって「今の担当タスクをどう考えてますか？ 」と質問したところ、K氏はため息まじりに答えました。
「ユーザー教育の担当になっているが、自分は本来SCMを専門としている部署にいる」とのこと。
自分の専門性とは違う仕事をアサインされてしまうのも、人が足りないプロジェクトなどであればよくある話です。長期アサインでもなさそうなので、そこまで気にしなくても……と思っていたら、話はそれだけではなく。
「今のタスクはSCMと関係ないので、どれだけがんばっても社内では評価されない。そもそも、ユーザー教育というタスクは社内でエンジニアのタスクとして定義されていない。なので、評価する基準もない」
さらにいえば、K氏の会社ではユーザー教育のやり方、何をすればよいのかもまったく定義されておらず、身近に相談する相手もいない状況とのこと。
「これまでのシステム導入ではどうやっていたんだろう……？」と思いましたが、過去の経験を頼りに「やったことがある人がやる。やったことがある人に聞く」で済ませていたのでしょう。
エンジニアにとって、専門的に身に付けるべきスキルはシステム開発に関わる技術です。ユーザー教育が同列に扱われることは、確かにないかもしれません。
技術以外にもシステム要件を詰めるなどの部分ではユーザーとのコミュニケーション能力は必要ですが、それも「教育」と同じではありません。
ちなみに、K氏はプロジェクトが佳境を迎える前に別の開発プロジェクトのアサインが決まったとのことで、晴れやかに去っていきました。
■「マニュアル」ってどう書けばいいの？
今度は別のシステムベンダから相談がありました。内容は、端的に言えば「マニュアルが書けない」。
今動いているシステム開発プロジェクトで、システムベンダ側のタスクに「システム操作マニュアルの作成」が含まれているのだが、どう書けばいいのか分からない。自社パッケージを導入するので標準マニュアルはあるが、自分達で作っておいてなんだがマニュアルとしてはまったく使いものにならない。
どんなマニュアルを書けばユーザーに満足してもらえるのか、よく分からない。そもそも、ウチのメンバーは文章を書くのが苦手だ。
ということで、「マニュアル作成だけ御社でやってくれないか？ 」という話でした。
この話の顛末は、また別の機会にコラムとしてまとめたいと思っていますが、早期にマニュアル開発～展開を行ったことで、教育は成功しました。
システムベンダは「初めてマニュアルがお客様に評価された」と喜んではいたものの、以後は「自分たちでマニュアル開発を行う」という流れにはならず（最初はそんな話もあったのですが）、「今後もよろしくお願いします」という結果に。
■エンジニアとユーザーは別の生き物
上記の事例を見ると、「システムベンダにはユーザー向けの教育ができないのか？」と思ってしまいますが、私はそもそもシステムベンダに所属するエンジニアの考える「教育」と、ユーザーがイメージする「教育」が異なると考えています。
どう違うのか、というと以下のようなイメージです。
【エンジニアの考える教育】
- 教育すべきシステムのことは分かっている。
- 分かっているから、知っている情報は全部提供する。
- ユーザーが知りたい情報は、提供した情報の中のどこかに書いてある（はず）。
- 提供した情報の中には、ユーザーには不要な情報もあるが、そこは必要なものだけを見てほしい（分かるよね？ ）。
- 当然、システムには「システムの都合」でできることと、できないことがある（当たり前だよね？）。
【ユーザーの求める教育】
- システムのことは分からない。正直興味もない。
- システム側の都合とかよく分からない。業務の都合が優先でしょ？
- 知りたいのは、自分の担当する業務の中でシステムをどう使えばいいか？ だけ。
- エラーが出るのはシステムが悪い。出てくるメッセージとかは読まない。
- それで、結局のところ、どのボタンを押せばいいのか教えて。
かなり誇張して書いてますが、そこそこ思い当たるところはあるのではないでしょうか。
この感覚の大いなる違いは、「システム開発を仕事としている」エンジニアと、「システムは業務で仕方なく使う」ユーザーとの対システムの意識の違いから来ているのだろうと考えています。
教育の前提として、エンジニアにとってはあくまで「システムが先」で、ユーザーは「業務が先」という話です。
互いを少しでも理解して歩み寄れば上手くいくのでは……と思いますが、そんな余裕がないのも実情です。
■ユーザー側に教育を実行する余力がない
今後はユーザー側の課題に話を移します。
「システムベンダがユーザーの求めている教育を提供できないなら、ユーザー側でやればいいのでは？」という発想にもなりますが、システム開発案件のRFPでは、ベンダ側に教育の実施を求めていることが多いのが実情です。
「なぜユーザー側が自分たちの業務のシステム開発であるにもかかわらず、ベンダに教育を投げたいのか？」の答えは、ユーザー側にも教育をする人的余裕とノウハウがないということです。
まず、プロジェクトメンバーとしてアサインされているユーザー企業の社員は、本業と兼務でプロジェクトの作業にあたっていることが多く、要件定義や設計など必須のタスクにかける時間はあっても教育に時間を割くほどの余裕がない。
さらに問題なのは、多くのユーザー企業は「システム導入」という以前に、「プロジェクトワーク」を経験したことがない社員が多いということ。
プロジェクトの体制を組む、計画を立てる、詳細なWBSを引く、チームごとにタスクが割り当てられる、課題管理をする……といっても、具体的に何をすればいいのか分からない。
もはや教育どころの話ではありません。
これも実際に聞いたことがある話ですが、ユーザー側のプロジェクトメンバーがやけに少ないケースで理由を確認すると「システム導入プロジェクトに参画した場合の評価基準が社内にないから」という回答が返ってきたことがあります。これは、システム導入云々というより、担当業務以外のプロジェクトワークの発生を会社側が想定していないということでしょう。
これでは、システム導入時の教育を自分たちでやろう、という発想にならないのも仕方がないかもしれません。
■教育の専門チームの設置が必要
さて、ではどうすればいいのか？ ですが、やはり地道に対処する他、手はありません。
システムの教育、かつ業務も考慮すべき話なので、ベンダ側とユーザー側で協力して対処し、教育専任のチームを立ち上げるのが順当な対策だと思います。
教育やユーザー展開は、プロジェクト全体の動きを正確に把握した上で同期をとって進める必要があります。そのため、各チームに教育担当を兼任するメンバーがいる……などの体制では、スムーズに教育を立ち上げられません。
そして、前回のコラムでも書きましたが、システム導入の目的は「導入目的を達成すること」なので、目的達成を目指した「教育計画」をプロジェクト全体の計画と同期する形で策定するところからスタートします。
さて、続きは次回のコラムで説明します。
次回からは、具体的な「システム導入教育」の施策を順を追って紹介していきたいと思います。