SaaS操作マニュアルの作り方｜画面キャプチャ前に決める7項目

SaaSの操作マニュアルは、画面キャプチャを並べるだけでは使える資料になりません。利用者の権限が違う、最初の設定が終わっていない、ボタン名が変わる、途中でエラーが出る。こうした条件を先に整理しないと、画像はきれいでも「どこから始めて、何ができたら終わりか」が分からない資料になります。

この記事では、社内ツールやクラウドサービスの手順書を作る担当者向けに、撮影前に決める7項目、初めて操作する人による確認方法、内製と外注の分け方を一つの流れにまとめます。特定のSaaSに依存しないため、管理画面、申請システム、顧客管理、予約管理などへ置き換えて使えます。

最初に決める7項目の全体像

最初に「対象者」「開始状態」「完了条件」「一手順の操作単位」「画面上の位置」「画像と代替テキスト」「例外対応と更新責任者」を一枚へ書き出します。この順番なら、操作の前提から成功確認、読み手への見せ方、保守まで抜けなくつながります。画面を撮り始めるのは、この骨組みがそろってからです。

1. 誰が、どの権限で使うか
2. どの状態から開始するか
3. 何を確認できたら完了か
4. 番号付き手順をどの粒度にするか
5. 操作対象が画面のどこにあるか
6. 画像に何を残し、代替テキストへ何を書くか
7. 失敗時の戻り方と更新担当をどうするか

1. 対象者と権限を一文で固定する

最初に「営業担当者が一般ユーザー権限で、新規顧客を登録する」のように、利用者、権限、目的を一文で固定します。「担当者向け」だけでは、管理者にしか見えないメニューを前提にしてしまうことがあります。部署名よりも、画面に影響するロールや権限名を優先してください。

同じ作業でも権限によって画面が違う場合は、一本の手順に混ぜず、冒頭で対象を分けます。管理者向けの補足が一か所だけなら注記で足りますが、操作経路が複数に分かれるなら別ページにした方が更新しやすくなります。

2. 開始状態と利用環境を明記する

手順1の直前に、ログイン済みか、対象のワークスペースを選択済みか、必要な初期設定が完了しているかを書きます。ブラウザやアプリの違いが操作に影響する場合は、確認した環境と確認日も残します。利用者が自分の画面と手順書を照合できる情報だけを載せます。

開始状態が複数ある場合は、最も一般的な入口を本文にし、別の入口は補足へ分けます。どの画面からでも読めるように情報を詰め込むと、かえって最短経路が見えなくなります。

• 開始画面の名称と、そこへ移動するための前提
• 確認したブラウザ、OS、アプリ版など必要最小限の環境
• 事前に必要な登録、権限、ファイル形式
• 検証日と、画面変更を再確認する時期

3. 完了条件を画面上の事実で定義する

「登録して終了」ではなく、「一覧に顧客名が表示され、ステータスが下書きになっている」のように、利用者が画面で確認できる状態を完了条件にします。通知メールや別システムへの反映が必要なら、反映までの目安と確認場所も分けて書きます。

完了条件を先に決めると、不要な画像を減らせます。最後の画面が決まれば、そこへ到達するために本当に必要な操作だけを逆算できるからです。保存ボタンを押したことではなく、保存された結果を確認したことを手順の終点にします。

4. 番号付き手順は一つの主操作に絞る

Microsoftの手順記述ガイドでは、複数ステップの操作は番号付きリストにし、一つの手順には一つの操作を書く考え方が示されています。「顧客を選択して内容を確認し、保存を押す」を一項目にせず、選択、確認、保存を分けます。途中で迷った場所が特定しやすく、画面変更時も該当箇所だけ更新できます。

入力欄が連続するフォームでは、一つずつ番号を増やすより、同じ目的の入力を箇条書きへまとめる方が読みやすい場合があります。番号は処理の順序、箇条書きは同じ段階の入力項目、と役割を分けます。

1. 左メニューで「顧客」を選択します。
2. 画面右上の「新規登録」を選択します。
3. 名称と担当者を入力します。
4. 入力内容を確認し、「下書き保存」を選択します。
5. 一覧で名称とステータスを確認します。

5. 画面上の位置を先に示し、操作を続ける

同じ名前のボタンやメニューが複数あるときは、「画面右上の［保存］を選択します」のように、場所を先に示します。利用者が全文を読んでから視線を戻す負担を減らせます。マウス、キーボード、タッチのどれでも実行できる操作には、「クリック」へ固定せず「選択」を使うと端末が変わっても通じます。

色や形だけで場所を示すのは避けます。「青いボタン」「歯車のアイコン」だけではテーマや表示倍率で迷います。領域名、見出し、ラベル、位置を組み合わせ、「設定画面の［通知］セクションで［メール］を選択」のように書きます。

• 場所：画面右上、左メニュー、設定画面の通知セクション
• 対象：表示されているラベルや項目名
• 操作：選択、入力、確認、保存
• 結果：表示の変化、ステータス、完了メッセージ

6. 画像は操作を補い、秘密情報を残さない

画面キャプチャは、文章だけでは位置関係が分かりにくい箇所へ絞ります。操作と同じ文章を画像内へ長く重ねる必要はありません。画像がなくても手順の順序と対象が理解でき、画像を見ると位置関係を早く把握できる状態が理想です。

撮影前に、氏名、メールアドレス、顧客情報、アクセストークン、APIキー、内部URL、ブラウザのブックマークを確認します。後からぼかすだけでなく、可能なら検証用データへ置き換えます。画像を更新したら、本文のボタン名と画像内の表示が一致するかも再確認します。

W3Cの画像代替テキストの判断手順では、画像が意味を持つ場合は文脈に合う代替テキストを用意し、複雑な情報は本文にも示す考え方が整理されています。操作画像では「顧客一覧の右上に新規登録ボタンがある画面」のように、その画像が伝える位置や状態を書きます。装飾だけの画像は読み上げを邪魔しない扱いにします。

7. 例外対応・戻し方・更新責任者を決める

正常系だけの手順書は、実務で止まりやすい資料です。入力エラー、権限不足、保存失敗、重複登録など、起こりやすく安全に案内できる例外を選びます。原因を断定できないエラーには、再送を繰り返さず、表示された時刻とメッセージを記録して担当窓口へ連絡するよう案内します。

取り消し可能な操作には、戻し方と影響範囲を書きます。削除、送信、決済、公開など元に戻しにくい操作は、実行直前に確認項目を置きます。最後に、SaaSの画面変更を誰が検知し、どの手順から更新するかを決めておくと、古い画像だけが残る状態を減らせます。

• よくある表示と、利用者が安全に確認できる範囲
• 再試行してよい条件と、止めて連絡する条件
• 取消・修正の手順と、他の利用者やデータへの影響
• 更新責任者、確認日、見直しのきっかけ

初めて操作する人に確認してもらう

作成者は操作を知っているため、前提の抜けに気づきにくくなります。対象業務をまだ覚えていない人に、口頭説明を足さず手順書だけで操作してもらいます。詰まった場所、迷った選択肢、完了を判断できなかった箇所を記録し、説明ではなく本文へ戻します。

内製と外注を分ける判断基準

手順が短く、対象者が少なく、画面変更が頻繁なら、業務担当者が更新できる軽量な内製形式が向いています。一方で、複数部署へ展開する、権限別に分岐が多い、既存資料の形式がばらばら、初見テストまで行う時間がない場合は、構成と品質確認を外部へ切り出す選択肢があります。

外注する場合でも、業務判断そのものを丸投げはできません。対象者、権限、入力例、完了条件、公開してよい画面情報は発注側が確認します。制作側には、対象範囲、納品形式、修正回数、画面変更時の扱い、秘密情報の処理方法を伝えます。

制作を依頼するときに渡す情報

依頼前に、対象SaaS名だけでなく、利用者、権限、対象業務、開始状態、完了条件、検証用データ、納品形式をまとめます。画面共有が必要なら、顧客データを表示しない検証環境と、閲覧できる範囲を先に決めます。機密情報をチャットや資料へ貼らず、社内の取り扱いルールに従ってください。

この記事では、判断材料を示した後にツキラボの操作マニュアル制作サービスを1件案内しています。

確認した一次情報

• Microsoft Writing Style Guide：Writing step-by-step instructions
• Microsoft Writing Style Guide：Describing interactions with UI
• W3C Web Accessibility Initiative：An alt Decision Tree
• デジタル庁：ウェブアクセシビリティ導入ガイドブックのアクセシビリティ対応

SaaSの画面、権限、仕様は更新される場合があります。実際の手順書では、対象サービスの公式ヘルプと検証環境を確認し、確認日を残してください。