【チーム開発】頭で理解はしているが心が納得していない状況の方が多くなるので、議論では折り合いを付けると共に、自身のストレスを上手く解消しよう
はじめに
対象
- 話し合いで妥協することが多いが、これで合ってるか迷っているメンバー向け。
前提知識
本記事は二重過程理論と認知的不協和の知識を前提に話を展開します。このためこれらの用語を知らない方は、先に以下の記事を読むことをおすすめします。
チーム開発における不協和の解消が抱える問題
頭で理解しているが心は納得していない
この現象自体はとても有名で、他にも様々な角度から解説されています。これを先述の二重過程理論・認知的不協和を用いて解釈を試みてみましょう。
さて二重過程理論では、異なる2つのシステムが推論を行うと説明をしました。頭で理解するのに用いるのはシステム2であり、心で納得するのに用いられるのはシステム1です。つまりここでは両システムによって推論された結果に、矛盾が生じているということになります。
- 認知1: 心は納得していない - システム1
- 認知2: 頭で理解している - システム2
さて現実問題どちらかが100%合っている・間違っているということはない筈です。有り体な表現ですが人の心は割り切れないものですし、議論における提案にはメリット・デメリットの両方があります。チーム開発ではよくこの認知的不協和に遭遇します。
話し合う人数が3人以上ともなれば、完全に特定の個人に納得のいく形で結論が出るのは、誰かの中の正解と一致したまま提案が通ったときくらいでしょうか。その他大勢は何らかの折り合いを付ける側になるので、頻度として譲り合いや妥協の方が多くなるのは当たり前です。
自己完結するか他の何かに向けるか
さて「狐と酸っぱい葡萄」を覚えているでしょうか。
狐はその点、賢くはありませんが、愚かではなかったように思います。
狐は自己完結しました。もし他の手段が使えたら、どうだったでしょうか。
- 鳥にお願いして獲ってもらい山分けする。
- カゴに化けて人間を騙し、葡萄をいただいて逃げる。
- 葡萄の木に八つ当たりする。
1つめは童話の象徴としての狐らしくはありませんが、誰も不幸にはしていませんね。対して残り2つは道徳的に問題があるかもしれません。対岸の火事と笑えない理由があるとすれば、これをチーム開発での議論の真っ只中でやらかしてしまうことがあるという点で。
前項のようにシステム1とシステム2の間で、認知的不協和が発生するまではよいのです。問題はこの不協和状態の解消が、チームの中でどのように行われているかということです。
安易に自己完結型が良いとは言えません。貯めたストレスは退社後や休日に別の場所で発散されるでしょうが、そんなストレスをもらうなら真面目に議論する意義を見いだせないと、心が離れていっている可能性はあるでしょう。特定の人からしか意見が出ない会議の完成です。
またこれはもっての他ですが、何らかの不正行為や議論妨害など、チーム開発にとって最悪の形で出ることもあります。心理的安全性の低い現場にはしたくありません。
現場レベルで理解する不協和の解消
あいつの言うことは正しいがあいつは嫌いだ
そうはいっても人間ですから、どんなに綺麗事を並べても感情で動きます。同じくらい仕事のできる部下がいたら、飲み会に来てくれて仲が良い方の部下を昇進させるでしょう。とはいえ明らかに優劣が決している意見でも、言った人によって採用・不採用を決めるのは問題です。
映画やドラマでは「あいつの言うことは正しいが、あいつは嫌いだ」という台詞が格好良く使われていますが、世の中全部あれで回っていたら苦労はしません。実際のプロジェクト会議では、何を言ったかではなく誰が言ったかで結論を出してしまうケースがあります。
システム2が正しいと評価した意見を、システム1が人の好き嫌いで否定しようとするケースですね。この場合、暴走しているのは醜悪な黒い馬です。
もちろんこの好き・嫌いが経験に基づく危険察知であれば、素直に従うこともあるかもしれませんが。であればシステム2で検証した際、明らかな誤りや大きなデメリットを発見できるでしょう。だからこの場合は、完全にプライベートな、議論の内容とは無関係の好き嫌いのことです。
まだ心の中だけで自己完結できればよいのですが、ストレス解消法が上手く確立できていないメンバーは、攻撃的な発言で追い詰めるような物言いをしてしまうことがあります。残念ながら矯正するのは難しく、多くはチームから剥がして隔離するしかありません。
新しい社内規則が営業の自由を奪う？
部署間のやり取りにルールが加わる、というのは社会人あるあるです。ことIT企業の開発と営業の間には、「開発の堪忍袋の緒が切れたときに、最低限のルールが追加される」ということがよくあります。どこに行っても大体似たような流れで、フェーズが違うだけという感じです。
- この種類の依頼を出す場合は、納期の3営業日前にすること。
- チケットを発行するときは、テンプレートに従うこと。
- 案件が発生したときは、人員・工数・予定を確保してから依頼すること。
彼らは決まって秒で、つまり直感的にシステム1でこう言います。
- 今まで通りでいい。不便になる。
- 営業に使える時間が減る。
- どうしてこんな敵対的なルールが制定されたのか。
実際、システム1は経験やバイアスに左右されやすいところがあります。もちろん開発側はルールと共に、システム2で検証したこれらの推論を共に提示するでしょう。
- 突発的な残業を減らせる。納期前に慌てなくていい。
- 開発側の手戻りやミスが減る。クレームも減る。
- 他案件との事前調整で、部署間のやり取りが円滑に進む。
全社で見たときはもちろん、営業部署側のメリットがあることも分かる筈です。
さてシステム1とシステム2、両方の認知が出揃ったところで。ルールの撤回に動くか、迎合したつもりでルールを破りまくるか、ルールの修正で折り合いを付けるか、新しいルールを甘んじて受け入れるか。
画面の前のあなたならどうしますか。今回は営業と開発でしたが、経理や総務、システム管理などでは他部署とのルールの折衝はあるあると思いますので、他人事と思わずに考えてみてください。
議論の結果として意見を変える
遊びに行くなら、海か山か。小学生の頃、ディベートの授業で議論した方もいるのではないでしょうか。議論の結果、意見を変えるというのは思っている以上に勇気が要るものです。
「お前！ 最初海派だったじゃんか……この裏切者！」
前言撤回は一見格好悪く見えますが、理由がしっかりしていれば実はそうでもないです。あまりにコロコロ意見を変えるのは別ですけども。前項の社内規則も含め、やはり現状維持バイアスはどこにでもありますね。自分が最初に出した意見は、誰だって可愛いものです。
議論を尽くした結果として意見を変えられる人は、システム2がシステム1を適切に制御できているとも言えます。非常に優秀な御者である証拠です。
システム2による客観的な評価と分析で、別の意見の方が優れていると認めて意見を変えることができる。この能力は一朝一夕に身に付くものではありません。まずシステム1とシステム2を明確に区別できているのが最低条件です。
システムの違いを認識できていないと本人も周囲も辛いと思います。論理的・客観的な事実を、感情的・主観的に否定として捉え、強く反発するのがデフォルト動作になるからです。何がなんでも自分の意見を通すことを前提に、論破するためだけに言動を尽くします。
意見を変えるなど、自己否定に繋がるため、もっての外です。
これは余談ですが、開発者は基本的には頭の回転が速い人が多いです。このため表面的なヒステリーや感情の噴出ではなく、論理的に筋が通っていない詭弁や屁理屈の類として、システム2を変に通して表に出てきます。きちんと発言内容を精査できないと見逃します。
仮にシステムの違いが区別できたとしても、メンバーの前で意見を変えるのは、人によってはとても簡単で、人によってはとても難しいことです。こればかりは個人で事情が異なりますので、自分と向き合って取っ掛かりを解消してくださいね。
解消せずに飲み込むこともまた必要
繰り返しになりますが、全員が納得するまで議論するのは無理です。なぜなら全員が100%納得して1つの結論を受け入れる、なんてことは現実的ではないからです。最終的にはその場で決定権を持つ者を説得、つまり理解させ納得させる競争になります。
そして話し合いの場において「頭で理解はしているが、心が納得していない」という状況を、自覚した上で上手く解消してやる必要があります。メンバーの誰かが白い馬と黒い馬の好き勝手にさせていると、チームが一気に機能不全になることは珍しくありません。
この状況で冷静に議論を進められるメンバーは、自分のプロジェクトでは誰でしょうか。黒い馬を暴走させまくっているメンバーはいませんか。システム2を全く使用しないで感覚だけで乗り切ろうとしているメンバーは。また自分自身は、そうなっていませんか？
もちろん話し合いで解消できるか、納得感60%くらいまで持っていけるのがベターですが。世の中そんなに上手くいかないので、狐のように自分の中で認知を変化させることで、折り合いをつけることも時に必要なんでないかと思います。
そしてそのストレスの捌け口を、その場でそのまま解消しようとするのではなく、趣味や娯楽などのチームへの損害が少ない手段に求めるのが無難ではないでしょうか。
おわりに
もしも常に自分の納得100%で進んでいるプロジェクトがあるとしたら、少しだけ周りを見てみた方が良いかも知れません。誰かが言葉を飲み込んで折り合いを付けている可能性があります。
それがもし説明や議論の不足によるものなら、補足や話し合いの時間をもう少しだけ取ることもできましょう。もしシステム1の暴走によるならば、システム2という御者によって誤りが正される機会になるかもしれません。
Discussion