マクドナルド理論の逆

最近しくじった話。

とあるテーマについて議論するミーティングに呼ばれた。アジェンダが丁寧に提示されていて時間もあったのと、自分にとって結構経験があるテーマだったので、事前に考えて一つの筋の通った意見を持っていた。

当日、参加者から意見を言うタイミングで、とりあえず積極的に発言する人がいなかったので、「手法Aが良いと思います。理由はこうです(浅い説明)」と発言した。

悪いことに、そこからとにかく議論が紛糾してしまった。手法Aは限定的な状況に使える手法で、安易に使ってしまうと後々厳しい状況になる。実際に自分たちの組織でも何度かその問題を起こしていた。一応、自分としては、今回の状況は問題にならない自信があったので提案したのだが、それを十分説明するには言葉足らずであった。

これは、「マクドナルド理論」の逆をいくような事例だったのではないか、と思った。マクドナルド理論とは、これだ。

「マクドナルド理論」を使うとより優れたアイデアが出てきてプロジェクトが進行する

ランチタイムにどこのお店に行く？という話になった時、「マクドナルドに行こうよ」と提案すると満場一致で「マクドナルドはやめようよ」と返され、不思議とよりよいアイデアが出てくる、というのがJon Bellさんの提唱する「マクドナルド理論」。

なんともマクドナルドに失礼な話ではあるが、一理あると思っている。ランチに行く店はどこだっていいのだ。さっさと有力な案が出て合意が取れるのがよい。何ならマクドナルドだって良いと思う。そんな中で、1つでも案が出ていれば、それがイヤなら反対するし、よければ賛成するし、とにかく意見を出させて話を前にすすめることができる。

さて、冒頭の僕の事例もこれに似ている。僕が手法Aを提案したところ、手法Aはやめてほしいと思っている人に強く反対されてしまう。ここまでは同じだ。

ではなにがまずかったのか。この議論において重要だったのは、ランチの行き先の話とは違って、結論よりもむしろその過程だったのだ。正直、手法AをとってもBをとってもこの件自体は問題なく進むだろうと思う。ただ、この件の性質はどうで、こうだから手法A/Bを選ぶのだ、とか、手法Aはこういう場合には選ぶべきではないが、こういう条件であれば選んでも良い、というような、より細かく汎用的な性質について理解できることのほうが重要だった。

このような状況で、そもそも今回の課題について共通理解を得られていない段階で、いきなり結論の一つを提案する、というのは非常に無謀で、議論を悪い方向に活性化させてしまうということを、身を持って学んだ。

代わりにやるべきだったのは、対象とする問題そのものを深く理解し、その場で共有されている状態を作ることだった。なんでも結論から入るのが正しいわけではない。とはいえ具体的な手法なしに理解するのは難しければ、「仮に手法Aをとるとすると、〜」のような入り方をすればよかったと思う。

まとめる。
・とにかくなんでもいいから結論が出れば良いときや、たくさんアイディアが出るのが重要な会議では、「マクドナルド理論」を積極的に使おう。
・結論よりも議論の過程こそが重要なときや、自分が深い思慮をもった意見を持っているときは、マクドナルド理論の逆で、いきなり結論の意見からぶつけるのを避け、前提となる共通理解を育むところから始めよう。

ちなみに、これを読んでくれている方の多くはソフトウェアエンジニアだと思うので、問題と手法Aと手法Bについても簡単に書いておく。
・問題は「ある共通的なロジックをどのように設計・実装するか」
・手法Aは「社内ライブラリ(gem)を用いる」
・手法Bは「マイクロサービスを作る」
もちろんこれだけでは判断できない話。どういう時なら社内ライブラリでもいいのか、という話題はそのうち気が向いたら書く。