「全然やってくれない」の正体。報告者の“断定”に騙されないアーキテクトのコマンド

バグの構造解析

2026.10.09

「全然やってくれない」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よくある場面

先日、パートナーが周囲にこうこぼしていました。

「うちの人は、育児を全然やってくれないんです」

これを聞いて、私のシステム（脳）はバグを起こしそうになりました。

なぜなら、私は仕事をしながら食事を作り、哺乳瓶を洗い、おむつ替えも寝かしつけも担当し、休日には離乳食までやっているからです。

パートナーの基準からすれば「足りない」のかもしれませんが、この稼働ログを見て「全然やっていない（ゼロである）」と表現されるのには、強烈な違和感がありました。

実はこれと全く同じバグが、ビジネスの現場、それもシステム運用やプロジェクト管理のど真ん中で頻発しています。

「サーバーがダウンしました！大惨事です！」と部下が騒ぐので、PMが青ざめて確認すると、単にその部下のPCのWi-Fi接続が切れていただけだった。

「Excelが壊れました！動きません！」と大騒ぎするから画面を見に行くと、「変更を保存しますか？」という普通のポップアップが出ているだけだった。冗談のような本当の話です。

ここで起きているエラーの正体は何でしょうか？

報告者が意図的に事実を歪曲して嘘をついているわけではありません。

本当の課題は、「事象の断定」と「解像度の低さによる言語化不足」です。

育児の例に戻りましょう。「全然やってくれない」という言葉から、聞き手（第三者）が受け取る事実は「育児のコミット量が数学的に0である」という状態です。

しかし真実は、「全くやっていないわけではない（20〜30はやっている）が、私の求める基準（100）を満たしていない」です。

報告者は「私の基準を満たしていない」と言語化する労力をサボり、「全然やっていない」と断定して逃げているのです。

日本語の「全然」は0を意味しません。「自分の基準を下回っている」という主観（解釈）です。

この「基準（閾値）」が一律ではないため、第三者が「0」だと受け取れば「なんて酷い夫だ、離婚しろ」という最悪のエラー対応になりますし、「20はやっている」と正確な事実が伝わっていれば「仕事もしてるのに、そこまでやってくれるなんて良い人じゃないか」という真逆の出力（評価）になります。

Excelの例も同じです。「自分の意図した通りに動かない（解釈）」を「壊れた（断定）」に変換して報告してくるから、システム障害だと誤認するのです。ただ一言、「『保存しますか？』という画面が出て止まっています」という【事実】を言語化してくれれば、「『はい』を押せば閉じますよ」の1秒で解決します。

では、なぜ彼らは事実をありのままに言語化できないのでしょうか？

それは、彼らの「事象に対する解像度が極端に低いから」です。

野球を例にしましょう。

無死一塁で、攻撃側が「ランエンドヒット」を仕掛けたとします。

野球を知らない人（解像度が低い人）のフィルターを通すと、こう報告されます。

「ランナーが盗塁して、バッターは空振りした。でも盗塁は成功したから、この作戦は『大成功』です！」

しかし、野球に詳しい人（解像度が高い人）が見ればこうなります。

「ランエンドヒットのサインでバッターが空振りした。結果的に塁は進んだが、ランエンドヒットという戦術としては『失敗』である」

解像度によって、「成功」と「失敗」という正反対の断定が生まれます。

物事の構造を理解していない人（QA層）は、目の前で起きている事象を正確に記述（言語化）できないため、自分の乏しい語彙の中から「大クレームです」「壊れました」「全然ダメです」という【極端な断定（解釈）】のラベルを貼り付けて投げてくるのです。

この「汚染されたログ（報告）」をそのまま受け取ると、組織は致命的な誤作動を起こします。では、PMはこの断定的なエラー報告から、どうやって「真の事実（ファクト）」だけを抽出（デバッグ）すればよいのでしょうか。

ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。

『FACTFULNESS』（ハンス・ロスリング他）
思い込みや大げさな表現に振り回されず、事実の解像度を上げて見る習慣が身につく。