スクリーンショット付きSOPの作成方法

標準業務手順書（SOP）は、定期的に行う作業をだれが担当しても毎回同じように行うための手順を定めた文書です。ソフトウェアを操作する手順にスクリーンショットを加えると、手順を追いやすくなります。特に月に1回以下しか行わない作業で効果があります。

この記事では、SOPに含める内容、作業手順書との違い、Temposhotを使ってMacで手順を記録する方法を説明します。全体を通して、サブスクリプション事業者の返金SOPを例として使います。この業務はサポート担当、請求担当、財務承認者の3者が担当します。

SOPとは

SOPは、繰り返し行う業務の目的、対象範囲、関与する役割、手順、確認項目を定めた管理文書です。月末締め、顧客への返金、ユーザーのオフボーディング、リリース前の確認など、作業結果を揃える必要がある業務で使用します。

視覚的なSOPは、ソフトウェアを操作する各ステップにスクリーンショットを追加したものです。正となる情報はテキストで、スクリーンショットは操作する場所を示します。

SOPが必要な業務

すべての業務に管理文書が必要なわけではありません。次のいずれかに当てはまる場合にSOPが有効です。

• 複数の担当者が同じ業務を行い、担当者によって結果が異なる。
• 四半期ごとなど、まれにしか行わない業務で、画面の操作を正確に覚えている人がいない。
• 誤りが金銭や信頼に影響する。例として、誤ったカードへの返金が挙げられます。
• 監査人、顧客との契約、または規制当局が業務の進め方を確認する。

例の返金業務は4つすべてに当てはまります。3人が関わり、月に約40回実行され、誤りがあると実際の金銭が返金されてしまい、決済代行会社との契約で返金ポリシーの文書化が求められています。

SOPと作業手順書の違い

この2つの用語は混同されがちです。違いは詳細さの度合いです。

	SOP	作業手順書
対象	業務全体。複数の役割にまたがる場合あり	業務内の1つの作業
記載内容	何が行われ、だれが、いつ行うか	1つの作業を正確にどう行うか
一般的な長さ	数ページと、リンクされた作業手順書	1つの作業をステップごとに記述
スクリーンショット	任意の概要	各ステップに1枚

実際には、視覚的なSOPに短い作業手順書をセクションとして含めることが多くあります。スクリーンショットが多い長い手順は、リンクされた作業手順書にするほうが管理しやすくなります。

返金の例での分割方法

返金SOP本体は、テキストで2ページ程度に収まります。クリック単位の手順は、業務が関わる3つのシステムごとに作成した3つの作業手順書に分けています。

この分割により、保守の範囲が限定されます。請求システムでボタンの位置が変わった場合は請求の作業手順書だけを更新し、承認ルールを含むSOP本文は変更しません。

業務の範囲を定義する

業務の最初のイベントと最後のイベントを、それぞれ1行で記述します。例として、「返金依頼が承認されたときに開始する。顧客が返金確認を受け取ったときに終了する。」と書きます。この2行の外にある作業は、別のSOPに記載します。

範囲を明確にすると、文書が短くなり、読み手が正しい文書を開いているかどうかを判断できます。

範囲内のイベントを整理する

最初のイベントと最後のイベントの間にある引き継ぎを、順番に書き出します。引き継ぎは、作業が別の担当者または別のシステムに移る地点です。返金業務には5つのイベントと3つの引き継ぎがあります。

エッジケースで範囲を検証する

手順を書く前に、範囲の線に対して特殊なケースを3つ当てはめます。電話で依頼された返金も「依頼が承認された」から始まるため範囲に含まれます。決済代行会社が自動的に取り消した返金は承認を経ないため範囲外です。元のカードではなくギフトカードへの返金は範囲内ですが、個別の例外が必要です。

2つの境界線の外にあるイベントは、それぞれ別のSOPにします。返金対象かどうかの判断は、このSOPより上流にあるポリシー上の判断です。後から届いたチャージバックへの対応は、別の紛争処理手続きです。

入力、役割、前提条件を整理する

手順の前に、業務を開始するために満たしておく必要がある条件を書き出します。

• 入力: 担当者が手元に用意する文書、ID、承認。
• 役割: 各作業を行う人、承認する人、報告を受ける人。
• アクセス: 必要なシステムと権限のレベル。
• 期限: 「月の3営業日目まで」など、期限または頻度。

入力が不足している場合、読み手は最初のページで気付くべきです。手順の9つ目で気付くべきではありません。

返金の例の前提条件

返金SOPはチェックリストから始まります。請求担当者は、どのシステムも開く前にこのリストを読み、1つでも欠けていれば作業を中止します。

システムと役割ごとにアクセス権を整理する

アクセスの問題は、取り消せない最初の操作の後に業務が途中で止まる原因になります。返金SOPでは、システムごとに各役割が必要とする権限を一覧にしています。これにより、最初のクリックの前にアクセス不足を発見できます。

システム	サポート担当	請求担当	財務承認者
ヘルプデスク	チケットの編集	チケットの閲覧	チケットの閲覧
請求ダッシュボード	なし	返金の実行	閲覧のみ
財務元帳	なし	なし	エントリの作成

役割は氏名ではなく職務で書く

「Anaが返金を実行する」と書くと、Anaが担当を変えた時点で手順が成り立たなくなります。「請求担当者が返金を実行する」と書き、役割と担当者の対応は別の名簿で管理します。こうすると、担当者が変わっても文書を改訂する必要がありません。

現在の業務を実行し、手順を記録する

業務を定期的に行っている担当者が、現在の方法を記録します。実際の業務で金銭が動いたり顧客の記録が変わったりする場合は、テスト用またはサンドボックスのアカウントを使用します。

1. 記録の設定

   Action Captureの画面（Command+3）でConfigureを開きます。Parse clicked elementsをオンにし、タイトルテンプレートにClick "[[element-name]]"を設定します。あわせてMark clicked areaをオンにします。

2. Action Captureを開始

   Start Action Captureを選択します。アプリをまたいで移動する業務ではActive Windowを、固定の領域を記録する場合はCapture Areaを選択します。

3. 業務を実行

   クリックが記録されるたびに、そのクリックの直前の画面が保存されます。クリックが不要な画面、例えば処理後に状態が変わる画面では、Capture nowまたはShift+Command+2を使用します。

4. 別の作業のために一時停止

   メールやチャットを確認するために業務から離れる場合は、Pause captureを選択します。戻ったらResume captureを選択します。

5. 記録を終了

   Finish captureを選択します。Documentがエディタで開き、各ステップが1ページずつ表示されます。

エディタでは、各タイトルを動詞で始め、操作するコントロール名を記載します。条件はPage descriptionに書きます。記録の対象についてはAction Captureガイドを参照してください。

返金の記録で使用した設定

返金業務は、ヘルプデスク、請求ダッシュボード、財務元帳の3つのアプリにまたがります。Active Windowは、クリックを受け取ったウィンドウを自動で追跡します。そのため、事前にウィンドウを選択しなくても1回の実行で3つのアプリすべてを記録できます。

ウィンドウ全体をPDFでA4サイズに縮小すると、大きい円はより見やすくなります。Show cursor in shortcut capturesをオンにすると、手動のショートカットで追加したステップにもポインタが表示されます。読み手が1つの項目だけを確認する必要がある状態画面で役立ちます。

記録セッションの流れ

請求担当者は、サンドボックスの注文に対する返金を1回のセッションで記録しました。記録を開始する前にセッションを計画したため、探索的なクリックが記録に含まれませんでした。

キーボード操作により、セッションを短く保てます。以下のショートカットを使うと、Temposhotのウィンドウに切り替えずに記録を操作できます。

SOP用にタイトルと説明を編集する

Click "Issue refund"のような下書きのタイトルは、「注文ページでIssue refundを選択する」のような操作指示に書き換えます。条件はPage descriptionに書きます。例として「注文合計ではなく、承認済みの金額を入力する」と記載します。説明は、PDFへの書き出し設定に応じて画像の前または後に表示されます。

実際の顧客データが写っているページは削除します。サンドボックスの注文ではほとんどの情報を避けられますが、ヘルプデスクのサイドバーには実際の顧客の最近のチケットが表示されることがあります。書き出しの前に、Framingで切り抜くか、Blur（Pro）で該当部分を隠します。

長い業務を小さなガイドに分割する

記録が15〜20ステップを超える場合は、区切りの良い箇所を探します。役割の引き継ぎ、待機時間、別のシステムへの切り替えなどが区切りになります。各部分を独立したガイドにし、SOPからその順にリンクします。

短いガイドは更新しやすくなります。あるシステムが変わった場合は、長い文書全体ではなく1つのガイドを差し替えます。

23ステップの記録の分割方法

返金業務の記録では23ページが作成されました。そのうち4つは誤操作で、ヘルプデスクの検索ボックスを2回、ツールチップを2回クリックしていました。残りの19ページは、システムが切り替わる箇所できれいに分割できました。

Temposhotには、1つのDocumentを複数に分割するコマンドはありません。代わりに、同じ記録セッションからパーツを作成します。Documentsで**Capture History…**から新しいDocumentを作成し、セッションを展開して1つのシステムのフレームだけを含めます。これを各パーツについて繰り返します。

タイトル、切り抜き、注釈の編集は分割後に、各新しいDocumentで行います。元のDocumentで先に行った編集は元のDocumentに残ります。各Documentは画像のコピーを個別に保持しているためです。

SOPの手順からパーツをリンクする

SOPの手順セクションには、作業手順書を順番に、担当する役割とともに記載します。読み手はリストを見て自分の役割を見つけ、その作業手順書だけを開けばよくなります。

1. サポート担当：WI-FIN-014-A、注文を確認（6ステップ）。
2. 請求担当：WI-FIN-014-B、返金を実行（8ステップ）。
3. 財務承認者：WI-FIN-014-D、元帳にエントリを記録（5ステップ）。

各リンクの横にあるステップ数で、読み手の見通しを立てられます。8ステップの作業手順書の9ステップ目に到達した読み手は、何かが誤っていると判断できます。

ステップ上限への対応

無料プランでは、Action Captureの1回の実行は5ステップで一時停止します。ただし、それまでに記録したステップは保存されます。そのため、23ステップの記録にはTemposhot Proが必要です。または、システムごとに5ステップ未満の短い実行を複数回行います。短い実行は前述の分割を自然に促すため、SOPに適しています。

確認項目、例外、中止条件を追加する

業務文書は、問題が発生したときの対応が書かれていなければ不完全です。

• 確認項目: 手順が成功したことを確認するチェック。例：「ステータスが Refunded と表示される」。
• 例外: 既知のバリエーションと対応方法。例：「注文が90日より古い場合は、手動返金のSOPに従う」。
• 中止条件: 作業を止めてエスカレーションする条件。例：「金額が依頼と異なる場合は、作業を止めて財務に連絡する」。

取り消しできない操作の前のページには、警告を追加します。短いTextラベル（T）またはRectangle（R）を確定ボタンの周囲に配置すると、画面を乱さずに注意を引けます。

読み手が行動できる例外を書く

例外が役立つのは、きっかけ、対応、担当者が明記されている場合だけです。曖昧な表現では、リスクのある場面で読み手が推測することになります。

取り消せない手順をスクリーンショットで示す

請求システムの返金確認ダイアログには、取り消しの操作がありません。このページでは、Confirm refundの周囲に赤いRectangleを配置し、「ここでは取り消せない」という4語のTextラベルを付けてリスクを示しています。3つの作業手順書すべてで警告の色を統一し、読み手が意味を一度覚えれば済むようにしています。

視覚的SOPの構成

1. タイトル、SOP ID、バージョン、発効日、責任者。
2. 目的と対象範囲（業務の範囲）。
3. 役割と責任。
4. 入力、アクセス、前提条件。
5. 手順：スクリーンショット付きでリンクされた作業手順書。
6. 確認項目、例外、中止条件。
7. 関連文書。
8. 改訂履歴。

各作業手順書は、Export PDFで書き出します。Proでは、PDFの設定ダイアログで表紙、ステップ番号、ページ番号を追加し、説明を各スクリーンショットの前または後に配置できます。表紙にはSOP IDとバージョンを記載します。その他の書き出し形式については書き出しガイドを参照してください。

返金SOPのヘッダー

例のSOPの最初のセクションは次のとおりです。各行は、監査人や新しく入った担当者が最初に確認する項目に答えています。

• タイトル: 顧客への返金。
• SOP IDとバージョン: SOP-FIN-014、バージョン3。
• 発効日: 承認後の翌月の初日。
• 責任者: 請求チームリーダー。
• 目的: 承認済みの返金依頼を、5営業日以内に元の支払方法へ返金する。
• 対象範囲: 承認済みの返金依頼から、顧客の確認メールまで。

目的の行には、意図的に数値を入れています。「5営業日以内」と書くことで、SOPに測定可能な管理基準が加わり、月次レポートで基準を超えた返金を数えられます。

印刷用作業手順書のPDF設定

請求担当者は、月次の照合作業のために印刷した作業手順書をデスクの近くに置いています。バインダーに綴じやすいように縦向きのA4を使用し、説明を画像の前に配置して、スクリーンショットより先に条件が読めるようにしています。

表紙には、Documentのタイトルとステップ数が表示されます。そのため、Documentのタイトルには「WI-FIN-014-B Issue a refund v3」のように、IDとバージョンを含めます。これらの設定のカスタマイズにはProが必要です。無料プランでは、PDFは既定値を使用します。既定値は、A4、Landscape、表紙あり、ステップ番号あり、ページ番号ありです。

SOPと作業手順書をまとめる

SOPの本文と3つのPDFを、文書管理システムにまとめて保管します。一貫した命名規則を使うと、各作業手順書を親SOPに対応付けられます。

WI-FIN-014-Cは期限切れカードの例外を扱い、別の記録実行で作成されたものです。そのため、パッケージには3つのシステムにまたがる4つの作業手順書が含まれます。ファイルごとにバージョンが異なるのは意図的です。元帳の作業手順書は初版以降に1回、請求の作業手順書は3回変更されています。それぞれが独自の番号を持ちます。

SOPをテストし、保守担当を決める

業務を行ったことのない人に、テスト用アカウントでSOPに従って作業してもらいます。作成者は見守るだけで、手を貸しません。質問が出るたびに、SOPの不足箇所が分かります。

次に、責任者を1人決め、見直し日を設定し、見直しのきっかけを一覧にします。きっかけの例は、システムの更新、ポリシーの変更、インシデントです。Documentは記録したMac上にローカル保存されるため、責任者は元のDocumentをそのMacに保管し、変更のたびにPDFを書き出し直します。

最初のテストで分かったこと

新しいサポート担当者がサンドボックスの注文で返金SOPに従いました。20分間で3つの質問がありました。チケットのどこに注文IDが表示されるか、税金も返金するかどうか、請求ダッシュボードの「部分返金」の意味です。それぞれの質問が、1つの編集につながりました。チケットのヘッダーを枠で囲んだスクリーンショット、税金に関する例外の1行、ページ説明の1文です。

編集後にテストを再度行います。質問がない2人目のテスト担当者がいれば、SOPは承認の準備ができたと判断できます。

返金SOPの見直しのきっかけ

請求チームリーダーは4つのきっかけを挙げています。いずれかが発生した場合は、10営業日以内に見直しを開始します。

• 請求ダッシュボードまたはヘルプデスクで、作業手順書内の画面が変更される。
• 返金ポリシーが変更される。例：90日の期間。
• 顧客に返金の誤りが届く。
• 他のきっかけがないまま6か月が経過する。

元のDocumentを責任者が保管する

各作業手順書は、責任者のDocumentsライブラリにあるDocumentです。請求システムが変更された場合、責任者はWI-FIN-014-Bを開き、**Capture new images…**で変更された画面を記録し、古いページを削除して再度書き出します。書き出し済みのPDFは自動では更新されません。文書管理システムのファイルを差し替え、バージョン番号を上げてください。

よくある質問

SOPのすべての手順にスクリーンショットが必要ですか。

ソフトウェアの手順は、1つずつスクリーンショットがあると役立ちます。「顧客に電話する」のようなソフトウェア外の手順には不要です。

SOPはどのくらいの頻度で見直すべきですか。

システムの変更、ポリシーの変更、インシデントのたびに見直します。それに加えて、組織が定める定期的な間隔で見直します。一般的には年に1回または2回です。

SOPとチェックリストの違いは何ですか。

チェックリストは確認する項目を並べたものです。SOPは、業務の進め方、役割、手順を説明します。多くのSOPはチェックリストで終わります。スクリーンショットチュートリアルのチェックリストを参照してください。

実際の顧客データを使用するSOPを記録できますか。

サンドボックスやテスト用アカウントが存在する場合は、必ずそれを使って記録してください。本番環境でしか存在しない手順がある場合は、Framingでページを切り抜き、書き出す前に残りの詳細をBlurで隠します。Capture HistoryからエクスポートしたZIPには、編集前の元のフレームがすべて含まれるため、共有する場合はDocumentの書き出しを共有してください。

1つの作業手順書はどのくらいの長さにすべきですか。

スクロールして戻らなくても読み終えられる長さにします。返金の例では、3つの作業手順書はそれぞれ5〜8ステップです。15ステップを超える場合は、引き継ぎ箇所またはシステムの切り替え箇所を探して、そこで分割します。

文書管理システムには何のファイルを保存すべきですか。

各作業手順書を書き出したPDFと、通常使用している形式のSOP本文です。Temposhotの書き出し元のDocumentは、編集用の正として責任者のMacに残します。

クリックの記録を分かりやすい手順ガイドにする

Action Captureは、業務の手順を一度記録し、SOP用の順序付きで編集可能なステップを作成します。Temposhotをダウンロードして、現在の方法で業務を記録してください。