『気をつけます』では何も変わらない｜ルールを物理的に強制する設計
前回の記事(「マニュアル作ったのに誰も読まない問題」)で、受動ルールを能動ルールに昇格させるという発想を整理しました。状況に応じて自動的にルールを呼び出す仕組みにすれば、人間の認知に頼らず組織が機能する、という話です。
実は、この記事を書いた直後に、自分の運用で「能動ルールを作ったのに、それでも守られなかった」という出来事がありました。
私は、自社のAIエージェント運用で「重要な変更を加えたら、必ず視覚的に動作確認すること」という能動ルールを以前から設計していました。発火条件も、自動提案の仕組みも、例外設計も整えてあった。前記事で書いた「能動ルールの4要素」を全て備えた、教科書通りの設計です。
それなのに、最近の作業でこのルールがほぼ完全にスキップされていたことが、後から発覚しました。能動ルールが組織にあるのに、運用の現場で発動しない。なぜそんなことが起きたのか。
この問題を掘り下げると、能動ルールという考え方の、もう一段先が見えてきました。それが「ハードブロック」という発想です。今回はこの話を、前記事の続編として整理します。
派手なテクノロジーの話ではありません。でも、「ルールを書いても守られない問題」の根本治療として、ここまで踏み込まないと組織は変わらないと、自身の失敗から痛感した内容です。
能動ルールでも守られない、という現実
前記事をおさらいすると、能動ルールには4つの設計要素がありました。
- 発火条件の明確化(どんな状況で発動するか)
- 自動的な提案の仕組み(状況がルールを呼び出す)
- 例外設計(必要に応じて緩める余地)
- 痛みの言語化(守らない場合のリスク)
これらを全部備えた能動ルールでも、なぜ守られないのか。私自身の経験を振り返って、3つの理由が見えてきました。
理由1: 「守ったかどうか」を確認する仕組みがない
能動ルールは「ルールを思い出す」段階までは強制力があります。でも、実際に実行したかどうかは確認されない。極端に言えば、ルールが画面に表示されても「了解」とクリックして無視することもできる。
意識の高い人なら毎回真面目に実行しますが、忙しいときや慣れた業務のときは、つい省略してしまう。実行確認のないルールは、結局「思い出す機会を増やしただけ」で終わります。
理由2: 「守らないとどうなるか」が即時に発生しない
能動ルールに「痛みの言語化」を含めても、その痛みは未来形の話です。「守らないと将来トラブルが起きるかもしれない」という抽象的なリスク。人間は、未来の抽象的なリスクより、目の前の作業効率を優先します。
ルールを守らなかったときに、即座に何かが起きる仕組みがない限り、軽視は続きます。
理由3: 「守らないという選択肢」が存在する
これが一番根深い問題です。能動ルールがあっても、「守らない」という選択肢が常にテーブルの上にある。意識の問題ではなく、構造の問題です。
選択肢が存在する限り、いつか誰かが「今回は省略しよう」と判断します。それが常習化すると、能動ルールが形骸化する。
ハードブロックという発想
これらの問題を解決する、もう一段先の発想がハードブロックです。
ハードブロックとは、「ルールを守らないという選択肢自体を、物理的に存在させない」設計のことです。守るかどうかを問うのではなく、守るしか選択肢がない状態を作る。
イメージしやすい例: ATMの暗証番号
身近な例で言えば、銀行のATMがそうです。
「暗証番号を入力してから現金を引き出してください」というルールを、銀行は人間の意識に頼って運用していない。暗証番号を入力しないと、そもそも引き出し画面に進めない。これがハードブロックです。
「暗証番号入力を忘れないよう気をつけてください」と張り紙をするのが受動ルール。ATM画面で「暗証番号を入力しましょう」とプロンプトが出るのが能動ルール。入力しないと先に進めないのがハードブロック。
ハードブロックは、「気をつける」「思い出す」「実行する」という人間の認知プロセスを全てバイパスします。守るしかない状態を、構造で作る。
重要なのは「物理的に」という部分
「物理的に不可能にする」という言葉に、重要な意味があります。口頭や文書での禁止ではなく、システムや構造でそれを実現すること。
「絶対にやらないでください」と書くのは、いくら強い言葉を使っても精神論です。「やろうとしてもできない」状態にして初めて、ハードブロックになります。
ハードブロックの3要素
ハードブロックを設計するには、3つの要素が必要です。
要素1: 検知
まず、ルールが守られていない状態を、システムが検知できる必要があります。
例えば、「重要な変更を加えたら必ず動作確認する」というルールなら、「重要な変更が加えられた」という事実と、「動作確認が行われた」という事実を、それぞれシステムが認識できなければなりません。
これは技術的な話というより、観測可能な状態として定義できるかという話です。「気持ちで重要だと思った」では検知できない。「3つ以上のファイルを変更した」「特定のフォルダ配下に書き込みをした」のように、客観的に観測可能な条件として定義する必要があります。
要素2: 遮断
次に、ルールが守られていない状態のとき、次のステップに進めない遮断機能を仕込みます。
ATMで言えば、暗証番号未入力のまま現金引き出しボタンを押せない状態。経理システムで言えば、承認者の電子署名がないまま支払処理を実行できない状態。「次に進めない」という物理的制約を作ることが、ハードブロックの核心です。
要素3: 記録
最後に、「ルールを守った」という事実を記録する仕組み。
これは検知と表裏一体で、検知ができるようにするための前段の仕組みでもあります。動作確認したらその記録を残す、承認したらその痕跡を残す、チェックリストを実行したら完了印を押す。記録があるから、次のステップに進めるという構造です。
この3要素が揃ったとき、ハードブロックが機能します。
なぜ多くの会社はハードブロックを使えないのか
ハードブロックの考え方自体は、別に新しくも難しくもありません。冒頭のATMの例の通り、誰もが日常で経験しています。
それなのに、多くの中小企業の業務ルールには、ハードブロックがほとんど存在しない。なぜか。
心理的な抵抗
一つ目は、心理的な抵抗です。ハードブロックは「現場を信用していない」という印象を与えがちです。「うちの社員はそんな悪いことしません」「みんな真面目にやっています」という前提があると、ハードブロックは過剰防衛に感じられる。
でも、これは認識のミスマッチです。ハードブロックは社員を疑う仕組みではなく、人間の認知の限界に対処する仕組みです。どんなに優秀で誠実な人でも、忙しい日や疲れた日にうっかりミスをします。それを構造で防ぐ。
経営者として持つべき視点は、「現場を疑うかどうか」ではなく、「現場の誰もがミスをし得る前提で組織を設計しているか」です。
「面倒」というフィードバック
二つ目は、ハードブロックを実装すると、必ず現場から「面倒」という反応が返ってくることです。それまで省略できていたステップが省略できなくなるので、当然と言えば当然。
ここで経営者が「現場の声に応えて」と緩めてしまうと、ハードブロックが機能しません。短期の摩擦と、長期の事故防止のトレードオフとして、経営判断する必要があります。
私の経験から言うと、ハードブロックの摩擦は最初の2〜3週間でほぼ消えます。新しい運用に慣れるまでの一時的な反発であって、中長期で見れば現場も「あの仕組みのおかげで助かった」と感じるようになる。経営者として大事なのは、最初の数週間を耐えること。
設計コストの誤解
三つ目は、ハードブロックの設計コストを過大評価していることです。「システムを導入しないと無理」「IT人材がいないと作れない」と思い込んでいる。
実際には、紙と運用ルールだけでハードブロックは作れます。
- 経理での例: 一定金額以上は、専用の承認用紙がないと支払処理できない運用。承認用紙は社長の机の上にしか置かない。
- 顧客対応での例: クレーム案件は、専用のエスカレーションシートに記入しないと終了報告ができない。
- 在庫管理での例: 棚卸時は、ペアでサインしないと帳簿への反映ができない。
これらは全部、ローテクなハードブロックです。システムは関係ありません。重要なのは「次に進めない構造」を作ることで、その実装手段はテクノロジーでも紙でも構いません。
4段階の強度設計
ここまでの話を整理すると、ルールには4段階の強度があります。
レベル1: 精神論(意識付け)
「気をつけましょう」「徹底しましょう」と呼びかけるだけのレベル。守るかどうかは完全に個人の意識に依存します。
実際にはほぼ機能しませんが、多くの会社の朝礼や会議で、このレベルでルールが伝達されています。
レベル2: チェックリスト(受動ルール)
ルールを文書化して、必要なときに参照できるようにしたレベル。ルールの存在を知っている状態は作れますが、思い出して使うかどうかは個人次第です。
前記事で言う「受動ルール」がここに当たります。マニュアルを整備した会社の多くがこのレベルで止まっています。
レベル3: 自動提案(能動ルール)
特定の状況になったときに、システムや運用が自動的にルールの存在を提示するレベル。前記事で言う「能動ルール」です。
「重大な変更ですね、確認手順を実行しますか?」と促す。思い出す必要がないので、レベル2より格段に機能します。ただし、提示された後に実行するかどうかは依然として個人次第です。
レベル4: ハードブロック(構造的強制)
ルールを守らないと次のステップに進めないレベル。物理的に省略不可能。守らないという選択肢が消えている。
ATMの暗証番号、医療現場のダブルチェック、会計監査の承認フロー。重要な業務ほど、このレベルが採用されています。
どのレベルを採用すべきか
全ての業務をレベル4にするのは過剰です。それぞれの業務の重要度とリスクに応じて、適切なレベルを選びます。
- 雑談、社内コミュニケーション: レベル1で十分
- 一般業務、ノウハウ伝達: レベル2(マニュアル化)
- ミスが出やすい繰り返し業務: レベル3(能動ルール)
- 重大な事故・損失につながる業務: レベル4(ハードブロック)
経営者として整理すべきは、自社のどの業務をどのレベルで運用すべきかを明示的に決めることです。これを放置すると、重要業務がレベル1で運用されているという危険な状態が放置されます。
ハードブロック設計の3つの落とし穴
ハードブロックは強力ですが、設計を間違えると逆効果になります。代表的な落とし穴が3つあります。
落とし穴1: 検知が広すぎて、誤発火が頻発する
検知条件を広く取りすぎると、ハードブロックが頻繁に発動して、現場の作業が止まります。
例えば「重要なファイル変更時はブロック」を「全てのファイル変更時はブロック」と広げてしまうと、些細な編集でも作業が止まる。これが続くと、現場が「ハードブロックを回避する裏技」を編み出してしまう。例外申請を乱用したり、検知条件を満たさないように作業を分割したり。
検知条件は狭すぎず広すぎず、本当に重要な瞬間だけに絞るのが鉄則です。
落とし穴2: エスケープハッチがない
緊急時や特殊事情があるとき、ハードブロックを一時的に外せる仕組みがないと、現場が完全に詰まります。
エスケープハッチには2種類あります。
- 事前申請型: 通常の承認フローを経て例外を認める
- 事後説明型: ブロックを越えて作業した後、なぜそうしたか記録を残す
どちらも、「外せる」が「履歴が残る」ようになっているのがポイントです。完全にブロックすると現場が硬直し、自由に外せると意味がない。外せるけど痕跡が残る設計にすると、安全性と柔軟性が両立します。
落とし穴3: 記録の検証が誰もやらない
ハードブロックの3要素のうち「記録」は、誰かが定期的に検証する前提でないと意味がありません。
「動作確認したログがあるけど、実際には確認していない」という偽装が、長期間バレないと、ハードブロックは形骸化します。
これを防ぐには、月次や四半期で、記録の中身をサンプリング検証する運用を入れます。AIで実装している場合は、ログの異常パターン(例: 1分以内に大量の確認完了が記録されている等)を自動検出する仕組みを併設するのも効果的です。
経営者として押さえるべき5つのポイント
ここまでの話を、経営者が今日から自社で考える形に整理します。
一つ目は、「気をつけます」「徹底します」で終わらせないこと。会議の最後に「気をつけよう」とだけ言って終わる議論は、ほぼ機能しません。どのレベル(1〜4)でルールを実装するかを、必ずセットで決める。
二つ目は、業務を重要度で分類し、適切な強度を割り当てること。全業務をレベル4にする必要はありません。でも、重大な事故につながる業務がレベル1で運用されていることは絶対に避けるべきです。最低でも、社内で年に一度、業務×強度のマッピングを見直す。
三つ目は、ハードブロックを「現場を信用していない」と捉えないこと。これは社員を疑う仕組みではなく、人間誰しもが持つ認知の限界に対処する仕組みです。経営者自身も含めて、全員がミスをし得る前提で組織を設計する。
四つ目は、エスケープハッチと記録検証をセットで設計すること。ハードブロックは強力ですが、それだけだと組織が硬直します。外せるけど履歴が残る、その履歴を定期的にチェックする運用と一緒に設計してください。
五つ目は、最初の摩擦を耐える覚悟を持つこと。ハードブロックを導入した直後は、必ず現場から不満が出ます。これは正常な反応です。2〜3週間経つと現場が新しい運用に慣れるので、それまでは緩めずに耐える。逆に、現場から永続的に不満が続く場合は、検知条件が広すぎるサインです。
私自身の実装例——AI業務でハードブロックを導入した話
具体例として、私自身の運用で最近導入したハードブロックを紹介します。
私は、AIエージェントを使った業務自動化を日常的に回しています。その中で、重要な変更を加えた後に動作確認をするという能動ルールが、運用の現場で守られない場面が頻発していました。
ルールはあった。発火条件も明確だった。「変更後に確認しましょう」という自動提案も出ていた。それでも、忙しいときや作業が複雑なときに、確認をスキップして作業を完了させてしまう。能動ルールでも防げなかった、典型的なケースです。
これを根本解決するために、3要素を備えたハードブロックを実装しました。
- 検知: 特定の種類のファイル変更を、システムが自動記録する
- 遮断: 動作確認の記録がない場合、作業の完了報告そのものをブロックする
- 記録: 動作確認を実行したら、記録が自動的に残る
これを入れたことで、「動作確認をしないという選択肢」が物理的に消えました。確認しない限り、次に進めない。これは厳しいようですが、結果として作業の品質が安定し、後から発覚するミスがほぼゼロになりました。
興味深い副作用
ハードブロックを入れて、想定外に良かった副作用がありました。
それは、作業中の精神的な負担が減ったことです。「動作確認、忘れていないかな」と気にし続ける必要がなくなった。ルールを守るかどうかの判断を、システムに完全に外注できるので、自分は本来の業務に集中できる。
これ、ハードブロックの隠れた効用だと思っています。「守らないと進めない」という制約は、一見、現場の自由を奪うように見えます。でも実際は、「守るかどうかを毎回判断する」という認知負荷から、現場を解放するんです。
「気をつけます」を組織から無くす
中小企業の経営会議で、最も頻繁に交わされる言葉は何だろうと考えると、おそらく「気をつけます」です。トラブルが起きたとき、ミスが発覚したとき、改善の必要性を話し合った後。最後に出てくる結論が「気をつけます」「徹底します」「意識します」。
でも、この言葉を口にした瞬間、問題は何も解決していないんです。意識で防げるなら、最初から起きていない。意識で防げないことが起きているから、改善の議論をしているはずなのに、結論が再び意識に戻る。これが、多くの組織が同じ問題を繰り返す根本原因です。
経営者として、組織から「気をつけます」を無くすという目標を立ててみてください。トラブルや改善議論の結論として、「気をつける」「徹底する」を禁句にする。代わりに「どのレベルで、どう仕組み化するか」を必ず議論する。
これだけで、組織の進化のスピードが変わります。
私自身、AIエージェント運用を通じて、この発想に強制的に向き合うことになりました。AIは「気をつけます」と言わない代わりに、ルールを書いた通りに守ろうとする。だから、ルールの設計が悪いとそのまま事故になる。人間相手だと「気をつける」で誤魔化せていた問題が、AIだと誤魔化せない。結果として、ハードブロックという発想に辿り着くのが早まりました。
これは、AIに限らず人間の組織にも完全に応用できる発想です。むしろ、AIで仕組み化できない組織は、人間でも仕組み化できていない。組織設計の本質的な弱点が、AIで露呈する。だからこそ、AI時代に組織設計の質が問われるんです。
ルールの設計こそ、経営者の中核業務
前記事「能動ルール」と、今回の「ハードブロック」を通じて伝えたいのは、ルールの設計こそ経営者の中核業務だということです。
経営者は数字を見る人、戦略を考える人、人材を育てる人——色々な役割があります。でも、組織が再現性を持って機能するための仕組みを設計する役割は、経営者にしかできません。現場の社員は、与えられたルールの中で最大限のパフォーマンスを出そうとしますが、ルールそのものを設計する権限を持つのは経営者だけです。
ルールの設計を雑にしている経営者は、現場に「気をつけて」と言い続けるだけで、組織が一向に進化しない状態に陥ります。逆に、ルールの設計を中核業務として位置付ける経営者は、組織が自動的に正しい行動を生み出す状態に進化していきます。
「うちの組織はルールが守られない」と感じている経営者は、ぜひ自社のルールを4段階の強度で見直してみてください。レベル1や2で運用しているはずの重要業務が、本当はレベル3や4にあるべきだったと気づくはずです。
そして、最低でもひとつ、ハードブロックを実装してみることをおすすめします。最初は摩擦があります。でも、それを乗り越えた先に、「気をつけます」が組織から消える瞬間が来ます。それは、経営者として最も達成感のある体験のひとつだと思っています。
ルールを守る組織を作るのではなく、守らないことが構造的に不可能な組織を作る。これが、AI時代の組織設計の最終形です。
関連記事
この記事のテーマに合うサービス：業務フロー自動化
スプレッドシート・メール・Slackの往復を、自動化で終わらせる
