認知の設計図 #8|“しくみのスキマ”という前提:見えない条件を読み解く
人が動くとき、そこには必ず「前提」があります。
明文化されていなくても、誰かが明確にルールとして決めたわけでなくても、そこに「あることになっている」もの。
行動の裏側でひっそりと息を潜め、私たちの方向や優先順位を無意識のうちに決定づけている見えない構造。
それが、このシリーズで扱ってきた「認知のOS」であり、組織という生き物が持つ「巨大なOS」でもあります。
そして、システムと人、あるいは人と人のあいだに広がる、説明されないまま残された「スキマ」。
このスキマこそが、人や組織の動き、そして私たちが日々直面するもどかしさを最もよく表す場所なのかもしれません。
今回は、その「スキマ」を読み解く視点について、少し解像度を上げながら、静かにまとめてみようと思います。
スキマとは、「言葉になっていない前提」のこと
人が何かに躓くとき、そこには必ず「前提条件のズレ」が存在しています。
たとえば、日々の職場でこんな光景を目にしたことはないでしょうか。
ミスを報告しない新人。
指示が曖昧なままプロジェクトを進めようとする上司。
会議で時間をかけて話し合ったはずなのに、いざ実務になると説明が噛み合わないチーム。
現場に新しいシステムを導入したのに、いつの間にか元の複雑なExcelでの管理に戻ってしまう部署。
良かれと思って導入されたはずのデジタル化が、かえって現場の業務を圧迫し、期待と成果がすれ違っていく現象。
これらを表面的な出来事としてだけ見れば、「現場のやる気が足りない」「個人のスキルが不足している」「コミュニケーションが足りていない」という、分かりやすく、そして誰も傷つかない説明がついてしまいます。
しかし、その手前には必ず、「説明されていない仕組み」が横たわっています。
この組織で、本当は何が一番大事にされているのか。
誰が、どんな評価基準や利害を優先して動いているのか。
何を言うと空気を乱すとみなされ、嫌われるのか。
どこまでが自分の責任範囲という安全地帯で、どこからが他人の領域という危険地帯なのか。
答えのある問題(タイプⅠ)を解こうとしているのか、まだ誰も答えを知らない問題(タイプⅡ)を解こうとしているのか。
これらを、私たちは何を「当然」として扱っているのか。
こうした前提の断片が繋がり、組織の文脈として機能し始めたとき、はじめて人の行動は「理由」を持ちます。
OSは、個人の悪意や意図から生まれるのではなく、この目に見えない「前提」の蓄積から生まれます。
スキマとは、まさにその前提が露わになる場所なのです。
スキマが見えると、現象は違う形に見えてくる
スキマを読むとは、目の前で起きている現象に「奥行き」を与える行為です。
たとえば、新しいシステムの導入が進まず、旧態依然とした業務フローが残り続けているプロジェクトがあるとします。
表層だけを切り取れば、「現場のITリテラシーが低い」「推進リーダーの管理不足」「ベンダーとのコミュニケーションの問題」といった要因が並べられるでしょう。
でも、業務設計者の視点でその「スキマ」を覗き込むと、全く別の景色が浮かび上がってきます。
実は、現場には「失敗を避ける文化」が根強く、新しいツールでミスを犯せば減点されるという恐怖がある。
上層部には「反対意見を言うと和を乱す」とみなされる空気が漂っており、曖昧さを残しておく方が組織内で安全に生き残れる。
期限や効率よりも、これまでの関係性や「阿吽の呼吸」を優先する空気が、部署間に深く根付いている。
そもそも、新しい仕組みを入れる目的や役割の線引きが曖昧なまま、手段だけが先行して始まってしまった。
現場が手放せない複雑なExcelは、単なる抵抗ではなく、システムが拾いきれなかった現場の例外処理や微細なニュアンスを補完するための「悲鳴の結晶」であった。
こうした「前提OS」が複雑に絡み合うとき、システム導入の遅延や現場の混乱という現象は、単なる事故ではなく「結果としての必然」になります。
スキマを見ることは、「誰が悪いか」を断罪することではありません。
「なぜ、私たちはこうなってしまうのか」という現象の奥に、どういうOSが働いたのかへと、視点をそっと移し替える作業なのです。
認知の設計図を読むとは、現象の“手前”を見ること
これまでのシリーズで扱ってきた、成果OS、承認OS、同調OS、評価OS、組織OS。
これらはどれも単体でポツンと存在しているわけではなく、日々の現象の手前にある「条件」として、静かに、しかし確実に働いています。
認知の設計図を読むとは、その見えない条件をそっと照らし出すことです。
なぜ、彼にとってその非効率に見える行動が「合理的」だったのか。
なぜ、あの会議での沈黙や先送りの判断が、彼らにとっては「当然」に見えたのか。
なぜ、新しいスキルやツールを持ち込んでも、古い土壌との間の摩擦が「避けられなかった」のか。
そこには必ずOSがあり、スキマがあり、前提があります。
「結果としての行動」を責めるのではなく、その行動を引き起こした「前提」を見る。
それが、業務でもITでもない狭間に立つ、業務設計者に近い視点なのだと思います。
スキマに気づくだけで、人は動きやすくなる
前提条件は、無理に指摘して暴き立てる必要はありません。
ましてや、「あなたの前提は間違っている」と正論で正す必要もありません。
ただ、「ああ、そういう前提で動いていたのか」と気づくだけでいいのだと思います。
自分や他人が囚われている前提を理解すると、人は少しだけ自由度を取り戻すことができます。
自分はなぜ、あの場面でそう判断してしまったのか。
なぜ、あの些細な言葉に強く反応してしまったのか。
なぜ、相手はあの冷たい言葉を選ばざるを得なかったのか。
なぜ、この組織はいつも同じような問題で立ち止まるのか。
こうした問いに対して、正解を急がず「余白」を持って向き合えるようになると、重くのしかかっていたOSの働きは急に軽くなります。
相手を自分の思い通りに変えるためではなく、「自分のOSを少しだけ整え、相手との距離感を測り直すため」の行為。
それが、スキマを見るということなのかもしれません。
おわりに:認知の設計図は「観察の道具」である
認知の設計図は、人を優秀か無能か、あるいは保守的か革新的かで分類し、レッテルを貼るためのものではありません。
OSは単なる「クセ」であり、スキマは組織が呼吸するための「余白」であり、前提は私たちが生きている「背景」です。
目に見えないそれらをそっと観察することで、これまで不条理に思えていた行動の意味が、少しだけ違う形で見えてきます。
世界は、声高に説明されたルールや計画よりも、説明されていない静かな前提で動いている。
もしそう思えたなら、自分のOSも、他者のOSも、少しだけ扱いやすくなる気がします。
そして、その理解と受容こそが、「しくみのスキマ」を読むということの、最も近い姿なのかもしれません。
読んでおきたい関連記事
この「見えない前提」や「構造」について、さらに思考を深めたい方へ。 しくみのスキマを読み解くための、観察の道具となる記事をご案内します。
層Ⅰ:しくみの“哲学”を問う
なぜ話は通じているのに、仕事はズレていくのか─ マネジメントやDXが空回りする本当の理由
相手の能力不足ではなく、お互いが持っている「辞書(スキーマ)」の違いがズレを生む構造について解説しています。現象の手前にある前提を知るための第一歩です。
業務設計者論|しくみの狭間に立つ設計者のまなざし
ITと現場業務の断絶を埋める職能として、どのように現象を観察し、構造を翻訳していくのか。設計者としての立ち位置を言語化した記事です。
層Ⅱ:しくみの“構造”を設計する
ズレの正体 #4|ズレは“立場の重力”から生まれる
人が分かり合えないのは性格のせいではなく、役割がもたらす「引力」が違うから。前提条件がどのように作られるのか、その物理的な力学について。
ズレの正体 #2|合意形成の核心は“共同注意”にある
同じものを見ているつもりでも、見えている景色が全く違う。前提を共有するための「共同注意」という概念について掘り下げています。
層Ⅲ:しくみの“思考”を設計する
認知の設計図 #6|“視座”が変わると、同じ世界が違って見える
どこから物事を見るかによって、前提条件は180度変わります。他者のOSを理解し、自分のOSを整えるための視点の切り替え方について。
