Trupeer Blog
要約
「SOPと作業指示書」に関するアドバイスの多くは、最初から誤った前提に立っています。すべてのプロセスには、きちんとした書類の積み重ねが必要だと考えるのです。つまり、ポリシー、SOP、作業指示書、チェックリスト、トレーニングガイドです。ですが、私はこのやり方が「実作業が始まると誰も開かない書類棚」を増やしてしまうのを見てきました。
私なら、もっとシンプルな問いにします。この作業は最初にどこで失敗し、誰が助けを必要とするのか？ 失敗が「責任の所在」「引き継ぎ」「承認」「エスカレーション」にあるならSOPを書きます。失敗が「1つのツール」「1台のマシン」「1つの画面」の中にあるなら作業指示書を書きます。特にSaaSのサポート、IT、オペレーションのような現代のチームでは、答えは「よりスリムな手順」と「より豊かなビジュアルのタスクガイド」です。
ここで、私が使っている素早い比較を紹介します。
ドキュメントの種類 | 何を答えるものか | 最適な用途 |
|---|---|---|
SOP | 何が起きるのか／誰が所有するのか／エスカレーション時にどうなるのか／どんな統制が適用されるのか | プロセスのガバナンス、整合性、監査可能性 |
作業指示書 | 1つのタスクが手順としてどう進むか | 実行、トレーニング、オペレーターの正確さ |
目次
「SOPと作業指示書はどちらが先か？」という問いが不適切な出発点である理由
結論： どのドキュメントが先に来るのかを聞くのをやめましょう。防ぎたい「失敗の種類」は何かを考えてください。
私の経験では、チームが行き詰まるのは、SOPと作業指示書を「必須の階層」として扱ってしまうからです。書類の積み重ねを上から全部作り、オペレーターが無視するのを見て驚きます。これは文章の問題ではありません。スコープの問題です。
書類名ではなくリスクから始める
プロセスのドキュメントとタスクのドキュメントは、役割が違います。SOPはプロセス・レベルの統制を扱います。作業指示書はタスク・レベルの実行を扱います。選択は、テンプレートライブラリに「すべてのSOPには子ドキュメントが必要」と書かれているかどうかではなく、リスク、ばらつき、役割の明確さによって決まります。
実用ルール： 問題が「人によって判断が変わる」なら手順を書きます。「人が間違ったものをクリックする」ならタスク指示を書きます。
小規模なサポートチームが、コンプライアンスが必要だと思って、単純なワークフローを3通りの方法でドキュメント化しているのを見たことがあります。必要ではありませんでした。作業のリスクは低く、訓練されたチームが行い、安定していました。明確なプロセスのドキュメントが1つあれば十分でした。
一方で、広い運用手順に、詳細なキーボード操作ステップを詰め込もうとするチームも見てきました。これも失敗します。CRM画面が少し変わった瞬間に、ドキュメント全体が古くなってしまうのです。
より良い捉え方
何かを書き始める前に、次のテストを使ってください：
まず何が壊れるかを聞く： 責任の所在、順序、承認、または実行の詳細ですか？
誰がそのドキュメントを必要とするかを聞く： マネージャー、監査担当者、新入社員は、現場のオペレーターとは異なるレベルの詳細が必要です。
作業がどれくらいの頻度で変わるかを聞く： 安定したワークフローなら、より広い範囲のドキュメントでも耐えられます。変化の速いソフトウェアには、モジュール化されたガイドが必要です。
ミニ例： SaaS企業の返金プロセスは、エージェントがすでにシステムを理解していて、手順が単純であれば、SOPは1つで足りるかもしれません。同じチームでも、請求プラットフォームでクレジット発行を行う画面が頻繁に変わるなら、その部分について別のビジュアル指示が必要になる可能性があります。
要点： きれいな教科書的な分け方は役に立ちますが、それが判断基準ではありません。リスクと役割の必要性が、階層のための階層ではなく、ドキュメント設計を決めるべきです。
SOPはプロセス・レベルで何を記録するのか
結論： SOPはプロセスを記録します。トリガー、スコープ、責任者、統制、記録、エスカレーションを定義すべきです。クリックごとの手順書になってはいけません。
チームが物事を複雑にしすぎていると思います。「標準作業手順（standard operating procedure）」という言葉を聞くと、あらゆるタスクの詳細を詰め込み始めます。その結果、ドキュメントは脆くなり、保守が難しくなり、使うのも面倒になります。
SOPに含めるべきもの
私の仕事では、しっかりしたSOPは通常、次のプロセス質問に答えます：
プロセスを開始するものは何か
各段階の責任者は誰か
必要な入力は何か
期待される出力または結果は何か
意思決定や記録を取り込むシステムは何か
いつエスカレーションする／止めるのか
SOPは「プロセスの高度」に存在します。TrupeerのSOPベストプラクティスガイドによれば、手順を肥大化させずに使える状態に保つのも、まさにこのレベルです。
SaaSサポートの例
B2B SaaSサポートチームのインシデント・トリアージをドキュメント化するとします。
SOPには、たとえば次のような内容を記載します：
トリガー： サポートチケットが「緊急」または「顧客報告の障害」として到着する。
責任者： Tier 1サポートが最初にトリアージする。エンジニアリングマネージャーがSEV-1のエスカレーションを所有する。
入力： チケットの詳細、アカウント履歴、サービス状況、利用可能ならログ。
判断ポイント： パスワードの問題、請求の問題、バグ、障害、安全上の懸念。
記録の基となるシステム： ヘルプデスク、インシデントチャネル、ステータスページ、エンジニアリングのキュー。
エスカレーションルール： 重大インシデントは、インシデントのプロセスに直ちに移行する。
何が欠けているかに注目してください。ボタンごとのCRM画面案内はありません。チケットフォームのスクリーンショットもありません。項目ごとの指示もありません。これらは別の場所にあるべきです。
良いSOPはツール移行に耐えます。悪いSOPは、ベンダーがUIを再設計した瞬間に壊れます。
SOPはどんなものにすべきか
最良の手順は、スタッフ変更、責任者の引き継ぎ、監査にも耐えられるほど安定していることに気づきました。手順が、役割や機能をまたいでプロセスがどう動くべきかを人に伝えます。すべての画面で誰かをトレーニングするものではありません。
ミニ例： ZendeskがIntercomになったとしても、インシデント・トリアージのSOPは概ねそのまま使えるはずです。システム名や記録参照を変える必要はあるかもしれませんが、プロセスのロジックはそのまま保たれます。
要点： SOPをガバナンス層として扱いましょう。 人やシステムをまたいで作業を調整するものであり、すべてのキー操作を教えるものではありません。
作業指示書はタスク・レベルで何を記録するのか
結論： 作業指示書は、ある1人が、ある状況の中で、1つのタスクをどう完了させるかを正確に記録します。
実行の詳細は作業指示書に入れるべきです。SOPがプロセスを定義するなら、作業指示書は、推測せずに誰かがタスクを実行する方法を説明します。私の経験では、これは実作業の最中に人が使うドキュメントです。
「高度の落差」が重要
業界のガイダンスでは、これらのドキュメントを「高度」で一貫して分けています。SOPはプロセス・レベルに位置し、作業指示書は1つのタスクにズームします。そこでは、SOPと作業指示書の違いを整理したこの解説で説明されている通り、使用するツール、設定、順序、そして正確さの期待値が明確になります。
この区別が重要なのは、タスクガイドが非常に具体的になり得るからです：
正確なクリック
必須の入力項目
ツール固有の確認
許容される例外
視覚的な手がかり
次に進む前に期待される結果
SaaSサポートの例に戻る
同じインシデント・トリアージのプロセスを考えてください。1つのSOPが、2つの別々のタスクガイドにリンクするかもしれません：
パスワードリセットの作業指示書
SEV-1エスカレーションの作業指示書
パスワードリセットのガイドでは、アイデンティティプラットフォーム上での正確な手順、アクセスをリセットする前の検証チェック、そしてその後に記録すべきノートを示せます。
SEV-1のタスクガイドでは、インシデントチャネルの手順、ステータスページの更新項目、そしてエンジニアリング、サクセス、リーダーシップに通知が届く順序を示せます。
スクリーンショットベースのガイドを作るなら、このビジュアル作業指示書のワークフローが、別の長いWordドキュメントよりもおすすめの形式です。
なぜ作業指示書はより早く変わるのか
ソフトウェアの画面、ボタンのラベル、または権限が変わると、作業指示書が週単位で壊れるのを見てきました。これは普通です。タスク・レベルのドキュメントは、実行の詳細に紐づいているため、より変化しやすいのです。
レベル | 典型的な焦点 | 失敗の起き方 |
|---|---|---|
SOP | プロセスの流れ、責任、統制 | 役割間での混乱 |
作業指示書 | ツールまたはシステムでのステップ実行 | 作業の実行時点でのエラー |
ミニ例： サポート担当者はSOPから返金ポリシーを知っているかもしれませんが、それでもStripe、Salesforce、またはカスタムの管理パネルで正しく返金処理を行うには、ビジュアルのタスクガイドが必要になることがあります。
要点： 作業指示書は精度のために使いましょう。 そこに入るのは、スクリーンショット、フィールドメモ、ショートカット、そしてオペレーター・レベルの判断です。
5つの現実的な基準で比較するSOPと作業指示書
結論： 多くの比較チャートは抽象的すぎます。役に立つ違いは、次の5つの実用的な基準に集約されます。スコープ、読者、形式、安定性、そして所有（責任）です。
オンラインの表の多くは、同じことを少し違う言葉で言っているだけです。これは、チームリードが「1つのプロセスを4つのタスクガイドに分けるべきか、それとも1つのスリムな手順として維持するべきか」を判断しようとしているときには役に立ちません。比較が本当に役立つのは、実際の保守と実際の責任に結びつけたときだけだと思います。
SOPと作業指示書：5つの現実的な基準
基準 | SOP | 作業指示書 |
|---|---|---|
スコープ | エンドツーエンドのプロセスをカバー | 1つのタスクまたはアクションをカバー |
読者 | マネージャー、部門横断チーム、監査担当者、新入社員 | オペレーター、エージェント、テクニシャン、実行担当 |
形式 | プロセス指向の文章、フロー、統制、役割 | ステップごとのガイド（多くの場合ビジュアル） |
安定性 | 時間とともにより安定 | ツールや画面の変更で頻繁に変わる |
所有（責任） | プロセスオーナー、部門リード、品質リード | チームリード、SME、現場機能のオーナー |
スコープがドキュメントの境界を決める
ISOに整合した実務では、SOPをプロセス・レベル、作業指示書をタスク・レベルとして扱います。ISO 9001:2015では、SOPや作業指示書を名前で固定することは求められていません。求められているのは、プロセスが計画どおりに実施されるという確信を持てるように必要な範囲で、文書化された情報だけを用意することです。品質の枠組みでは一般に、手順をプロセス・レベルに、作業指示書をタスク・レベルに対応づけることが多いです。
そのため、チームが「1つのプロセスに5つの作業指示書が必要か？」と聞いてきたら、最初の問いはスコープです。各タスクで使うツール、リスク、例外の分岐が異なるなら分けます。そうでないなら、スポーツのための書類を作らないでください。
読者によって文章のスタイルが変わる
SOPは、プロセスを監督し、承認し、監査し、引き継ぐ人にとって意味が通じる必要があります。作業指示書は、今まさに作業をしている人を助ける必要があります。これらは、必要とするものが異なる別の読者です。
オペレーター向けガイドを、抽象的なポリシーの言葉で書いているチームを見たことがあります。それは役に立ちません。プロセスのガバナンスを、トレーニング用の文章のように書いているケースも見ました。逆も同じ問題です。
形式と安定性が、あなたの仕組みを形作るべき
SOPは通常より安定している一方で、作業指示書はツール、画面、または実行の詳細に紐づいているため、すぐに古くなることに気づきました。このパターンは、指示書とSOPの違いに関するこのガイダンスにも反映されています。
チームがドキュメント化する前にプロセスをビジュアルで整理しているなら、1ページも書く前に、プロセスマッピングツールの概要が、プロセスの見え方とタスクの見え方を分けるのに役立ちます。
SOPには安定したロジックを残し、不安定な詳細は指示書に押し出しましょう。
ミニ例： 財務の承認プロセスは、数か月同じままかもしれません。コーディネーターが入力するERPの項目は、調達がワークフローを更新した次のタイミングで変わる可能性があります。
要点： 分け方が「形式的か非形式的か」を決めるのではありません。安定したプロセス統制か、変化しやすいタスク実行かの違いです。
実務におけるISO 9001のSOPと作業指示書の扱い
結論： ISO 9001が重視するのは、SOPや作業指示書というラベルを使ったかどうかではなく、「統制された文書化された情報」です。
チームはしばしば大きな時間を無駄にします。「標準では特定のドキュメント一式が必要だ」と多くの人が思い込むのです。しかし違います。ISO 9001:2015では、より広い用語である文書化された情報を使い、SOPと作業指示書の違いを実務的に説明したこの解説で述べられている通り、プロセスが計画どおりに実行されるという確信を持てるように必要なものを組織が維持することを求めています。
監査担当者が通常気にすること
私の経験では、監査担当者は「名前」よりも「統制」をはるかに重視します。ドキュメントが承認されていて、最新で、追跡可能で、そして実際の作業のやり方と結びついていることを見たいのです。
それは通常、次を意味します：
バージョン管理： 誰でも、どのコピーが最新か分かる。
承認と責任： レビューに責任を負う人がいる。
トレーサビリティ： プロセスマップ、手順、タスク・レベルのガイダンスが揃っている。
使用の証拠： 記録とアウトプットが、文書化されたプロセスと一致している。
3つの状況、3つの異なる答え
サポートチームは、チケットのトリアージ用の高レベル手順1つと、いくつかの運用用ジョブエイドがあれば監査に通るかもしれません。ITの変更管理チームは、薄いガバナンス手順と、複数のデプロイ固有のタスクガイドが必要になることがよくあります。変更の種類ごとに実行が異なるからです。ラボでは、サンプル取り扱い用の正式なSOPを1つ用意し、さらに、オペレーターの精度が重要になる校正やラベリング、機器セットアップのための別指示が必要になるかもしれません。
タスク層に品質に配慮した構造が必要なら、このISO準拠の作業指示書フォーマットガイドが実用的な出発点になります。
監査担当者はドキュメントの膨大さを評価しません。評価するのは統制、一貫性、そして証拠です。
ミニ例： 会社は、あるドキュメントを手順、SOP、または作業指示書と呼ぶことができます。プロセスが統制されていて、人が最新バージョンに従っているなら、タイトルはチームが考えるほど重要ではありません。
要点： 架空の監査担当者のために過剰に文書化しないでください。 プロセスを確実に機能させる最小限の統制された文書を作りましょう。
適切なドキュメント選択を変える3つの現実的なシナリオ
結論： 適切なドキュメントは、リスク、ばらつき、そしてどれだけ詳細が必要か（誰が必要とするか）で決まります。
多くの記事はこれを1つの階層に押しつぶします。私はそれに賛同しません。同じ会社でも、あるワークフローではSOPだけで十分で、別のワークフローではタスクガイドだけが必要で、さらに規制のある運用では両方が必要になることがあります。
以下は、平易な英語でのパターンです。
SaaSサポートにおけるシナリオ1
サポートチームが、返金をシンプルで馴染みのあるワークフローで扱うとします。ポリシーのルールは明確です。同じ訓練を受けたエージェントが毎日同じ作業を行います。私の経験では、この場合はSOPが1つで足りることが多いです。
手順は、承認の上限、責任、例外対応、そして記録の基となるシステムを定義すべきです。請求ツールが分かりにくい、または頻繁に変わる場合でなければ、別の作業指示書は不要かもしれません。
ミニストーリー： 3ステップの返金フローについて、すでにすべてのエージェントが手順を完全に理解しているのに、スクリーンショットガイドの保守に時間を無駄にしているチームを見たことがあります。ガイドは統制ではなく、手間（オーバーヘッド）を増やしていました。
IT変更管理におけるシナリオ2
薄いSOPに複数のタスクガイドを組み合わせるのが、たいてい勝ちます。SOPは、リスク分類、承認、ロールバックの期待値、変更ウィンドウを定義すべきです。実行の詳細は別の作業指示書に入れるべきです。データベースのパッチ、フロントエンドのデプロイ、インフラ変更は、同じ正確な手順に従うことはほとんどありません。
この違いが重要です。ガバナンス層は1つ。実行パスは多い。
ラボ運用におけるシナリオ3
ラボの作業は、より融通がききません。サンプル取り扱いのSOPは必須になるかもしれません。なぜなら、プロセス自体に正式な統制が必要だからです。そこに、校正、ラベリング、機器セットアップのような高リスクのタスクについて、ビジュアルの作業指示書を重ねます。1つでも見落とすとオペレーターのエラーにつながるからです。
この構造がうまく機能するのを見たことがあります。正式なプロセス文書は安定したままにしつつ、ミスが最も問題になる場面で、テクニシャンに対してタスク・レベルの精密なサポートを提供できるからです。
要点： 階層が答えを決めるのではありません。リスク、ばらつき、そして読者が決めます。
なぜビジュアルとAI生成の作業指示書が勝っているのか
結論： ビジュアルでAIが生成したドキュメントは、タスク・レベルの内容がより速く変わり、スクリーンショット、クリップ、翻訳の恩恵をより大きく受けられるため、SOPよりも作業指示書に適しています。
これは、多くのチームがまだ十分に内面化できていない変化です。作業指示書は、1つのツール、1つの役割、または1つの画面に紐づきます。だからこそ最初に古くなりますが、同時に最新のツールで最も改善しやすいドキュメントでもあります。
手順はスリムに保つ
新しいガイダンスでは、作業指示書をビジュアル、デジタル、多言語として捉える流れが強まっているのを感じます。特にソフトウェア中心のワークフローではそうです。一方でSOPは、より上位のガバナンス文書として維持されます。
これは実務で見ていることと一致しています。埋め込みスクリーンショット付きの長いWord SOPは、すぐに古くなります。短い手順に、更新されたビジュアルのタスクガイドを組み合わせた方が、はるかに長持ちします。作り方の完全ガイドはビジュアル作業指示書をご覧ください。
現代チームのための実用的なモデル
この判断ルールを使ってください：
SOPを書く：プロセスの境界、責任、統制、エスカレーションが必要な場合。
ビジュアルの作業指示書を書く：特定のシステムで、担当者が正確な手順を必要とする場合。
両方を使う：プロセスはチーム横断で統制されているが、実行はタスク・レベルで変わる場合。
ソフトウェアのワークフローからタスクガイドを作るチーム向けに、AIが画面録画をステップごとのドキュメントに変える仕組みを説明したこの内容が、モデルを明確に示しています。実際には、Trupeerのようなツールで、画面録画を構造化されたビジュアル指示、スクリーンショット、ドキュメントに変換できます。UIが変わるたびに巨大なSOPを書き直すより、はるかに保守しやすいのです。
画面が毎月変わるなら、そのステップを中核の手順に埋め込まないでください。
ミニ例： カスタマーサクセスチームは、プロダクトチームがインターフェースを更新するたびにビジュアルの管理パネル指示を再生成しつつ、アカウント引き継ぎのSOPは安定したまま維持できます。
要点： AIは「作業の近く」に置くべきです。 SOPはスリムに保ち、変化の速い詳細はビジュアルの作業指示書に入れましょう。
実用的な判断ルールと、よくある質問への簡単な答え
結論： 所有（責任）、境界、統制を定義するならSOPに入れるべきです。ツールやシステムでのステップのやり方を示すなら作業指示書に入れるべきです。
私は、チームが迷っているときに使うシンプルな週次チェックリストを用意しています。
私が実際に使っている判断ルール
リスクのレベル： プロセスのリスクが高いほど、より明確な正式なガバナンスが必要になることが多いです。
変更頻度： 変化の速いステップは、コアのSOPの外に置くべきです。
読者のスキルレベル： 新任やローテーションのスタッフには、明示的なタスクガイドが役立ちます。
監査の必要性： 統制の証拠が必要なら、承認と記録を明確に文書化してください。
TrupeerがSOPと作業指示書の作成をどう支援するか
上で述べた分け方が機能するのは、変化の速い層（作業指示書）が更新しやすい場合だけです。Trupeerはまさにそのために作られています：
タスクを1回記録： 誰かが実際に作業を行うときに、TrupeerのChrome拡張機能で作業指示書をキャプチャします。
ビジュアルのステップを自動で取得： Trupeerが各アクションを検出し、注釈付きのスクリーンショットで番号付きステップを作成します。
SOPはスリムに保つ： スクリーンショットを手順にコピーするのではなく、SOPを作業指示書にリンクします。
画面が変わったら更新： SOPに触れずに、影響を受けたタスクを再録画します。
すべてのオペレーターに届ける： 指示を65+言語に翻訳し、PDFまたはWordとして書き出すか、ヘルプセンターに埋め込みます。
Trupeerのステップバイステップガイドジェネレーターを試す.
よくある質問
作業指示書なしでSOPだけで成立しますか？
はい。リスクが低く安定したワークフローでは、スリムなSOPが1つで十分なケースをたくさん見てきました。チームがタスクの詳細をすでに理解しているなら、完璧に見せるためだけに追加のドキュメントを作る必要はありません。
ISO 9001の監査担当者は両方を期待しますか？
自動的には期待しません。私の経験では、プロセスに合った統制された文書化された情報を期待しています。形式についてのより多くの背景が必要なら、このISO準拠の作業指示書フォーマットガイドが実用的な出発点になります。
1つのドキュメントで両方の役割を担えますか？
場合によりますが、私はあまりおすすめしません。プロセスが小さく安定しているなら、ハイブリッドなドキュメントでも機能します。所有（責任）やツールのステップが、異なる速度で変わり始めたら分けましょう。
それぞれはどのくらいの頻度で見直すべきですか？
プロセスの責任者、統制、またはエスカレーションルールが変わったときにSOPを見直してください。ツール、画面、方法、または実行パスが変わるたびに作業指示書を見直します。
作業を2倍にせずに両方を最速で作る方法は？
まずはワークフローそのものから始めます。プロセスを1回記録し、その同じソースからプロセス概要とタスク・レベルのガイドを生成します。通常、それが最もきれいな進め方です。このガイドではTrupeerで作業指示書とSOPの両方を作る方法を示しており、こちらはプロセス文書化の書き方を扱っています。
要点： テンプレートで文書化しないでください。失敗リスクとユーザーの必要性で文書化しましょう。
TrupeerでSOPはスリムに、作業指示書は最新の状態に保ちましょう。 ワークフローを1回記録すると、Trupeerがスクリーンショットと短い動画付きのステップバイステップのビジュアルガイドに変換します。画面が変わったら、手順を書き直すのではなく、影響を受けたステップを再録画してください。TrupeerのSOP作成ツールを試す.
よくある質問
Can an SOP stand alone without a work instruction?
Do ISO 9001 auditors expect both?
Can one document serve both roles?
How often should each be reviewed?
What's the fastest way to produce both without doubling work?
