ポリシーと手順は、きちんと運営される組織のOSです。何が期待され、どのように実行されるのかを定義します。Trupeerなら、無料のポリシー／手順テンプレートから始めて、ブランドガイドラインでカスタマイズし、従業員が実際に見てくれる動画ウォークスルーに、分厚いポリシー文書を変えることで、ポリシー作成にかかる時間を何時間も節約できます。

ポリシーと手順の違いは何ですか？

ポリシーはルールと立場を示します。何が必ず起こるべきか、何が許可されないか、そして誰が判断するのかを明確にします。義務を表す言葉で書かれ、変更はめったにありません。リスクを負う立場によって承認されます。

手順は、何かをどのように行うかを、実行する人がステップごとに説明します。システムやプロセスが変わるたびに変わり、ガバナンスではなく、実務を行うチームが所有します。

また、多くのガイドで両者の横に登場する「プロセス」は、手順が収まっているより広い流れで、通常は複数の役割と複数の手順にまたがります。

実務的な見分け方は動詞です。must、may not、is required to を書いているなら、それはポリシーです。click、check、send、confirm を書いているなら、それは手順です。両方が大量に含まれる文書は、通常、結びつけられた2つの文書であり、手順側を適切にカバーするのがSOPテンプレートです。

なぜ多くのポリシーライブラリには誰も必要としない文書が含まれるのか

ポリシーテンプレートを検索すると、15個、30個、あるいは100個以上が提示されます。どのリストも「出発点」として見せられ、ほとんどの組織では買い物リストのように扱われます。

結果は予測できます。テンプレートやコンサルタントのチェックリストから組み立てられ、10年かけて増えたライブラリには、誰も依頼したことを覚えていないポリシーが含まれています。しかも、誰も問題にしたことのないテーマで、もはや存在しない職種名を参照しています。

これは、特定の理由がある分、ポリシーが少ない状態よりも悪いことです。人が信頼できないライブラリは、そもそも参照されなくなります。スタッフは、同僚に聞くよりも調べる方が遅くて信頼性が低いと学び、その習慣が定着すると、本当に重要なポリシーは、重要でないポリシーと並んで読まれなくなります。

つまり、問題は「どのポリシーを持つべきか」ではありません。「正当化できるポリシーはどれか」であり、その正当化は名前を付けられる必要があります。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したいテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディタ内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置および関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新済みテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるかを確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じてそのまま調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

ポリシー／手順テンプレートを使うと、次のことができます：

• 作成時間を節約： どんなポリシーにも使える実績ある構造で、空白ページをスキップできます。

• コンプライアンスを維持： 規制当局や監査人が求める要素を、組み込みセクションでカバーします。

• ブランドに沿って運用： Trupeerのブランドキットでロゴ、フォント、色を適用できます。

• 定着を改善： 長いPDFを、従業員が実際に最後まで見られる動画ウォークスルーに変換します。

• グローバルに標準化： 地域ごとのローカル調整を加えつつ、同じテンプレートを各地域で使えます。

• すべての従業員に届ける： 1クリックでポリシーを65言語以上に翻訳できます。

すべてのポリシーには、名付けられる起点が必要です

すべてのポリシーの先頭に1つの項目を追加します。「なぜこれが存在するのか」です。目的ではありません。目的は常に、何らかの形で一貫性を担保することですが、起点を記します。

正当な起点は3つあります。

法的または規制上の義務。 それを明記してください。個人情報保護に関する法律、健康と安全の義務、業界の規制、雇用法。特定の法律や規制当局がこのポリシーを求めているなら、そのポリシーには起点があります。

法律に限らない外部要件。 認証基準、保険会社の条件、顧客との契約上の要件、資金提供者の条件。これらは実在し、条項番号を含めて具体的に名付けるべきです。

インシデント、または既知のリスク。 何かが起きた、あるいはほぼ起きかけた。そして組織が再発防止を決めた、という状況です。何だったのか、いつだったのかを記録します。

この3つのいずれもないポリシーが存在するのは、テンプレートパックに含まれていたからです。それが自動的に無価値になるわけではありませんが、誰も見直さず、誰も強制せず、ライブラリの中で周囲のすべてを薄める形で置かれることを意味します。

既存のライブラリ全体に対して、この項目を遡って埋めていく作業は気が重いものですが、ガバナンス機能ができる最も役に立つことの1つです。

検証のテスト：誰が、どのように、どれくらいの頻度で確認するのか

2つ目の項目は、ポリシーを「単なる宣言」から「管理（コントロール）」へ変えるものです。

すべてのポリシーについて、次の3点に答えてください。守られていることを誰が確認するのか。監査、サンプル、システムレポート、マネージャーの承認サインなど、どの方法で確認するのか。そして、どの頻度で確認するのか。

3つすべてに答えられないなら、それはポリシーではありません。単なる希望が書かれているだけで、組織はそれが守られているかどうかを知る手段を持っていません。

それは必ずしも削除の理由になるとは限りません。場合によっては、特にポリシーに実際のリスクがあるとき、検証を構築する理由になります。ただし、暗黙のままにせず「発見事項」として記録すべきです。検証できないポリシーは、特定の種類のエクスポージャー（露出）だからです。規制当局、保険会社、顧客に「私たちはこれを行う」と伝えているのに、それを示せない状態になります。

文書が本当に役に立つのに本当に検証できない場合は、ラベルを付け替えてください。「ガイダンス」と呼び、ガバナンスの承認ルートではなくチームのオーナーを付け、ポリシーライブラリから外します。ガイダンスは正当で有用なカテゴリです。ガイダンスをポリシーだと偽ることが、ライブラリを信頼できないものにするのです。

無料のポリシー／手順テンプレート：コピーすべき構造

ここからコピーしてください。アスタリスクが付いた2つの項目は、標準テンプレートでは省略されています。

ヘッダー。 ポリシーのタイトル。参照番号。バージョン。承認者と日付。有効日。レビュー日。所有者（人物ではなく役割として）。

起点。 このポリシーを必要とする義務、要件、またはインシデントを、具体的に名付けます。

目的。 1段落。このポリシーが何のためのものかを、平易な言葉で。

適用範囲。 明示的に除外されるグループを含め、誰に適用され、どこで適用されるか。委託先や派遣スタッフは、最もよく漏れる項目です。

定義。 意味が変わることでポリシーの効果が変わる用語のみ。用語集ではありません。

ポリシーの記述。 番号付き。1つの義務につき1つ。must、may、またはmust notで書きます。「should」は避けてください。shouldは強制力がなく、弱いポリシーのほぼすべてに登場します。

役割と責任。 このポリシーのもとで、役割ごとに誰が何をするのか。

検証。 コンプライアンスを誰が、どの方法で、どの頻度で確認するのか。そして証拠はどこに保管するのか。

違反。 ポリシーが守られなかった場合に何が起きるのか、そして誰が対応するのか。

関連文書。 ここで言い直すのではなく、このポリシーを実装する手順を、名前と場所で示します。

改訂履歴。 日付、バージョン、何が変わったか、誰が承認したか。

ここまでコピーしてください。リストにないものに注目してください：ステップです。もしポリシーにシステムの使用方法に関する番号付きの指示が含まれているなら、それらは、この文書が参照する別の手順に入れるべきです。

貴社に本当に必要なポリシーはどれですか？

テンプレートのリストからではなく、義務から考えましょう。

まず、貴社のタイプ、規模、業界に対して法律が組織に求めるものから始めます。多くの法域では、健康と安全、個人情報保護、雇用に関する事項、そして業界固有のものをカバーする短く具体的なリストになります。法務アドバイザーなら1時間で作れますし、その1時間は価値があります。

次に、貴社の認証、保険会社、資金提供者、そして大口顧客が求めるものを追加します。これらは条項番号の参照付きで届くため、起点の項目は自然に埋まります。

さらに、貴社自身の過去の事情が求めるものを追加します。インシデントログ、苦情、ヒヤリハット、直近3年の保険請求を見てください。2回起きたことは、ポリシーか手順に値します。

そしてそこで止めます。30個のテンプレートのリストが示しているからといってポリシーを追加しないでください。小規模組織に適切な数は15未満であることが多く、中規模でも60を超えることはめったにありません。200件のライブラリは、ほぼ確実に「検討されたセット」ではなく、テンプレートパックの残りが積み上がった結果です。

187のポリシーと104の孤児を抱える住宅協会

Ferndale Housingは、450名のスタッフで約9,000戸の住宅を管理しています。そのポリシーライブラリには、テンプレートパック、コンサルタント、そして継続的なコンプライアンス案件から、約15年かけて積み上げられた180件の文書がありました。

ガバナンス担当リードはトレース演習を実施しました。各文書について、それを必要とする義務または出来事を名前で特定します。

41件は法令または規制上の要件にトレースできました。23件は認証、保険会社、資金提供者の条件にトレースできました。19件は特定の過去のインシデントにトレースできました。104件は、そもそもトレース可能な起点がまったくありませんでした。

その104件のうち、68件は作成された日以来一度も見直されていませんでした。31件は、もはや存在しない職種名を参照していました。12件は、同じライブラリ内の別のポリシーと矛盾していました。

矛盾の1つは、すでに彼らにコストを発生させていました。修理が緊急になる条件について、2つのポリシーが異なる閾値を示していました。1つは24時間、もう1つは同じカテゴリの不具合について4時間です。コンタクトセンタースタッフは、研修で教わった方を適用していました。苦情がオンブズマンへエスカレーションされた際には、どのポリシーが適用されるかが一部で争点になり、解決には法務・経営の時間として3週間に加え、補償の裁定が必要でした。

より深いコストは、スタッフ調査で明らかになりました。フロントラインスタッフの71%が、ルールが何かを知る必要があるときは、調べるよりも同僚に聞くと言っていました。

一掃（クリアアウト）にかかったのは四半期でした。104件の孤児のうち22件は、誰も記録していなかった本当の起点があることが判明し、それを反映して書き直されました。19件はガイダンスとして再分類され、明示的にラベル付けされ、チームのオーナーが付きましたが、承認ルートはありません。63件は撤回されました。

ライブラリは180件の文書から105件へ減りました。

その後、残ったすべてのポリシーに起点と検証の項目を追加しました。14件は検証の項目にまったく答えられず、その場合はドキュメントの不足ではなく、ガバナンス上の指摘事項として記録されました。つまり、組織には「守られているかどうかを知る手段がないルール」があることを意味するからです。1年以内に、その14件のうち9件は検証ルートが整備され、5件はガイダンスへ格下げされました。

一掃から12か月後、「同僚に聞くよりもポリシーを調べる」と答えたフロントラインスタッフの割合は、29%から58%へ上昇しました。

人が実際に従えるポリシーを書くには

まずポリシーの記述を書き、その後に他のすべてを書きます。目的、適用範囲、定義は、実際に何を求めているのかが分かってからの方が書きやすく、先にそれらを作ると、薄いルールの周りに長い前置きができがちです。

must と must not を使います。shouldは、書き手がコミットすることに不安があるときに出てくる言葉で、shouldだらけのポリシーは破れません。つまり強制できないということです。

すべての記述に番号を振り、1つの義務につき1番号にします。「and」で結ばれた2つの義務を含む記述は、途中までしか守られません。

読んで従う必要がある人のために書きます。読んでくれるかもしれない規制当局のためではありません。どちらの読者も実在し、コンプライアンス側の読者が、実際に何かが起きるかどうかを決めます。規制当局向けの言い回しが避けられない場合は、付録に入れてください。

人ではなく役割に名前を付け、名付けたすべての役割が今も存在することを確認します。

そしてテストします。従う必要がある人に渡し、「今なら何を違えてやるか」を聞いてください。答えが「何もない」なら、ポリシーがすでに起きていることを説明しているだけで問題ありませんが、その点は認めるべきです。あるいは、抽象的すぎて実行できません。

ポリシーを使えるようにする言葉とトーン

短い文と能動態です。「Managers must approve expenses over £500（マネージャーは£500を超える経費を承認しなければならない）」のように書き、「expenses in excess of £500 are subject to managerial approval（£500を超える経費はマネージャーの承認の対象である）」とはしません。

個人に適用されるなら2人称、組織に適用されるなら3人称を使います。1つの文書に混ぜるのはよくあり、混乱を招きます。

法的な言葉ではなく平易な言葉で書きます。法的用語が、平易な言葉にない意味を持つ場合を除きます。定義済みの用語を使う必要がある場合は、1回だけ定義し、常に同じ言葉を使い、見栄えのために言い回しを変えたくなる衝動を抑えましょう。

判断ではなく具体的な閾値を使います。「Within two working days（2営業日以内）」は強制できます。「Promptly（速やかに）」は強制できません。

そして、行為者を隠す受動的な構文は避けます。「It is expected that（〜が期待される）」では、誰にも何をすべきか伝わりません。誰が行動しなければならないのか名付けられないなら、その記述はまだ準備できていません。

ポリシーと手順は1つの文書にすべきですか？

通常は違います。その理由は「見た目の整頓」ではなく「保守」です。

ポリシーと手順は承認ルートが異なります。ポリシーは通常、取締役会、経営陣、または委員会の承認が必要です。手順は運用上のオーナーが必要です。結びつけると、システム更新によって生じる手順の変更を含め、手順の変更のたびに、ポリシーのレベルで再承認が必要になります。実務では更新は起きないため、結合された文書は、形式上は承認されたまま、手順側だけが静かに間違った状態になります。

また、変わる頻度も大きく異なります。個人情報保護ポリシーは2〜3年ごとに変わるかもしれません。一方で、対象者アクセス要求の取り扱い手順は、ケース管理システムが変わるたびに変わります。

分けてリンクさせてください。ポリシーは、それを実装する手順の名前を示します。手順は、それがどのポリシーに仕えるかを示します。手順が、稼働中のシステムに対する重大な変更を1回だけ行うものであれば、method of procedureが適切な形です。繰り返し発生する運用タスクであれば、SOPまたはジョブエイドです。

会社のポリシーテンプレートと、それぞれが属する場所

一般的な会社のポリシーセットは、オーナーが異なるグループに分かれます。何かをダウンロードする前に、これを知っておく価値があります。

雇用と行動。 懲戒、苦情、欠勤、平等と多様性、柔軟な働き方、内部通報。人事が所有し、法務のインプットで承認され、法域の影響を強く受けます。ここは、汎用テンプレートが最もリスクが高い領域です。

健康、安全、環境。 健康と安全のポリシー、リスク評価、インシデント報告、そして業界固有の義務。一定の人員規模を超える場合に、所定の様式とともに法令で求められることが多いです。

情報とテクノロジー。 利用の許容範囲、情報セキュリティ、個人情報保護、リモートワーク、調達。これらのうちの1つを適切に書いた実例として、IT調達ポリシーテンプレートがあります。承認ルートや閾値も含めて示されています。

財務と商業。 経費、委任権限、贈収賄防止、利益相反、調達の閾値。

運用と業界固有。 規制当局、認証、サービスモデルが求めるものは何でも。

3つ目と4つ目のグループからテンプレートをそのまま取り、適応して先へ進んでください。1つ目と2つ目のグループから取る場合は、かなり慎重に行ってください。内容は法域固有であり、間違えたときのコストはドキュメントの問題ではないからです。

ヘルスケアのポリシー／手順テンプレート：何が違うのか

ヘルスケアのポリシーは検索流入が多く、実際に別分野の専門性があるため、そこは率直に言う価値があります。

変わるのは3点です。臨床ポリシーは臨床ガバナンスの承認と臨床領域の執筆が必要で、汎用テンプレートではどちらも提供できません。内容は特定の規制当局や認証団体に紐づいており、その要件は規範的で、国やケアの提供形態によって異なります。そして、保管期間、バージョン管理、スタッフの理解の証拠は、通常は良い実務ではなく義務として求められるため、周辺のプロセスが文書と同じくらい重要になります。

このページの構造は、ヘルスケア組織が必要とする管理系および運用系のポリシー（調達、情報ガバナンス、人事、施設）には機能します。臨床ポリシーの作成には使うべきではありません。

臨床の内容については、規制当局の要件と専門団体のガイダンスに基づいて進め、臨床ガバナンスを通じてポリシーを執筆・承認してください。テンプレートから始めることが本当に間違ったアプローチになる、数少ないケースの1つです。

より一般的に、このページの内容は法務またはコンプライアンスの助言ではありません。雇用、安全、個人情報保護、業界の規制はすべて法域によって異なり、これらの領域のポリシーは、発効する前に有資格のアドバイザーによって見直されるべきです。

ポリシー／手順テンプレートをWordまたはPDFで入手できますか？

下書き用および作業用のコピーとしてはWordまたはGoogle Docsです。ポリシーは複数ラウンドのコメントと承認を経て、改訂履歴が重要になるためです。

公開版はPDFです。発効中のポリシーは固定し、バージョンを押印し、日付を付ける必要があります。そうすれば、誰もが同じ文書を読んでいることになり、特定の日付に適用されていたバージョンを証拠として示せます。この最後の点は、何かが争われたときには、聞こえる以上に重要になります。

ポリシー登録簿はExcelです。ポリシーそのものではありません。文書ごとに1行で、タイトル、参照、所有者、承認日、レビュー日、起点、検証方法、最終検証日を記載します。この登録簿があることでライブラリを管理でき、ほとんどの組織が欠いている成果物です。レビュー日と起点で並べ替えるだけで、個々のポリシーを読むよりも10分でガバナンスについて多くが分かります。

ポリシーがゆっくり変わるときに、手順を最新に保つ方法

ポリシーを手順から切り離すと、承認の問題が解決され、保守の問題が生まれます。つまり、文書が増え、手順側は常に変わるようになります。

その手順側にこそ労力がかかります。手順を更新するには、すでに使い方を知っているシステムについて、誰かが再スクリーンショットを撮り直し、ステップを書き直す必要があり、その作業はいつも緊急の何かに負けてしまうからです。

Trupeer AIがその大部分を取り除きます。タスクを実行する人が一度だけ記録し、出力は、ステップと画面がすでに取り込まれた書面の手順になります。作成ではなく確認の準備ができている状態です。ポリシーは安定したまま承認され、下にある手順は、システムが変わったときに午後のうちに更新できます。

記録する。ブランド化する。翻訳する。Trupeerする。

SOP creatorは手順そのものをカバーし、documentationはポリシーと、それに紐づく手順を一緒に保ちます。そして、ポリシーセットがある機能全体の運用方法を説明している場合、operational manualテンプレートが、コンテンツを重複させずにその見え方を組み立てる方法をカバーします。セットアップ手順はdocument template setup guideにあります。

よくある質問

Wordで無料のポリシー／手順テンプレートはありますか？

上記の構造は、起点と検証の項目を含めて、そのままWordまたはGoogle Docsに貼り付けられます。標準テンプレートでは省略される項目です。ゲート付きのダウンロードもフォームもありません。ハウステンプレートとして保存するときは、ヘッダーブロックをロックしてください。レビュー日と所有者の項目は、最もよく空欄のままになるからです。

PDFでポリシー／手順テンプレートはありますか？

PDFで公開し、文書エディタで下書きします。公開版は固定し、バージョンを押印しておく必要があります。そうすれば、特定の日付に有効だったバージョンを証拠として示せます。ここが、ポリシーライブラリが役に立つかどうか、または役に立たないかの分かれ目です。

小規模組織向けのシンプルなポリシーテンプレートはありますか？

はい。シンプルな方が、たいていの場合はより良いです。ヘッダー、起点、目的、適用範囲、番号付きの記述、責任、検証、違反、レビュー日。これは1ページで、完全なポリシーです。小規模組織が困るのは、短すぎるポリシーを書くからではなく、長大なテンプレートパックを採用してしまうからです。

ダウンロードできる会社のポリシーテンプレートはどこで入手できますか？

たくさんのライブラリが提供していますが、注意点は「どのグループから取るか」です。財務、商業、運用のテンプレートはうまく適応できます。雇用、健康と安全、個人情報保護のテンプレートは法域固有であり、使用前にアドバイザーによる見直しが必要です。そこに引き継がれた誤りのコストは、ドキュメントのコストではないからです。

ポリシーは誰が承認すべきですか？

それを対象としているリスクを負う人です。多くの組織ポリシーでは経営執行者または取締役会の委員会、運用ポリシーでは機能の責任者になります。テストは、承認者が、そのポリシーが不十分だった場合に責任を問われ得るかどうかです。誰も責任を負えないなら、承認は事務的なものになり、ポリシーは強制されません。

ポリシーはどれくらいの頻度で見直すべきですか？

法的または規制上の起点があるものは毎年、その他は2〜3年ごとに加え、法律が変わったとき、その領域でインシデントが起きたとき、または責任ある役割が変わったときはトリガーとして見直します。カレンダー上のレビューだけでは、変更のないまま再発行される文書が大量に生まれるため、サイクルよりもトリガーの方が重要です。

ポリシーはどれくらいの長さにすべきですか？

多くは1〜3ページです。長くなるのは、通常、手順が混ざってきたか、規制文言が参照ではなくそのまま再現されているからです。適用される人が5分で読めないポリシーは、監査人以外には誰にも読まれません。

ポリシー、手順、プロセスの違いは何ですか？

ポリシーはルールであり、誰が判断するかを示します。手順は、1つのタスクを1つの役割が行うためのステップです。プロセスは、それらの手順が収まっているより広い流れで、通常は複数の役割にまたがり、最終的に成果（アウトカム）へ至ります。ポリシーはプロセスを統制し、手順はそれを実装します。