違和感を感じた時、言語化できないのは自分の責任だと人類は思いがち。
でもそれって、本当にそうなのか？

いろんな現場でいろんな人と作業してきたけど、
最近になって言語化できないの「俺悪くなくない？」って思うようになってきたんだよね。

まぁもちろん、ある程度の言語化は必要。
自分が理解してるのは当然であるようなことはそれはそうかも知れない。

たとえばこんなケース。

違和感1：抽象度の不一致の例

💭 違和感
この処理、なんか読みにくい。
でも、どこが読みにくいのかうまく言えない。

🧭 整理できる点

• 「読みにくい」をそのまま出さない
• 抽象度の不一致や責務の混在として分解できる。

🧘 違和感が整理された問
この処理は「ユーザーごとの表示可否を判定する」ことが目的だと理解しています。
ただ、現在はデータ取得・条件判定・レスポンス整形が同じ箇所にまとまっていて、どこが表示可否の判断なのか追いづらく見えました。

今後条件が増えるなら、判定部分だけ切り出した方が変更しやすいか確認したいです。

---

違和感2：目的、トレードオフの未整理の例

💭 違和感
この機能、そこまで複雑な設計にする必要ある？
なんか大げさに見える。

🧭 整理できる点

• 目的とのズレとトレードオフ未整理として整理できる。
• 得られるメリットに対して複雑さが見合うか？に変換する。

🧘 違和感が整理された問
この設計は、将来の拡張に備えることが目的だと理解しています。

一方で、今回の要件に対しては抽象化の層が多く、
初期実装と保守のコストがやや大きく見えました。

現時点で想定している拡張パターンがあるのか、
それとも今回はシンプルに始める方がよいのか確認したいです。

---

違和感3：テストの目的と担保範囲の不明瞭さ

💭 違和感
このテスト、書いてあるけど何を守りたいのかよく分からない。
実装の形だけ確認してるように見える。

🧭 整理できる点

• 目的とのズレ。
• 何のためにテストをするのかを考えて、このテストが担保したい振る舞いは何か？に変換する。

🧘 違和感が整理された問
このテストは回帰防止を目的としている理解です。
ただ、現在の内容は内部実装の呼び出し方を確認していて、
ユーザーに見える振る舞いが壊れたときに検知できるかが少し気になりました。
このテストで固定したい仕様や振る舞いを確認したいです。

---

なるほど。まぁ確かにこの辺は、気遣いや配慮のレベルだよね。
相手も人間だし、相手に分かりやすい言葉で伝えるべきであるという命題は真だ。
そうあって欲しいと俺も思う。

でもさ、さすがに配慮だけだと厳しいケースもあるよね。

---

業務運用上の前提とのズレ

💭 違和感

仕様が要件に対して間違っていない。
ただ、実際に現場で使うとかなり運用しづらそうに見える。

👁 自分が持っている認識

• 通常ケースを中心に組み立てられているように見えている
• 実際の運用で発生する例外対応や確認作業まで含めると、現場側の負荷が大きくなりそう

🧩 相手が持っている認識

• 現場ではそこまで例外が多くない
• 運用よりも仕様の一貫性を優先したい

---

この違和感を、自分だけで整理して具体的な問にするのは難しい

• 違和感を持つ側が見えているのは「仕様」と「自分が想像できる運用」まで
• 相手側が見ている実際の運用頻度、例外ケース、体制

これを無理に問いの形にしようとすると

• 自分が持っていない情報を想像で埋めないといけない
• 想像で穴埋めした問いが労力の割に全然違ったものになってしまうリスク
• 想像での補完そのものに時間がかかる

という点で難しいし、ぶっちゃけめんどくさい。
それでも作成する？Slackに論文めいた投稿しちゃうの？
それはそれで良いチャレンジだとは思うけどさ。

ただ、こんな難しいチャレンジができる人なら対話した方が絶対いい。

🤝 この違和感で対話した方が良い点

• 実際の運用でどの程度の例外対応が発生する想定なのか
• その負荷を誰がどのように吸収する前提になっているのか

これを対話できる現場は健全だと思います！
日本中の開発現場がこうであることを祈る。
そうじゃないなら、経済産業省にでもパブコメ打ちに行こうぜ。
募集してるか知らないけど。

---

そもそも違和感の発生源って何？

で、今回はこれを考えてみたかった。

• 目の前の説明や実装から読み取れること
• 自分が理解している目的・前提・期待

「期待されているもの」と「見えているもの」のズレかなと思う。
以上。めっちゃ単純だった。

---

違和感ってどういう現象なの？

ズレなのは分かったけど、違和感ってどう扱うんだ？

• 「期待されているもの」は、設計者の意図、運用上の制約、業務の前提といった、相手側の枠組みに支えられている
• 「見えているもの」は、自分の経験や知識から組み立てた、自分側の枠組みに支えられている

違和感は、この二つの枠組みが食い違っているという信号と捉えることで
ただの面倒な感覚ではなく、良い設計の入口になるんじゃないかな。

• 自分の理解が足りないのか
• 設計の前提条件が足りないのか
• 両方とも妥当だが、優先軸が違うのか

2つの枠組みが食い違っている可能性があるのに、自分の枠組みで判断する必要なんかない。
と思ってしまいたい自分がいる。

人間は対象をそのまま見ているのではなく、自分の持っている分類や判断を通じた枠組みで対象を見ている（超越論的観念論）
つまり違和感が、自分と相手の枠組みのズレであるならば

• 自分は自分の枠組みを通してしか対象を見られない
• 相手も同じく、相手の枠組みを通してしか対象を見ていない

対象そのものを見ているつもりで、実際にはそれぞれの枠組みを通して対象を解釈している。
お互いの枠組みを並べて、すり合わせる機会を作ることが違和感の価値かなと思いました。

現実は、権威だったり、圧力だったり、分断だったりで上手くいかないのかも知れない。
ただ、相手も良いものを作りたいという目的は同じはず。
こうやってソフトウェアは作っていくのが本来的で良いと思う。
対話に障害がなくなれば日本にもシリコンバレーができる日が来るんじゃないですかね。

知らんけど。