ディベート技術を用いた論理的な対話の型

伊東 輝

人間関係は意思決定の連続である。

日常の中にも意思決定は溢れており、例えば「どこでランチを食べるのか」「ホビーショップで何を買うのか（もしくは何も買わないのか）」といった身近な所にも意思決定の場面が存在する。
何となくで意思決定するのも悪くはないが、高い利得を得るためには論理に基づいた意思決定が必要になる。
少なくとも、仕事の場で意思決定の必要が生じた場合は、論理に基づいて高い利得を得られるようにするべきである。

意思決定を行うための論理的なアプローチとして、ゲーム理論というアプローチが考えられるが、ゲーム理論が有効な場面は各プレイヤーの意思決定の組み合わせによって利得が変わる場面（競合関係や互恵関係がある場面）に限られるという問題、そしてアナログな人間関係の世界では利得を数値化するのが難しいという問題がある。
そこで、この記事では、より汎用性が高いディベートの技術を紹介する。

この記事で解説する技術は、ディベートの競技で用いられる一般的な型であるが、現実の議論ではこの型にとらわれる必要はない。
しかし、このような型の存在を知っていれば、現実の議論の方向性で迷った場合の道しるべになるだろう。

なお、「ディベートの技術は人間同士のコミュニケーションの役には立たない（むしろ逆効果である）」という意の批判をされることがあるが、これは「ディベートの技術をベースとした論理的な世界」と「現実の人間関係で求められる感情的な要素が含まれるコミュニケーション」のギャップを埋めようとしない、言い換えるとディベートの世界の論理的思考を剥き出しにせずにオブラートで包む努力が不十分であることによって生じる問題である。
ギャップを埋めるための技術（オブラートで包む技術）については、別の記事で触れることとする。

(1)議題の定義

意思決定を行うためには、まず何について意思決定を行うのか、つまり議題を定義する必要がある。
また、意思決定する上では、議題を肯定する意見と否定する意見をぶつけることで多面的な検討を行うことが望ましいため、「～べきであるか否か」という語尾で終わる議題を設定した方が無難だろう。

例えば、ITシステムの保守開発の現場に参画しているとする。
その現場では、各担当者がコーディングを行うことでシステムの更改を定期的に行っているが、コーディングを行う際の規約は存在せず、その規約を作るかどうか検討する必要がある、とする。
この場合、「今の保守開発の現場で、コーディング規約を新たに導入するべきであるか否か」といった形で議題を定義するのが適切だろう。

(2)提案の具体化

議題を定義した後は、その議題を肯定するためには具体的にどのような提案となるのか、を考える必要がある。
具体的な提案という形に落とし込まないと、何について肯定・否定するべきかが不明確となり、あたかも空中戦のような議論となるからである。

前述の例の議題で言うと、「団体Aが提唱しているコーディング規約をドキュメントとして開発者とレビュー担当者へ広める」のような提案をするのが望ましいだろう。

なお、コーディング規約を導入すること自体の是非ではなく、「団体Aが提唱している」コーディング規約を導入するべきか否かを議論したい場合は、議題の設定が誤っている。
このような場合は、「今の保守開発の現場で、『団体Aが提唱している』コーディング規約を新たに導入するべきであるか否か」という議題とするのが適切である。
（そうしない場合、「団体Bが提唱しているコーディング規約を採用・導入する」という提案が可能になってしまい、本来議論するべき団体Aのコーディング規約に焦点が定まらなくなる可能性がある）

(3)提案のメリット・デメリットの組み立て

提案には、導入することによるメリットとデメリットが存在する。
具体的な提案を決めた後は、その提案に対して、メリットとデメリットを組み立てる必要がある。

メリットとデメリットは、以下の要素が含まれる主張を掛け合わせることで、組み立てることができる。

【提案のメリット】

内因性×解決性×重要性を掛け合わせることで組み立てられる。

  • 内因性　：提案を導入していない現状で問題が発生しているという主張

  • 解決性　：提案を導入することで問題が解決するという主張

  • 重要性　：問題を解決することは重要であるという主張

前述の例の提案で言うと、以下のような主張が考えられる。

  • 内因性　：ソースファイル毎でソースの書き方がバラバラである

  • 解決性　：コーディング規約により、今後改修されるソースは書き方が統一される

  • 重要性　：ソースの書き方が統一されれば、可読性が高まり、不具合が減る

【提案のデメリット】

固有性×発生過程×深刻性を掛け合わせることで組み立てられる。

  • 固有性　：提案を採用していない現状では問題がないという主張

  • 発生過程：提案を採用することで新たに問題が出るという主張

  • 深刻性　：新たに発生する問題が重大であるという主張

前述の例の提案で言うと、以下のような主張が考えられる。

  • 固有性　：現状では１つ１つのソースファイル内では書き方が統一されている

  • 発生過程：改修時に規約に従うと、ソースファイル内で書き方が不統一になり得る

  • 深刻性　：ソースファイル内で書き方が不統一になることで、逆に可読性が低下する

(4)主張を支える根拠

メリット（内因性×解決性×重要性）やデメリット（固有性×発生過程×深刻性）の主張の論理の繋がりも重要であるが、主張を支える根拠が存在するかどうかも重要となる。

根拠としては、書籍や記事、調査結果といったものが考えられる。

例えば「現状では１つ１つのソースファイル内では書き方が統一されている」と主張したい場合は、ソースファイルをサンプル的にピックアップし、調査し、例示すると良いだろう。

(5)メリットとデメリットの比較のための価値基準

メリット・デメリットを組み立て、主張の根拠も確認できた後は、次はメリットとデメリットを比較する必要がある。
メリットの方が大きければその議題（提案）は採用するべき、デメリットの方が大きければその議題（提案）は採用するべきではない、と意思決定することができる。

メリット・デメリットの大きさは、理論的には「内因性×解決性×重要性」（メリット）もしくは「固有性×発生過程×深刻性」（デメリット）の大きさで示すことができる。
しかし、この比較を数値で表すことが困難、もしくはそうすることが望ましくない場合が多い。
そのため、主観により比較せざるを得ないことが多くなるが、主観で大きさを比較・評価するのは難しい。

そこで重要になるのが、「価値基準」という観点である。
議題の意思決定の影響を受ける関係者が何を大切にしているのかを明確にすることで、メリットとデメリットの比較を容易にすることができる。

例えば、前述の例のメリット・デメリットの大きさを比較する場合、「ソースファイル内で書き方が不統一になったとしても時間をかければ統一化できる」という前提を置けるのであれば、長期的に見た場合のコードの可読性を重視するのか、近視眼的に見た場合のコードの可読性を重視するのかが、判断の分かれ目になるだろう。
前者の場合（例：長期的に利益が見込まれるシステムの保守をしている場合）はメリット、後者の場合（例：市場に浸透するかが不透明なシステムの保守をしている場合）はデメリットの方を重視するべきだろう。

(6)付随的提案と代替案

発展的な話になるが、議題とは直接関係のない提案についても、関連性が高いものであれば同時に検討するべきである。

議題を肯定する側は、議題を肯定する提案と同時に、付随的提案を行うこともできる。
また、議題を否定する側は、議題を肯定する提案のデメリットを訴えるだけでなく、議題の外にある代替案を提示することもできる。

付随的提案や代替案も加味した上で、議題の肯定・否定に際して、取り得るスタンスをまとめると以下のようになる。
意思決定としては、どのスタンスが関係者にとって一番優れているのかを議論し、そのスタンスが示す案を採用する（もしくは何もしない）ことを決定する、という流れになる。

図1-1：付随的提案や代替案も加味した意思決定

ただし、代替案を議論に持ち出す場合は、議論が不必要に複雑になる可能性がある。
複雑な議論を避けたい場合は、付随的提案のみでメリットが出てしまわないように注意した上で、代替案については別の議題を立てて別途議論することとした方が良いだろう。
（ディベートの競技でも、場合により、代替案の使用を禁止している）

付随的提案と代替案の詳細は以下の通りである。

【付随的提案】

提案を行う際に、議題を直接肯定するわけではないがデメリットの発生を防ぐのに有効な付随的提案を同時に行うことができる。
付随的提案を行うことでメリットを得つつデメリットの発生を抑えられるのであれば、議題を肯定する提案と付随的提案を同時に採用するのが良い、という判断になる。

例えば、前述の例の場合、「新規のソースファイルにのみ規約を適用し、既存のソースファイルについては規約を適用除外する」という付随的提案を併用することで、デメリットの発生を防ぐ効果を期待できる

ただし、付随的提案を採用することで新たなデメリットが発生しないか、付随的提案だけで良いのではないか（付随的提案のみを切り出して代替案にできるのではないか）、といった観点からの議論は必要である。
（前述の付随的提案の場合は、規約が存在することが前提となっているため付随的提案のみを切り出すこと自体不可能である。しかし、「既存のソースファイルを書き直して、ソースファイル間の書き方の差異をなくす」のような付随的提案の場合は、この付随的提案のみを切り出すことが可能、かつ議題を肯定せずとも付随的提案のみでメリットが出てしまう可能性がある。）

【代替案】

議題を肯定しなくてもメリットを得られるような代替案を提案することで、その代替案が一番良いという結論となる場合がある。

例えば、前述の例の場合、「色々なソースの書き方について教育し、色々な書き方に慣れてもらう」という代替案の方が優れている可能性がある。

もちろん、その代替案のメリットやデメリットを論じた上で、議題を肯定する提案（＋付随的提案）よりも優れていると言えるのか、という観点からの議論は必要である。
加えて、代替案を議題を肯定する提案と同時に採用した方が良いのではないか（代替案を付随的提案とした方が良いのではないか）、という観点からの議論も必要である。

この記事が気に入ったらサポートをしてみませんか？