【チーム開発】言うほど我々は議論の勉強をしてきてないので、議論の基礎が学べる良書を布教すれば、打ち合わせの質が上がって楽できるのでは…！
はじめに
対象
- 議論ができてるつもりのITエンジニア向け。
俺たちは雰囲気で議論をやっている
「ぜんぜんわからない 俺たちは雰囲気で議論をやっている」
物事には必ず規範が存在する
規範とは、判断や行動の基準となる原則や価値観のことで、目に見えにくい土台とも言えます。
ITエンジニア向けにいくつか例を出すと、DRY原則・YAGNI原則などが規範に含まれるといえそうです。またデザインパターンのように、典型的な問題の解決方法はある程度確立されています。普段何気なく書いているコードに隠れている、意識しないと見えない規範です。
同じように議論においても、意識しないと見えてこない原理・原則が存在し、また議論の型としていくつかのモデルが用意されています。論拠を示す、論点を集中する、三段論法を活用するなどがこれに該当します。
つまり何も考えずに進めている議論は、プログラミングでいうところの、原理・原則やデザインパターンを無視したヤベー実装ということになります。そんなヤベー議論が至るところで行われているのが実情です。
ここからは私の話をしよう
ITエンジニアが議論する場は多いですが、最もこじれやすいのはプルリクエストです。次点、プロジェクトの方針を決める定例会議でしょうか。折衷案が取れないケースが揉めやすいです。
- A: レビュイー（レビューを受ける側の人）
- B: レビュワー（レビューをする側の人）
説明上、分かりにくいので以下、ABで進めます。
- 根拠・論拠が説明できない
- 会話例:
- B「ここはこうして」
- A「理由を教えてください」
- B「できないなら、私がやります」
- Aは修正理由となる根拠・論拠を求めています。一方でBは関係のない話題に切り替えると同時に、修正を行う方向で話を進めています。議論になっていません。
- 会話例:
- 伝統に訴える
- 会話例:
- B「これこれの方法で進めてください」
- A「今回のケースでは、その設計だと将来的に問題が出そうです。調査結果はIssueを参照してください」
- B「でももうこの方法で進めるって決まっているから」
- Aは将来的な懸念事項について論点を提示しています。Bは『決まっているから』という一点張りで、論点の正当性を問うことを避けています。
- 会話例:
具体的に起きた事例をデフォルメしています。頼むから議論をしてくれ、と何度思ったことか。プルリクエスト以外のミーティングやチャットも含めれば、まだまだ事例には事欠きません。
特に『伝統に訴える』例ですが、プロジェクト初期に策定した詰めの甘い設計に基づく全体方針の問題点が、個々の具体的な実装で発覚するのはよくあることです。極力問題点が出ないよう努めますが、もし出てきてしまった場合、土下座して設計の見直しと方針の調整を行います。
間違っても眼の前の問題から目を逸らし、その場限りの議論で論点をずらし、放置したままにしてよい事柄ではないのです。積み重ねていけばプロジェクトのコードは近いうちに破綻するのですから。しかし意識的に論理を組み立てていかなければ、目の前の議論は簡単にすれ違います。
議論を学ぶための第一歩
では少しでもマシな議論をするために、議論ひよっ子の我々はどうしたらよいのか。
『新版 議論のレッスン』
良書です。1,000円でお釣りが返ってきます。初心者向けです。まずはこの本だけでも読んでください。活字が苦手な方はせめて初級編まででいいので読んでください。IT業界でいうところの、『現場で役立つシステム設計の原則』くらいの本だと思います。
- ファシリテーション？
- 相手を言い負かす詭弁？
- 会議を円滑に進める段取？
そんなものはまともな議論の基礎を知ってからでも遅くありません。基礎がないのに小手先のテクニックだけ身に付けても、使い方を間違えるだけです。まず個々人が議論のルールを把握しなければ、優れた議論を始める前提すら整わず試合終了です。ルールがバラバラな訳ですから。
特に議論の勉強をしたことがないのであれば、我々はマジックナンバーすら見破れないひよっ子ITエンジニア同然です。そんなひよっ子が立派な鶏になれるくらいのポテンシャルを持つ本です。
『誤謬論入門』
A5判で400ページあります。が、全10章のうち第5章から9章までは、誤謬辞典という名のアンチパターン集です。IT業界でいうところの、『プリンシプル オブ プログラミング』と『SQLアンチパターン』を足したくらいの本だと思います。参考図書扱いで上げておきます。
『新版 議論のレッスン』よりは、ITエンジニアへのとっつきやすさに分がある本です。興味を惹かれた誤謬をいくつか読んでみて、肌に合いそうだと思ったら、最初からじっくり読むのが良いと思います。会議や日常生活の中で経験したことのある誤謬だとかなり共感できます。
常に議論を意識する
ITエンジニアであれば、以下のようなあらゆる場面です。
- 日常会話
- 朝会・夕会
- 業務のチャット
- ミーティング・定例
- プルリクエスト
- ドキュメント
常に議論の基礎を意識しながら過ごしてみましょう。最初は自分が話すときに意識するのは難しいので、まずは誰かが話したり書いたりしている文章の主張や根拠を探してみてください。詳細な方法や原理・原則は各書籍で詳しく説明されていますので、あえてここでは語りません。
おわりに
この記事がきっかけで、少しでも建設的な優れた議論が増えたら、それはとっても嬉しいなって。
Discussion