3行まとめ
- 「好みの問題」は思考停止のサイン
- 「好みの問題」が逃げ道になる理由は心理的負荷と言語化スキル不足
- 「好みの問題」を議論の終着点ではなく議論の出発点にしよう
はじめに
あなた：「ここは〇〇とした方がいいと思う」
相手：「いや、私は△△の方がいいと思う」
あなた：「コードの可読性を踏まえると、〇〇の方がいいと思う」
相手：「△△でも読みやすいから好みの問題だと思う」
チームで何かを決めるときやレビューの場面で、こうしたやり取りを見聞きしたことがある人は多いのではないでしょうか。特に設計の方向性やコードスタイル、UIデザインのように絶対的な正解が存在しないテーマでは、話し合いが平行線になりやすいです。そうしたとき「好みの問題」という言葉は便利な逃げ道になります。誰の意見も否定しないし、場の空気も壊さない、とりあえず会話を終わらせるにはちょうどいい言葉のように感じます。
しかし、私はこの「好みの問題」という言葉に強い違和感を持っています。なぜなら、それは思考を止める言葉だと感じるからです。私自身、過去実際に設計方針を「好みの問題」だからと深掘りせずに決めてしまい、後になって仕様変更のたびに大きな修正コストが発生し、深く後悔した経験があります。この実体験から得た学び、「好みの問題」を議論の出発点に変えるヒントを共有したいと思い、本記事を執筆しました。
本記事では、「好みの問題」という言葉の危険性と、その背後にある心理やスキルの問題について私が感じてきた違和感を掘り下げていきたいと思います。
「好みの問題」により思考が止まるリスク
私が「好みの問題」という言葉に違和感を覚えるようになったのは、それが思考停止のサインに感じたからです。
意見が分かれるとき、そこには必ずメリットとデメリット（トレードオフ）が存在するはずです。そしてそのバランスを見て、どの文脈ではどちらが適しているかを判断する、それが本来あるべき意思決定のプロセスだと考えています。
しかし「好みの問題だよね」と言ってしまった瞬間、そのトレードオフを考える行為が打ち切られてしてしまいます。まだ表面化していない違いを探る機会を、自分から手放してしまうことになるのです。
もちろん、時には直感や経験に頼ってよい場面もあると思います。ですが、その直感や経験がどこから来ているのかを言語化しようとする姿勢こそが、議論の質を高めます。これは本当に好みなのか？見えていない判断軸があるのか？そう問い直すことで、議論の質だけでなく判断の質も、そしてチームの成熟度も一段階高められると考えています。
なぜ人は「好みの問題」に逃げたくなるのか
ではなぜ、「好みの問題」で片づけたくなるのか？
私の経験的にその背景には、心理的な負荷と言語化スキルの不足、この2つの主な原因があると感じています。
心理的な負荷を下げたいから
まず一つ目は、議論を続けるのがしんどいからといったシンプルな理由です。
- 話が長くなりすぎて疲れてしまった
- 空気が重くなりかけている
- 相手を傷つけたくない、否定したくない
このような場面では議論を終わらせるための言葉として「好みの問題」が使われやすいと感じます。
決して悪気があるわけではなく、むしろ場の雰囲気や相手への配慮を優先した結果です。しかし、この空気に流された判断が積み重なると、意思決定の質は徐々に下がっていきます。なんとなくで選ばれた仕様や設計が、後々の修正コストとして跳ね返ってくる、このような経験のある方も多いのではないでしょうか？
言語化スキルが不足しているから
もう一つの原因は、そもそも選択肢の比較や評価をうまくできない言語化スキルの課題です。次のような場面に遭遇した場合、言語化スキルが不足している可能性が非常に高いです。
- メリット・デメリットを洗い出せない
- 長期的な影響や副作用を想像できない
- 評価軸が立てられない
言語化スキルが不足していると、意見の違いを「何がどう違うのか？」という視点で捉えることができません。私自身、「なんか違うけど理由はわからない」→「たぶん好みの問題だ」と短略的な判断をしてしまっていたと反省しています。
ここで誤解してほしくないのは、言語化スキルの不足は必ずしも（いわゆる）技術力不足だけを指しているわけではないということです。もちろん、技術力は言語化を深めるうえで重要ですが、知識の習得には時間がかかります。一方で現状の知識レベルでも、思考を整理し言葉にする努力は今この瞬間から取り組める改善ポイントです。「なぜそう思うのか？」を立ち止まって言語化する、この小さな積み重ねが個人やチームの改善を生み出すはずです。
「好み」と向き合うために必要な視点
「好みの問題」で終わらせずに、建設的な議論や判断に持ち込むために、私が意識している具体的な視点を紹介します。
議論の目的をすり合わせる
まず何よりも、何のための議論なのかを明確にすることが出発点です。
目的が不明確なまま議論を始めてしまうと、意見のすれ違いや比較の基準のズレが生じ、議論が長期化しやすくなります。「Aさんは可読性を重視して話しているのに、Bさんはパフォーマンスの観点で話している」このような状態では、議論は噛み合わず、疲れや面倒臭さだけが残る結果になってしまいます。そして最終的には、「好みの問題でいいか。。。」と終わらせてしまうことも少なくありません。
トレードオフを見つけ、言語化する
アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ。
（引用：Mark Richards、Neal Ford 著、島田 浩二 訳, ソフトウェアアーキテクチャの基礎, O'Reilly, 2022）
アーキテクチャに関わらずどんな選択肢にも、メリットとデメリットがあります。この前提に立てば、正解を探す、何を優先するかの議論が可能になります。
例えば：
- A案は保守性が高いが、初期実装コストが高い
- B案は開発が早いが、後々の拡張性に課題がある
- C案は保守性も高く開発も早いが、チームにナレッジがなく学習コストが高い
こうしたトレードオフを明確にし、何を重視するかを議論することで、感覚的な好みではなく根拠のある意思決定になります。
また、トレードオフを言語化して共有することは、意思決定の記録としても非常に価値があります。
コミュニケーションの不確実性を理解する
もう一つ忘れてはならないのが、コミュニケーションの不確実性です。人は、他人を完全に理解することはできません。相手の考えていること、感じていること、意図や背景は、どれだけ関係が深くても推測の域を出ないのが現実です。
だからこそ重要なのは、自分の意見や感覚を率直に言語化することです。逆に、相手が理解してくれる前提で話を省略してしまうと、認識のズレや非建設的なすれ違いが生まれやすくなります。
しかし、否定されたくない、空気を読まないと思われたくないといった心理から率直に話すことが難しい場面もあります。こうした心理が働いている状態は心理的安全性が低いというサインでもあります。このような状況下では、まずはチーム全体で対人リスクを恐れない行動を増やすことが重要です。
- 小さな違和感でも口に出してよい
- 未熟な意見でも大切に扱う
- 指摘ではなく、学びのきっかけとして捉える
こうした文化が積み重なることで、好みで片づけられていた議論が、学びと納得のある意思決定へと変化していくはずです。
「好みの問題」で決着してOKなケース
判断基準やトレードオフが共有されたことを前提として、次のような場面では「好みの問題」で打ち切って良いと考えています。
-
その意見の差異が小さいと合意できたとき
成果物の品質やユーザー体験への影響が軽微で、どちらを選んでも困らないとチーム全員が納得できる場合。 -
やってみないと評価できないとき
フィードバックを得ながら判断を深めるケース。このときは 「後で変えやすいか？」 を追加の評価軸として必ず確認する。
具体例
コードフォーマッタの設定
Go なら gofmt、JavaScript/TypeScript なら prettier のように公式またはデファクトのフォーマッタがある場合、行長や改行位置などの細部は動作にも品質にもほぼ影響しません。自動整形のおかげで運用コストもゼロに近いため、「どちらでも良い」と合意し、一括で設定を統一する方がメンテナンス性とレビュー効率の両面でメリットが大きくなります。
暫定的なUIオブジェクトの配置
ボタンの配置や配色パターンのような UI デザインは、ユーザーヒアリングやアクセス解析を通じて検証しなければ効果を測れません。初期リリースを優先したい場面では、まずは現時点での好みで決めてしまい、実データが得られた時点で改めて最適化を行う方が合理的です。その際は後から変更しやすい設計にしておくことが不可欠です。
まとめ
「好みの問題」という言葉は、便利です。場の空気を壊さず、議論を早く終わらせることができます。ときにそれは実用的な判断かもしれません。
しかし、そこで議論を止めてはいけません。意見が分かれるということは、必ずそこに違いがあるということです。その違いを掘り下げ、「なぜそう思うのか？」「どんなメリット・デメリットがあるのか？」と問い直すことで意思決定の納得感が高まります。また、そのプロセスの副産物として、チーム全体の成熟度も高められます。
だからこそ、「好みの問題」は終わりの言葉ではなく、始まりの問いとして扱うべきだと私は信じています。
「物流の次を発明する」をミッションに物流のシェアリングプラットフォームを運営する、ハコベル株式会社 開発チームのテックブログです！ 【エンジニア積極採用中】t.hacobell.com//blog/engineer-entrancebook
Discussion
何か嫌なことでもあったのでしょうか？
思考停止=悪という固定概念に囚われ、「これ以上議論をすること自体が有意義かどうか」という視点がすっぽり抜け落ちているように思えました。チームに存在する全ての事柄に対して議論をするのは現実的ではないと思いますので。
もし辛口な印象を与えてしまったとしたら申し訳ないのですが、はっきり言って、実務上で生じた何らかの問題によって筆者が不快な体験（こちらの記事の場合は「好みの問題」として一蹴されること）をしたが、それに対してメンバーに直接物申す勇気はなく、主語を拡大し「であるべきだ」という論調で自身が体験した事実への反論を展開する記事を投稿することで自己満足するという、よくあるタイプの記事という印象しか受けませんでした。
ただの体験談的な記事なら問題ないと思います。しかし、こちらの記事は煽りタイトルからの一意見の主張というスタンスの記事（＝コミュニティに対して広い範囲で影響を与える記事）になると思うので、前述のような視点を鑑みず一方的に「逃げ」や「思考停止」といった強めの言葉で断定するのは、コミュニティに対して有害であるとすら思いました。
soretteaさん
率直なフィードバックをありがとうございます。
記事を読み返してみるとご指摘のとおり、思考停止＝悪というニュアンスが強く、「これ以上議論をすること自体が有意義かどうか」という視点が十分に示せていなかったと感じます。
「好みの問題」と片づけてしまい後悔した実体験、チームの振り返りにおいて議論の進め方について声が上がりまさにカイゼンを進めている最中であること、本記事中で引用・参考にさせていただいた書籍から洞察が得られたこと、これらを経緯として本記事を投稿しました。これらの経緯を本文に明示できていなかった点は反省しています。
現在のところ本文は未更新のままですが、コミュニティへ誤った影響を与えかねない点を鑑み、取り急ぎコメントにて改善方針を共有します。
上記を反映したうえで、「「好みの問題」を議論の終着点ではなく議論の出発点にしよう」・「「好みの問題」は思考停止のサイン」というメッセージは維持します。このメッセージを残すのは、初歩的なレベルの議論整理を意図しているためです。「好みの問題」と言った瞬間にまずはトレードオフを探してみるという基礎ステップを共有したく、あえて基本に立ち返る主張は残します。
記事を更新でき次第、改めてお知らせいたします。貴重なフィードバックありがとうございました。
記事の内容を更新しました。改訂前が気になる方もいらっしゃると思うので、こちらにDiffを残しておきます。
議論するときに相手の気持ちを考えるコストがないのがAI開発のメリットだと思います。どうしても人間だから考える続けるとどこかで合理的な決断ができなくなりますし。
プロダクトの完成度のほうが同僚の気分よりも大事だとしても、人間関係のせいでどうにもならないのは悔しいですね。
日程調整のときに「いつでもいいですよ」と言うのも思考停止な気がします。