日本語

Notionで腐らないプロセス設計とSOP

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

先四半期、47本のドキュメントが入ったNotionワークスペースを監査しました。そのうち31本をアーカイブしました。「レビュー対象」としてマークしたのではありません。アーカイブです。サイドバーから消えました。チームは2週間気づかず、気づいたときには3人からお礼を言われました。

これがほとんどのOpsドキュメントの実態です。40本以上のSOPがNotionとConfluenceとGoogleドライブ（誰もリンクを持っていない）に散らばったワークスペースを引き継ぎます。6ヶ月後には、約73%が実際のプロセスから乖離しています。ドキュメントの作成者は2四半期前に退職しています。新入社員は「本当のやり方」を、その火曜日に手が空いていた人から口頭で教わります。ドキュメントは形式的な監査のために存在します。誰も開かない。

このPlaybookは私が代わりにやることです。1ページのSOP、Loom優先のウォークスルー、90日のレビューサイクル、そして次の四半期が始まる前にライブラリの60%を削除すべきものを特定するゴーストドキュメント診断です。いずれも理論ではありません。今まで3つのOpsチームで実施し、同じパターンが成立しています。ライブラリを半分に削減すると、残ったものへのアクセスが2倍になります。

1ページSOP（と削除すべきもの）

機能するSOPには5つの項目があります。それだけです。6項目目を書き始めたなら、それはSOPではなくトレーニングドキュメントであり、別の場所に置くべきです。

私がすべての新しいドキュメントに貼り付けるテンプレートです:

# {プロセス名}

**目的**（1文）: このプロセスが存在する理由と、実行されないと何が壊れるか。
**担当者**: {チームではなく個人名}
**最終レビュー日**: {YYYY-MM-DD}
**次回レビュー日**: {YYYY-MM-DD + 90日}

## ステップ
1. {動詞 + 対象 + ツール}
2. {...}
3. {...}

## 完了基準
- {測定可能な成果1}
- {測定可能な成果2}

## エスカレーション
{トリガー条件}が発生した場合、{担当者}に{期間内}に連絡する。

これは印刷して1枚に収まります。意図的にシンプルです。スクリーンショットなし、背景の説明テーブルなし、「背景と根拠」なし。それらはWiki、Loom、またはキックオフミーティングに属するものです。ここではありません。

削除するものとその理由:

背景セクション。 「このプロセスは2024年のインシデントに対処するために設計され...」誰も気にしません。SOPは今日その作業をする人のためのものです。歴史が必要なら尋ねます。

複数の分岐を持つ決定木。 SOPに入れ子の条件分岐があるなら、それは2つのSOPが1つのふりをしているものです。分割しましょう。

ツールUIのスクリーンショット。 スクリーンショットはそれが文書化するプロセスより速く陳腐化します。SalesforceがボタンをUI変更すると、あなたのSOPは今年ログインしていない人が書いたように見えます。代わりにLoomを使ってください。次のセクションで詳しく説明します。

「プロのヒント」や「注意事項」ボックス。 指摘する価値があるなら、それはステップです。ステップでないなら、ノイズです。

完了基準の項目は多くのOps Managerが省くもので、最も重要な部分です。「月次クローズを実行する」はプロセスではありません。「月次クローズを実行し、すべての銀行照合でゼロの差異を示し、5営業日目までに総勘定元帳がロックされている状態にする」がプロセスです。基準はプロセスが機能したかどうかを示すものです。なければ、SOPが壊れているかどうかを判断できません。

Loom優先のドキュメント: 5分は8ページより優れている

今の私がSOPを書く順番であり、以前やっていたこととは逆です:

プロセスを最初から最後まで実行しながら自分のLoomを録画する。5〜8分。
1.5倍速で見返す。止まる箇所、ステップを飛ばす箇所、自己修正する箇所をメモする。
そのメモから1ページのSOPを書く。
ドキュメントの先頭にLoomを埋め込む。

Loomが真実の情報源です。1ページのドキュメントはそのインデックスです。書かれたドキュメントを権威あるものと考えるよう訓練されてきたため、逆に感じられます。しかし計算はシンプルです。5分のウォークスルーは視聴されます。8ページのドキュメントは、読者が必要だと思う見出しをスキャンされてから閉じられます。

視聴回数がこれを裏付けます。私が運営した最後のチームでは、Loom視聴回数上位10本のSOPが四半期あたり平均14回再生されました。同じSOPのNotionドキュメントは、平均3回のページビューで滞在時間22秒でした。みんなビデオを見て、作業して、ドキュメントは開きませんでした。

Loomについて私が守るルール:

トリガーから始める。 「ベンダー更新の連絡が受信ボックスに届いたのでこれをやっています。」「みなさん、こんにちは、今日は...についてお話します」ではなく。
顔ではなく画面を映す。 ウェブカメラは時間と注意を消費します。作業は画面にあります。
クリックではなく判断を説明する。 「自動更新の条項が30日を超えているため、法務にフラグを立てています。」「コメントボタンをクリックしています。」ではなく。
6分を超えたら撮り直し。 超えたなら計画ステップを省略しました。もう一度。
プロセスが変わるたびに撮り直し。 古いLoomを編集しないこと。新しいものを録画して埋め込みを置き換えます。古いバージョンはLoomライブラリに歴史的記録として残ります。

Loom優先のアプローチはもう1つ誰も話さないことも解決します。書き手の思い込みの問題です。最初にSOPを書くと、起きていると思うプロセスを説明します。最初に録画すると、実際に起きているプロセスを文書化します。この2つはほとんど同じドキュメントになりません。Loomは正直さを強制します。

90日のレビューサイクル

私のライブラリのすべてのSOPには2つの日付フィールドがあります: 最終レビュー日と次回レビュー日。次回レビューは常に90日後です。「年1回」ではありません。「必要に応じて」でもありません。90日、カレンダーに登録し、通知を設定します。

90日の時点で、指名された担当者は3つのうちどれかをします:

プロセスを再実行する。 実際に実行する。乖離をリアルタイムで発見する。
変更なしを確認する。 最終レビュー日を今日に更新し、次回レビュー日を90日後にずらす。2分で完了。
ドキュメントを編集してLoomを撮り直す。 30分かかります。価値があります。

これを機能させるルール: レビューサイクルを2回見逃したらドキュメントをアーカイブする。「後で更新」ではなく。 半年間誰も手を触れないのは、必要とされていないという強いシグナルです。それでも必要なら、アーカイブすることで誰かからSlackのメッセージが来ます。それで誰が実際に使っているかが分かります。再登録し、担当者を再指名し、90日のレビューを設定します。

Notionに保存済みビューとして監査クエリを保持しています。3列: SOP名、担当者、最終レビューからの日数。降順でソート。180日を超えるものは削除候補です。四半期末にこれを実行し、死んでいるものをアーカイブし、チームに1行のメモを送ります。「今週9つのSOPをアーカイブしました。探して見つからないものがあればメッセージください。」

この運営を2年間続けて、「メッセージください」への返信はちょうど4件でした。そのうち2件は、新しいドキュメントに置き換えられたものを探していた人（リダイレクトしました）。2件は本当のアーカイブミス（再登録しました）。40本以上のドキュメントが1件の苦情もなく消えました。

この比率があなたのSOPのうちどれだけが実際に機能しているかを語っています。

「ゴーストSOP」診断

ゴーストSOPとは、ワークスペースには存在するがチームの日常業務の現実には存在しないドキュメントです。これはほとんどのOpsライブラリで最大のカテゴリーであり、発見するための監査には約1時間かかります。

3つの兆候。どれか1つでも当てはまれば十分です:

担当者が不在。 担当者フィールドに、退職した人、チームを移動した人、または担当を確認したことがない人の名前がある。現在の従業員をドキュメントにタグ付けできないなら、ゴーストです。

最終編集が180日以上前。 「稼働中」とされているプロセスに、半年間一切の手が加わっていない。プロセスが変わっていないか（私の経験では稀です）、誰も確認していないかのどちらかです。いずれにせよ、ドキュメントは維持されていません。

被リンクゼロかつ最近の閲覧ゼロ。 他のドキュメント、オンボーディングチェックリスト、過去90日間のSlackメッセージのどれもこのSOPへのリンクがないなら、どのワークフローにも組み込まれていません。孤立して存在しています。ゴーストです。

最も速い監査は口頭で行うものです。チームの3人を選んで、それぞれに聞きます。「今すぐXをする必要が出たら、どこを見ますか?」SOPを指摘するなら、生きています。「ジェイミーに聞きます」と言うなら、ドキュメントは死んでいてジェイミーが実際のSOPです。ジェイミーが退職する前に、ジェイミーが実演するLoomでドキュメントを置き換えてください。

以前47本のドキュメントが入ったワークスペースでこれを実施しました。28本が3つの兆候すべてに該当しました。さらに3本が3つのうち2つに該当しました。1つの午後に31本をアーカイブしました。翌月チームはゆっくりではなく速く動きました。検索結果にゴーストとの一致が表示されなくなったからです。

テンプレートかカスタムか: 再利用すべきときと新規作成すべきとき

すべてのプロセスにカスタムSOPが必要なわけではありません。プロセスによっては汎用的なものもあり、その場合に新しいドキュメントを書くこと自体が無駄になります。

テンプレートを使う場合:

オンボーディングチェックリスト。 新入社員のITセットアップ、ソフトウェアアクセスリクエスト、1日目のウォークスルー。パターンは職種をまたいで同一で、アクセスリストだけが変わります。
ベンダーレビュー。 更新日、契約額、担当者、最終パフォーマンス確認、解約期限。5つのフィールド、すべてのベンダーに。
インシデント対応。 深刻度レベル、オンコール体制、エスカレーションのタイミング、事後分析テンプレート。フレームは再利用可能で、インシデントの詳細は事後分析に記録します。
月次クローズ。 同じ勘定科目、同じ照合、同じロック日。差異を記入するだけ。

新規作成する場合:

部門横断的なもの。 セールス、財務、法務をまたぐプロセスには、あなたの会社の報告構造に固有の引き継ぎがあります。テンプレートは重要な摩擦点を隠してしまいます。
実際の引き継ぎがあるもの。 「セールスが商談をオンボーディングチームに渡す。」データはどこにあるか? 誰が誰に連絡するか? 応答のSLAは? テンプレートはあなたのツールを知りません。
収益に関わるもの。 見積もりから入金まで、契約承認、案件審査。承認マトリクスを見逃した汎用SOPのコストは数日間の手戻りです。常にカスタムで作成してください。

私が使う判断基準: 最小限の編集で3つの異なる会社でも同じSOPが機能すると想像できるなら、テンプレートにします。プロセスが特定のテックスタック、特定のチーム構造、または特定の収益モデルによって形作られているなら、新規作成します。

実践的なメモ: テンプレートのSOPは_templatesフォルダーに入れます。誰かが新しい職種のオンボーディングチェックリストを必要とするとき、テンプレートを複製して職種固有のフィールドをカスタマイズします。テンプレート自体は読み取り専用です。これにより、18ヶ月かけてすべてのチームのオンボーディングSOPが少しずつ異なるものになっていく緩やかな乖離を防ぎます。

担当者のルール: 一人の人間、「チーム」は不可

「Opsチームがこれを担当する」は、誰も担当しないことを意味します。どの会社でも同じパターンを見てきました。ドキュメントにチームが担当者としてリストされ、チームが入れ替わり、ドキュメントが陳腐化し、12ヶ月後にはドキュメントが一つのことを言いプロセスが別のことをしています。

ルールは: SOP 1本につき1人の名前を付けた人間、例外なし。 担当者フィールドにフルネームを記入します。退職した場合、アクセス権を取り消すオフボーディングチケットと同じタイミングでSOPが再割り当てされます。現在の担当者がいないSOPはワークスペースに加えません。新しいドキュメントをレビューして担当者フィールドが「Operations」や「TBD」なら、差し戻します。

これは官僚的に聞こえます。そうではありません。これが説明責任を生み出す単一のルールです。指名された担当者は:

90日ごとにプロセスを再実行する。
何かが変わったらLoomを撮り直す。
問題が発生したときにSlackのメッセージを受け取る。
他の人からの編集を承認する。

担当が共有されていると、これらは何も起きません。名指しされると、すべて起きます。なぜなら担当者の名前がドキュメントにあり、自分のSOPが本番で失敗した人物になりたいとは誰も思わないからです。

これを定着させるために使うパターン: チームの四半期レビューで、指名されたすべての担当者が自分のSOPのリストとレビュー日を受け取ります。生成に約10分かかります。このリストは公開されています。3件の期限切れレビューを抱える人物になりたいとは誰も思いません。担当者の可視化以外のプロセス変更なしに、2四半期以内に私が運営したチームの期限切れ率が40%から10%未満に下がりました。

大きなSOPが実際に複数人にまたがる場合のもう1つのパターン: 主担当者とバックアップを指名します。主担当者が90日のレビューを行います。バックアップは主担当者が休暇中や会議中の場合に連絡する相手です。2名です。5名ではありません。「チーム」でもありません。

このPlaybookからルールを1つだけ持ち帰るなら、これにしてください。1ページフォーマットは役に立ちます。Loom優先のアプローチは役に立ちます。90日サイクルは役に立ちます。これらはいずれも、そのSOPが自分のものだと知っている指名された担当者なしには機能しません。

実際にどう見えるか

このチームで運営を始めて3ヶ月後、ワークスペースは47本のSOPから19本になりました。SOP 1本当たりのLoom視聴回数が3倍になりました。「Xのドキュメントはどこにある?」というSlackメッセージが、1日5〜6件のベースラインから週約1件に減少しました。2人の新入社員が1ヶ月目に、ベテランメンバーによるシャドウウォークスルーなしにLoomと1ページドキュメントだけでオンボーディングを完了しました。

仕事はドキュメントをもっと書くことではありません。仕事は少ない、より良いドキュメントを、各々に1人の担当者を置き、90日ごとにレビューし、使われなくなったときは淡々とアーカイブしながら維持することです。ほとんどのOpsチームはドキュメントが過剰で、メンテナンスが不足しています。その比率を逆転させてください。

オペレーションズ・マネージャー・プレイブック