標準作業手順書の例：3つの作成事例

標準作業手順書の例は、見出しの一覧ではなく、実際の手順や使用するシステム、例外への対応まで示しているものが参考になります。ここでは、具体的な例を3つ紹介します。さらに、継続して見直せる手順書の構成や、実際の作業に沿って文書化する方法、手順書が現状の業務を反映しているかを確認する方法も解説します。

標準作業手順書とは

SOPは、繰り返し行う作業の進め方を説明します。誰が、どの順番で、どのシステムを使って作業するのか、通常の手順に当てはまらない場合はどうするのかを記載します。チームで作業方法を共有し、新しいメンバーを教育するための共通資料になります。実際の作業と照らして確認した時点が新しいほど、手順書の信頼性も高まります。

標準作業手順書の例を3つ紹介

各例では、ロール、システム、期待される成果、例外時の対応を記載したステップ表を使います。こうした情報があると、手順に沿って作業しやすくなり、システムに記録された実際の作業とも比較しやすくなります。

例1：シェアードサービスにおける請求書の例外処理

この手順は、請求書の3点照合に失敗した時点で開始します。例外の列には、ステップが予定どおり進まなかった場合の対応を記載します。

最後の行では、繰り返し発生する問題をチームが見直しに回せるようにしています。すべての例外に同じ対処が必要だとは想定していません。

例2：商品の受領と棚入れ

例3：ITサービスデスクでのインシデントの初期対応

SOPに記載する内容

次の標準作業手順書を作成する際は、以下の構成を参考にしてください。

• **目的と適用範囲：**手順の対象と対象外を明記します。範囲を明確にすると、1つのSOPで1つの作業を扱いやすくなります。
• **開始条件：**手順を開始するきっかけとなる事象を示し、どの場面で適用するのか分かるようにします。
• **ロール：**個人名ではなく、ロールごとに責任を記載します。人は入れ替わりますが、ロールは比較的変わりにくいためです。
• **番号付きのステップとシステム：**各ステップの内容、担当者、使用するシステムを記載します。
• **例外時の手順：**通常の手順に当てはまらない場合の対応を説明します。理想的なケースだけでなく、よくある逸脱も含めます。
• **統制と証跡：**何を、どこに記録し、どのくらいの期間保管するかを明記します。
• **担当者と改訂履歴：**責任者を記載し、変更の日時と内容を記録します。
• **見直しのきっかけ：**システム、規制、チームの変更や、測定されたパフォーマンスの変化など、見直しを行う条件を定めます。

改訂履歴には、いつ、何が変わったかを記録します。見直しのきっかけを設定しておけば、手順が古くなる前に再確認できます。

SOPが使える状態か確認する方法

手順を公開または改訂する前に、次の点を確認してください。

• 適用範囲に、SOPの対象外となる内容も記載されていますか。
• 開始条件は冒頭付近に明確に示されていますか。
• 各ステップにロール、システム、期待される成果が記載されていますか。
• アプリケーション上で行うステップには、読者が見る画面が示されていますか。
• 通常の手順に当てはまらない場合の対応が説明されていますか。
• 担当者が明記され、改訂履歴もありますか。
• 特定の事象をきっかけに見直す仕組みがありますか。
• 手順をイベントデータと比較し、違いがあればプロセス担当者と確認しましたか。

最後の質問に答えられない場合は、まず作業を記録しているシステムを特定してください。実際の作業と手順が今も一致しているかを確認できるようになります。SOPの管理を、単なるファイル保管ではなく、見直しのサイクルに変えられます。

SOPの管理方法

SOPの作成は、作業の半分にすぎません。SOPプログラムの管理では、手順書の保管場所、最新版、見直し担当者を決める必要があります。専用の標準作業手順書管理ソフトウェアを使う場合も、文書をフォルダーで管理する場合も、チームごとにコピーを作ると古い版が残ります。ProcessMindでは、手順を説明対象のプロセスと一緒に管理するため、文書とともにガバナンスも維持できます。

• **手順を説明対象のアクティビティに追加します。**各プロセスには文書ツリーがあり、環境レベルでセクションを一度設定できます。すべての手順書で、説明、適用範囲、ロール、目標、ガバナンスの見出しを共通して使えます。組織に必要なカスタムセクションを追加し、作業手順は探しに行く必要のあるフォルダーではなく、該当するステップと一緒に管理します。
• **プロセスと合わせて見直します。**プロセスの状態は、下書き、レビュー中、承認済み、公開済み、廃止、アーカイブ済みと進みます。レビュー担当者は「自分のレビューが必要」フィルターで対象を確認できます。承認と同時に公開版を作成できるため、ある場所で承認した文書が別の場所で変更されることはありません。
• 作業の場所でコメントします。ステップのコメントを追加を使うと、そのアクティビティについて話し合えます。フィールド、統制、例外に関する質問を手順の隣に残せるため、受信トレイに埋もれません。
• バージョンを保管します。バージョン履歴には、変更内容、日時、変更者が記録されます。公開時に、読者が閲覧するバージョンが決まります。
• **モデルのロールを反映します。**文書内のRACIマトリクスには、モデル内で各アクティビティに割り当てられたロールが反映されるため、文書上の担当者と図の担当者が一致します。
• **画面を使う作業は、その画面上で手順を記録します。**ProcessMind内でスクリーンショットや画面録画を撮り、必要なコントロールが見えるように切り抜きます。保存画像に個人情報を黒塗りで固定し、Markdownで手順を追加できます。機密情報と思われる項目を自動検出する機能もあります。枠は編集可能なため、保存前に修正できます。記録はアクティビティに添付された資料として保存されます。
• **ファイルが必要な読者向けにエクスポートします。**見直しや品質管理システムにはWord、バージョン管理にはMarkdown、配布や保管にはPDFまたは印刷を使えます。エクスポート設定では、まだ文書化されていないモデル要素、プロセス図、アクティビティごとのRACIを出力に含めるか選択できます。文書化されていない要素を一覧にすると、手順に不足がある箇所をすばやく把握できます。

文書化は管理の半分にすぎません。もう半分は確認であり、同じ場所で行えます。文書化したステップをシステムに記録されたアクティビティと比較し、教育、文書、プロセスのどれを変更すべきか判断します。承認された変更は、独自のバージョン状態とともに文書に反映されます。

2つの制約を明確にしておきます。ProcessMindは記録を整理し、見直しのための証跡を提供しますが、コンプライアンスを認証するものではありません。また、品質マネジメントシステムで必要な承認や、法務チームが管理するポリシーライブラリに代わるものでもありません。このワークフローの外で使う画面記録ツールも、たとえばScribeのように、作業の進め方を同じように記録できます。少数の手順書を1つのチームで管理するなら、社内Wikiで十分な場合もあります。ただし、社内Wikiも独立した文書保管システムも、手順と実際の作業が今も一致しているかは確認できません。

イベントデータからSOPを作成する方法

イベントデータからは、ERP、ITSM、WMSなど、業務を記録しているシステム上でどのステップが実行されたかが分かります。プロセスに関する知識と合わせて、手順書の作成やレビューに役立ててください。プロセスマイニングは、こうした用途にも使えます。

1. イベントログを読み込む

   プロセスを記録するシステムからケースID、アクティビティ、タイムスタンプを特定します。比較しやすい状態を保つため、ケースの定義と期間はそれぞれ1つに統一します。

2. 文書化されたプロセスに対応付ける

   記録された順序をSOPのステップと並べて確認します。文書化されたステップの中には、すべてのケースで発生するもの、まれにしか発生しないもの、まったく発生しないものがあります。それぞれについて確認が必要です。

3. 差異を分析する

   各経路が実行される頻度、業務の待ち時間、繰り返されるステップを測定します。データに見られる違いは、調査のきっかけであり、業務に問題がある証拠ではありません。

4. 重要な差異をSOPに追加する

   上記の3つの例のように、繰り返し発生するものを、担当者、システム、期待される出力を記載した例外行として追加します。そのうえで、データだけでは分からない点を、実際に業務を行う人に確認します。

プロセスの確認にデータを使うことはできますが、データだけですべての判断の理由が分かるわけではなく、あるべきプロセスを定めることもできません。業務を担当し、責任を持つ人に調査結果を確認してもらい、あわせて担当者と見直しのきっかけを決めておきましょう。担当者がいない手順書は、実態とずれていきます。