はじめに
業務システム開発の仕事をしていると、ユーザーマニュアル、オペレーションマニュアル、などの名前で
何らかのエンドユーザー向けのマニュアル作成を行うことがあります。
いくつかのシステムを開発したり現行調査をしたりする中で、いいなと思う内容を書き残します。
提供手段の候補
- システム内のヘルプ機能にどういう場合にどの機能を使うべきかとFAQを、各機能に対象機能のチュートリアルと詳細説明をそれぞれ組み込む
- システム内のヘルプ機能にどういう場合にどの機能を使うべきかとFAQを、各機能に対象機能の詳細説明をそれぞれ組み込む
- システム内のヘルプ機能にすべての情報を組み込む
- WordやPowerPointで作成されたPDFファイルをシステムからダウンロード出来るようにする
- WorkやPowerPointで作成されたPDFファイルを個別に配布する
使い手側としては上記の順位で使いやすいでしょう。
現行システム調査をする立場としては、1.～3.のように完全にシステム内に閉じていると、
調査対象システムの利用権限をもらえない場合に少し困ることもありますが。
構成要素の候補
すでに前節でも少し触れていますが、おおよそ以下のような内容が候補となります。
- システムの概要
- システムの利用開始手順
- システムの起動、終了方法
- システム全体の画面レイアウト
- 機能一覧とその概要
- 業務フロー
- 各業務作業で利用する機能と操作概要
- エラー発生時の対応方法
- 各機能の詳細な操作方法と計算処理の仕様
基本的には上記の順序で記載すればよく、最後の項目は参考情報扱いで省略可能です。
基本的には見たら分かる操作を目指して設計しますが、改修を重ねる中で、機能追加時に大規模な
レイアウト変更がコスト的に困難で複雑な操作をユーザーに要求せざるを得ない場合もあるので、
最後の項目も設けておくとユーザビリティを犠牲にすることのデメリットが少しは緩和されます。
また、システムが業務的に想定外の結果を返した際にユーザーでの調査を可能とするために、
システムによってブラックボックス化した計算処理の仕様を記述することも役立ちます。
特にこの計算処理の仕様については業務システム特有かもしれませんが、ユーザー提供することは
ユーザーとシステム開発担当の両者にメリットがあります。
各項目の記載内容
システムの概要
誰が何をするためのシステムか、既存システムとの関係性や役割の違いなどを記載します。
ユーザーが一人称で自分の業務を想像したときに、このシステムを使うべき対象者かどうかは
この章だけですぐに理解できる状態にすることが望ましいです。
システムの利用開始手順
実際に利用したいとなった場合に、具体的に何をすればいいかを記載します。
業務システムの場合、システム所管部署の担当者のメールアドレスとユーザー登録メールの
テンプレートを記載するような場合もあるでしょう。
一般的なソフトウェアのマニュアルでいうとユーザー登録方法やインストール方法にあたる、
システム起動までのすべての作業が書かれてある必要があります。
システム開発の役割分担によっては、この章は顧客側に作成をお願いする可能性もありますが、
他の章と情報が分断されることは避けましょう。
システムの起動、終了方法
利用のための準備が整った状態で、システムを起動するための手順と、システムの利用を
終了するための手順を記載します。
起動方法と終了方法はまとめて記載してあった方が分かりやすいです。
システム全体の画面レイアウト
システム全体で統一的な画面レイアウトと操作のルールを記載します。
例えばQiitaでいうと、ヘッダ左部にユーザーに紐づかないメニューが配置されていて、
ヘッダの右部にユーザーに紐づくメニューが配置されていて、フッタにはメイン画面に対する
アクションが配置されている、といった内容です。
特殊な構成にしていなければ、普段からインターネットやゲームでシステムに慣れている人は
読まない部分なので、システムに慣れていない人向けだと思って丁寧に書くのがおすすめです。
また、システム全体として統一的な入力ボックスやアイコンなどのレイアウトと操作方法についても
ここで記載しておくのがいいでしょう。
必須入力項目のレイアウト、単一選択ボックスと複数選択ボックスの違い、日付入力でのゼロ省略可否と
スラッシュ省略可否の関係性、などが例です。
機能一覧とその概要
業務的な階層構造を意識した構成で、機能の一覧を記載します。
例えば、ユーザー管理の配下に新規ユーザー登録、ユーザー情報変更、ユーザー情報削除、などです。
業務フロー
システム化計画や要件定義などの上流フェーズで作成するシステム化後のTo-Beの
業務フローを記載します。
ここでの業務作業の粒度がそのまま次の章の目次になるため、細かい分岐は出来るだけ省略して
ユーザーがひとつの業務作業と認識している作業を単位とするように気をつけます。
各業務作業で利用する機能と操作概要
前章の各業務作業に対して、機能一覧上のどの機能を利用するか、その機能での大まかな
操作方法を記載します。
大まかというのは、例えば入力画面でいうと、
必要な項目を入力したら「確認画面へ」ボタンをクリックして入力内容を確認します
といった具合です。
◯◯ボタンをクリックすると、と書くとシステムの仕様を書いてしまいがちなので、
◯◯ボタンをクリックして、と書いてボタンアクション後にユーザーが行うべきことを
記載するようにすると素敵です。
もちろん、SPAのようにひとつの画面内で複数のボタンアクションが必要な場合は
ボタンアクション毎に記載する方がよいでしょう。
この章の各項の目次は「～するには」とつけるイメージです。
例えば、既存の顧客情報を修正するには、などです。
注意点としては、業務フローの順序は意識しながらも、それよりも
業務のグルーピングを意識することです。
顧客管理業務、という業務のグループがあった上で、その配下に
顧客を新規登録するには、既存の顧客情報を修正するには、などとなります。
エラー発生時の対応方法
画面にエラーを通知しながらも処理を継続可能な正常異常系などとも呼ばれる業務エラーと、
処理の継続が不可能で強制的にエラー画面へ遷移するシステムエラーとに大きく分かれます。
システムエラー発生時の連絡方法や処理の最初からやり直すための手順などについては、
出来ればエラー画面で完結させることが望ましいです。
ここでは業務エラーのうち、エラーメッセージだけでは伝えきれないことを
記載することになります。
各機能の詳細な操作方法と計算処理の仕様
画面の各項目毎の入力方法や、入力可能な値の範囲などを記載します。
特に選択肢形式で選択させるものの、各選択肢の意味を記載することが重要です。
また、数値計算や複数項目の入力内容から何らかのロジックで結果を算出する処理では、
その計算処理の仕様も公開できるとベターです。
本章はシステムの特性や対象ユーザーのレベルによっても必要度が大きく変わるため、
他の章に比べて多大なコストを払って作成するべきかどうかはケースバイケースです。
全体的な注意事項
操作の説明は画面が先、結果の説明は説明が先
必ず、操作内容を書く前にその操作を行う画面のイメージ図を配置します。
最初には画面例が来るものの、その後の操作で「確認画面で内容を確認してOKを押下する」と
書いてしまってから確認画面のイメージ図が登場する、などがよくある失敗です。
操作対象画面例 → 操作内容説明 → 操作結果説明 → 操作結果画面例、という順序を原則とします。
常に主体はユーザー
ユーザーが主語の文章は能動態で「～する」と記載する。
システムが主語の文章は受動態で「～される」と記載する。
機能や画面の名称は用語を統一
これはシステム開発中も気を付けるべきことですが、ユーザーマニュアルでは開発中の
「なんとなく通じる言い換え」が一切通用しないのでさらに注意が必要です。