議論が噛み合わない理由は、知識量ではなく「抽象度」の違いかもしれない

1. 同じ話をしているのに、なぜ噛み合わないのか

まず、次のような会話を読んでみてください。

佐藤さん： この機能、今は動いていますが、似たような通知処理が増えたら管理しづらくなりそうです。状態変化を通知する仕組みとして切り出した方がよいと思います。

鈴木さん： でも、今のコードで通知は出ていますよね。バグも出ていないので、このままでよくないですか。

佐藤さん： 今の一箇所だけならそうなんですが、今後の変更に弱いんです。

鈴木さん： でも、今後増えるかはまだ決まっていないですよね。

佐藤さんと鈴木さんは、同じコードを見て、同じ機能について話しています。どちらかが明らかに間違っているわけでもありません。それでも、話がかみ合っていないように感じます。

なぜでしょうか。

佐藤さんは「複数の場面にまたがる設計上の構造」を見ています。鈴木さんは「いま目の前の実装が正常に動いているか」を見ています。同じコードを見ていながら、見ている「層」が違うのです。

こうした経験は、プログラミングに限らず、さまざまな場面で起きているように思います。

高校まで得意だった科目が、大学の専門課程に入った途端にわからなくなった
コードは書けるのに、デザインパターンになるとピンとこない
現場の作業はできるのに、PMBOKのような体系的な概念が遠く感じる
SNSで同じ話題を議論しているはずなのに、まったく話が噛み合わない

これらはすべて、別々の問題のように見えて、じつは同じ構造を持つ現象かもしれません。

問いとして立ててみます。「これは単なる知識不足なのか。それとも、扱っている抽象度の違いなのか。」

2. 抽象度とは何か

「抽象度」という言葉を使う前に、少し整理しておきます。

抽象度が高いとは、個別の事例や手順から離れて、複数の事例に共通する構造・型・関係性・原理を扱うことです。

プログラミングで例えるなら、こういう段階の違いです。

大切なのは、抽象が「上」で具体が「下」という話ではないことです。抽象と具体は上下の序列ではなく、行き来するためのレイヤーとして捉えるのが自然だと思います。

ここで一つ、キーになる観察を置いておきます。

抽象度の違いは、知識量の違いに見えやすい。

「あの人はデザインパターンを知らない」「PMBOKを理解していない」という見方は、実態を正確に捉えていない可能性があります。知識不足だけではなく、話している抽象度のレイヤーがズレている、というケースも多いのではないでしょうか。

3. 主例：コードは書けるが、デザインパターンがわからない

プログラミングを例に、もう少し丁寧に見てみます。

コードを書くことと、デザインパターンを理解することは、必要とする認知のレイヤーが違います。

コードを書く段階： 目の前の入力・処理・出力を扱う。「このボタンを押したらこの関数が動く」という因果関係が見えていればよい
デザインパターンの段階： 複数の場面に共通する設計上の型を扱う。「今後どんな変更が来ても対応できる構造とは何か」を考える必要がある

次の会話を読んでみてください。

佐藤さん： この処理、支払い方法ごとに if 文が増えていくので、Strategy パターンっぽく分けた方がよさそうです。

鈴木さん： でも、クレカと銀行振込だけなら if で十分じゃないですか。

佐藤さん： 今は十分です。ただ、支払い方法が増えるたびにこの関数を触ることになります。

鈴木さん： 増えたときに直せばよくないですか。

佐藤さんは「変更パターン」を見ています。鈴木さんは「現在の分岐数」を見ています。

どちらも正しいことを言っています。ただ、見ている抽象度のレイヤーが違います。

デザインパターンが「わからない」人は、プログラミング能力が低いとは限りません。「具体的なコードを書く」から「複数の場面に共通する設計の型を見る」へのジャンプを、まだ経験していない状態かもしれません。

このジャンプは、教えてもらうだけでは難しく、具体的な問題に何度も直面しながら「あ、こういう構造のことか」と腑に落ちる瞬間を積み重ねるものだと思います。

4. 補助例：PMBOK と非凸性も同じ構造

同じことは、別の領域にも起きています。

PMBOKの例

PMBOKが「机上の空論」に見える場合、その人が実務を知らないわけではないことが多いです。実務経験と抽象概念の接続が、まだできていない状態と考える方が近いかもしれません。

非凸性の例

大学以降の学問でよく起きる「具体的な計算」から「問題空間の構造を見る」への移行は、まさにこの抽象度のジャンプです。

いずれも、単なる知識量の問題だけではなく、見ているレイヤーの違いとしても捉えられます。

5. 「抽象化に耐えられない」とは何か

「抽象化についていけない」という状態は、能力が低いというより、次のような状態として捉えられるかもしれません。

具体例がないと、意味を保持し続けるのが難しい
すぐに使い道が見えない概念に、ストレスを感じる
概念同士の関係を頭の中で保持し続ける負荷が高い
わからない状態のまま探索し続ける時間に、耐えにくい

持ち帰ってほしいのは、「わからない」の中には、抽象度の負荷が含まれているという見方です。「理解できない」と「抽象度が高くてまだ保持できない」は、同じように見えて、別のことを指している可能性があります。

たとえば「Observer パターン」と言われても何も浮かばない人が、「通知先が増えるたびに同じ関数を直すのがつらい」という具体的な状況を聞くと、急に理解の糸口が見えることがあります。これは知識の有無だけでなく、抽象概念を受け取るための足場があるかどうかの違いです。

6. 重要なのは、抽象と具体を往復できること

ここが、この記事でいちばん伝えたいことです。

単に抽象的に考えられる人が優れている、という話ではありません。抽象だけで話し続ける人も、現実の問題に落とせなければ弱いです。逆に、具体にしか目が向かない人は、状況をまたがった判断が難しくなります。

重要なのは、次の往復ができることだと思います。

具体例から共通する構造を取り出す
抽象概念を、別の具体例に当てはめてみる
相手がいるレイヤーに合わせて、説明の仕方を変える
必要に応じて、作業・設計・理論のレイヤーを移動する

たとえば、「往復できている状態」は次のような会話に現れます。

佐藤さん： 今は if 文で足りています。ただ、通知先が増えるたびに同じ関数を直す形になっています。

鈴木さん： つまり、今の問題というより、変更が増えたときの影響範囲を見ているんですね。

佐藤さん： そうです。なので、通知処理を切り出せる形にしておきたいんです。

鈴木さん： なるほど。それなら、今の通知先が2箇所になるケースで、どう分けるか見せてもらえますか。

佐藤さんは抽象（変更パターンへの備え）を具体（今の実装の状況）に落として説明しています。鈴木さんは「影響範囲」という一段抽象的な言葉で受け取り、さらに「具体例を見せて」と具体に引き戻しています。抽象と具体の往復が双方向で起きています。

採用したい考え方をまとめると、次のようになります。

人によって、得意な抽象度が違う
役割によって、必要な抽象度が違う
チームには、抽象化する人と具体化する人の両方が必要

逆に、避けたい考え方はこれです。

抽象がわかる人は上位
具体しか見ない人は下位
抽象化できない人は適性がない

この記事は、抽象度が高い話についていける人を称えるための記事ではありません。

7. 教育、仕事、SNS にどう効くか

教育や仕事の割り振りのヒントとして

抽象度の扱い方を観察することで、教育や仕事の割り振りのヒントにはなりえます。ただし、固定的な能力判定にしてはいけない、という点は強調しておきたいです。

参考になりそうな観察ポイントをあげてみます。

具体例をいくつか見たあと、共通点を言語化できるか
抽象概念を、別の具体例に適用できるか
抽象的な説明を聞いたあと、具体的な行動に変換できるか
わからない概念に出会ったとき、質問できるか、黙り込むか

注意点も必ずセットで持っておく必要があります。

教育歴や経験の差を、能力差と誤認しない
抽象化が苦手な人を、低く評価しない
抽象化が得意な人も、具体化できるとは限らない

SNS での議論が噛み合わない原因の一部も、抽象度のズレで説明できるかもしれません。

次の会話を読んでみてください。

佐藤さん： この問題は、個人の努力だけではなく、制度設計の影響が大きいと思います。

鈴木さん： でも、自分の知り合いは努力して抜け出しましたよ。

佐藤さん： その人の努力を否定しているわけではなく、全体として再現しやすい仕組みかどうかを話しています。

鈴木さん： でも、努力している人がいるなら、結局は本人次第では。

佐藤さんは「制度や構造」の話をしています。鈴木さんは「個別事例」の話をしています。どちらかが必ず間違っているわけではありません。価値観や立場の違い以前に、まず議論のレイヤーが揃っていない可能性があります。

技術的な議論でも、社会問題の議論でも、同じ構造のすれ違いが起きます。

佐藤さんが「設計原則」を話しているとき、鈴木さんは「手元の実装が動くか」で返している
佐藤さんが「制度や仕組み」を話しているとき、鈴木さんは「個人の努力や例外事例」で返している

立場や知識量の違いだと思っていた衝突が、じつは抽象度のレイヤー違いだった、というケースは多いのではないでしょうか。

8. ギャップを埋めるにはどうするか

最後に、実用的な視点を置いておきます。

抽象側の人ができること

いきなり概念名や専門用語を出さず、具体例から入る
相手が見ている具体を否定しない
「この例をもう一段一般化すると」と、レイヤーを移動することを明示する
抽象概念を、具体的な行動や判断基準に戻す

具体側の人ができること

「それはどの具体例に当たるのか、聞いていいですか」と確認する
「いま構造の話をしていますか、それとも個別事例の話ですか」と整理する
一つの事例だけで反論する前に、相手が一般化している範囲を確認する

共通してできること

いま自分たちが話している抽象度を確認する
「具体例の話」「構造の話」「判断・行動の話」を分ける
抽象的な言葉を、人格評価や批判として受け取らない

学問や仕事や SNS で起きる「わからなさ」や「噛み合わなさ」は、単なる知識不足でも性格の問題でもなく、抽象度のレイヤー差として捉えると整理しやすくなります。

ただし、抽象度の高い話ができることだけが価値ではありません。重要なのは、抽象と具体を往復し、相手や状況に応じてレイヤーを合わせられることだと思います。

「話が通じない」と感じたとき、相手の理解力を疑う前に、まず自分たちが同じ抽象度で話しているかを確認してみる価値があるかもしれません。