第4回　システム導入教育(1)　教育の計画を作ろう

キャリア | スキル

» 2012/11/26

　こんにちは、エル・ティー・エスの忰田です。

　このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容を紹介しています。

　前回までは、システム導入時教育が求められる背景や課題について説明してきました。

　システム導入時の教育展開が必要なのはユーザー側、システムベンダ側ともに認識はしているものの、互いの立場・スキル・認識の違いや、組織や業務上の制約によって必要な教育の提供が難しい実情があります。

　とはいえ、何もしなければシステム導入の目的は達成できません。導入効果を表すには、状況に応じた適切な施策の実施が必要になります。

　今回からは、これらの具体的な「教育施策」について説明していこうと思います。

■最初に陥る失敗

　いきなり「失敗」の話ですみません。しかし、さてシステム開発のプロジェクトが動き出すぞ……というところで、最初の落とし穴があります。

　最初に何をするか？という段階でいきなり失敗し、以後コントロール不能に陥るパターンです。よくある（よく見てきた）パターンは以下。

取りあえず作れそうな機能からマニュアルを作り始める
いきなり教育で使う「ツール」の選定を始めてしまう
大体のスケジュールだけ立てて、あとの調整や実行は開発側に丸投げする（進ちょく管理もしない）
教育なんてユーザーテストに間に合えばいいから……と思って放置する

と、こんなところでしょうか。

　1と2はかなりの頻度で発生します。しかし、これを始めてしまってから後になって方針転換するのは至難の業です。

　なぜ発生頻度が高いのか？というと、

　目に見える分かりやすいもの（マニュアル・ツール）の選定や作成を始めると、何となく「進んでいる！」という錯覚に陥ってしまう

からです。

　ただ、これはシステム開発でいえば、

　要件定義もやっていないのに、個別機能の開発を「これでいいよね？」くらいの感覚で進めてしまう

ほどの危険な行為です。成功するはずがありません。

　3の「スケジュールだけ立ててあとは開発側に丸投げ」もよく目にするパターンですが、丸投げされる側にフットワークの軽い人材がそろっていれば現場力でなんとかなる可能性があるだけ、他のパターンよりマシです。

　マシといっても、丸投げされる開発側が個別チームごとに勝手に動くので、統一感のある教育施策は実行できず、結果としてユーザー側の対応負荷が増加します。

　また、このパターンで何とかできるのも開発側に教育を検討・実施する余裕があるケースのみで、多くの場合いざ教育が必要というフェイズに入る直前になって初めて「マズイ」ということが分かり、急きょ大がかりなテコ入れをして力技で乗り切ろうとします。教育実施直前に追加工数が大幅に膨らむパターンです。

　4の「取りあえず放置」の場合は、もうどうしようもありません。

　ただ、この場合はユーザー教育以外の重要なタスクも失敗している可能性が高いので、教育の失敗は目立たずに済みます。

　プロジェクトの注目が他の課題に向いている隙に巻き返しましょう。

■失敗しないために、システム導入時教育で最初にやること

　それでは、上記のような「失敗」を避けるために「最初」に何をすべきでしょうか？考え方はシステム開発のプロセスと同じです。（1）要件定義をして、（2）設計して、（3）開発する、そのための段取りを立てる必要があります。

　教育の場合は、（1）要件定義で必要情報の収集を行い、（2）その結果を基に教育施策を設計します。そして、システムそのものの設計・開発フェイズと同期をとりつつ、（3）教育に必要なツール・ドキュメント・環境を整備し、各施策を実施していきます。

　これらの教育でやるべきことを「教育計画」としてまとめることが、最初に行うべきアクションです。

　ここで作成する「教育計画」が、「マニュアルを作成する」「トレーニングを実施する」のようなザックリした方針やToDoのみを書いただけのものでは意味がありません。必要なのは、誰を対象としたどんなマニュアルを、いつ・誰が・何をインプットにして、どのようなプロセスを経て作成するのか？また個々の教育施策によっていつまでに何を達成するのか、など前提となる要件も含めて具体的な作業レベルまで計画することです。

　それでは、意味のある教育計画を作成するためにはまず何が必要でしょうか？

■教育計画作成に必要不可欠な情報

　システムについてどう教育するか？を検討するには、事前にユーザーやシステム化する業務について細かい情報を収集しておく必要があります。この最初に行う情報収集と検討のプロセスを私たちは「ユーザー分析」と呼んでいます。

　ユーザー分析では、まずプロジェクト全体としての開発・導入期間、ユーザーの対象範囲、システム化する業務の範囲・内容を明確にします。これらはシステム開発プロジェクトを開始する時点で大体決まっているので、それほど苦労せずに情報収集が可能です。

　この後が、重要です。

　プロジェクト全体の情報から一歩踏み込み、導入のための教育という観点で、教育期間、教育対象のユーザー範囲、ユーザーの特徴を明確にしていきます。

【教育期間】

　ユーザー教育は、ユーザーがシステムを使い始める前までに実施する必要があります。システムを使い始める前まで、といっても前日や一週間前まで……では遅すぎます。教育を実施した上でユーザーがシステム化される業務を理解し、導入前と近いレベルまで習熟するには時間がかかるからです。

　また、教育を受けた上で初めてユーザーは「自分たちの仕事のやり方が変わる」ということを他人ごとではなく自分にも影響があると認識し、必要であれば質問をし、回答を得ることで理解を深めます。これらユーザーが理解・習熟する時間も含めて、教育提供の時期を検討し、それまでに提供する側の準備ができるように作業期間を逆算します。

　さらに教育期間は、ユーザーのカテゴリに合わせて複数検討する必要があります。ユーザーのカテゴリは、システムの利用頻度や利用形態（インプットをするのか？参照するのみか？）、またユーザーテストに参加するようないわゆるパワーユーザーか否か、などで区別できます。

　これらのユーザーカテゴリごとに、教育が必要な期限が異なります。教育計画には、各ユーザーの役割に合わせた教育期間・施策を明記する必要があります。

【教育対象のユーザー範囲】

　システム導入をするユーザー組織の中で、どの部署のどの業務の担当者が教育対象となるのかを明確にします。システム導入プロジェクトが開始される時点でおおまかなシステム対象ユーザーは定義されているはずですが、「教育」を検討する上ではさらに詳細なユーザー分析が必要になります。

　導入するシステムが提供する機能や業務範囲ごとに、どこにいる・誰が・いつシステムを利用するのかを明確にし、ユーザー範囲を設定し、必要な教育レベルを検討します。

　ここで特に重要になるのは、上記「教育期間」でも触れたユーザーカテゴリごとの対応、ユーザーの権限ごとに役割が異なるケース（同一機能でも使い方が異なる場合）への対応、また遠隔地や異なる組織（関係会社など）のユーザーを含めた教育実施のプラン作りです。

　このように、ユーザー範囲を明確化するには、複数の側面からユーザー分析を行う必要があります。

【ユーザーの特徴】

　教育を成功させるためには、システムを導入するユーザー組織がどんな集団なのかをあらかじめ知っておく必要があります。システム開発・導入などに対して「作ったモノを売るビジネス」のような印象を持っている人もいると思いますが、実態はシステムを導入する組織に対してシステム開発・導入の「サービス」　提供を行う対人ビジネスです。

　であれば、サービス提供をする相手がどんな人達なのか？を理解せずにプロジェクトを進めても成功するはずがありません。ユーザー教育を計画する上では、まず最低限の情報として以下を収集します。