Skip to content

Commit dbee619

Browse files
authored
Merge pull request #1694 from future-architect/feature
議論が噛み合わないときは、論点が混ざってるかもしれない
2 parents 6ebe48b + 0dff540 commit dbee619

File tree

6 files changed

+100
-0
lines changed

6 files changed

+100
-0
lines changed
Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
1+
---
2+
title: "議論が噛み合わないときは、論点が混ざってるかもしれない"
3+
date: 2025/10/02 00:00:01
4+
postid: b
5+
tag:
6+
- 会議
7+
- コミュニケーション
8+
- 新人向け
9+
category:
10+
- Business
11+
thumbnail: /images/2025/20251002b/thumbnail.jpg
12+
author: 真野隼記
13+
lede: "会議をしていて、話が噛み合わなくなったり、議論が発散してしまったりすること、ありませんか?そんな状況に陥る原因の1つに、複数の論点がいつの間にか混ざっている*ことがあります。"
14+
---
15+
<img src="/images/2025/20251002b/image.jpg" alt="image.png" width="800" height="397" loading="lazy">
16+
17+
会議をしていて、話が噛み合わなくなったり、議論が発散してしまったりすること、ありませんか?
18+
19+
- 「あれ、なんか今なんの話をしているか追いつけなくなっちゃった」
20+
21+
そんな状況に陥る原因の1つに、**複数の論点がいつの間にか混ざっている** ことがあります。
22+
23+
## 論点が次々生まれていく様子
24+
25+
例として、データガバナンスをテーマに「データオーナーをどう定義するか」を議論しているとします(設定の作り込みの甘さはご了承ください)。
26+
27+
最初の議題は、**「データオーナーをどういった立場の人を選出すべきか?」** とします。これが「論点1」です。
28+
29+
> **論点1:オーナーの選出について**
30+
>
31+
> * **問い:** データオーナーはだれが担うべきか
32+
> * **論点:** 実際にデータを生成している業務担当者か、それとも業務責任者か、そのデータを一番くわしい人(場合によっては利用者)か?
33+
34+
この議論の最中、ある参加者がこう言います。「私たちの会社は組織変更が頻繁にあり人の移動が激しい。権限の紐付け運用が現実的か懸念がある」
35+
36+
ここで、**「オーナーに紐づく権限をどう実装するか?」** という「論点2」が生まれました。
37+
38+
> **論点2:権限の実装**
39+
>
40+
> * **問い:** データオーナーに紐づく権限をどう管理するのか? 組織移動が頻繁であるため、陳腐化しないか不安である。
41+
> * **論点:** 組織に直接権限を付与するのか、ADグループのような役割(ロール)を作って管理するのか?
42+
43+
「論点1」 は **アクターの定義** の話、「論点2」 は **権限管理の実現手段** 寄りの話です。すでにレイヤーの異なる議論が混ざり始めています。さらに議論が白熱すると、「そもそも、うちの会社におけるデータオーナーの "あるべき姿" って何なんでしょう?ただの権限設定の承認者なのか、あるべきデータモデルについても検討する責務を持ちますか?」などと派生した論点3や、論点1と2の亜種である1'と2’など次々に出てくることもあります。
44+
45+
実際の会議ではこうした推移の解説者はいないので、文字で書く以上に混沌化しやすいです。
46+
47+
## なぜ論点を混ぜると危険なのか
48+
49+
このように複数の論点が整理されないままだと、アクロバティックな空中戦になってしまいます。
50+
51+
* 話の焦点がぼやける
52+
* 前提条件が一致しないため、同じような議論を繰り返すことになりがち
53+
* 思考が発散する
54+
* 参加者がそれぞれ関心事についてバラバラに話すため、深い議論ができない
55+
* 認識のズレが生まれる
56+
* 本来はギャップがあるにも関わらず、参加者が想像で補完するため、言った言わない問題に繋がりかねない
57+
58+
結果として、決めるべきことが決めきれず、時間と労力を消費してしまいます。なにか決まったように見えたとしても、それは錯覚でしょう。
59+
60+
## 論点を分離して、議論を前に進める
61+
62+
では、どうすればよかったのか。答えはシンプルで、**論点を明確に分離し、一つずつ議論すること**です。
63+
64+
- 「みなさん、ありがとうございます。やるべきことがたくさん見えてきたと感じました。今までの議論をまとめると、3つの議題が出たと思います。①オーナーの選出方、②権限の実装、③役割のあるべき論です。①の懸念事項はXXXや△△△で。②の懸念事項は...(省略)」
65+
66+
というように、出てきた論点と懸念事項(参加者の関心ごとです)をリスト化して全員に見せ、今話している論点が何なのかを明確にします。その上で、今テーマにしたい議題以外は、「後で(いつまでを目処に)」議論しましょうと伝えると良いでしょう。
67+
68+
また、もし自分が話していて、「あ、今ちょっと違う論点を混ぜちゃったかも」と気づいたら、
69+
70+
- 「すみません、少し話が逸れました。関連する話ですが、これは別の論点ですね。まずはこちらの話を…」
71+
72+
とできるだけ早く修正すると、参加者の認知リソースを奪わなくて済みます。
73+
74+
もし、別の論点を持ち出したい場合は、今の議論が落ち着いたタイミングなどで、明示的に「**別の論点なんですが**、◯◯については△△の課題があると思いますが、どうしましょうか?」と、参加者を混乱させないように一言、断りを入れるなどの考慮をすると良いでしょう。
75+
76+
## アドリブに強くなる
77+
78+
会議では何かしらの資料ベースに話すことが基本です。それらを入力として、参加者が「あれ、この点はどうなっている?」と発散し視点が広がるのはむしろ好ましいことです。何なら、様々な観点から課題を洗い出したいといったプロジェクトの初期フェーズでは、あえて論点整理に向かわず、そのまま発散方向に突き進むことも有効な場合があります。
79+
80+
しかし計画の実現に向けて、1つずつ課題を潰しこみたい実行フェーズでは、議論が派生したとしても、論点を明確にして話す必要があります。派生した論点の場合は、当然ながらベースとなる資料を事前に準備できません。この場合、共有している資料上にテキストボックスを追加したり、スライドのメモ欄や、別途テキストエディタを画面共有しながら、懸念事項や議論のアウトラインを入力しながら議論することがお勧めです。
81+
82+
参加者が自分よりキャリアが上の人で、議論の流れに割って入りにくいことも多いでしょう。そんなときは以下の言い回しを行いつつ、整理する場面をよく見かけます。
83+
84+
-**ちょっと私の理解のために確認させて下さい**。今は、◯◯という論点と、△△という論点がある状態であっていますか? この場合、◯◯の課題ではXXXさんが気にしている点は、xxxとxxxxがあり~(と言いながら、エディタで書く)」
85+
86+
言い回しを少し気をつけるだけでも、ぐっと受け手の印象は変わります。
87+
88+
GoogleスライドやMiroなど、共同編集が可能なサービスをすでに画面共有しているなら、黙って今議論している課題の構造をまとめる動きをとっても良いでしょう(出来が悪そうなら消せばよいだけです)。
89+
90+
難しい展開の会議に出くわしても、できる限り手と頭を動かし、箇条書きでも良いので状況を構造化する。これができる人は少ないので差別化にもなります。労をいとわず会議の推進役となりましょう。
91+
92+
## まとめ
93+
94+
「事実と推測を分ける」のと同じくらい、**「論点と論点を分ける」** ことは、生産的な議論をする上で重要です。
95+
96+
議論が噛み合わないと感じたら、一度立ち止まって、
97+
98+
- 「今、出てきた論点は複数存在して、別々に議論できないか?」
99+
100+
...と鳥の目的な、俯瞰した視点に変えてみると良いでしょう。論点と論点が関連している場合もあります。しかし、それでも議論ポイントを分離し、より根っこにあると思われる論点を先に取り組むといった交通整理ができると、複雑な会議が想像以上にスムーズに話が進むことも多いです。

source/images/2025/20250924a/thumbnail.jpg:Zone.Identifier

Whitespace-only changes.
84 KB
Loading
File renamed without changes.
70 KB
Loading
13.1 KB
Loading

0 commit comments

Comments
 (0)