本記事は、1時間で読み終わるエンジニアリングマネジメント本を書き始めてみるで挙げたトピックの1つです。

はじめに

業務では、何らかの選択肢の中から1つを選ばないといけない場面が頻繁にあります。

エンジニアリングチームであれば、設計方針をどうするか、どの技術を採用するか、といった判断が日常的に発生します。プロダクトマネジメントでも、どの施策を続けるか、どの機能を優先するか、といった意思決定が必要になります。

そのときの決め方にはいくつかあります。リーダーが決めるのも1つですし、多数決で投票して決めるのも1つです。ほかにも、アジャイル界隈であればfist to fiveのような方法もあります。

このうち多数決は、比較的よく使われる選択肢の1つだと思います。選挙でも使われる方法なので、広く浸透しているのが強い理由の1つでしょう。

この多数決は、全員の意見を出すので一見公平に見えるかもしれません。ですが、実際にはそう単純ではありません。多数決にはデメリットが多くあります。代表的なものは、考慮されない意見の圧殺です。たとえば、文化祭の出し物を決める場合に多数決を使った場合、少数派の意見は切り捨てられるといったようにです。

個人的な意見では、多数決を意思決定のデフォルトの選択肢にしないほうが良い、というのが私の考えです。

多数決の問題

業務における多数決の問題は、少なくとも2つ大きな問題があると私は考えています。

最適解が選ばれるとは限らない

多数決は、「いちばん支持された案」を選ぶ仕組みであって、「いちばん良い案」を選ぶ仕組みではありません。

これが問題になりやすいのは、特にクリエイティブさや長期的な視点が必要な場面です。たとえば、選択肢のなかには、癖があるが独創的で長期的な価値をもたらすものがあります。ところが多数決では、こうした案が不利になりやすいです。理解しやすく、説明しやすく、無難な案が勝ちやすいからです。この辺りは、逆説のスタートアップ思考を読むと、よりイメージしやすいかもしれません。

いずれにせよ、平凡な意思決定に収束しやすくなります。短期的には納得感があるように見えても、最終的なアウトカムにつながりにくいのです。

やり方をミスると、ものすごく時間がかかる

もう1つの問題は、やり方を誤ると非常に遅くなることです。

多数決には、各人が内容を理解し（必要なら再説明して）、全員が投票して、結果をまとめる必要があります。人数が増えるほど、この一連のコストは急激に重くなります。

特に面倒なのは欠席している人がいて、投票が集まらない場合です。そうなると、意思決定が延期されてしまいます。

現代では、意思決定のスピード自体が競争優位の1つです。決まるのが遅ければ機会損失になります。逆に、すばやく決めてすばやく試せるなら、多少の粗さは後から修正できます。意思決定の速度を失うのは、かなりの痛手になります。

なお、多数決が向いている場面とコツもある

もちろん、多数決が全部悪いわけではありません。たとえば、飲み会の店、振り返りでちょっとしたネクストアクションを決めるなど、失敗しても影響が小さい場面では有効です。

また、多数決にもコツがあります。それはvote数を1つに決めないことです。では何個にしたらいいかというと、選択肢の半分ぐらいのvote数が良いでしょう。この辺りは、詳しくは 『きめ方」の論理　──社会的決定理論への招待』を参照ください。

では、どうやって決めるのがいいのか？

個人的には、参加者の意見は取り入れつつ、誰か意思決定者を1人決めて、その人が決めてしまうのが良いと考えています。

理由は単純で、責任の所在が明確になり、決定が速くなり、文脈を踏まえた判断がしやすいからです。

意思決定は、単に票を数える作業ではありません。文脈を考慮し、選択肢のトレードオフを比較し、最後に組織としてどちらを取るかを決める作業です。ここでは、参加者全員の嗜好を均等に反映させることより、全体として良いアウトカムにつながるかどうかのほうが重要です。前述の通り、この方法であれば一定のスピード感を保ちやすく、試行錯誤もやりやすくなります。

実際の運用

実際には、以下のようなステップで意思決定するのが良いでしょう。

  1. 論点と選択肢を先に整理する
  2. 関係者から意見、懸念、前提条件を集めて、1に反映する
  3. 最終決定者が判断する、その際「なぜその案を選んだのか」をドキュメントに残しておく
  4. 周知する。必要に応じて、特に影響を受ける人には個別に説明する

この流れを事前に明確にしておくと、「全員の意見を聞いたのに、なぜ反映されないのか」という不満を減らしやすくなります。

大事なのは、全員の意見を全部採用することではありません。全員の意見を聞いたうえで、何を採用して、 何を捨てたか を明確にすることです。

採用されなかった意見への対処

もちろん、集めた意見の中には、最終案にまったく反映されないものもあります。

ですが、それをそのまま放置しないための手当てはできます。意思決定の記録として「こういう理由から、この案を選んだ」と残しておくことと良いでしょう。必要であれば個別に話をして、懸念点がどこで扱われたのかを説明すること。これだけでも、納得感はかなり違います。

全員の案を採用できないこと自体は、悪ではありませんし、そもそも現実的ではありません。問題になりやすいのは、議論が不透明で、なぜその案が選ばれたのかがわからないことです。

まとめ

多数決をデフォルトの選択肢にするのは、あまりおすすめしません。 参加者の意見は広く取り入れつつ、最後は一人の意思決定者が決める。これが、速度と質の両方を保ちやすいやり方だと考えています。