Day 88 コントロールが多すぎる組織は、なぜ疲弊するのか　Why Over-Controlled Organizations Burn Out

サイバー判断力によるヒューマン・ハードニング

» 2026/01/25

[シリーズ構造] 柱F｜判断はどこで起きるのか
過剰なコントロールが失敗するのは、人が怠慢だからではありません。プレッシャーの下で摩擦が増え、抜け道が合理化され、判断が曇るからです。現実の業務と噛み合わない統制は、人を疲弊させながら、かえってリスクを高めます。必要なのは数ではなく、圧力下でも機能する設計です。

▶ シリーズ全体マップ： 人間のしなやかさ ― サイバー判断力のために

▶ 柱F｜リスクとガバナンス 関連記事：

• Day 81｜リスクを語れる共通言語をつくる
• Day 82｜ネガティブリスクとポジティブリスク ― 不確実性の両面を統治する
• Day 83｜サイバーリスクの構造化 ― 「気になる話」を比べられるシナリオに変える
• Day 84｜リスク・トレランスという境界線 ― 限界が重要な理由
• Day 85 | リスク許容度とは何か ―判断を本当に変える問い
• Day 86 | 判断はどこで起きるのか ― リスクが行動に変わる瞬間
• Day 87 | 良いコントロール／悪いコントロール
• Day 88 | コントロールが多すぎる組織は、なぜ疲弊するのか

コントロールが多すぎる組織は、なぜ疲弊するのか

～どこまでが十分で、どこからが過剰なのか。その間にあるバランス～

多くの組織は、自分たちを息苦しくしようとしているわけではありません。

安全でありたい。
説明責任を果たしたい。
もう二度と、「想定外」に振り回されたくない。

そう思って、コントロールを足します。
さらに足します。
そして、ある日、ふと気づく。

紙の上では「よく統制された組織」なのに、現実では、ひどく疲れ切っている。

ここに、ひとつの逆説があります。
コントロールは、重くなりすぎると、コントロールでなくなる。

摩擦になります。
そして、摩擦は、静かに人の行動を変えていきます。

今日は、その失敗の型を扱います。
コントロールの量が、組織疲労へと変わるとき。
そして、なぜその疲労が、気づかれないままリスクを増やしていくのか。

コントロールが増えると、摩擦が仕事を圧迫し始める

コントロールには、必ずコストがあります。良いコントロールであっても、例外ではありません。

時間。
クリック。
承認。
証跡の収集。
会議。
待ち時間。
コンテキストの切り替え。

一つひとつは、耐えられます。
でも、積み重なると、それが一日の大半になります。

ある密度を超えると、コントロールは「ガードレール」ではなくなります。

道そのものになる。

すると、システムは人に、こう迫ります。
スピードを落とすか。
それとも、迂回するか。

この「迂回」は、モラルの問題ではありません。構造上、そうならざるを得ないのです。

正規のやり方では、実際の仕事量・スピード・締切に耐えられなくなったとき、人は必ず別のやり方を探す。こうして、過剰なコントロールは、最初の疲労―運用の引きずりを生みます。

コントロールが多すぎると、判断の質が落ちる

Day 87 で定義したように、良いコントロールとは、判断を、繰り返し可能な行動に変える仕組みでした。

過剰なコントロールは、その逆をします。判断点を、増やしてしまうのです。

• どの承認が必要なのか
• どの例外ルートが「正しい」のか
• 今回は、どの証跡が「十分」なのか
• 誰が判断者なのか
• ポリシーが衝突したとき、どれが優先されるのか

その結果として生まれるのは、確実性ではありません。判断の霧です。

この霧が、納期や現場の圧力と出会うと、起きることは、だいたい決まっています。

人は、「リスクを下げる」ことよりも、「とにかく通す」ことを最適化し始める。

この瞬間、コントロールは演劇になります。

人が不誠実だからではありません。システムそのものが、「結果を変えること」より
「プロセスを通過すること」を学習させてしまったからです。

過剰なコントロールは「例外自己増殖」を生む

コントロールが、実際の業務スピードに合っていないとき、組織は、例外で調整し始めます。

最初は、本当に特殊なケースだけ。けれど、コントロールは増え続け、業務のテンポは変わらない。

やがて、例外が当たり前になります。

こうして生まれるのが、いわば、例外で回る組織です。

• 例外が増える
• レビュー担当が詰まる
• 詰まりを解消するため、形式的な承認が増える
• 形式承認が常態化し、ゲートが機能しなくなる
• 機能しないことを理由に、さらにコントロールが追加される

このループは、自己強化します。

コントロールの量が、それ自体を正当化し始める。

そして、実際に効いている「統制」は、また非公式なものへと戻っていく。

誰が通せるか。
誰がサインできるか。
誰が「なかったこと」にできるか。

それは、統制ではありません。社会的ルーティングです。

リスクの反転

コントロールを増やすほど、危険になるとき

Day 88 の中核となる主張は、これです。

ある閾値を超えると、追加されたコントロールは、残余リスクを増やす。

なぜなら、それが引き起こすのは、

• さらなる迂回
• レビューされない回避策
• シャドーシステム
• 記録されない緊急アクセス
• 期限の切られない「一時的」例外

そして、最も深刻なのは、現実を検知する力が落ちていくことです。

人は、実態ではなく、整った証跡を作ることに熟達していく。

システムは、外を測らなくなる。自分自身を測り始める。

音量は上がる。でも、視界は、まったくクリアにならない。

「適正なコントロール」とは、少なさではない

では、ちょうどよい量とは何か。

最小でもない。
最大でもない。
他社の監査ファイルを、そのまま写すことでもない。

適正なコントロールとは、

• 頻度が高い行為は、低摩擦でなければならない（できれば自動化）
  　毎日起きることを、気合や書類で統治してはいけない。設計で統治する。
• インパクトが大きい行為は、強いゲートが必要
  　致命的な下振れがあるなら、制約された経路、強制された既定値、期限付き権限、自動ログ、必須レビュー。
• 例外は、高く、そして見えるものでなければならない
  　道徳的に高いのではない。運用的に高い。間違ったことを、静かにできてはいけない。

ここで、フレームワークが意味を持ちます。コントロールの一覧としてではなく、調整と適用性を議論するための道具として。

ISO 27001 の適用宣言書（SoA）は、どのコントロールが、なぜ必要なのかを、リスクと結びつけて説明するためのものです。

「多いほど成熟している」という発想への、明確な否定。

NIST が、コントロールベースラインにテーラリングを前提としているのも、システムは文書ではなく、あなたの環境そのものだからです。

締め

過剰なコントロールは、人の規律が足りないから失敗するのではありません。

プレッシャーの中で、システムがインセンティブを変えてしまうからです。

摩擦を増やし、迂回を合理的にし、判断を霧に変え、例外を常態にする。

良いコントロールは、「多さ」ではありません。

止めるべきものを、組織を疲弊させることなく止められること。

明日は、いちばん難しいところへ進みます。そのバランス点を、どう見つけるのか。
過剰にも、不足にもならず、プレッシャーの中でも崩れないコントロールを、どう設計するのか。

それでは、また明日。

――――

[Series Structure] Pillar F | Where Judgment Happens
Over-control does not fail because people lack discipline. It fails because, under pressure, friction rises, workarounds become rational, and judgment degrades.
When controls multiply without regard to how work actually happens, organizations exhaust their people while increasing residual risk. Effective control is not about more rules, but about design that holds under pressure.

▶ Series overview: Series Overview -- Human Flexibility for Cyber Judgment

▶ Other posts in Pillar F (Risk & Governance):

• Day 81 | Building a Shared Language for Risk
• Day 82 | Negative vs. Positive Cyber Risk -- Governing Both Sides of Uncertainty
• Day 83 | Structuring Cyber Risk -- Turning Concerns into Comparable Scenarios
• Day 84 | Risk Tolerance as a Boundary -- Why Limits Matter
• Day 85 | Defining Risk Tolerance -- The Questions That Actually Change Decisions
• Day 86 | Where Judgment Happens ー When Risk Turns into Action
• Day 87 | Good Controls / Bad Controls
• Day 88 | Why Over-Controlled Organizations Burn Out

Too Much Control: Why Over-Controlled Organizations Burn Out

(How much is enough, when it becomes too much, and the art of balance in between)

Most organizations don't set out to suffocate themselves.

They set out to be safe.
They set out to be accountable.
They set out to never be surprised again.

So they add controls.

And add controls.

And then one day, the organization is "well-controlled" on paper--and exhausted in reality.

This is the paradox: control can be so heavy that it stops being a control.
It becomes friction. And friction changes behavior.

Today is about that failure mode: when control volume turns into organizational fatigue--and why that fatigue quietly increases risk.

When controls multiply, friction starts eating the work

A control always has a cost. Even a good one.

The cost might be time, clicks, approvals, evidence collection, meetings, waiting, context switching.

Individually it's tolerable. Collectively it becomes the day.

At a certain density, controls stop being "guardrails."
They become the road.

And then the system makes a simple demand:

Either you slow down, or you route around it.

That routing-around is not moral failure. It's physics.
When the official path can't carry the required flow, bypasses appear.

That's how over-control creates the first kind of fatigue: operational drag.

Too many controls produce the wrong kind of decision-making

Day 87 defined good controls as mechanisms that turn judgment into repeatable action.

Over-control does the opposite.

It multiplies judgment points:

• Which approval applies here?
• Which exception path is "allowed"?
• Which evidence is "acceptable" this time?
• Which team owns the decision?
• Which policy wins when two policies conflict?

The result is not more certainty.
It's decision fog.

And when decision fog meets delivery pressure, something predictable happens:

People stop optimizing for "risk reduction."
They start optimizing for "getting through."

That's the moment when control becomes theater.

Not because people are dishonest--
but because the system has trained them that passing the process matters more than changing the outcome.

Over-control creates an "exception economy"

If controls are too strict for the actual operating tempo, the organization compensates with exceptions.

At first, exceptions are rare--used for real edge cases.
Then controls expand. Tempo stays the same.
So exceptions become normal.

Now you get the exception economy:

• Exceptions increase → reviewers become a bottleneck
• Bottlenecks increase → reviewers rubber-stamp to keep flow moving
• Rubber-stamping increases → gates stop being gates
• Gates stop being gates → leadership adds more controls
• More controls → more exceptions

This loop self-reinforces.
Control volume becomes self-justifying.

And the real, lived "control" becomes informal again:
"Who can get it approved?"
"Who can sign?"
"Who can make it go away?"

That's not a control system.
That's social routing.

The risk inversion: when more control makes you less safe

Here is the core academic claim of Day 88:

Past a threshold, additional controls increase residual risk.

Because they trigger:

• more bypassing,
• more unreviewed workarounds,
• more shadow systems,
• more undocumented emergency access,
• more "temporary" exceptions that never expire.

And most importantly:

They reduce the organization's ability to detect reality, because everyone gets good at producing compliance artifacts.

In other words: the system starts measuring itself.
It gets louder, not clearer.

"Right-sized control" is not less control. It's better geometry.

So what is the right amount?

Not minimal.
Not maximal.
Not "best practice" copied from someone else's audit binder.

Right-sized control means:

• High-frequency actions must be low-friction (or automated).
  If a thing happens every day, you cannot govern it with heroism and paperwork. You must govern it with design.
• High-impact actions must be hard-gated.
  If the downside is catastrophic, the control must be structural: constrained paths, enforced defaults, time-bounded privilege, auto-logging, mandatory review.
• Exceptions must be expensive and visible.
  Not morally expensive--operationally expensive.
  You should never be able to "quietly" do the wrong thing.

This is where formal frameworks become useful--not as a list of controls, but as an argument for tailoring and applicability.

For example, ISO 27001's "Statement of Applicability" exists to document which controls apply (and why), linking control selection to risk--rather than treating "more controls" as automatic progress.

And NIST's concept of tailoring control baselines exists because a baseline is not the system--your environment is.

Closing

Over-control doesn't fail because people lack discipline.
It fails because it changes the system's incentives under pressure.

It creates friction until bypassing becomes rational.
It creates decision fog until passing matters more than reducing risk.
It creates an exception economy until the gate is no longer a gate.

Good control is not "more."
Good control is the ability to stop what must be stopped--without exhausting the organization into workarounds.

Tomorrow, we'll do the hard part:
how to locate the balance point--how much control is enough, when it becomes too much, and how to design controls that hold under pressure without turning the organization into sludge.

References　参照・出典・参照文献

Dennis Henry. (2025, March 2). The Security Friction Quotient -- When Strong Security Backfires. Medium. https://medium.com/@dennishenry/the-security-friction-quotient-when-strong-security-backfires-9765a8a4c2cd

National Institute of Standards and Technology. (2020, September). SP 800-53B: Control baselines for information systems and organizations (includes updates as of December 10, 2020). https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final

OneTrust. (n.d.). What is Statement of Applicability? https://www.onetrust.com/blog/what-is-statement-of-applicability/