第15回 システム導入教育(11) システム操作マニュアルの設計（前編）
こんにちは、エル・ティー・エスの忰田です。このコラムでは、システム導入時のユーザー教育を中心とした「システム展開支援」サービスについて、その目的や内容について紹介しています。
今回は「システム操作マニュアル」を書き始める前の「設計」工程について書きたいと思います。マニュアルの設計において、最初に考えるべき部分は「目次」です。まずは目次構成をどうするのか？ から考えていきます。
■マニュアル全体の目次構成は何を基準にして作る？
マニュアルは小説・ビジネス書やその他市販されているような「読み物」ではないので「最初のページから最後まで読み進める」という読み方はしません。11回目のコラムにも書きましたが、マニュアルの代表的な利用シーンは「分からなくなったときに見る」です。そのため、自分が知りたい情報がマニュアルのどこに書いてあるのか？ を、どれだけ早く見つけられるか、が問題になります。この「どこに何が書いてあるか？」を分かりやすくするための見出しの要素がマニュアルの「目次」です。
それでは、目次はどのように作ればいいのでしょうか。
- 誰の視点に合わせればいいのか？
「マニュアルの目次を作っているのですが、どんな目次にすれば分かりやすいと思いますか？」とユーザー側の担当者に聞けば、何らかの答えが返ってくるでしょう。
ただし、誰に聞いたとしても、その人の「主観」が入ります。購買業務の一部分を担当しているユーザーの意見を聞けば、購買業務の一部分が中心となった目次になります。別の業務の担当者でも同じです。ユーザーは「自分の担当業務」から業務全体を見通し、自分の担当業務の観点から他の関連する部署とやりとりをして仕事を進めています。それ自体は間違いではありません。
では、システムを開発しているエンジニアに聞くと、どうなるのでしょうか。おそらく、システムの「機能」や「データの流れ」をベースにした目次になるでしょう。もしくは、そのエンジニアの関与している業務・機能だけ重点的に説明する構成になるかもしれません。
プロジェクトに参画しているエンジニアは、それぞれ決められた役割があるので、その役割に対して責任を負っています。その責任をまっとうしようとすると「自分の担当する機能については詳しく説明しなければいけない」という感覚になりがちです。しかし、一般のユーザーが見るマニュアルには、そこまでの細かい説明は求められていないため、下手に細かい説明を盛り込もうとすると、全体のバランスが悪くなります。
- 必要な2つの視点
特定の業務のことを中心に書いても、システムの機能のことを詳しく書いても、目次としてはうまくまとまりそうにありません。特定のではどうするか？ というと視点に偏り過ぎているからです。
必要なのは業務とシステムを包括した「全体を捉える視点」です。そしてもう1つ必要な視点は「客観的な視点」です。誰の視点に合わせるか？ に話を戻すと、この2つの視点を持った人に聞けば、全体像が見えてきます。
が、そんな人はほとんどの組織で存在しません。ではどうするのか？ というと、「全体を捉える」ことと「客観性」を担保すべく、業務やシステム化する範囲を整理して、一定のルールでドキュメント化します。このプロセスがいわゆる「業務シナリオ」や「業務フロー」の作成です（作業の名称は、会社はプロジェクトごとに異なると思いますが、ここでは業務フローとします）。
- 目次構成の土台になるもの
業務システムを導入する場合は、ほとんどの場合その業務の業務フロー（もしくはそれに近いもの）を作成しますが、この業務フローが「業務の全体」を見通せる視点を備えていれば、目次構成の基にすることができます。
もう1つ必要な「客観的な視点」という部分については「第三者の視点」が入ることが望ましいです。
以前にユーザー側で業務フローを全て作成したプロジェクトを経験しましたが、各業務の担当ユーザーが明確な作成ルールもない状態で「自分の業務」を中心にフローを書いたために「フロー同士がつながっていない業務フローに（形は）似た別の何か」が出来上がっていました。業務を客観的に把握し、それを正しくフローに落とし込むのは未経験者が何となくやってできる作業ではない、ということがハッキリした経験でした。業務を理解して運用するスキルと、業務を可視化するスキルはまったく別物だということです。
ということで、マニュアル全体の目次構成を作るには、個々の業務とシステムを含めた業務全体像の可視化ができる人間、またそのためのプロセスが必要です。それらの作業工程の成果物を、まずは目次構成の土台として考えることができそうです。
さて、今回はこのくらいにして、次回はマニュアル設計のより細かい部分を考えたいと思います。