結論の手前にある見えない扉についての対話

Share

ゼミで議論が噛み合わない。Aさんは「それは間違っている」と言い、Bさんは「いや、正しい」と言う。30分後、どちらも同じことを言っていたと気づく。前提が違っていただけだった。

この30分は無駄だったのか。無駄だった。だが、ほとんどのグループ議論でこの種の無駄は日常的に発生している。

結論が違うのではなく、前提が違う

議論が噛み合わないとき、多くの人は「相手の結論が間違っている」と考える。だが実際には、結論が違うのではなく、前提が違っていることのほうが圧倒的に多い。

「大学の授業は役に立たない」という主張を例にする。これに対して「いや、役に立つ」と反論する前に、確認すべきことがある。「役に立つ」とは何を意味しているのか。就職に直結するスキルのことか、思考力の訓練のことか、教養としての知識のことか。この定義が揃っていなければ、議論は永遠に平行線だ。

会話で賢く見える人は、この前提のズレに最初に気づく人だ。正しい結論を持っているからではなく、結論の前に前提を確認するからだ。

前提を確認する技術

前提の確認は、具体的には「問い返し」の技術だ。相手の発言を受けて、その背後にある前提を言語化する。

「それってどういう意味で使っていますか?」。もっとも基本的な前提質問だ。相手が使っている言葉の定義を確認する。「コスパが悪い」と言われたとき、何のコストと何のパフォーマンスを比べているのかを確認する。

「こういう理解で合っていますか?」。相手の発言を自分の言葉で言い換えて確認する。これは前提の確認であると同時に、「あなたの話を聞いています」というメッセージでもある。

「前提として何を想定していますか?」。やや直接的だが、議論の方向を根本から修正できる。相手が暗黙に置いている前提を可視化する。

「もしかして、前提が違うかもしれないのですが」。自分と相手の前提が違う可能性を示唆する。断定を避けることで、相手の防御反応を起こさずに済む。

弱い言い方の技術

前提の確認で重要なのは、「弱い言い方」を使うことだ。

「それは違います」と言えば、相手は防御態勢に入る。だが「こういう理解で合っていますか?」と言えば、相手は「確認に答える」という態勢になる。内容はほぼ同じなのに、反応が全く違う。

弱い言い方のコツは、断定を疑問に変えることだ。「AはBだ」を「AはBだと思うんですが、どうですか?」に変える。「それは間違いだ」を「もしかして前提が違うかもしれないのですが」に変える。

これは議論を避けることではない。議論の土台を揃えることだ。前提が揃った上での反論は生産的だが、前提が揃っていない状態での反論は空転するだけだ。

場面による使い分け

前提の確認には場面に応じたフォーマルさのグラデーションがある。

ゼミ。 もっともフォーマルな場だ。「先生のおっしゃる『自由』は、消極的自由と積極的自由のどちらの意味でしょうか」のように、術語を使って正確に確認する。ここでの前提確認は、むしろ歓迎される。教授は「よい質問だ」と言うだろう。

友人との雑談。 フォーマルさを下げる必要がある。「え、それってどういうこと?」「つまりこういうこと?」くらいの軽さがちょうどいい。あまり精密に前提を確認すると、「なんで普通に話してるのに詰められてるの」と思われる。

バイト先。 実務的な文脈では、前提確認は確認作業として自然に行える。「この作業、今日中ということでいいですか?」「このやり方であってますか?」。ここでは前提確認が「丁寧な仕事」として評価される。

前提の確認が「賢く見える」理由

前提を確認する人が賢く見えるのには、構造的な理由がある。

第一に、相手の話を正確に聞いていることの証明になる。前提を確認するためには、相手が何を言ったかを正確に把握している必要がある。「ちゃんと聞いている」と感じさせるだけで、相手からの評価は上がる。

第二に、議論の見通しがよくなる。前提が揃えば、どこが合意点でどこが対立点かが明確になる。議論が整理される。整理できる人は賢く見える。

第三に、無駄な対立を避けられる。前提が違うだけの「疑似的な対立」を解消できるので、本当に意見が分かれる論点に集中できる。

ソクラテスは問いを返すことで相手の前提を明らかにし、対話を通じて真理に近づこうとした。ソクラテス的問答法の核心は「正しい答えを知っていること」ではなく、「正しい問いを投げること」だった。

前提の確認ができない場面

ただし、前提の確認が常に可能なわけではない。

相手が感情的になっているとき、前提の確認は逆効果になることがある。「そういう意味じゃないんだけど」と余計に怒らせる。感情の渦中にある人は、論理ではなく共感を求めている。

また、権力勾配が大きい関係では、前提の確認が「反抗」と受け取られるリスクがある。上司に「それはどういう意味ですか?」と聞くことが、場合によっては「指示に従わない」と解釈される。

前提の確認は万能ではない。だが、少なくとも対等な関係における議論においては、もっとも効果的な技術のひとつだ。賢い人は答えを知っているのではなく、問いの立て方を知っている。そして問いの中でもっとも基本的なものが、「前提は何ですか?」という問いだ。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu