「わかった」はたぶん分かっていない。暗黙のデフォルト値への依存と、優先順位の権限設計

① 言語化のバグ

2026.10.30 2026.10.20

※本記事にはプロモーション（広告）が含まれています。

「わかった」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よくある場面

「洗濯物、やっておいて」
「わかった」

パートナーからの依頼を受け、私は目の前にある「洗い上がった洗濯物の山」に手を伸ばし、自分なりに丁寧に畳み始めました。

しかし数時間後、パートナーが叫びます。

「洗濯物頼んだのに、やってないじゃん！」
「いや、ちゃんと畳んでおいたよ」
「そうじゃなくて、洗濯機を『回す』のを頼んだんだけど！」

ビジネスの現場でも毎日発生している悲劇です。

PMが「これ、やっておいて」と依頼し、部下が「わかりました！」と元気よく返事をしたのに、納期に出てきたものは全くの別物（フォーマット違い・粒度違い）だった、というバグ。システム間で言えば、「API（インターフェース）の仕様不一致」です。

なぜ、私たちは詳細な仕様を確認せずに「わかった」と処理を進めてしまうのでしょうか。

それは、相手の言語化能力への過剰な期待と、自分の脳内にある「暗黙のデフォルト値」への依存があるからです。

受信側（私）のOSはこう解釈しました。

「普通に考えれば、目の前に洗い上がった山があるのだから『畳む』という処理がデフォルトだろう。もし『回す』というイレギュラーな処理なら、別の注記パラメータが来るはずだ」

発注側（パートナー）のOSにもバグがあります。「価値観が同じ（同じ家に住んでいる）なのだから、いちいち明言しなくても文脈で伝わるだろう」という、相手のエスパー能力への過剰な信頼です。

我が家ではこのクラッシュを経て、今では「最優先で洗濯機を回しておいて」と、明確な動詞と優先順位のパラメータが飛んでくるようになりました。

かつての私は、こうした指示に対して「なぜそれが最優先なのか（天気が良いから外に干したい等）」という背景（Why）まで説明してほしいと不満を抱いていました。「急ぎで」とだけ言われても、自分が今やっている作業をなぜ中断しなければならないのか納得できなかったからです。

しかし、アーキテクトの視点で自己デバッグを行い、気づきました。

私が「Why」を求めていたのは、相手の指示に納得するためではなく、「タスクの優先順位を決めるスケジューラーの権限」を自分が握りたかったからです。

最終的に論理的な優先順位が最適化されるのであれば、その権限は必ずしも自分が持つ必要はありません。実行者（私）がすべてのタスクにおいて「優先順位の決定権限」まで巻き取ろうとするのは、システムの負荷として明らかに「Too Much（越権行為）」です。

では、組織のアーキテクト（PM）は、どのように要件を定義し、実行者に「Why（背景）を説明せずとも、即座に割り込み処理を実行させる」ためのシステムを構築すればよいのでしょうか？

「やっておいて」「いい感じにして」のような指示では、受け手は自分の頭の中の「暗黙のデフォルト値」で中身を補ってしまいます。「わかった」と返ってきても、わかっている中身が違うのはこのためです。

何をするか（動詞）、どんな形で出すか（フォーマット）、いつまでか。この3つを指示の必須項目にするだけで、解釈のズレは大きく減ります。

ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。

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

『1分で話せ』（伊藤羊一）
相手に「伝わる」ための要点の絞り方と構成を学べる一冊。指示の“仕様”を相手の頭に正しく届ける土台になります。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp