今回は「システム操作マニュアル」を書き始める前の「設計」工程について書きたいと思います。マニュアルの設計において、最初に考えるべき部分は「目次」です。まずは目次構成をどうするのか？ から考えていきます。
■マニュアル全体の目次構成は何を基準にして作る？
マニュアルは小説・ビジネス書やその他市販されているような「読み物」ではないので「最初のページから最後まで読み進める」という読み方はしません。11回目のコラムにも書きましたが、マニュアルの代表的な利用シーンは「分からなくなったときに見る」です。そのため、自分が知りたい情報がマニュアルのどこに書いてあるのか？ を、どれだけ早く見つけられるか、が問題になります。この「どこに何が書いてあるか？」を分かりやすくするための見出しの要素がマニュアルの「目次」です。
それでは、目次はどのように作ればいいのでしょうか。
「マニュアルの目次を作っているのですが、どんな目次にすれば分かりやすいと思いますか？」とユーザー側の担当者に聞けば、何らかの答えが返ってくるでしょう。
ただし、誰に聞いたとしても、その人の「主観」が入ります。購買業務の一部分を担当しているユーザーの意見を聞けば、購買業務の一部分が中心となった目次になります。別の業務の担当者でも同じです。ユーザーは「自分の担当業務」から業務全体を見通し、自分の担当業務の観点から他の関連する部署とやりとりをして仕事を進めています。それ自体は間違いではありません。
では、システムを開発しているエンジニアに聞くと、どうなるのでしょうか。おそらく、システムの「機能」や「データの流れ」をベースにした目次になるでしょう。もしくは、そのエンジニアの関与している業務・機能だけ重点的に説明する構成になるかもしれません。
プロジェクトに参画しているエンジニアは、それぞれ決められた役割があるので、その役割に対して責任を負っています。その責任をまっとうしようとすると「自分の担当する機能については詳しく説明しなければいけない」という感覚になりがちです。しかし、一般のユーザーが見るマニュアルには、そこまでの細かい説明は求められていないため、下手に細かい説明を盛り込もうとすると、全体のバランスが悪くなります。
特定の業務のことを中心に書いても、システムの機能のことを詳しく書いても、目次としてはうまくまとまりそうにありません。特定のではどうするか？ というと視点に偏り過ぎているからです。
必要なのは業務とシステムを包括した「全体を捉える視点」です。そしてもう1つ必要な視点は「客観的な視点」です。誰の視点に合わせるか？ に話を戻すと、この2つの視点を持った人に聞けば、全体像が見えてきます。
が、そんな人はほとんどの組織で存在しません。ではどうするのか？ というと、「全体を捉える」ことと「客観性」を担保すべく、業務やシステム化する範囲を整理して、一定のルールでドキュメント化します。このプロセスがいわゆる「業務シナリオ」や「業務フロー」の作成です（作業の名称は、会社はプロジェクトごとに異なると思いますが、ここでは業務フローとします）。
業務システムを導入する場合は、ほとんどの場合その業務の業務フロー（もしくはそれに近いもの）を作成しますが、この業務フローが「業務の全体」を見通せる視点を備えていれば、目次構成の基にすることができます。
もう1つ必要な「客観的な視点」という部分については「第三者の視点」が入ることが望ましいです。
以前にユーザー側で業務フローを全て作成したプロジェクトを経験しましたが、各業務の担当ユーザーが明確な作成ルールもない状態で「自分の業務」を中心にフローを書いたために「フロー同士がつながっていない業務フローに（形は）似た別の何か」が出来上がっていました。業務を客観的に把握し、それを正しくフローに落とし込むのは未経験者が何となくやってできる作業ではない、ということがハッキリした経験でした。業務を理解して運用するスキルと、業務を可視化するスキルはまったく別物だということです。
ということで、マニュアル全体の目次構成を作るには、個々の業務とシステムを含めた業務全体像の可視化ができる人間、またそのためのプロセスが必要です。それらの作業工程の成果物を、まずは目次構成の土台として考えることができそうです。
さて、今回はこのくらいにして、次回はマニュアル設計のより細かい部分を考えたいと思います。
]]>ということで、今回のコラムはこれまでと少し内容を変えて、展示会出展レポートを書きたいと思います。
■展示会って……
いわゆる「展示会」というイベントは、主として分かりやすい「形」のある製品を展示して来場者にPRする場です。製品をたくさん売るには、幅広い購買層を得ることが第一で、そのために展示会に出展する企業はいろいろな販促品を配って来場者の興味を引く作戦に出るわけです。
ITサービス・システム開発関連の展示会でも同様で、形のあるハードやパッケージ製品が出展商品の主流です。ただし、ソフトウェア開発の業界では、エンジニアの派遣やテストの代行などの明確な「形のない」サービスも一部出展されています。
そんなIT関連の展示会に「システム展開支援サービス」を出展しました。出展内容は「システム導入時のユーザー教育」です。非常にニッチなサービスを出展したため、来場者の反応は様々でした。
■なんで展示会に出てみようと思ったのか？
システム導入時のユーザー教育のサービスを展示会に出展して、果たして人は集まるだろうか？ という、素朴な疑問がスタートでした。私が持っていた仮説は「（システム導入時のユーザー教育で）困っている人はいるはず。だが、それを専門的に支援するサービスの存在を知らない」でした。であれば「人が集まる展示会という場に出てみて、世の中の反応を見てみよう」ということになり、展示会出展を決めたのです。
出展の主目的は「調査」なので、コストは最小限に抑えました。販促物を配ったり、コンパニオンのおねえさんを使ったり…… などは一切なし。また、やたらとブースに人を呼び込むのも目的に反するので、会場でブースに来てくれた人から話を聞く、を基本スタイルとして「過剰な営業はしない」というルールのもと、サービスを説明できる社員を集めて展示会に臨みました。
■出展してみてどうだったのか？
ブースには人だかりができて大盛況…… なんてことにはならず、「システム導入時のユーザー教育支援」と書かれた看板を見て興味をひかれた人がポツポツと立ち止まる…… という状況でした。
来場者の反応で一番多かったのは「こんなサービスがあるなんて知らなかった」で、わざわざ立ち止まってくれた人の多くは、過去にユーザー教育で失敗したり、苦労したりという苦い経験のある人ばかりでした。ここまでは予想どおりです。
その他、多く聞かれた反応として「ベンダーの作るマニュアルは分かりにくい。ベンダーに操作研修をやってもらっても分かりづらい。教育部分は専門家に頼んだ方がいいのかも」など、システムを導入するユーザー企業側の声がありました。
また「もう少し前に知っていれば……」とのコメントは、昨年に基幹システム導入で苦労した情報システム部の部長さん。ユーザー企業側で、自社のシステム導入に関わった人であれば、一定の割合でユーザー教育の課題を認識しているようです。
■ITエンジニアも問題意識を持っている
ここまではユーザー企業側のコメントをいくつか書きましたが、終わってみればシステム開発・導入を行っているITベンダー・ITコンサルタント企業の来場者のほうが多かったです。
ITエンジニアを抱えている会社の経営者の方は「社員は開発に専念させたいので、マニュアル書きやユーザートレーニングは外注できればしたいと思っていた」とのコメント。他には「開発は自社でできるが、ユーザー教育は自分達ではうまくできない。パートナーとして協業できれば……」という声が多かったです。
実際のところ、システム展開支援サービスはITベンダーなどのパートナー協業・役割分担してプロジェクトに入ることがほとんどなので、実はこれも予想どおりでした。
ということで、どうやら「サービスを求めている人」はユーザー企業側・ITベンダー側それぞれで、一定数存在する（っぽい）、ということが分かりました。なので、出展目的の「調査」は一定の結果を得られたということです。
■まとめ
今回は展示会出展レポートとしてコラムを書きました。まだまだ「システム導入時のユーザー教育」の専門サービスは認識されていないと思います。なので、これからはどんどん宣伝します！ …… というつもりはないのですが、ユーザー教育にも課題があり、これを解決しないとシステム導入は上手くいかない、ということをもっと発信できれば、と思っています。
次回のコラムからは、また前回のコラムの続きを書いていきたいと思います。それでは。
]]>今回も「システム操作マニュアル」の作成をテーマに、「マニュアル作成前にやること」の後半を書きたいと思います。
■完成させるための仕組みを作っておく
マニュアルの「完成」とは、どんな状態でしょうか？ というと「ドキュメントとして100％完全なモノが出来上がること」というよりは「ユーザーの承認が得られる状態に至ること」が実態に近いです。マニュアルは基本的に業務や状況に合わせてメンテナンスを続けていくドキュメントなので、もう何も手を入れなくてもいい状態、にはなりません。「作成前に決めた目標を達成できるドキュメントになっているか？」を判断して、問題なければ納品します。
この納品に至るまでには、ユーザーのレビューをクリアする必要があります。作成した各マニュアルについて、それぞれの内容の正しさを担保できるレビュアー（の工数）を確保し、同じ基準・同じルールでレビューをしてもらいます。
しかし、多くのユーザーはプロジェクトワーク特有の「役割」や「責任範囲」の意味、そして事前に決めたルールに従って作業を進める、という仕事の仕方に慣れていません。これは、普段は自社・自部門の中の自分の担当業務という範囲だけで業務を回すという仕事の仕方をしているため、プロジェクト内だけの限定的なルール、役割、スコープという概念にうまく馴染めないのが原因だと思います。エンジニアとは根本的に仕事の仕方が違うのです。
結果として、ルールが理解できずにレビュアーごとにレビューの深さの差が出たり、スコープを考慮できずに追加の要望を出してきたり…… といった事態が発生します。これは、システム開発でもマニュアルを作る場合でも同じです。
これを回避するためには、統一したレビューの観点やレビューポイントについての理解を共有する場を設けることが必要です。何をするにもまずは、事前にしっかりとコミュニケーションをとっておきましょう。それでもなかなか難しい…… という場合は、レビュー結果を取りまとめるユーザー側の責任者（権限を持つ人）を設定することが望ましいでしょう。
■マニュアルの公開方法を決めておく
マニュアルをどうユーザーに公開して見てもらうのか？ は、見せ方によって作り方も変わってくるため、実際はかなり初期のマニュアルの設計工程で固めておかなければならない事項です。
「PDFにしてお客さまがすでに利用しているドキュメント管理システムに載せる」などの公開方法の場合は、PDFにした場合に見やすいフォーマットにする必要がありますし、ファイルをどんな単位で分割するか？ も決めなければいけません。実際にマニュアルを読むユーザーの作業現場にPCがない、台数が少ないなどの場合は紙に印刷することが想定されるため、紙に印刷した場合に見やすいデザインにしないと読もうとは思われないでしょう。
最近はタブレット端末の利用も進んできているため、その場合の配信・閲覧する仕組みも考慮すべき要素です。Webブラウザで見ることが前提の場合は、操作性やハイパーリンクの使い方をどうするか？ などが重要なポイントになります。
取りあえず「社内ポータルサイトにマニュアルの置き場所を作っておく、という方針で、細かいところは後で考える」にして先に進める…… などは、実はよくある話です。しかし「細かいところは後で」にして放っておくと、実は掲載できるファイルサイズをオーバーしていてサイトに載せられない…… とか、システムを頻繁に利用する派遣社員にはポータルサイトを見る権限がない…… などの問題が直前になって分かる、といったことも発生します。実際、何度かありました。
公開方法を検討したら、必ず「本当に、それが可能なのか？」を検証しておきましょう。
■まとめ
前回から2回にわたって「システム操作マニュアルの作成前に決めておくこと」について書いてみました。
今回書いたことをすべて検討したうえでマニュアル作成に進むのは実際のところ時間的に難しいこともありますが、やっておけばそれだけ後工程のリスクを減らせられます。「やらずに進めて失敗」は「上流工程の検討が適当だったから、要件があやふやで開発が難航するシステム」と同じです。苦労は早いうちにしておきましょう、ということです。
次回は「システム操作マニュアルを設計する」工程について書きたいと思います。
前回から引き続き「システム操作マニュアル」の作成をテーマに、今回は「マニュアル作成前にやること」について書きたいと思います。
■何をどこまで作るかを決める
まずは、マニュアルを作成する目的と範囲を決めます。読み手は誰か？ いつどのように読むのか？ などの情報を集めて、どんなマニュアルが必要なのか？ またマニュアルでどこまでカバーするのか？ を決めていきます。
そして、例えば
「システム利用者に対する基本操作の教育は研修でカバーする。業務シナリオごとの操作手順については、該当するマニュアルを参照することで利用者が独力で操作を完了できるようにする。ただし、例外操作や業務上のルールについては別途フォローする仕組みを作る」
など、ユーザーとのコミュニケーションの中で「マニュアル」が達成すべき目標を決めて共有します。
大事なのは「ここで決めた目標を達成するレベルのマニュアルを作成する」また「決めた目標を超える内容まではカバーしない」という方針について関係するメンバー間で共有することです。可能であれば、マニュアルのサンプルを作成してどのように、どこまで書くか？ まで含めて共有して認識を合わせましょう。
また、作成する範囲と期限を決めます。これは、マニュアル作成に使える時間と、マニュアルを「最初にいつ使うのか？」を考えていけば決まってくるでしょう。研修を実施するまでに○○業務と××業務のマニュアルは必要、とかユーザーテストまでにマニュアルができていないとマズイ、など多くのシステム導入プロジェクトではシステム稼働前の時点で必要になるケースがほとんどです。
■どうやって作るかを決める
書き手の考えや意見を書く論文やエッセイなら、書き手の頭の中にあることを整理して書き出せばいいのですが、マニュアルに書き手の考えを書くことはありません。マニュアル作成に必要なのは「誰が書いても同じになるようにする」ための、共通したインプット情報とルール、作業工程です。
マニュアルを作成するための主要なインプットとして挙げられるのは、業務フロー・画面設計書、あとは仕様書などの関連資料です。これらの「システムを開発するために必要なドキュメント」から必要な要素を抜き出し、整理して再構築することで「システムを利用し業務を回すために必要なドキュメント」＝マニュアルを作成します。
インプットとなる情報をどう使うか？ またどんな目次構成・ページ構成にするか？ 表現や言葉の使い方のルールやファイルの設定ルール、サーバへの格納ルールなど、諸々の作業ルールを決めます。一度標準的なルールを決めてしまえば他のプロジェクトでも流用できる部分はありますが、業務やお客さまの組織固有の言葉の使い方やインプット情報による作業プロセスの違いなど、個別に変わってくる部分も多いのが現実です。
ネタとルールが決まれば、あとはどんな工程を経て完成させるか？ を決めます。大きく見れば作業工程も作成ルールに含まれますね。
インプットを基に初期作成後、セルフレビューをしてマニュアル作成をするチーム内でまたレビュー、その後システムの仕様と合っているかのレビューと業務観点のユーザーのレビューに進む、が基本的な流れです。ただし、多くの場合システムが完成する前にマニュアルを作成するので、マニュアル作成の途中での仕様変更にどう対応するか？ のルールも決めておく必要があります。
■この後は……
マニュアルの作成目的と作成範囲、さらに作り方までを決めよう、というところまで進みました。そろそろマニュアル作成を開始できそうですが、あと2つ事前に考えた方がいいことがあります。
それでは、続きは次回に。
]]>前回までは「システム操作研修」について書きましたが、今回からは「システム操作マニュアル」について書いてみたいと思います。
■マニュアル作成、好きですか？
これまでエンジニアの方で「マニュアル書くの好きなんだよね！」という人には、残念ながら会ったことがありません。
聞いたことがあるのは……「マニュアル書くのは苦手」「マニュアル書くのは嫌い」「とにかくどう書けばいいか分からん」「そもそもお客さんにマニュアルの品質なんて期待されてないよ」などなど、ネガティブな意見ばかり。そもそも、マニュアル以外にもさまざまなドキュメントを作成している中で、さらに面倒な「マニュアル」などは書きたくない、というのが実情でしょうか。
しかし、システム操作研修と同じく、多くの場合操作マニュアルもユーザーから求められる成果物の一部になっています。そもそも必要か？ はこの後に書きますが、とにかく書かないとダメな場合がほとんどです。
■そもそもマニュアル必要ですか？
どうしてマニュアルが必要なのか？ 理由はイロイロとあるでしょう。ミスを減らす、業務の属人化防止、そもそも操作方法が書かれていないとシステムをどう使うのか分からない、などなど。
では、質問を変えて「どうしてもマニュアルが必要なのか？ 」だと、どうでしょうか？
マニュアルがあればミスが減るか？ というと……あまり変わらない気がします。画面インターフェイスを工夫して設計した方がミスは減らせそうです。属人化を防ぐ、という部分では少しは役に立ちそうです。ただし、どこまでできるかはマニュアルの品質に大きく左右されますし、またシステム操作マニュアルだけで属人化から脱却することは難しそうです。
操作方法が書いていないとシステムの使い方が分からない、は正論のような気もしますが、操作方法を細かく書かないと操作できないシステム、使い方が分からないインターフェイス、というのは別の課題がありそうな気がします。そもそも、業務をしっかりと理解した上で、業務上の必要な情報をいつどこにインプットするか、どうアウトプットするか、のルールさえ分かっていれば細かい操作方法を書いたマニュアルがなくても操作はできるでしょう。
■いつ、どんな理由でマニュアルを見ますか？
ゲームの操作方法や、テレビ番組の録画予約方法は、慣れている人ならマニュアルがなくても操作可能です。慣れていなくても、自分が何をしたいのか？ を分かっていて、それらしいボタンを見付けられれば操作できそうです。
（自分が何をしたいのか？ が分かっている、というのは、例えば「テレビ番組の録画予約をする」という漠然とした動作だけではなく、「録画予約」をするという目的のために、1.「メニュー」や「番組表」を開く 2.番組を指定する 3.予約を設定する、くらいの段取りまで頭の中に組み上げられる、ということです。「分からない」というセリフが多い人は、目的だけ見てしまい、どう達成するかをまったく考えていないことが多いですよね）
どうしても分からない、もしくは知らない言葉や経験したことがない状況が発生した場合だけマニュアルを見ればいいのです。
マニュアルの利用シーンの多くは「分からなくなった場合に見る」です。常に机の上に開いて置いておく必要はないわけです。が、それが「業務システムの操作マニュアル」になると、お客さんは急にイロイロな理由を付けて「アレが書いていない」「これだけでは分からない」などと言い始めます。
そういった意見が出るのは、おそらく自分たちの業務をよく理解していなかったり、業務が整理できていなかったりするのが原因です。もしくは、システムのメニューや画面設計がダメすぎて、画面を見ても何をすべきかまったく分からない、が原因かもしれません。
■分厚いマニュアルと薄いマニュアル、どっちがいいですか？
業務（理解・整理）がダメ、システムがダメ、な状況で「ダメなところはマニュアルでなんとかカバーしよう！ 」という方向に動くことがあります。よくあります。結果どうなるか？ というと、印刷すると電話帳のような厚さになるマニュアルができます。アレもコレも書く、という方針で作るので、当然ボリュームが増えて作成工数も増えます。
しかし、よく考えてみるとマニュアルの利用シーンの多くは「分からなくなった場合に見る」です。読み手は自分が知りたいごく一部の情報だけを見たいのですが、手元にあるのは電話帳のようなボリュームのマニュアルなので、知りたい情報を探すだけで一苦労です。そして当然ですが、メンテナンス性も最悪なので一度作ったら誰も手を付けずに放置されます。
だから私は、マニュアル作成をする際はいつも「できる限りボリュームを減らしましょう」と言っています。わざわざお金をかけて苦労して「使えないモノ」を作っても、誰も幸せにならないからです。
■では、何をどこまで書けばいいのか？
「システム操作マニュアル」を作成します、と説明してマニュアルを作っても、ユーザーの一部から「業務のことが書いていないから、これでは分からない」と言われることがあります。「業務のことは業務マニュアルを作成して、そちらに書かれてはどうでしょうか」と言うと、一度は引き下がるのですが、しばらくするとまた同じことを言われます。仕方ないので「いや、システム操作マニュアルには操作方法を書く、ということで合意いただいているはずですが」と言うと「そんな話は知らない。そもそも操作方法だけ書かれても分からないじゃないか」と、ちゃぶ台返しが待っています。
さて、これはどこに問題があるでしょうか？
ちゃぶ台返しをしてしまうことが問題（これはユーザー側がプロジェクトワークの方法とルールを理解していない、という問題）なのは当然ですが、根本の問題は「システムの操作方法だけ書く」＝「システムの操作方法しか書かない」という方針です。ユーザーさんの言っていることは100％間違いではなく、操作方法だけ書かれてもそこに業務の要素がない限り読み手は理解できません。読み手は業務のことは知っていますがシステムのことを知らないので、操作方法だけではひも付けができないのです。
（ただし、システム開発全体のコストを下げる目的で「納品するマニュアルは最低限の操作説明のみ記載 ※だから価格を下げろ」の流れになることがあり、結果として上記のような方針にならざるを得ないケースがあります。残念ですが……。）
結果として出てくる最適解は「業務の流れ＋操作説明」の構成で、かつ業務の細かい説明までは書かない（書けば分厚いダメなマニュアルになる）になるのですが、常にどんなプロジェクトでもこの方法でOK！ というやり方は存在しないので、都度システム導入先組織の文化や気質に合わせた調整が必要になります。ユーザーのことを深く知り、理解した上で施策を練らなければ教育の成功もシステムの定着もできない、ということです。
■まとめ
システム操作マニュアルについて意識すべきポイントは、今回のコラムでも書きましたが以下の4つです。
取りあえず、これら4つを意識するだけでもかなり違ってくると思います。
次回はもう少し踏み込んで「マニュアルの作成前にやること」について書きたいと思います。
]]>ここ数回のコラムでは「システム操作研修」の設計から準備について順を追って書いてきましたが、ついに今回で「研修」をテーマにした連載が終了です。では、最後となる研修の「実施」について考えてみます。
■実施……の前にリハーサルをやろう
時間がない、実施直前まで説明内容を作りこんでいた、データの仕込みが間に合わなかった、などなど、研修実施前にリハーサルができないケースは多いでしょう。でも、やりましょう。やる前提でスケジュールを組みましょう。
研修実施に不慣れで経験がない人ほど、リハーサルをしません。なんとかなるだろう、と根拠のない自信を胸にぶっつけ本番で失敗します。やってみないと分からないことは、案外多いのです。
部屋の広さや受講者が座る机の配置、講師が使うPCやプロジェクターなどを投影する場所…など、確認しておかないと後悔します。部屋の広さ（あとは形・明るさ・照明の配置も）によって、声の大きさや「どこまで講師から見えるか」が変わってきます。どのくらい声を出せば最後列まで届くのか、全体の何割の顔（反応）を見ながら進められるのか、は重要な要素です。また、マイクがあるか？ スピーカーはどこにあるか？ など部屋の設備を確認する意味でも、リハーサルは重要です。
■研修講師、得意ですか？
いろいろと書いておいてどうかと思いますが、かくいう私自身、決して講師役は得意ではありません。特に最初のころは不得意というより苦手意識が強かったです。しかし、何度か経験するといくつかの「コツ」が見えてきました。
苦手、うまくできない、という人は以下の問題を抱えていることが多いです。
受講者の前に立っているのに、受講者を見ずに画面や紙ばかり見てしまう。これでは受け手が話を聞いているか分かりません。1人で勝手にしゃべっているのと同じです。これが、苦手意識を持っている人が最もやりがちな失敗です。受け手の顔を見て、反応を確認しつつ説明する、を実践しましょう。
読み上げるだけなら、最近は機械でもできますね。細かい説明文を都度読み上げる、などをやると時間も足りなくなります。必要なのは音読して聞かせることではなく、伝えて理解を得ることです。
読み上げをしてしまう原因は、主に説明する対象に関する理解が足りないことです。知っている・分かっていることであれば、ポイントを絞り込んで説明できるはずです。よく言われる話ですが、人に説明できないということは要するに理解できていないのです。理解はしているけど、どうしてもしゃべる段階になるとうまくできない、という場合は説明する単位（ページやフローなど）ごとに、ポイントを1～3つくらい書き出してそれを読んで伝えましょう。ポイントを書き出す、という作業を行うことで頭の中が整理され説明できるようになる、という効果もあります。
早口で説明する人に「早過ぎるよ」というと「そうですか？ そんなに早く話したつもりはなかったですが」などの答えが返ってくることが多いです。自分がしゃべっているスピードの妥当性がよく分からない状態。それは言葉を変えれば「いつもと違う＝ 緊張している」ということです。
緊張している人はゆっくりしゃべれません。緊張するクセを直すには、まず一番は「慣れる」ことですが、慣れるだけの時間がない場合は「短く区切ってしゃべる」「少ししゃべったら息抜きの動作をする」などを意識して繰り返しましょう。区切ることを意識しはじめると、それだけでスピードが落ちてきます。また例えば「息抜きの動作として時計を見る」と決めておき、一度しゃべるのをやめて時計に目を落とす、という動作を意識的に行うと緊張がずいぶん和らぎます。あまり時計を見過ぎると不自然なので、その場に合う自然な動作がいいでしょう。
大事なことは二度言ってください。「大事なことなので二回言いました」とは実はかなり的確な言葉です。聞き漏らしは誰にでも発生します。そして、大事なことを聞き漏らすだけで一気にその後の理解が崩れることがあります。前提が違っていた、必須の手順が抜けていた、正常系か例外かを聞いていなかった、などは発生する前提で考えましょう。「途中から聞いても分かるように説明する」を意識して、振り返りをしつつ話をすることが大事です。
■システム操作説明のコツ
まず「話す」という観点でよくやってしまう行動を説明しましたが、これ以外にも重要な要素があります。システムの「操作」の説明であるが故に必要になってくるポイントがあるのです。
受け手は画面を見ているのだから大丈夫だろう、という考えは捨ててください。黙ったまま画面操作のデモしても受講者は「何をしているんだろう」としか思いません。また、無音の時間が続くだけで受講者の集中力は低下し「今何をやったんだっけ」につながります。
まず「これからどんな操作をするのか」「講師の操作を見ていてほしいのか」「受講者も同じように操作をするための時間なのか」を必ず説明した上で、講師は操作をしましょう。
例えば「システムを起動させて○○ボタンを押して次の画面で△△項目に何か入力する」という動作を説明する場合で、悪い例と良い例で比較してみます。まずは悪い例。
このように「操作の説明はしていても合間に空白の時間がある」だけで聞き手の集中力が途切れます。
では、次は同じ操作を説明する良い例です。
といった具合です。なんとなく「説明慣れしている」ように聞こえませんか？ このように「これから何をするか」と「今何をしているか」を、実況するようなイメージで説明しましょう。
今何を見せているのか？ 次に何を見てほしいか？ など、次のアクションにつながる情報を常に伝え続けます。
例えば、
などなど、どこを説明するか？ これから何をするか？ どこを見てほしいか？ その後で何をするか？ などの情報を提供し、受け手の視点や動作の道筋を示した上で、本格的な説明に入ります。
この時も、画面や紙ばかりを見て話さず、受講者に目を向けて常に反応を見つつ進めることが重要です。
■まとめ
さて、4回にわたって「システム操作研修」について書いてみました。
実際のシステム導入プロジェクトの現場では、なかなか研修の開発や準備に時間をかけられないという事実もありますが、そうはいっても時間や労力をかけなければ成功しないくらいに困難な作業です。データやシステムではなく、人を相手にした作業になるため、相手の期待値や相手の理解力も踏まえた研修を提供しないと、価値が生まれません。「よかった」「理解できた」と思ってもらうこと、をゴールとして考え、さまざまな人の協力を得ながら進めていきましょう。
]]>このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容を紹介しています。
前々回のコラムから「システム操作研修について」をテーマに、なぜ研修を実施するのか？ から研修カリキュラムの設計についてを説明しました。今回は、個々の研修を開発し実施準備をする工程について考えたいと思います。
■準備完了！「これで大丈夫だろう」が命取り
研修のカリキュラムができた時点で各研修の中で何を説明するか？ もある程度明確になっています。当日何を話すかを考えて、資料も準備して、そこで「もう大丈夫だろう」と思ってしまうと、落とし穴があります。そのまま進めると、実施当日になって「半分も説明できないまま終了時間になってしまった」という結果になるケースが多いのです。最初から「2時間の研修」と分かっていて、教育する内容もだいたい決まっていたはずなのに、なぜこのような状況が発生するのでしょうか？
■本当にすべてを「今」教えないといけないのか？
特定の業務に関するシステム操作について2時間の「研修」を作成する、という場面があったとします。その業務に関与するユーザー部門を相手に、研修で何を教育すべきか？ をヒアリングしていくと、どんな結果になるでしょうか？
などなど、この機会に教えたいという欲が出てしまい、収集がつかなくなりがちです。その結果を真に受けて詰め込み型の研修を作ると、「一つのテーマは最大5分しか説明できない」といった結果になり「5分ごとに違う内容を休む間もなく説明される」ことになります。こうなると、全体の話の流れもなにもあったものではありません。そもそも5分で1テーマの説明は無理なので時間内に終わらなくなりますし、受講者も「講師が早口で何を言っているのか分からなかった」という感想しか持てないでしょう。
こんな結果を避けるためには、説明する内容に優先順位を付けて優先度の低いものを思い切って切り捨てるしかありません。切り捨てられる説明をしてほしかった一部のユーザーは「いや、ここも重要だ」と反論するでしょう。確かにその反論は正しいかもしれませんが、すべての業務が「その時点で」教育すべき重要な内容なのか？ というと、そんなことはないはずです。教育する時点が、ユーザーテストの前ならば、テストシナリオに関わる業務範囲を重点的にケアすべきですし、システムの本稼働前ならば、稼働直後に発生する業務範囲を詳しく教えるべきです。本稼働の半年後に使う機能（でも業務的にはとても重要）であれば、確かに重要かもしれないですが、「半年後にやることを今教わっても忘れる」が現実です。
■何分で説明できるのか？ を検証する
「これは15分もあれば説明できるだろう」と考えて、そして考えただけでそのまま進めてしまうと……失敗します。「いやそんなことないだろう」と思う人は、やってみてください。「私は経験豊富だから大丈夫」と思っている人は「経験豊富なプロ研修講師こそ、必ず説明内容と時間の検証をする」という事実を知るべきです。
何が問題か？ というと「これは15分もあれば説明できるだろう」という【浅い考え】が問題です。そこに「受講者の前で話して反応を見つつ先に進める」という要素が入っているのか？ 「資料やシステムの画面、画面の中でも操作する順に受講者の視点の移動を促し、理解を確認しつつ説明する」という非常に神経を使う作業が考慮されているのか？ という話です。
一つのテーマに対して、具体的にどう話すのか？ 話すときにどの資料を使って、どうポイントをまとめるのか？ システムの操作をさせるなら、一つ一つの操作ステップのデモとその説明、受講者の演習にどれだけ時間がかかるか？ など、細かく状況や説明の方法を整理し、使う時間を検証します。そこまでやると「15分だけでは思っていたほど話ができない」ということがやっと分かってきます。
■タイムシートを作る
研修の中で説明する内容を絞り込み、説明する内容を詳細化するところまで終えると、やっと研修1コマの細かい時間配分が見えてきます。この結果を説明内容と時間（分）で区切り、タイムシートに落とし込みます。長時間の研修であれば休憩時間という要素も必要ですし、操作の実習をするのであれば状況にもよりますがシステムへのログインをするための時間も考慮しないといけません。また、連続性のある研修であれば「前回の復習」や「今回のまとめ」のような振り返りの時間も必要です。
これらを全て考慮し、時間配分をタイムシートに記録します。研修教材とタイムシートまで作成しておけば、一つの研修を繰り返し実施する際に毎回ブレなく同じ説明内容や時間配分を維持することができる、という利点もあります。
■そして「仕込み」をする
システム操作研修が他の教育研修より労力がかかるのは、受講者に「実際にシステムを操作させる」ことが求められるためです。操作させるための準備が必要です。いわゆる受講者用の「データ仕込み」という手間のかかる作業です。一度仕込み方を決めてしまえば、場合によっては、後はバッチで自動化、研修実施前の環境を復元して繰り返し、などもできますが、いずれにしても「最初の仕込み」と、そもそもの「仕込みをする環境の確保」また「どんなデータを入れておくか？」「どんな操作をさせるか？」といった決めが必要になります。
この中で最も苦労するのは「どんなデータを入れておくか」の問題です。研修実施時点では「それっぽい」データがシステムに入っていないことがあります（データ移行のテストができている場合は運がいいですが、実際データ移行がスムーズに進んだプロジェクトを見たことがありません）。それでもできる限り「それっぽい」データを準備すれば、受講者は見知ったデータ・名称を見られるため、そこからシステムの構造を理解できます。
仕込み作業は「決め」さえ乗り越えればあとは単純な繰り返しです。体調に気をつけて準備を進めましょう。
■あとは、研修実施！
ということで、やっと準備が終わると、最後の工程「実施」が待っています。後はやるだけ、の状態ですが、最後に失敗すると努力も台無しです。
実施の工程については、次回のコラムで書きたいと思います。
]]>このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容を紹介しています。
前回のコラムから「システム操作研修について」をテーマに、これまでの経験から前提事項やポイントをまとめています。今回は、システム操作研修全体のカリキュラムをいかに設計するか、を考えたいと思います。
■研修のカリキュラムを作る
システム操作研修の肝となるのが「カリキュラム」です。研修の実施がゴールであれば、カリキュラム設計はそのゴールまでの道筋を作る重要な工程となります。研修の準備から実施までに必要な工数も、カリキュラムが出てこないと詳細化ができません。そのため、なるべく早い段階でカリキュラム設計に着手することが後の工程の失敗を防ぐための最大のポイントとなります。
カリキュラムを作る前にシステム導入時のユーザーに対する「教育計画」ができていれば、ある程度の情報が揃っているはずです（教育計画については4回目と5回目のコラムで説明しています）。
ユーザー教育を実施する期限、教育の目的（ゴール設定）、教育範囲、大まかな対象者、などはカリキュラムを作る前の時点（教育計画の作成時）で明確にしておくべきでしょう。
上記の前提となる情報を踏まえて、具体的な研修実施計画（＝カリキュラム）を作成します。
カリキュラム設計で重要なポイントは、以下の4点です。
研修の実施形態は多種多様です。やり方だけでも、対面で実施、テレビ会議などの非対面形式、eラーニングなどのツール利用、などなど方法はいくつもあります。また対面で実施の場合でも、遠隔地のユーザーがいる場合は本社・支社などに集めて研修をするか、実施する側が各地を訪問するか、という判断もあれば、直接プロジェクト側から研修の対象とするのは主要なユーザーのみとして、その他のエンドユーザー研修はユーザー側に委ねる、などの判断もあります。
その他、カリキュラムをどんな切り口で設計するか？ も重要です。システムの機能で分ける、業務の種類で分ける、受講対象者となるユーザーの部署で分ける、などやり方はいくつもありますが、それぞれ一長一短あるために「何を優先するのか？ 」を明確にしておく必要があります。ユーザーの都合を最優先するのであれば、ユーザー部署ごとに最適なカリキュラムを提供すべきですし、効率を優先して最小の工数で研修を実施するなら、システムの機能ごとに研修クラスを設置し、それぞれの部署から必要な部分だけを受講してもらう方法をとります（この方法は受講者の選別や業務と機能のひもづけが非常に難しいですが……）。
実施形態によって、研修の開発期間や必要な情報、実施場所や回数が大きく変わってくるため、システム導入教育全体の中でも最も重要かつ難度が高い作業です。
複数の研修に出席するユーザーの場合、出席するごとに研修内容や教材の構成が全く違っていたら、毎回異なる説明の流れや教材の見方をその都度覚えなければいけなくなります。そうなると、研修を開発する側の工数も多く消費されてしまいます。
このような事態にならないように、研修の基本的な構成や研修教材のテンプレートを決めておきます。業務システムの研修では、大きく分けて「業務の解説パート」と「システム操作手順の教育パート」に分かれます。これらの説明順序や毎回の研修で必ず伝える内容（受講の注意点や各研修コースの前提・目的・ゴールなど）の基本構成をあらかじめ決めておき、各研修コースでは基本構成に沿った形で研修を実施します。教材も同じように、基本構成に合わせた一定のテンプレートを使って開発することで、受講者が毎回教材を最初から最後まで読み込む必要がなくなります。研修開発の作業予定も基本構成が決まっている方が見通しやすいはずです。
実施形態や基本構成について結論が出たら、次は実施形態に合わせた、実施をフォローするための必要な研修教材を定義します。研修開発とは別枠で操作マニュアルを開発しているケースでは、そのマニュアルをそのまま教材として利用することが多いですが、実際の研修ではマニュアルの中身を順番に説明する、ではなくマニュアルの内容を抜粋・まとめた説明になります。その場合、マニュアルのみで完結させることが難しくなるため、補足資料や補助教材を準備するなどの合わせ技で対応することが多いです。
また、システム操作研修の場合、実際の「システム操作」そのものを研修の中で実践します。この「操作演習」を行う場合は、演習をスムーズに進めるための「どこで何を入力しどう操作するか？」を説明する資料も準備します。
実施形態が決まると、それぞれの研修の受講者が誰か？ が明確になります。受講者をベースにして実施形態を設計している場合は、最初からある程度把握できているかもしれません。
これらの研修クラスに対する受講者をどこまで管理するか、どのように管理するか、を決めておきます。簡単に言えば、個人や部署のレベルで出欠をとるか？ を決めよう、という話です。
研修の受講率はシステムが稼働可能かを判断するための要素にもなり得る（ちゃんと研修開発して管理していれば）ため、必要であれば出欠を管理します。ただし、ただ出欠だけ管理しても「理解度」までは判定できないため、受講後のアンケート実施やヒアリング、理解度テストなどの方法も合わせて利用することが重要です。ただし、これらの実施管理や理解度判定は、研修の目的・到達目標が正しく明確に定義されている場合は有効に働きますが、目的がハッキリしないまま行うと出席率の数字やアンケートの結果に翻弄されるだけになるため、注意が必要です。うまく管理できそうになければ、あえてやらない方が無難かもしれません。
■各研修コースで扱う内容を決める
カリキュラムの設計が進むと、各研修のコースで何を教育するか？ が明確になってきます。このコースは2時間で「海外向け発注プロセスを説明する」くらいのレベルにまでは落ちてくるはずです。
これを、もう少し具体的な内容に落とし込みます。2時間という時間の使い方を意識して、限られた時間の中で何を伝えるのか？ を整理します。このレベルまで整理すると、複数のコースで教育内容が重複する・研修コースに漏れがある、などの問題が顕在化してくることがあるため、必要に応じて研修コースをまとめる・追加する・削減する、などを行い、各研修コース内容の精査を進めます。
内容を決めたあとは、2時間の枠のうち何を何分で説明するか？ までを整理し構成を詳細化するのですが、こちらは次回のコラムで説明したいと思います。
このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスの目的や内容を紹介しています。
今回からは、システム操作研修について書いていきます。
■なぜ、システム導入教育で「研修」をやるのか？
あらためて思い返すと、どうして研修が必要なのか？ というテーマを具体的に考えたことはないような気がします。いい機会なので「研修を実施する理由」について考えてみようと思います。
まずは1つ目。
ユーザーさんから「マニュアルが（分かりやすく）ないからシステムが使えない」「まともな研修も受けていないから使い方が分からない」などの話を聞くことがあります。こういった話を聞くと、「マニュアルがあれば、研修を受けていれば、システムが使えるんですか？ 本当に？」と思ってしまいます。
立派なマニュアルがあっても、充実した研修を受けても、使えない人（＝覚える気がない人）は使えません。使えるようになるのは、「仕事だし仕方がないから、新しいことを覚えよう」と覚悟を決めた人だけです。
それでもやはり、「マニュアル」「研修」というキーワードを強く言い続けるユーザーさんは多い。なぜだろうか？ と考えると、それは単に「マニュアルも研修も、当然あるべきもの」と考えているから、ではないでしょうか。
高いお金を払って買ったor開発した「新しいシステム」という箱の中には、当然のように立派な「マニュアル」が入っていて、使い方は専門の講師が「研修」をやって教えてくれる、と思っているユーザーは多いです。本当に多いです。本来、システム導入は導入先組織の業務の仕組みにシステムを組み込む、ということなので、どう使うか？ 利用者にどう使い方を伝えるか？ はユーザー側が主体となって考えるべき話です。ですが、どうしても自分たちを「お客さま」だと思ってしまい、やるべきことを見失うユーザーさんは多いです。多いですよね……。
ということで、「なぜ、システム導入教育で研修をやるのか？」という問いへの1つの回答として「当然研修をやってくれる、とユーザーが期待しているから（やらざるを得ない）」が考えられます。
2つ目の回答としては、「短期間での教育が必要だから、研修を実施する」です。
新システムが稼働し始めたら、その新しい仕組みを使って業務を回さなければいけません。「新しいシステム？ まぁ自分はゆっくり使い方を勉強するよ」ではいけないわけです。稼働する前の開発期間で教育を終わらせる、が前提である以上、集中的な教育提供が必要なため、結果として「研修」という形態を用いることになります。
そしてもう一つ、これが最も大きな理由だと思います。それは「教育対象の人数が多いから」です。この「人数が多い」という点について、もう少し掘り下げて考えてみましょう。
■最も効果のあるシステム操作研修とは
「研修」、正確にいえば「集合研修」という形式で教育をする上で最も大きな課題は、多人数相手の教育のため一人一人の理解に合わせて個別にフォローできない、という点です。
逆にいえば、教育効果を最大にしたければ「集合研修」ではなく「一対一」でシステムの操作方法を教えればいい、ということです。やはり、最も教育効果を出したければマンツーマンがいい、という結論に至るのです。
といっても、現実を見るとシステム導入の現場にそんな人的余裕はありません。そのため多人数を相手にした「研修」の教育効果を上げようとする場合、いかに「1対1」の教育形式に近づけるか？ を考える工程をたどることになります。
■教育効果の高い研修を設計する
「1対1」の教育効果を多人数の集合研修でも発揮するには、という観点で研修を設計するポイントを考えると、以下の3点が挙げられます。
相手が一人であればその一人に合わせた説明をすればいいのですが、研修は多人数が相手です。受講者のスキル・知識の幅が広すぎると、どこに合わせても「合わない」人が出てきます。どんなスキル・知識レベルの人を対象とする研修なのか、を定義し、定義した想定ユーザー像に近い受講者を集めます。
研修を受講する人数は、少なければ少ないほどいいのですが、1回に受講する人数を減らすと研修の実施回数を増やすことになります。一度に終わらせた方が実施する側はラクです。が、一度に教えられる人数には上限があります。
講師1名のみで実施する研修であれば10名が限度、講師に加えてアシスタント1名がいる場合でも、30名が限界です。できれば20名程度がベターです。私も何度も研修を実施したり、現場に立ち会ったりと経験していますが、上記の人数以上になると一気に研修の効果が落ちます。100名近くのケースもありましたが、もはや研修ではなく講師の演説でした。そして、後になって「あんな研修では分からない」と言われるオチが待っています。
人数と同じくらい重要なのが、時間です。一度の研修時間は2時間程度が最適です。それ以上は、一度に人が覚えられる知識量の限界を超えてしまいます。3時間の研修で「ラスト5分」という時に「最初に教わったことを思い出せるか？」と聞くと、なかなか難しいのです。「一対一」で会話しながら教わるのであれば、分からなくなったらその都度確認できる（講師も相手の理解度を見てフォローできる）のですが、集合研修ではなかなかそうもいきません。であれば、記憶できる範囲の時間で完結させる、が最適な対応になります。
■まとめ
上記で書いたこと以外にも、あらためて考えてみるとイロイロとポイントはあげられそうですが、今回はこのへんでおしまいにします。そして今回はあまり触れていませんが、システム操作教育はその名のとおり「システム操作の方法」と「そのための前提知識」を教えるものです。ただ知識や手順を教える以上の難しさ・複雑さがそこには凝縮されています。
次回以降は、その辺りに踏み込んで考えてみたいと思います。
]]>このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容について紹介しています。前回のコラムでは、システム導入プロジェクト開始時に行う「教育計画」の作成について説明しました。
今回は「教育計画」の作成と併せて実施する「ユーザーとのコミュニケーション方法の定義」について説明します。
■「急にシステム変更を知らされる！」をなくそう
今回は、とあるシステム導入プロジェクトで起きた事例の紹介からスタートします。
プロジェクトも後半に差し掛かり、ユーザーテスト前にエンドユーザー教育を始めようとした矢先。いざユーザー研修の対象者と話してみると、「システムが変わるんですか？ いつから？ そんな話聞いてないですよ」と言われる。
取りあえずPMをつかまえて、
そんなような話が以前、残念ながら実際にありました。
プロジェクト初期段階の計画フェイズから参画していれば状況に気付けたのですが、エンドユーザー研修実施の直前に急きょ「教育だけやって！」との依頼を受けて参画したため、ユーザーとのコミュニケーション状況まで事前に確認できていませんでした。
この後、ユーザー研修のスケジュールをユーザー側担当者に打診し、「そんなスケジュールを急に言われて対応できるか！」と怒られ（そりゃ怒ると思います……）、スケジュールの引き直しからスタートし、その後「ごめんなさい」を繰り返しつつ調整を進めてなんとかユーザー研修の実施までこぎ着けました。このとき、ユーザーテストの開始も遅れていたので、「ユーザー研修が遅れたせいでテストが進められない！」にならずに済んだのは不幸中の幸いでした。
さて、前置きが長くなりましたが、このような「コミュニケーションミス」が発生する原因はどこにあるのでしょうか？
■プロジェクト現場で発生するコミュニケーションミス
コミュニケーションに問題が発生する原因は、大きく分けて2つあります。
1つ目はコミュニケーションそのものの問題です。
多くの場合、プロジェクト現場ではユーザー側とベンダ側がコミュニケーションを行い、そしてそれなりの確率で気付かないうちに意思疎通に失敗しています。失敗を繰り返すことで「どうせ伝わらない」⇒「ムダ、めんどくさい」になり、だんだんとコミュニケーションの頻度そのものが減っていく、という悪循環に陥ります。
これは、ベンダとユーザーが「別の生きもの＝互いに異なる性質を持つ人の集団」であることを認識、また配慮せずにやりとりを行ってしまうために発生する問題です。（この話は第3回目のコラムで書きました）
この課題への対処は「相手にとって理解できるコミュニケーションを行う」こと以外ありません。実際に実践すると非常に地道で面倒な作業ですが、間違いなく「やらない」より「やった」方がプロジェクトの失敗要因が減ります。覚悟して「相手に合わせた」コミュニケーションを続けるように努力しましょう。
さて、今回のコラムの主題は、2つ目の原因「コミュニケーションのルール・ルートがない」ことへの対処です。
システム導入のプロジェクトに参画している一部のユーザーは、システムが導入される事実を知っています。が、その他のエンドユーザーにどこまで情報が伝わっているか？ は実はよく分からない（誰に聞いても明確な答えが返ってこない）ケースが多いです。
よく分からない、ということは要するに「伝わっていない」のです。いつの間にかみんな知ってた！ なんてことは99％起きません。（あえて100％ではなく99％にしているのは、社内の情報を社外（例えばFacebookなどのSNS）で知った、というセキュリティ上明らかに問題のある情報ルートが存在している場合があるからです。いや、実際にあるんです……）。
会社などの大きな組織に対して何かの情報を発信し、末端の社員まで行きわたらせるには、それなりの仕組みが必要です。一般的な企業では、総務部や人事部などの部署（あるいは前述の部署などが管理する企業内ポータルサイトなどのIT基盤）がこの機能を担っていますが、システム導入のプロジェクトではどうか？ と考えると、情報伝達の仕組みがそもそも抜け落ちているケースが散見されます。
プロジェクト内での情報伝達がそもそもマズイというケースも残念ながらよくありますが、ここで問題にしているのは、プロジェクトからユーザー組織全体への情報発信の機能がない！ というケースです。システム導入はプロジェクトのメンバーだけが関与していればよいわけではなく、最終的にはユーザー組織のある程度の範囲あるいは全体が関与することになります。この関与する多くのユーザーとのコミュニケーションとは、単に「関係者全員にメールを流す」だけで済む話ではありません。
システム導入の成功・失敗の判断は「導入目的の達成」にある（と第2回目のコラムで書きました）ため、エンドユーザーに対する目的の共有や理解の支援から始めなければ意味がないのです。そのためには、地道な説明の繰り返しや、ユーザー組織を巻き込み組織内の「人」に食い込んだコミュニケーションを行う必要があります。そのための必要なのは、やはり「コミュニケーションのルールやルートの設定」をすることです。
私たちが提供しているシステム展開支援のサービスでは、プロジェクト進行に必要なコミュニケーション支援を行う場合「コミュニケーションプラン」を作成し、プランに沿った情報発信を行います。
■コミュニケーションプランを作り、役割とルートを設定する
コミュニケーションプランとは、エンドユーザーに対してプロジェクト側から情報提供を行っていくための役割やルートを定義し、その実行を支えるための計画です。通常は、教育計画を作成する段階で同時にプランニングします。
エンドユーザーとひとくちに言っても、その階層はさまざまです。
実際は役職以外のシステム運用における役割の違いもあるため、もっと複雑な階層に分かれます。これら、さまざまな階層のユーザーに対してプロジェクトの進行に合わせて情報を提供するための仕組みを作ります。
仕組み作りのポイントは3つ、「段階的な情報発信」と「情報のルート整備」と「役割を与える」ことです。
いきなり細かい話（新システムの操作方法とか）から始めても理解できません。まずは「システムが導入される」という情報を小出しに発信し「認知」してもらうことを優先します。その後「あたながたの仕事が変わるんです」というメッセージを表に出して「興味」を持ってもらいます。
この情報を、時間をかけてかつ期間を開け過ぎずに発信し続けることで、システム導入について「急な話」ではなく「前から聞いていた話」のイメージに定着させます。そして十分にシステム導入のイメージを持った後で「導入教育」のフェイズに入っていきます。
単に「プロジェクトからユーザー全体への発信」では、情報は伝わりません。全員に同じように伝えられた、ということは「自分」にとっては大して影響の大きな話ではないのかな、と感じるのが自然ではないでしょうか。
重要なのは「あなた」に伝えている「あなたに関係のある話」という認識を持たせることです。これを実践するためには、1人の情報発信者に対する受信者の数がある程度限られている（同じような集団である）必要があります。そのため、基本的にプロジェクトからの情報伝達のルートはユーザー企業の組織の枠組みを利用します。ユーザーのAさんが所属する○○部署の通常連絡の中にプロジェクトからの情報も含めるのです。
前述した「情報のルート整備」では、通常の組織の枠組みを利用する、と説明しましたが、単に利用するだけでは情報は上手く伝わりません。例えば、○○部の担当者に対する情報伝達の役割を、○○部の責任者である部長が担っていたとします。しかし、そのまま「部長お願いします」だけの場合、情報は伝わりません。放っておいても部長は通常業務で忙しく、また「システム導入」という面倒な仕事に対応する知識や労力が不足してる場合もあります。
そこで、部長を補佐して情報伝達を推進する役割を、部長以外の「実行可能な」人間に与えることでサポートします。プロジェクトから「情報伝達の推進窓口」の役割を与えて、プロジェクトの準メンバーとして主体的に動いてもらうのです。「推進窓口」の任命責任は部長などのグループの責任者に与えます。プロジェクトからは、この「推進窓口」のメンバーに随時連絡をし、状況を共有しておきます。ユーザーの組織の規模が大きい場合は、この「推進窓口」の役割を1つの部署内に複数段階設定し、末端まで情報が行き届くようにします。
この役割を担うメンバーは、その後プロジェクト終了までプロジェクトと現場のパイプ役になり重要な役割を果たします。IT知識もある程度求められ、臨機応変に動いてもらう必要も出てくるため、ベテランよりも若手の方がいいでしょう。
これらのポイントを押さえてコミュニケーションの仕組みを構築し運用することで「システム導入なんて聞いてない！」を防ぎ、エンドユーザーのシステム稼働後の早期立ち上がりを支援できます。
■まとめ
コミュニケーションプランは、他のユーザー教育タスク全般に関わる非常に重要な位置付けにあります。教育計画の作成が不十分な場合、教育タスクの実行フェイズで失敗する可能性が高くなりますが、実行そのものが頓挫するレベルにはそうそう至りません。実行が遅れたりなかなかユーザーの了解がもらえず終電を逃したり、と立て直しに苦労するだけです。
しかし、コミュニケーションプランが未整備の場合は教育タスクの実行以前の問題が発生します。ユーザーの協力が得られない、プロジェクトの実行がユーザー組織にそもそも認められない、などの問題が起きる可能性があるのです。実際、過去に失敗した大規模プロジェクトの中には、プロジェクトの進行そのものの問題以前に、エンドユーザーからの反対によって中止されたケースも多々あることをご存じでしょうか。それほどに、コミュニケーション不足はシステム導入プロジェクトにおいて重要な課題になるのです。
世の中にはプロジェクトマネジメントにおけるコミュニケーションの重要度を説いた書籍が大量に出回っています。書店に行けば、すぐに目に付くはずです。また、過去にシステム導入に失敗した経験を持つユーザー企業（で、かつ失敗からの学びがまともにできる組織）の場合、コミュニケーション方法の整備に恐ろしいほどの執念を持ちます。「コミュニケーションさえしっかりできれば、失敗するリスクが大幅に減る」という確信を持っているからでしょう。
何気ない会話もコミュニケーションの一環です。普段、あなたが誰かと会話するときに無意識に言葉や伝え方を選んでいるように、プロジェクトでのコミュニケーションでは意識的に「伝える」ための方法や表現をしっかりと考えるようにしていきたいですね。
ということで、今回は「コミュニケーションプラン」の作成について説明しました。
次回からは、ユーザー教育実行時のメインタスクとなる「ユーザー研修」について説明します。
]]>このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスを取り上げ、その目的や内容について紹介しています。
前回のコラムでは、システム導入が決まった！ というところで、最初に着手する「教育計画」の作成に必要な情報として、以下の3つを挙げました。
これら3つの情報を収集しユーザーに必要な教育について検討する「ユーザー分析」のプロセスから、教育計画の作成がスタートします。
今回は、この「ユーザー分析」の次のステップとして何をするのか？ そしてどのように教育計画を作成するのか？ を説明します。
■ユーザーにどう教育すれば効果が出るのか？ を考える
ユーザーの情報を集めることで、まずは以下の情報が導き出せるはずです。
※実際の「ユーザー分析」では、なかなか情報が集まらず（ユーザーに聞いても回答をもらえないケースが多々あります……）完全な情報がそろわないことの方が多いのが現実ですが、まずは「主要なユーザー」についての情報を押さえるようにします。
上記2つの情報を基にすることで、教育の実施期限が分かりますので、あとは「どう教育するか」を考えます。
そこで必要になる情報が、「ユーザーの状況」と「教育する内容（範囲）」です。これらを知るためには、以下のようなことを確認します。
「どう教育するか」とは、どうすれば・どこまで教えれば教育が成り立つのか？ を考えることです。
例えば、ユーザーにマニュアルや研修を「提供すれば」それでOKと考えるのは間違いです。大事なのは「提供したか？」ではなく、「相手が受け取れたか？」です。
そのため、教育するユーザーが受け取れる形式・理解できる内容に「教育すべきこと」を組み立てて提供する必要があります。普段PCを使わないユーザーに教材の電子データだけを配布しても意味がありませんし、業務の前提やルール・制約が分かっていないユーザーにシステム上での業務の考え方や入力項目の意味を教えても理解はできません。
どのユーザーに、どこまでシステムを理解してもらう必要があるか？ を考えて、ユーザーの状況に合わせて教育する内容を組み立てていきましょう。
ユーザー教育も大きくくくれば「コミュニケーション」の一部です。皆さんも普段誰かと情報をやりとりする場合、相手が受け取れる方法・相手が理解できる伝え方を無意識に選択しているはずです。
この「普段は無意識にやっていること」を、ユーザー教育では明確に意識して進めることが重要です。
■教育でやることをスケジュールに落とし込む
ここまでで、教育対象のユーザーの分類と分類ごとの教育実施期限、また必要な教育内容と方法を考えてきました。この先は、教育内容を具体的なタスクに落とし込み、最終的にスケジュールを作成する工程です。
教育提供側からすれば教育は実施すべきタスクの一部なので、期限と作業ボリュームと必要なメンバーを考えて工数を割り出し、WBSに落とし込みます。ここまでくれば、他の作業の設計と大きく変わりはありません。
教育を実施する要員の計画もここまでに明確にしておいた方がいいでしょう。また、教育実施には必ずユーザー側のレビュー・承認が必要になります。特にマニュアル等のドキュメントレビューは想像以上の時間がかかりますので、レビュー工数の確保もこの時点でやっておかないと後で困ることになります。
そもそも教育実施側の要員に余裕がない場合（ほとんどのケースで教育実施要員に余裕はないと思いますが……）は、教育内容や対象のユーザー範囲を少しずつ削っていくしかありません。ただし、削れば削るほど後の工程に良くない影響が出ますので、本当に問題がありそうな場合はバックアッププランも考えておいた方がよいでしょう。
あとは、教育を受ける側の「業務の都合」を確認します。教育を受けるユーザーは当たり前ですが通常業務を抱えているので、業務に支障がないようにやりくりしつつ、スケジュールに落とし込みます。
■この先何をするのか？ のイメージを共有する
さて、やっとスケジュールまで形になってきました。教育計画の作成としては、これで半分終わったというところです。なぜ「半分」なのか？ というと、スケジュールだけでは意味がないからです。
教育計画では、「具体的なスケジュール」と「具体的な作業のアウトプットイメージ」がセットであることが重要です。何をするか？ を具体的に共有できていない場合、いざスケジュールどおりに教育施策を実施しようとしても、
などの意見が直前になって噴出し、再検討⇒スケジュールの引き直し……となるパターンが少なくないからです。
システム導入時の教育は、システムの設計・開発・テストなどの工程に比べてユーザーが参加する頻度が高く、また「やること」が定型化されていないため、「やることのイメージが違う！」が起きやすいのです。
それでは、何をどの程度まで具体的に決めておくべきでしょうか？
教育計画を作成する時点では、ほとんどの場合システムの画面イメージもなく、設計書・仕様書等の資料も作り終わっていません。そんな状況の中で、例えば教育用に作成するマニュアル等のドキュメントの中身を細かく定義するのは極めて困難です。また、たたき台もない中で細かい議論に終始しても結論は出ません。
ここですべき作業は、なるべく大きな論点からスタートし、計画時点で決められる決定事項を積み重ねておくことです。
例えば、教育用に作成するマニュアルであれば、
などが該当します。
これらを検討し、決定した内容を前提とすることで、ある程度「中身」のイメージが限定されてきます。作成プロセスや担当者が明確になることで、作成や運用に関与するメンバーが「対応できる範囲」の「現実的に作成可能なマニュアル」がイメージされるはずです。
この時点で「教育でやること」を目に見える形で100％決める必要はありません。作業イメージと、完成イメージの大まかな「見た目」が共有できていればOKです。あとは、作成・運用プロセスを可視化（資料化）し、計画時点で想定可能な大まかな「完成イメージ」を共有して教育計画書に記載します。
■計画を共有し、教育タスクをスタートしよう！
ここまでの説明で、教育計画の作成では何をすべきか？ が把握できたでしょうか？
それでは最後に、システム導入教育で「やること」や「やり方」が明確になるまでの検討プロセスを含めて、ユーザーを含めた関係するメンバーで内容を共有し教育計画書を作り上げます。
計画を共有、合意する上で重要なことは、ここまでに説明したとおり、
以上の3点です。
以前のコラム（2回目、3回目）で書きましたが、システム導入プロジェクトに参画するユーザー側とベンダ側には、同じ作業を行う場合でも意識の違いがあります。これらの「違い」を認識した上で、教育実施イメージに理解の違いが発生しないように、具体的な計画を共有することが重要です。
さて、前回と今回でシステム導入教育で最初に行う「教育計画」について説明しました。次回は、教育と同じく重要な「ユーザーとのコミュニケーション」をどう行うか？ について説明してきたいと思います。
]]>このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容を紹介しています。
前回までは、システム導入時教育が求められる背景や課題について説明してきました。
システム導入時の教育展開が必要なのはユーザー側、システムベンダ側ともに認識はしているものの、互いの立場・スキル・認識の違いや、組織や業務上の制約によって必要な教育の提供が難しい実情があります。
とはいえ、何もしなければシステム導入の目的は達成できません。導入効果を表すには、状況に応じた適切な施策の実施が必要になります。
今回からは、これらの具体的な「教育施策」について説明していこうと思います。
■最初に陥る失敗
いきなり「失敗」の話ですみません。しかし、さてシステム開発のプロジェクトが動き出すぞ……というところで、最初の落とし穴があります。
最初に何をするか？ という段階でいきなり失敗し、以後コントロール不能に陥るパターンです。よくある（よく見てきた）パターンは以下。
と、こんなところでしょうか。
1と2はかなりの頻度で発生します。しかし、これを始めてしまってから後になって方針転換するのは至難の業です。
なぜ発生頻度が高いのか？ というと、
目に見える分かりやすいもの（マニュアル・ツール）の選定や作成を始めると、何となく「進んでいる！ 」という錯覚に陥ってしまう
からです。
ただ、これはシステム開発でいえば、
要件定義もやっていないのに、個別機能の開発を「これでいいよね？ 」くらいの感覚で進めてしまう
ほどの危険な行為です。成功するはずがありません。
3の「スケジュールだけ立ててあとは開発側に丸投げ」もよく目にするパターンですが、丸投げされる側にフットワークの軽い人材がそろっていれば現場力でなんとかなる可能性があるだけ、他のパターンよりマシです。
マシといっても、丸投げされる開発側が個別チームごとに勝手に動くので、統一感のある教育施策は実行できず、結果としてユーザー側の対応負荷が増加します。
また、このパターンで何とかできるのも開発側に教育を検討・実施する余裕があるケースのみで、多くの場合いざ教育が必要というフェイズに入る直前になって初めて「マズイ」ということが分かり、急きょ大がかりなテコ入れをして力技で乗り切ろうとします。教育実施直前に追加工数が大幅に膨らむパターンです。
4の「取りあえず放置」の場合は、もうどうしようもありません。
ただ、この場合はユーザー教育以外の重要なタスクも失敗している可能性が高いので、教育の失敗は目立たずに済みます。
プロジェクトの注目が他の課題に向いている隙に巻き返しましょう。
■失敗しないために、システム導入時教育で最初にやること
それでは、上記のような「失敗」を避けるために「最初」に何をすべきでしょうか？ 考え方はシステム開発のプロセスと同じです。（1）要件定義をして、（2）設計して、（3）開発する、そのための段取りを立てる必要があります。
教育の場合は、（1）要件定義で必要情報の収集を行い、（2）その結果を基に教育施策を設計します。そして、システムそのものの設計・開発フェイズと同期をとりつつ、（3）教育に必要なツール・ドキュメント・環境を整備し、各施策を実施していきます。
これらの教育でやるべきことを「教育計画」としてまとめることが、最初に行うべきアクションです。
ここで作成する「教育計画」が、「マニュアルを作成する」「トレーニングを実施する」のようなザックリした方針やToDoのみを書いただけのものでは意味がありません。必要なのは、誰を対象としたどんなマニュアルを、いつ・誰が・何をインプットにして、どのようなプロセスを経て作成するのか？ また個々の教育施策によっていつまでに何を達成するのか、など前提となる要件も含めて具体的な作業レベルまで計画することです。
それでは、意味のある教育計画を作成するためにはまず何が必要でしょうか？
■教育計画作成に必要不可欠な情報
システムについてどう教育するか？ を検討するには、事前にユーザーやシステム化する業務について細かい情報を収集しておく必要があります。この最初に行う情報収集と検討のプロセスを私たちは「ユーザー分析」と呼んでいます。
ユーザー分析では、まずプロジェクト全体としての開発・導入期間、ユーザーの対象範囲、システム化する業務の範囲・内容を明確にします。これらはシステム開発プロジェクトを開始する時点で大体決まっているので、それほど苦労せずに情報収集が可能です。
この後が、重要です。
プロジェクト全体の情報から一歩踏み込み、導入のための教育という観点で、教育期間、教育対象のユーザー範囲、ユーザーの特徴を明確にしていきます。
【教育期間】
ユーザー教育は、ユーザーがシステムを使い始める前までに実施する必要があります。システムを使い始める前まで、といっても前日や一週間前まで……では遅すぎます。教育を実施した上でユーザーがシステム化される業務を理解し、導入前と近いレベルまで習熟するには時間がかかるからです。
また、教育を受けた上で初めてユーザーは「自分たちの仕事のやり方が変わる」ということを他人ごとではなく自分にも影響があると認識し、必要であれば質問をし、回答を得ることで理解を深めます。これらユーザーが理解・習熟する時間も含めて、教育提供の時期を検討し、それまでに提供する側の準備ができるように作業期間を逆算します。
さらに教育期間は、ユーザーのカテゴリに合わせて複数検討する必要があります。ユーザーのカテゴリは、システムの利用頻度や利用形態（インプットをするのか？ 参照するのみか？ ）、またユーザーテストに参加するようないわゆるパワーユーザーか否か、などで区別できます。
これらのユーザーカテゴリごとに、教育が必要な期限が異なります。教育計画には、各ユーザーの役割に合わせた教育期間・施策を明記する必要があります。
【教育対象のユーザー範囲】
システム導入をするユーザー組織の中で、どの部署のどの業務の担当者が教育対象となるのかを明確にします。システム導入プロジェクトが開始される時点でおおまかなシステム対象ユーザーは定義されているはずですが、「教育」を検討する上ではさらに詳細なユーザー分析が必要になります。
導入するシステムが提供する機能や業務範囲ごとに、どこにいる・誰が・いつシステムを利用するのかを明確にし、ユーザー範囲を設定し、必要な教育レベルを検討します。
ここで特に重要になるのは、上記「教育期間」でも触れたユーザーカテゴリごとの対応、ユーザーの権限ごとに役割が異なるケース（同一機能でも使い方が異なる場合）への対応、また遠隔地や異なる組織（関係会社など）のユーザーを含めた教育実施のプラン作りです。
このように、ユーザー範囲を明確化するには、複数の側面からユーザー分析を行う必要があります。
【ユーザーの特徴】
教育を成功させるためには、システムを導入するユーザー組織がどんな集団なのかをあらかじめ知っておく必要があります。システム開発・導入などに対して「作ったモノを売るビジネス」のような印象を持っている人もいると思いますが、実態はシステムを導入する組織に対してシステム開発・導入の「サービス」 提供を行う対人ビジネスです。
であれば、サービス提供をする相手がどんな人達なのか？ を理解せずにプロジェクトを進めても成功するはずがありません。ユーザー教育を計画する上では、まず最低限の情報として以下を収集します。
これらの情報を収集し、教育対象となるユーザーがどんな集団なのかを検討します。
ここまでが、ユーザー分析の最初のステップ、情報収集のプロセスです。そして、この後収集した情報をもとに教育対象の「ユーザー像」を定義し、ユーザーに最適な教育施策について検討を進めます。
ここから先のプロセスについては、また次回のコラムで紹介したいと思います。
]]>前回はシステム導入時に考慮すべき「導入目的の達成」に向けた課題と対応について説明しました。
今回は、システム導入時に必要な「教育」の課題について説明します。
システム導入にはユーザー教育が必須ですが、教育成果を出すにはシステムベンダ側・ユーザー側双方が持つ課題に対応していくことが必要です。
まずはシステムベンダ側の教育の課題から話を進めます。
■「ユーザー教育」はキャリアにならない
数年前、とあるEPR導入プロジェクトにユーザー教育担当として参画していたときの話です。
ユーザー教育担当は、私の他にシステムベンダ側から参画していたメンバー（仮にK氏とします）もいました。
K氏は与えられたタスクはきちんとこなすものの、あまりやる気が感じられません。気になって「今の担当タスクをどう考えてますか？ 」と質問したところ、K氏はため息まじりに答えました。
「ユーザー教育の担当になっているが、自分は本来SCMを専門としている部署にいる」とのこと。
自分の専門性とは違う仕事をアサインされてしまうのも、人が足りないプロジェクトなどであればよくある話です。長期アサインでもなさそうなので、そこまで気にしなくても……と思っていたら、話はそれだけではなく。
「今のタスクはSCMと関係ないので、どれだけがんばっても社内では評価されない。そもそも、ユーザー教育というタスクは社内でエンジニアのタスクとして定義されていない。なので、評価する基準もない」
さらにいえば、K氏の会社ではユーザー教育のやり方、何をすればよいのかもまったく定義されておらず、身近に相談する相手もいない状況とのこと。
「これまでのシステム導入ではどうやっていたんだろう……？」と思いましたが、過去の経験を頼りに「やったことがある人がやる。やったことがある人に聞く」で済ませていたのでしょう。
エンジニアにとって、専門的に身に付けるべきスキルはシステム開発に関わる技術です。ユーザー教育が同列に扱われることは、確かにないかもしれません。
技術以外にもシステム要件を詰めるなどの部分ではユーザーとのコミュニケーション能力は必要ですが、それも「教育」と同じではありません。
ちなみに、K氏はプロジェクトが佳境を迎える前に別の開発プロジェクトのアサインが決まったとのことで、晴れやかに去っていきました。
■「マニュアル」ってどう書けばいいの？
今度は別のシステムベンダから相談がありました。内容は、端的に言えば「マニュアルが書けない」。
今動いているシステム開発プロジェクトで、システムベンダ側のタスクに「システム操作マニュアルの作成」が含まれているのだが、どう書けばいいのか分からない。自社パッケージを導入するので標準マニュアルはあるが、自分達で作っておいてなんだがマニュアルとしてはまったく使いものにならない。
どんなマニュアルを書けばユーザーに満足してもらえるのか、よく分からない。そもそも、ウチのメンバーは文章を書くのが苦手だ。
ということで、「マニュアル作成だけ御社でやってくれないか？ 」という話でした。
この話の顛末は、また別の機会にコラムとしてまとめたいと思っていますが、早期にマニュアル開発～展開を行ったことで、教育は成功しました。
システムベンダは「初めてマニュアルがお客様に評価された」と喜んではいたものの、以後は「自分たちでマニュアル開発を行う」という流れにはならず（最初はそんな話もあったのですが）、「今後もよろしくお願いします」という結果に。
■エンジニアとユーザーは別の生き物
上記の事例を見ると、「システムベンダにはユーザー向けの教育ができないのか？」と思ってしまいますが、私はそもそもシステムベンダに所属するエンジニアの考える「教育」と、ユーザーがイメージする「教育」が異なると考えています。
どう違うのか、というと以下のようなイメージです。
【エンジニアの考える教育】
【ユーザーの求める教育】
かなり誇張して書いてますが、そこそこ思い当たるところはあるのではないでしょうか。
この感覚の大いなる違いは、「システム開発を仕事としている」エンジニアと、「システムは業務で仕方なく使う」ユーザーとの対システムの意識の違いから来ているのだろうと考えています。
教育の前提として、エンジニアにとってはあくまで「システムが先」で、ユーザーは「業務が先」という話です。
互いを少しでも理解して歩み寄れば上手くいくのでは……と思いますが、そんな余裕がないのも実情です。
■ユーザー側に教育を実行する余力がない
今後はユーザー側の課題に話を移します。
「システムベンダがユーザーの求めている教育を提供できないなら、ユーザー側でやればいいのでは？」という発想にもなりますが、システム開発案件のRFPでは、ベンダ側に教育の実施を求めていることが多いのが実情です。
「なぜユーザー側が自分たちの業務のシステム開発であるにもかかわらず、ベンダに教育を投げたいのか？」の答えは、ユーザー側にも教育をする人的余裕とノウハウがないということです。
まず、プロジェクトメンバーとしてアサインされているユーザー企業の社員は、本業と兼務でプロジェクトの作業にあたっていることが多く、要件定義や設計など必須のタスクにかける時間はあっても教育に時間を割くほどの余裕がない。
さらに問題なのは、多くのユーザー企業は「システム導入」という以前に、「プロジェクトワーク」を経験したことがない社員が多いということ。
プロジェクトの体制を組む、計画を立てる、詳細なWBSを引く、チームごとにタスクが割り当てられる、課題管理をする……といっても、具体的に何をすればいいのか分からない。
もはや教育どころの話ではありません。
これも実際に聞いたことがある話ですが、ユーザー側のプロジェクトメンバーがやけに少ないケースで理由を確認すると「システム導入プロジェクトに参画した場合の評価基準が社内にないから」という回答が返ってきたことがあります。これは、システム導入云々というより、担当業務以外のプロジェクトワークの発生を会社側が想定していないということでしょう。
これでは、システム導入時の教育を自分たちでやろう、という発想にならないのも仕方がないかもしれません。
■教育の専門チームの設置が必要
さて、ではどうすればいいのか？ ですが、やはり地道に対処する他、手はありません。
システムの教育、かつ業務も考慮すべき話なので、ベンダ側とユーザー側で協力して対処し、教育専任のチームを立ち上げるのが順当な対策だと思います。
教育やユーザー展開は、プロジェクト全体の動きを正確に把握した上で同期をとって進める必要があります。そのため、各チームに教育担当を兼任するメンバーがいる……などの体制では、スムーズに教育を立ち上げられません。
そして、前回のコラムでも書きましたが、システム導入の目的は「導入目的を達成すること」なので、目的達成を目指した「教育計画」をプロジェクト全体の計画と同期する形で策定するところからスタートします。
さて、続きは次回のコラムで説明します。
次回からは、具体的な「システム導入教育」の施策を順を追って紹介していきたいと思います。
前回、第1回目のコラムで「システム展開支援」という仕事について、簡単にご紹介しました。
「システム展開支援」のサービスを簡単にまとめると、
この4つを行います。
4つすべてに共通することは、システム導入のサポートではあるものの、「対システム」ではなく「対ユーザー」のサービスである、ということです。
今回のコラムでは、対ユーザーのサービスとして「システム展開支援」が求められる理由・背景を書いていきたいと思います。
■開発が無事に終わればシステム導入は成功？
システム導入のプロジェクトが佳境を迎え、多少の問題はあるものの稼働は無事に迎えられそう……となった場合、そのシステム導入は「成功している」ように感じると思います。
開発側のシステムベンダから見れば、成功で間違いないでしょう。稼働後の保守・サポートは継続するとしても、「開発」が無事に終わっていれば「成功」でいいはずです。
それでは、ユーザー側から見たときはどうでしょうか？
システムの導入は、ユーザーにとって「目的」ではなく「過程」です。
「このシステムを導入することがプロジェクトの目的だ」というケースは少ないでしょう。
なぜなら、ユーザー側にとっての「システム導入」とは、「業務改善」「標準化」「競争力強化」などを目的としたプロジェクトの一部でしかないからです。
「プロジェクトの成功」は、システム導入の「効果が発揮され、その先の目的が果たされたかどうか」で判断されます。導入したシステムがとりあえず無事に稼働しているから……だけでは、成功か失敗かは分かりません（無事に開発が終わってない場合は失敗とすぐ分かりますが……）。
システム導入の効果を発揮するには、
が必要です。
「開発」を主な作業とするシステムベンダが、開発に加えて上記3点をサポートするのは難しく（そもそもスコープに入れていないケースが多い）、結果としてユーザー側が対応しなければならなくなります。
しかし、この対応は簡単ではありません。
■エンドユーザーは「システムの変更」を喜ばない
現行システムがどうしようもなく使いにくい……などの理由がない限り、実際にシステムを使うエンドユーザーは「システムの変更」を歓迎しません。
なぜかと言えば、それは単純な理屈で「自分の仕事のやり方が変わる」からです。これは「一度覚えたことを、また覚え直さなければならない」という意識があるからです。
急激な変化にさらされれば、誰でも多少は「なぜ？ 」「必要なのか？ 」と感じます。その結果出てくる言葉は……システム導入にかかわる仕事をした誰もが一度は聞くセリフだと思いますが、「前のほうが良かった」「以前と違う」「分かりづらい」などなど……。
慣れているやり方から、知らないやり方に変われば誰でも最初は「分かりづらい」「前のほうが分かりやすい」と感じるでしょう。当たり前の反応です。
そして、この反応は時間が経てば新しいやり方に慣れるために沈静化していきます。
と、これだけで済めば良いのですが、実際はもう少し複雑です。
■目的は業務の標準化
最近の大規模システム導入では「自分の仕事のやり方が変わる」に留まらない変化が出てきています。
システム導入の目的が過去と現在で大きく変わってきているからです。
どういうことかと言うと、分かりやすい例として、
・現行システム：
10～20年前に作られたスクラッチ開発のシステム
・新システム ：
業務標準化、情報のリアルタイム化を目指しパッケージ導入
システムを実際に利用するエンドユーザーにとって、システム導入のイメージはいまだに「10～20年前に作られたスクラッチ開発のシステム」がほとんどで、新しいシステムが導入されれば、
・現場の負担が減る
・作業効率が上がる
・今より使いやすくなる
と、漠然と「新システムを入れれば今より良くなるはずだ」と思い込みがちです。
（実際にお客様からこんな言葉をよく聞きます）（特に、30代後半以上の方に多いです）
確かに、過去に行われた「業務をシステム化する」開発では、そのような面もあったかもしれません。
しかし、現在多く行われるシステム導入は、多くの場合「業務をシステム化する」ことを目的としていません。
現在のシステム導入は「業務の標準化」「情報のリアルタイム化」「企業の競争力強化」を目的としていることがほとんどです。
その結果、何が起きるかといえば、
特に、素早い経営判断が求められる現在では、判断材料とする分析レポートなどの出力のために、常に最新の情報が正しく入力されている必要があります。
結果として、システムを使うエンドユーザーの負荷は上がります。
「今より良くなるはずだ」と思っていたのに、実際は「慣れていないので分からない」上に「業務負荷が上がった」という結果になるわけです。
では、どうすべきでしょうか？
■導入の目的を伝えて期待値を下げる
画期的な解決方法は、残念ながらありません。
現場のエンドユーザーの反発は、どんな対策をしても起きるでしょう。起きるのであれば、その反発を最小限に抑えるための努力をするしかありません。
何もしなければ、エンドユーザーの「期待値（事前期待）」はコントロールできません。エンドユーザーの期待値は「業務がラクになるかもしれない」「システム化できていない部分が対応されるかも」など、どこまでも膨れ上がっていく可能性があります。
また、同時にシステム導入に不安感を持つエンドユーザーは「知らない」故に理由のない不安を募らせていきます。
このような、見えない「期待」や「不安」が解消されないまま導入が進むと、システムの「教育効果」や「正しい運用」は期待できません。必要なのは、正しく「認知」してもらい、自分の業務とひもづけて「意識」し、いずれは「興味」を持ってもらうことです。
まずは、エンドユーザーに以下の内容を伝えましょう。
伝えることが大事です。すぐに興味を持ってもらう必要はありません。伝えることで、正しく状況を認識してもらい、そしていずれは「やらなければいけない」という自覚を持ってもらう。そこから、システムの現場展開がスタートします。
■まとめ
今回は、「システム展開支援」が求められる理由・背景をテーマに、ユーザー側で対応する課題・アクションとなる以下について説明しました。
これら、ユーザーだけでは対応が難しいタスクを支援するのが、システム展開支援のサービスです。
次回は、「システム展開支援」が求められる理由・背景の続編として、プロジェクトに参加するシステムベンダ側、またプロジェクトそのものから見たシステム展開の課題について説明したいと思います。
このコラムでは、私の担当するサービス「システム展開支援」がどんなものか？？ を紹介し、またそれに関連するテーマで何か書ければ～と思っています。
■自己紹介
まずは、簡単な自己紹介を。
最初に入社した会社（社員10名程度のパッケージソフト開発会社）で約2年システム開発周りの業務を経験し、その後の約2年でテクニカルライターとしてパッケージソフトのマニュアル開発を経験。
2007年から現在所属する株式会社エル・ティー・エスで「システム導入支援（兼ビジネスライティング）」を主要な領域とするコンサルタントとして多くのプロジェクトに関与してきました。
導入に関わったシステムの規模は大小さまざまですが、「システム導入時のユーザー教育」をメインタスクとして仕事をしています。
■「システム展開支援」について
では、ここからはこのコラムで紹介するサービス「システム展開支援」について。
「システム展開支援」とは、エンドユーザー企業にシステムを導入する際に、導入するシステムがユーザーの現場に展開され定着するまでをサポートするサービスです。
せっかく作ったシステムでも、実際に使われなくては期待した導入効果は発揮されません。ですので、私達はシステムをユーザーに「使ってもらう」ための支援をしています。
何をするのか？？ と言うと、それほど複雑でも画期的なサービスでもありません。
・システム導入の目的をユーザーに知らせる
・システム導入のための「ユーザー教育」を行う仕組みを構築する
・システム導入のための「ユーザー教育」を実施する
・ユーザーがシステムを使えるようになるまでサポートする
これら、システム導入の現場であれば程度は違えど「一般的に行われている」作業を「専門的に行い成果を出す」のが、私の担当する「システム展開支援」サービスです。
■システム導入時のユーザー教育の現状
多くのプロジェクトで、ユーザー展開・教育のプロセスは「オマケ」的な扱いになっており、例えばプロジェクトの予算が足りなくなると真っ先に削減される対象になったりもします。
ですが、ユーザー展開・教育は本来「システム導入を成功させる」ために必須のプロセスです。これらのプロセスを怠るとどうなるか……。
その結果起きる「失敗パターン」は、現実に多く発生しています。
・「新システム」がユーザーに理解されずに失敗したプロジェクト
・とりあえず開発は終わってリリースしたが、誰も使えない新システム
・導入はできて稼働しているが、当初の導入効果を発揮できずにいるシステム
上記のような失敗パターン、身に覚えはないでしょうか？
実際に経験したことがなかったとしても、失敗プロジェクトのケースとして話に上がったことはないでしょうか？
こんな失敗を「起こさない」「繰り返さない」ために、プロジェクト現場で専門的なコミュニケーション・教育ノウハウを活用したシステムのユーザー展開を行っています。
次回以降、「システム展開支援」サービスの目的・背景から、実際に行う具体的な施策について、実際の事例を交えて説明していきたいと思います。