一言でいうと： 良い設計は、使っていることを忘れさせる。悪い設計は、ユーザーに「なんで？」と言わせて自己紹介してくる。
0. 5秒で結論
ある対戦ゲームで、上位ランクに上がった平日の昼、対戦相手がなかなか見つからなかった。人口が少ないこと自体は仕方ない。だが、見つからないたびに人間が再試行を押す必要があると話が変わる。
対戦ゲームなのに、対戦相手より先にUIと戦っている。
ここから出てくる原則が、対戦以外で戦わせるなである。これはゲームだけでなく、サービス、職場、制度、店、ウェブサイト、人間関係まで広く使える。
人は「普通なら次はこうなる」「この目的なら、この仕組みになるはず」という予測を持つ。現実がそこから外れると「ん？」「なんで？」「なんか変」が出る。この記事では、そのパターンを便宜上構造的不整合の検知と呼ぶ。正式な心理学用語ではなく、予測誤差、期待不一致、処理流暢性、人と環境の適合、期待違反、熟達直感を実務向けに束ねる呼び名だ。
ただし重要なのは、違和感が鳴ったことと、その原因について自分の推理が正しいことは別という点である。違和感は警報。判決ではない。
1. 発端：カードゲームを始めたはずなのに、最初のボスが再試行
ランクが上がる。平日昼で人が少なそう。マッチングする。相手が見つからない。再試行を押す。また見つからない。また押す。何回目だよ。
UIは人間を生成できない。しかし、相手が見つかるまで検索を続ける、自動で再検索する、待機中に別画面を見られる、といった設計は考えられる。
ここで不満は「人がいない」から「なぜ俺が検索係なのか」に変わる。ゲームはカードを選ばせ、読み合いをさせ、勝敗を決めるためのものだ。マッチング再起動係を任命するためではない。
人間をcronにするな。 ゲームを開いたらゲームをさせてほしい。UI運用保守職に応募した覚えはない。
2. 原則：目的外PvEを消せ
一般化すると、ユーザーが達成したい目的とは無関係な摩擦を、ユーザーの仕事にしないとなる。
買い物したいのに会員登録と戦う。予約したいのに空き枠検索と戦う。申請したいのに複数Excelと戦う。仕事を終わらせたいのに承認者を探すゲームをする。自動化したのに毎日「ちゃんと自動で動いたかな」と人間が見張る。会話したいのに相手の謎ルールを毎回解読する。
全部、目的外PvEである。ユーザーは「決済フォーム撃破」の実績解除を求めていない。
良いサービスは、ユーザーの敵を増やさない。
3. 完成度が高いと「特に何も感じない」
良いサービスを使ったとき、人は必ずしも「このUI、神！」とは思わない。自動ドアが普通に開く。決済が普通に終わる。検索したら欲しいものが出る。次の操作が分かる。権限を持つ人が明確。話が普通に通じる。そして終わる。
感想：特になし。
しかし、この「特になし」が強い。処理流暢性の研究では、情報を楽に処理できる感覚が好感、確信、親しみなどの判断に影響しうることが研究されている。サービス研究でも、期待と実際の性能の関係は満足度と密接に関係する。
完成度の高い設計ではシステムが透明になる。反対に低いと、システムが「ここを押せ」「先に戻れ」「理由は言わない」「担当は別部署」と自己紹介を始める。
悪い設計は自己紹介がうるさい。良い設計は存在感を消す。
だから「何も感じなかった」は0点ではない。場合によっては最高得点だ。
4. 違和感を研究の言葉に翻訳する
予測誤差（prediction error）：脳は次を予測し、現実との差を学習に使う。264件の神経画像研究を統合したメタ分析では、報酬・罰・行動・認知・知覚・社会的推論など広い領域でprediction errorが検討された。日常語なら「え、そうなるの？」である。
期待不一致（expectancy disconfirmation）：サービスで期待と実際の経験がズレること。2024年公開のメタ分析は150 records、168の独立研究、58,597人を統合し、期待、知覚された性能、期待不一致、満足度の関係を検討した。性能だけでなく「思っていたのと違う」も効く。
処理流暢性（processing fluency）：読みやすい、見つけやすい、理解しやすい、次が予測しやすい。つまり、ユーザーの脳みそを無料の補助CPUとして使うなという話でもある。
Person–Environment Fit：良い環境は絶対値ではない。人の欲求・能力・価値観と、仕事や組織が要求・提供するものの適合を見る。高級な靴でもサイズが合わなければ痛い。
Expectancy Violations Theory：人は相手、関係、状況、規範から「普通こうする」を予測する。そこから外れると注意が向く。ただし、予想以上に親切など良い期待違反もある。
5. 構造的不整合の5分類
- 目的―手段不整合：「早くしたい」→承認を3つ増やす。「対戦させたい」→再検索を手作業にする。
- 責任―権限不整合：「自分で決めろ」→決めると「勝手に決めるな」。これは権限委譲ではなく地雷原体験学習。
- 発言―行動不整合：「挑戦歓迎」→失敗だけ長く責める。「効率化」→自動化後に手確認を追加。ポスターと現場が別会社。
- 評価―成果不整合：生産性を欲しいのに滞在時間を褒める。品質を上げたいのに不具合報告を減点する。人は成果でなく点数の取り方を最適化する。
- 人間―システム不整合：同じボタン、同じ転記、毎日の起動、異常なし確認を人にやらせる。人間をcronにするな。
6. 違和感センサーの思考フロー
目的を把握 → 普通ならどういう構造か予測 → 現実を見る → 差分を発見 → 「なんで？」 → 原因・基準・責任を調べる → 必要なら仕組みを変える。
違和感が多い人は単に不満が多いとは限らない。目的と実装を無意識に比較している可能性がある。ただし副作用もある。一度「この工程いらなくない？」と見えてしまうと、次から毎回見える。靴の中の小石が散歩全体の主役になる。
世界のUIデバッグモードが解除できない。
7. サービス：UIをボスキャラにするな
見るべきはユーザーの旅にある目的外戦闘だ。同じ情報の再入力、不要な確認、失敗後の手動復帰、戻ると消える入力、分かりにくい主ボタン、原因でなくコードだけのエラー、システムが知っている情報を人に質問すること。
一個一個は小さい。しかし小さい石でも靴の中に入れば、2km後にはレビュー全文が石の話になる。
成熟したサービスは「何を追加するか」だけでなく、「ユーザーが何をもう意識しなくていいか」を考える。
8. 環境：制度のバグを根性でパッチするな
職場では、誰が決めるか不明だからベテランに聞く、完了条件が不明だから空気を読む、データの場所が不明だから詳しい人を探す、例外が文書化されていないから前回担当者を探す、システムがつながっていないからExcelでつなぐ、スケジュールが壊れるから誰かが毎日監視する、ということが起きる。
これで仕事が終わると「問題ない」と見える。違う。人間が制度の不具合をリアルタイムで手動補正しているだけかもしれない。
人が優秀であるほど、壊れた仕組みが長生きすることすらある。最高の現場力が最低の設計を延命する。地獄の相互扶助である。
9. 人：違和感は警報、読心術ではない
人でも、発言と行動が何度も違う、場面でルールが変わる、責任だけ一方向に動く、といった反復パターンは観察対象になる。
ただし「言動に不整合がある」は観察できるが、「だから絶対に悪意がある」は推論である。
分けるべきは、①実際に観察した事実、②自分が予測していたこと、③どこがズレたか、④別の原因仮説、⑤次に何を見れば検証できるか。
違和感は火災報知器であって、放火犯の顔写真ではない。
10. 熟達直感はいつ当たるのか
KahnemanとKleinは2009年、専門家の直感が信頼できる条件を議論した。重要なのは、学習できる規則性が環境にあることと、十分な練習と結果のフィードバックがあることだ。
結果を繰り返し確認できる領域では異常検知が育ちやすい。反対に、結果がほぼ返ってこない、規則が頻繁に変わる、偶然性が強すぎる環境では、経験年数だけで直感が正しいとは言えない。
当たった違和感だけ集めるな。外れた違和感も保存する。脳内レビューサイトで自分の星5だけ表示しない。
11. 違和感を改善に変える
- 目的を書く：本来、何を達成したい？
- 現状を書く：実際には何をさせられている？
- 目的外戦闘を探す：本当に必要？
- なぜ人間がやるか疑う：技術、安全、コスト、規約、レガシー、本当に理由がある？
- 消す・自動化・まとめる・見える化：工程削除、定型判断の自動化、入力や承認の統合、状態・担当・次の行動の明確化。
- 改善後に測る：本来の目的以外を考えた回数は減った？
12. 新しい完成度指標：Why Count（なんで？回数）
一回の利用で「なんでこれ押すの？」「なんでまた入力？」「なんでこの人に聞くの？」「なんで俺が確認？」「なんでこのルール？」と思った回数を数える。
0回：設計が透明。かなり強い。 1〜2回：良好。 3〜5回：システムが自己主張し始める。 6回以上：ユーザーが製品ではなく運用保守を体験している。
正式な学術尺度ではない。しかし改善会議では、「満足度4.2」より「予約まで平均3.4回なんで？が出る」のほうが直す場所を見つけやすい。
13. 「普通」は最高級品
自動ドアは開いて当然。電気はついて当然。検索は見つかって当然。決済は終わって当然。職場では担当者が分かって当然。人間関係では最低限、毎回ルール解析しなくていいのが当然。
だから完成度が高いものほど「普通でした」で終わる。しかし、その普通の裏には大量の例外処理、テスト、設計判断、運用改善がある。
最高の設計は、努力の跡をユーザーに見せない。 レストランで「今日も厨房が燃えませんでした！」と報告しない。普通に飯が出てくる。それが強い。
14. 結論：良い設計は消える
違和感は、世界が悪い証拠でも自分が正しい証拠でもない。まずは頭の中の予測モデルと現実に差があるという通知だ。
違和感 → 事実と解釈を分ける → ズレを分類 → 原因を検証 → 不要な摩擦を消す → もう「なんで？」と思わない。
ゲームなら相手とだけ戦える。サービスなら目的だけ達成できる。職場なら仕事そのものに集中できる。人間関係なら毎回ルール解析をしなくて済む。
最後の評価は地味かもしれない。
「別に、普通だった。」
その「普通」は、設計者にとってかなりの褒め言葉である。
対戦以外で戦わせるな。仕事以外で仕事させるな。生活以外で運用保守させるな。そしてユーザーを、あなたのシステムの無料デバッガーにするな。
