第11回　システム導入教育(8)　システム操作マニュアルを考える

» 2013/03/18

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

　前回までは「システム操作研修」について書きましたが、今回からは「システム操作マニュアル」について書いてみたいと思います。

■マニュアル作成、好きですか？

　これまでエンジニアの方で「マニュアル書くの好きなんだよね！」という人には、残念ながら会ったことがありません。

　聞いたことがあるのは……「マニュアル書くのは苦手」「マニュアル書くのは嫌い」「とにかくどう書けばいいか分からん」「そもそもお客さんにマニュアルの品質なんて期待されてないよ」などなど、ネガティブな意見ばかり。そもそも、マニュアル以外にもさまざまなドキュメントを作成している中で、さらに面倒な「マニュアル」などは書きたくない、というのが実情でしょうか。

　しかし、システム操作研修と同じく、多くの場合操作マニュアルもユーザーから求められる成果物の一部になっています。そもそも必要か？はこの後に書きますが、とにかく書かないとダメな場合がほとんどです。

■そもそもマニュアル必要ですか？

　どうしてマニュアルが必要なのか？理由はイロイロとあるでしょう。ミスを減らす、業務の属人化防止、そもそも操作方法が書かれていないとシステムをどう使うのか分からない、などなど。

　では、質問を変えて「どうしてもマニュアルが必要なのか？」だと、どうでしょうか？

　マニュアルがあればミスが減るか？というと……あまり変わらない気がします。画面インターフェイスを工夫して設計した方がミスは減らせそうです。属人化を防ぐ、という部分では少しは役に立ちそうです。ただし、どこまでできるかはマニュアルの品質に大きく左右されますし、またシステム操作マニュアルだけで属人化から脱却することは難しそうです。

　操作方法が書いていないとシステムの使い方が分からない、は正論のような気もしますが、操作方法を細かく書かないと操作できないシステム、使い方が分からないインターフェイス、というのは別の課題がありそうな気がします。そもそも、業務をしっかりと理解した上で、業務上の必要な情報をいつどこにインプットするか、どうアウトプットするか、のルールさえ分かっていれば細かい操作方法を書いたマニュアルがなくても操作はできるでしょう。

■いつ、どんな理由でマニュアルを見ますか？

　ゲームの操作方法や、テレビ番組の録画予約方法は、慣れている人ならマニュアルがなくても操作可能です。慣れていなくても、自分が何をしたいのか？を分かっていて、それらしいボタンを見付けられれば操作できそうです。

（自分が何をしたいのか？が分かっている、というのは、例えば「テレビ番組の録画予約をする」という漠然とした動作だけではなく、「録画予約」をするという目的のために、1.「メニュー」や「番組表」を開く 2.番組を指定する 3.予約を設定する、くらいの段取りまで頭の中に組み上げられる、ということです。「分からない」というセリフが多い人は、目的だけ見てしまい、どう達成するかをまったく考えていないことが多いですよね）

　どうしても分からない、もしくは知らない言葉や経験したことがない状況が発生した場合だけマニュアルを見ればいいのです。

　マニュアルの利用シーンの多くは「分からなくなった場合に見る」です。常に机の上に開いて置いておく必要はないわけです。が、それが「業務システムの操作マニュアル」になると、お客さんは急にイロイロな理由を付けて「アレが書いていない」「これだけでは分からない」などと言い始めます。

　そういった意見が出るのは、おそらく自分たちの業務をよく理解していなかったり、業務が整理できていなかったりするのが原因です。もしくは、システムのメニューや画面設計がダメすぎて、画面を見ても何をすべきかまったく分からない、が原因かもしれません。

■分厚いマニュアルと薄いマニュアル、どっちがいいですか？

　業務（理解・整理）がダメ、システムがダメ、な状況で「ダメなところはマニュアルでなんとかカバーしよう！」という方向に動くことがあります。よくあります。結果どうなるか？というと、印刷すると電話帳のような厚さになるマニュアルができます。アレもコレも書く、という方針で作るので、当然ボリュームが増えて作成工数も増えます。

　しかし、よく考えてみるとマニュアルの利用シーンの多くは「分からなくなった場合に見る」です。読み手は自分が知りたいごく一部の情報だけを見たいのですが、手元にあるのは電話帳のようなボリュームのマニュアルなので、知りたい情報を探すだけで一苦労です。そして当然ですが、メンテナンス性も最悪なので一度作ったら誰も手を付けずに放置されます。

　だから私は、マニュアル作成をする際はいつも「できる限りボリュームを減らしましょう」と言っています。わざわざお金をかけて苦労して「使えないモノ」を作っても、誰も幸せにならないからです。

■では、何をどこまで書けばいいのか？

　「システム操作マニュアル」を作成します、と説明してマニュアルを作っても、ユーザーの一部から「業務のことが書いていないから、これでは分からない」と言われることがあります。「業務のことは業務マニュアルを作成して、そちらに書かれてはどうでしょうか」と言うと、一度は引き下がるのですが、しばらくするとまた同じことを言われます。仕方ないので「いや、システム操作マニュアルには操作方法を書く、ということで合意いただいているはずですが」と言うと「そんな話は知らない。そもそも操作方法だけ書かれても分からないじゃないか」と、ちゃぶ台返しが待っています。

　さて、これはどこに問題があるでしょうか？

　ちゃぶ台返しをしてしまうことが問題（これはユーザー側がプロジェクトワークの方法とルールを理解していない、という問題）なのは当然ですが、根本の問題は「システムの操作方法だけ書く」＝「システムの操作方法しか書かない」という方針です。ユーザーさんの言っていることは100％間違いではなく、操作方法だけ書かれてもそこに業務の要素がない限り読み手は理解できません。読み手は業務のことは知っていますがシステムのことを知らないので、操作方法だけではひも付けができないのです。

　（ただし、システム開発全体のコストを下げる目的で「納品するマニュアルは最低限の操作説明のみ記載 ※だから価格を下げろ」の流れになることがあり、結果として上記のような方針にならざるを得ないケースがあります。残念ですが……。）

　結果として出てくる最適解は「業務の流れ＋操作説明」の構成で、かつ業務の細かい説明までは書かない（書けば分厚いダメなマニュアルになる）になるのですが、常にどんなプロジェクトでもこの方法でOK！というやり方は存在しないので、都度システム導入先組織の文化や気質に合わせた調整が必要になります。ユーザーのことを深く知り、理解した上で施策を練らなければ教育の成功もシステムの定着もできない、ということです。

■まとめ

　システム操作マニュアルについて意識すべきポイントは、今回のコラムでも書きましたが以下の4つです。