人間関係は意思決定の連続です。
日常の中にも意思決定は溢れていて、例えば「どこでランチを食べるのか」「ホビーショップで何を買うのか（もしくは何も買わないのか）」といった身近な所にも意思決定の場面が存在します。
何となくで意思決定するのも悪くありませんが、得するためには論理に基づいた意思決定が必要です。
少なくとも、仕事の場で意思決定の必要が生じた場合は、論理に基づいて高い利得を得られるようにするべきです。
意思決定の方法はいくつかありますが、この記事では、汎用性が高いディベートの技術を紹介します。
この技術は、他の人との議論を通して論理的な意思決定を行う場合に特に適しています。
この記事で解説する技術は、ディベートの競技で用いられる一般的な型ですが、現実の議論ではこの型にとらわれる必要はありません。
また、現実の議論では、論理のみでなく、相手の感情にも気を配る必要がある場合もあります。
しかし、このような型の存在を知っていれば、現実の議論の方向性で迷った場合の道しるべになります。
(1)議題の定義
意思決定を行うためには、まず何について意思決定を行うのか、つまり議題を定義する必要があります。
また、意思決定する上では、議題を肯定する意見と否定する意見をぶつけることで多面的な検討を行うことが望ましいため、「～べきであるか否か」という語尾で終わる議題を設定した方が無難です。
例えば、ITシステムの保守開発の現場に参画しているとします。
その現場では、各担当者がコーディングを行うことでシステムの更改を定期的に行っているが、コーディングを行う際の規約は存在せず、その規約を作るかどうか検討する必要がある、とします。
この場合、「今の保守開発の現場で、コーディング規約を新たに導入するべきであるか否か」といった形で議題を定義するのが適切です。
(2)提案の具体化
議題を定義した後は、その議題を肯定するためには具体的にどのような提案となるのか、を考える必要があります。
具体的な提案という形に落とし込まないと、何について肯定・否定するべきかが不明確となり、あたかも空中戦のような議論となるからです。
前述の例の議題で言うと、「団体Aが提唱しているコーディング規約をドキュメントとして開発者とレビュー担当者へ広める」のような提案をするのが望ましいです。
なお、コーディング規約を導入すること自体の是非ではなく、「団体Aが提唱している」コーディング規約を導入するべきか否かを議論したい場合は、議題の設定が誤っています。
このような場合は、「今の保守開発の現場で、『団体Aが提唱している』コーディング規約を新たに導入するべきであるか否か」という議題とするのが適切です。
（そうしない場合、「団体Bが提唱しているコーディング規約を採用・導入する」という提案が可能になってしまい、本来議論するべき団体Aのコーディング規約に焦点が定まらなくなる可能性があります）
(3)提案のメリット・デメリットの組み立て
提案には、導入することによるメリットとデメリットが存在します。
具体的な提案を決めた後は、その提案に対して、メリットとデメリットを組み立てる必要があります。
メリットとデメリットは、以下の要素が含まれる主張を掛け合わせることで、組み立てることができます。
【提案のメリット】
内因性×解決性×重要性を掛け合わせることで組み立てられる。
- 内因性 ：提案を導入していない現状で問題が発生しているという主張
- 解決性 ：提案を導入することで問題が解決するという主張
- 重要性 ：問題を解決することは重要であるという主張
前述の例の提案で言うと、以下のような主張が考えられる。
- 内因性 ：ソースファイル毎でソースの書き方がバラバラである
- 解決性 ：コーディング規約により、今後改修されるソースは書き方が統一される
- 重要性 ：ソースの書き方が統一されれば、可読性が高まり、不具合が減る
【提案のデメリット】
固有性×発生過程×深刻性を掛け合わせることで組み立てられる。
- 固有性 ：提案を採用していない現状では問題がないという主張
- 発生過程：提案を採用することで新たに問題が出るという主張
- 深刻性 ：新たに発生する問題が重大であるという主張
前述の例の提案で言うと、以下のような主張が考えられる。
- 固有性 ：現状では１つ１つのソースファイル内では書き方が統一されている
- 発生過程：改修時に規約に従うと、ソースファイル内で書き方が不統一になり得る
- 深刻性 ：ソースファイル内で書き方が不統一になることで、逆に可読性が低下する
(4)主張を支える根拠
メリット（内因性×解決性×重要性）やデメリット（固有性×発生過程×深刻性）の主張の論理の繋がりも重要ですが、主張を支える根拠が存在するかどうかも重要です。
根拠としては、書籍や記事、調査結果といったものが考えられます。
例えば「現状では１つ１つのソースファイル内では書き方が統一されている」と主張したい場合は、ソースファイルをサンプル的にピックアップし、調査し、例示すると良いでしょう。
(5)メリットとデメリットの比較のための価値基準
メリット・デメリットを組み立て、主張の根拠も確認できた後は、次はメリットとデメリットを比較する必要があります。
メリットの方が大きければその議題（提案）は採用するべき、デメリットの方が大きければその議題（提案）は採用するべきではない、と意思決定することができます。
メリット・デメリットの大きさは、理論的には「内因性×解決性×重要性」（メリット）もしくは「固有性×発生過程×深刻性」（デメリット）の大きさで示すことができます。
しかし、この比較を数値で表すことが困難、もしくはそうすることが望ましくない場合も多いです。
そのため、主観により比較せざるを得ないことが多くなりますが、主観で大きさを比較・評価するのは難しいです。
そこで重要になるのが、「価値基準」という観点です。
議題の意思決定の影響を受ける関係者が何を大切にしているのかを明確にすることで、メリットとデメリットの比較を容易にすることができます。
例えば、前述の例のメリット・デメリットの大きさを比較する場合、「ソースファイル内で書き方が不統一になったとしても時間をかければ統一化できる」という前提を置けるのであれば、長期的に見た場合のコードの可読性を重視するのか、近視眼的に見た場合のコードの可読性を重視するのかが、判断の分かれ目になるでしょう。
前者の場合（例：長期的に利益が見込まれるシステムの保守をしている場合）はメリット、後者の場合（例：市場に浸透するかが不透明なシステムの保守をしている場合）はデメリットの方を重視するべきでしょう。
(6)付随的提案と代替案
発展的な話になりますが、議題とは直接関係のない提案についても、関連性が高いものであれば同時に検討した方が良いです。
議題を肯定する側は、議題を肯定する提案と同時に、付随的提案を行うこともできます。
また、議題を否定する側は、議題を肯定する提案のデメリットを訴えるだけでなく、議題の外にある代替案を提示することもできます。
付随的提案や代替案も加味した上で、議題の肯定・否定に際して、取り得るスタンスをまとめると以下のようになります。
意思決定としては、どのスタンスが関係者にとって一番優れているのかを議論し、そのスタンスが示す案を採用する（もしくは何もしない）ことを決定する、という流れになります。
ただし、代替案を議論に持ち出す場合は、議論が不必要に複雑になる可能性があります。
複雑な議論を避けたい場合は、付随的提案のみでメリットが出てしまわないように注意した上で、代替案については別の議題を立てて別途議論することとした方が良いでしょう。
（ディベートの競技でも、場合により、代替案の使用を禁止しています）
付随的提案と代替案の詳細は以下の通りです。
【付随的提案】
提案を行う際に、議題を直接肯定するわけではないがデメリットの発生を防ぐのに有効な付随的提案を同時に行うことができます。
付随的提案を行うことで、メリットを得つつデメリットの発生を抑えられるのであれば、議題を肯定する提案と付随的提案を同時に採用するのが良い、という判断になります。
例えば、前述の例の場合、「新規のソースファイルにのみ規約を適用し、既存のソースファイルについては規約を適用除外する」という付随的提案を併用することで、デメリットの発生を防ぐ効果を期待できます。
ただし、付随的提案を採用することで新たなデメリットが発生しないか、付随的提案のみでメリットが出ていないか（付随的提案のみを切り出して代替案にできるのではないか）、といった観点からの議論は必要です。
（前述の付随的提案の場合は、規約が存在することが前提となっているため付随的提案のみを切り出すこと自体不可能である。しかし、「既存のソースファイルを書き直して、ソースファイル間の書き方の差異をなくす」のような付随的提案の場合は、この付随的提案のみを切り出すことが可能、かつ議題を肯定せずとも付随的提案のみでメリットが出てしまう可能性があります。）
【代替案】
議題を肯定しなくてもメリットを得られるような代替案を提案することで、その代替案が一番良いという結論となる場合があります。
例えば、前述の例の場合、「色々なソースの書き方について教育し、色々な書き方に慣れてもらう」という代替案の方が優れている可能性があります。
もちろん、その代替案のメリットやデメリットを論じた上で、議題を肯定する提案（＋付随的提案）よりも優れていると言えるのか、という観点からの議論は必要です。
加えて、代替案を議題を肯定する提案と同時に採用した方が良いのではないか（代替案を付随的提案とした方が良いのではないか）、という観点からの議論も必要です。
後書き
論理的な意思決定を行う上で、今回の記事で紹介したようなコミュニケーションの技術も重要ですが、その論理の中身が机上の空論になっていないか、IT業界においてはプログラミングを初めとしたIT関連の専門知識に基づいて論理を組み立てられているか、ということも重要になります。
株式会社サイゼントでは、即戦力のJavaプログラマーを育てるための書籍「絶対にJavaプログラマーになりたい人へ」をKindleで販売しています。
同じく、Spring Frameworkについてきめ細かく解説した別冊も販売中です。
また、上記の書籍をテキストとして用いたプログラミングスクール「サイゼントアカデミー」も開校しています。
このスクールは、受託開発事業・SES事業である弊社が、新入社員向けの研修で培ったノウハウを詰め込んだものです。
ご興味がある方は、上記画像から個別ページにアクセスしてみてください！
コメント