組織の意思決定で失敗しないための具体的な方法

組織で仕事をすることで多くの資源（ヒト・モノ・カネ）を使うことができるようになり、より大きな仕事ができるようになります。
しかし、一人で仕事する場合と比べて優れた意思決定ができるとは限らず、せっかく多くの資源を用いて仕事をしたとしても、仕事の方向性を誤ることがあります。むしろ、組織の中で意思決定するからこそ、誤った意思決定をしてしまう可能性がある。

この記事では、そのような意思決定がなぜ行われるのか、そして、それをどのように防げば良いのかを書いていきます。

また、組織で仕事をする上では、自分が推す案とは異なる意思決定がされることがあり、その場合にも組織として一貫性のある行動が行われるように協力する必要があります。
この記事では、どのような心構えで協力すれば良いのかについても書きます。

(1)集団浅慮の考慮

組織で意思決定を行うことで誤った結論や行動が導き出されてしまうことを「集団浅慮（グループ・シンク）」と呼びます。

バランスの良い意志決定を行うためには、特定の議題に対して、肯定・否定の両方の視点からの検討が必要です。
仮に、一人で意思決定を行った場合に肯定・否定の両方の視点を上手く取り入れられたとしても、組織ではそれが難しくなる場合があります。

具体的には、以下のような要素が存在する場合に、それが難しくなります。

・組織に対する帰属意識が高い

イエスマンとして組織についていくことが目的になる恐れがあり、多様な意見が出てきにくくなる。

・外部情報が入ってこない

物事を客観的に判断したり、さまざまな角度から見直したりすることが難しくなる。

・一部の人物の権力や影響力が強い

一部の人物の意見が重用されやすくなり、多様な意見が出てきにくくなる。

・決定事項に関係者の利害が絡む

各関係者が、自分に有利になるような特定の結論に導くのを目的に議論するようになる恐れがある。
（全体最適な結論に導くのが難しくなる）

・ノルマや時間に追われている

結論を出したり行動したりすることが目的になり、内容を深く検討することが難しくなる。
（短期的に見れば早急に行動した方が良い場合も多いが、長期的に見て望ましくない方向に進みやすくなる）

実例としては軍事の例が挙げられることが多く、例えば、第二次世界大戦で降伏の判断が遅れた日本政府の例は集団浅慮であると言われています。
また、戦後のアメリカのピッグス湾事件やチャレンジャー号爆発事故等も集団浅慮の例として取り上げられることが多いです。

集団浅慮を防ぐためには、以下のような方法が有効です。

・啓蒙活動を行う

「多様な意見を出すこと」「外部の意見を取り入れること」「中立な立場を守ること」「全体最適を考えること」等の意識を啓蒙することで、集団浅慮は起こりにくくなる。

・集団の在り方を変える

集団をどのように構成するかを変えることで、人間関係が変わり、集団浅慮を招く要素が解消されることがある。
例えば、「集団を小グループに分けて意思決定を行い、次にこれらの結論を持ち寄って集団としての意思決定を行う」という「バス・セッション法」と呼ばれる仕組みを導入することで、多様な意見が出やすくなり、集団浅慮が起こりにくくなる。

・稚拙な意思決定は例外事項とする

ノルマや時間に追われている場合は稚拙な意思決定も致し方ない場合もある。
しかし、これは例外事項として扱い、次回からは稚拙な意思決定を防ぐ仕組みを整備しそれを守らせる、ということを徹底するのが重要である。

(2)意思決定者の意向を汲んだ行動

組織での意思決定では、自分に最終的な決定権がないという状況が往々にして起こり得えます。
具体的には、取引先や上位会社、上司、先輩の決定に従わざるを得ない、ということが少なくありません。

集団浅慮ではない合理的なプロセスを踏んでいたとしても、最終的な意思決定が、自分の意に沿わないものであることもあります。
しかし、組織で活動する上では、自分が推す案に拘り、無理に押し通そうとするのは賢い判断ではありません。
自分の方が折れて、組織としての決定に従い、それに基づいた行動をすることが賢い判断です。

しかし、自分が異なる意見を推していたということは、組織で決定した結論には何かしらの問題があることに気付いているはずです。
組織としての結論を覆さない形で、かつ実作業に近い細かいレベルで、問題を解消する方法を提案するのが賢い判断です。

例えば、Javaのコーディング規約を検討している時に、「業務ロジックが膨大というシステムの性質からして人海戦術に頼らざるを得ない」ということを重視し、組織として「習得者が多くないラムダ式は使用禁止とする」という決定をしたとします。
また、自分がリーダーポジションの技術者であり、ラムダ式の利点を理解した上でラムダ式を使いたいと思っていたとします。
ここで、組織としての決定を無視するような形でラムダ式を使うのは賢い判断ではありません。ソースコードが統一的な書き方をされなくなることにより可読性や保守性が低下したり、組織内で衝突を生んだりする恐れがあるためでです。
その代わり、「共通処理に関しては、実装する技術者が限定され、どの技術者も一定以上のレベルであるため、共通処理に限りラムダ式を使わせて欲しい」といった形で提案をすることが賢い判断です。このような提案であれば通る可能性が高く、通れば組織としての決定を無視しない形で、快適に作業することができるようになります。

前回の記事に続いて、ソフトスキル関連の記事でした。

先日、株式会社サイゼントから書籍「絶対にJavaプログラマーになりたい人へ」を発売し、お陰様でご好評いただいています。
感想も寄せられ、今まで気づいていなかった要望があることに気付くこともできました。
要望に応えるため、新たな執筆活動に取り掛かりました。
ブログの執筆に時間を割くことが難しくなってしまいますが、続報にご期待ください！

上記の書籍は、Javaプログラマーとしてのキャリアをスタートしたい人向けのプログラミングスクール「サイゼントアカデミー」でも用いています。
書籍の執筆を通して、スクールのコンテンツもどんどん改善したいと思います！