事業開発見習い日記

東京でBDやってる人の日記

有事のマネジメントと平時のマネジメント

とある日本企業でメガディール(クロスボーダー)を何件も経験した人の話を聞いた。その中で事業開発のマネジメントに関することが触れられていたので、思い出しながら書いてみる。たくさん示唆のあった話の中から、ここだけ取り出すのも非常に失礼かもしれないが、こういう基本的なところは大事だなと思ったので書いてみよう。

事業開発の組織のマネジメントは「有事のマネジメント」で、通常の事業の「平時のマネジメント」とはまったくちがう。

「平時のマネジメント」は階層でなりたっている。上に行けば行くほど多くの情報が集約され、意思決定は逆に上から下に下ろしていく。

不要な情報を下におろしてはいけないのは、各々が役割と目標を持っており、それに向かって全力を尽くしてもらうためだ。不用意な情報共有は、チームの混乱を招き、モチベーションを低下させる。そして、おまけに変な尾ひれがつく。

意思決定も広い範囲を見ている人が最も重要な判断を下すべきだ。それでないと組織が変な方向に向かってしまう。結果として、意思決定の影響度合いが、組織の階層と一致するようになっている。

一方で、「有事のマネジメント」は、タスクフォースである。重大な問題が起こった時のエスカレ先みたいなイメージだ。関与する社員が限定されるかわりに、完全な情報共有が行われることが望ましい。BDもこちら側だ。

なぜこんなことをするかというと、いくつか理由はある。

  • 圧倒的にスピードが大事。階層を切っているとまあ遅くて失敗する。共有もれも頻繁に発生する。
  • 意思決定が広範囲にわたり、問題を人に切り分けられない。たいていの問題は、システムと人事のトレードオフだったり、税務とガバナンスのトレードオフだったり、法務と買収価格のトレードオフだったりして、1人の専門家で片付く問題が存在しない。情報共有の階層を分けると、文脈を踏まえない検討をしてしまったりして、まず確実に最適解に至らない。
  • チームメンバーを信頼している証拠になる。メンバーとしては共有されない情報についてはサポートのしようがない。また、共有されていないことがあるとわかると、少なくとも共有されていないこと自体が、進行上の問題点として認識する。そして自分のアウトプットにも100%の自信を感じなくなる。(なぜなら正しい前提と文脈を踏まえてるとは思えないから)。また他人の判断ミスもカバーしようがなくなるので、結果として「それについては自分の責任範囲ではない」と言うようになってしまい、チームの求心力の低下を招く。
  • 社外に対して足並みをそろえる必要がある。当たり前だが、会社同士の交渉の場合、一丸となっていないと、交渉相手として信頼関係を築けない。

 事業開発組織は、基本的にリーダー(意思決定者)とメンバーしかおらず、階層は存在しないのが望ましい。意思決定のやり方は合議で決定するのが望ましい、というか、全ての専門的な観点を兼ね備えて判断する必要があるから、合議の上でリーダーが判断する、という方法しかない。

たぶんこんな感じだったはず。