情シスとユーザマニュアル：ワークフローシステムを導入したとき

前はよく書いてました

　新しいシステムやサービス導入のとき、ユーザマニュアルを書く機会ってありませんか？

　外注することもありますが、その場合も開発ベンダの方が作った資料って、詳細設計書みたいになっていたり、肝心なことが書いていなかったり、まあ、本職ではないですからね。

ワークフローシステムを導入した時

　弊社のワークフローシステムを10年ほど前に導入したとき、マニュアル作成を担当したときに気を付けたポイントを書いてみます。

簡易版と詳細版を分ける

　弊社の場合、ワークフローで圧倒的に使うのは、会計清算、出張精算、あとは稟議です。とくに会計と出張精算は、だれでも使うので、これと、基本的なログイン周りを実際のフローに沿って解説した6Pの簡易版を作りました。
　利用のフローに沿ってスクリーンショットを入れて、入力箇所にはポインターと解説を置いて、といった形で作ると、6Pでもすぐですが、これがとても好評でした。

　詳細版は、特に稟議まわりでしか使わないような、ひっかかりがちなポイントを記載して20Pくらいで作りました。
　こちらはインデックス性を重視して「〇〇のときは」といった章立てをたくさん作って、QA中心の構成にしました。

実際に使ってみて書く、そして使ってもらう

　ほかでもやっていて思うのですが、開発者は「こんなの説明しなくてもわかるだろう」と思っていることが多いです。しかしユーザは思わぬところでひっかかりますので、利用ユーザの多いマニュアルは、実際に使って操作してもらう、というプロセスを経ると安心だと思います。

　今回の導入では、ライトユーザは自分でよいとして、管理監督職クラスの人に触ってもらう必要がありました。そこは、情シスで一番稟議を大量に書いている開発チームの主任さんに評価をお願いして、詰まったポイントをケーススタディで加えました。さらに、社内のサポートデスク経由で入ってくる問い合わせについても、よくあるものは、ケーススタディとして加えました。

マニュアル作成で陥りがちなポイント

今はどちらかというと人の作った文書をチェックする側ですが、よく注意するポイントを書いておきます。

・長い…盛り込みたいことやアピールポイントを全部書いちゃう。アピールポイントは、リリース告知に混ぜておけばいいんです。
・簡易版と詳細版が同じになる…簡易版って好評だから「こちらに載せろ」という問い合わせが来がち。簡易版はストイックに。
・流れとQAを混ぜない…問い合わせ受けている立場の人は、QAを重視しますが、分けた方がよいと思います。

10年やってみて

　作成後情シスを出ていた時代がありましたが、今になっても当時の完成版よりほぼバージョンアップがなく、「これがないと困る」「これで全部できる」といった評価をいただいていますので、うまくいったパターンだと思います。

　しかし、これに限らず、最終的には「読み手を考える」といった、根本にある考え方を理解してもらいたいのですが、HOWTO的に「じゃあこれと同じ構成でやればいいや」的な考え方に頼りがちなのも情シス。。。難しいものです。