異なる文化の開発組織を融合させるための3つのステップ【M&A後のCTOの役割】
コロナ禍において、多くの企業がテクノロジーを活用し、自社のビジネスを再定義するケースが多く見られました。また、ソフトウェア業界自体も成熟化が進んでいますが、そのような状況でも企業はさらなる成長を求められています。
その際に、成長手段の1つとしてM&Aが考えられます。そして、CTOは異なる文化の開発組織を融合し、ビジネスインパクトを生み出すことを求められます。しかし、異なる文化の組織を融合させることは容易ではありません。
今回は、前ZOZOテクノロジーズ執行役員CTOで、現BuySell Technologies 取締役CTO 今村さん(@kyuns)に「異なる文化の開発組織を融合させるためのCTOの役割」というテーマでお話を伺いました。
開発組織のPMI（組織統合）
M&Aを行うと、次にPMI（Post Merger Integration）と呼ばれる、統合プロセスが発生します。その際、CTOは開発組織を融合させるというミッションが課せられます。
このミッションへ取り組むには、以下の3つのステップを順に取り組んでいきます。
企業の状況により、順番が多少前後するケースはありますが、基本的には、組織のビジョンから制度へ落とし込み、それを社員に浸透させていきます。
各Stepを順に説明します。
Step 1. ビジョンやロードマップを策定する
M&Aの目的は、双方のシナジーを活かして価値を創出することです。そのため、M&A前からプロダクトがどのような大きな成長を描けるのかを考える必要があります。そして、M&Aの際には、それを双方の組織に対して説明することも重要です。
また、双方への説明以外にも、上記目的を実現させるために、CTOは開発組織の統合と変革を行うことが求められます。そのため、CTOのミッションは、組織のあるべき姿をビジョンとして掲げ、その実現までのロードマップを描き、それを浸透させることだと言えます。
具体的なタスクの一部を紹介します。
■ 組織課題の把握
M&Aは2つの組織を融合するものです。そのため、双方の組織が同等な成熟度であることは稀で、どちらか、もしくは双方の開発組織に課題が存在します。組織の成長のためには、その課題を始めに認識する必要があります。
その際に、日本CTO協会が公開しているDX Criteriaが役立ちます。このDX Criteriaを用いると、課題を効率的にリストアップできます。具体的かつ網羅的な評価項目があり、誰でも簡単に現状の組織や開発プロセスの課題を見つけることができます。
なお、現在は簡易診断ツールも提供されており、より使い始めるハードルが下がっています。
■ バリュー（行動指針）の策定
バリュー（行動指針）は、「理想の組織を実現するために、社員はどのように行動すべきか」を言語化したものです。 DX Criteriaでプロセス面の課題を見つけるのと同時に、社員が同じ価値観で行動できるよう、このようなバリューの策定が必要不可欠です。
1つの組織に融合するためには、それぞれが持っていたバリューを1つに揃える必要があります。その際に、どちらか一方の価値観に合わせようとすると、必ず失敗します。価値観を揃えていくためには、双方がお互いに歩み寄り、尊敬しあう姿勢が求められます。そのマインドを持ちながら、お互いが大事にしている価値観を踏まえて、新しいバリューを策定します。
例えば、開発組織の中には、デザインを重視している組織もあれば、デザインよりも開発のしやすさを重視する組織もあります。また、技術力にこだわりを持っている組織もあれば、プロダクトにこだわりを持つ組織、エンドユーザーを重視する組織など、様々な価値観を持った組織があります。これまで大切にしてきた価値観と相反する価値観を押し付けては、融合はうまくいきません。CTOは、社員インタビューやアンケートなどを実施し、社員が大切にしている価値観を発見、そして言語化すると良いでしょう。
このように、プロダクトや組織の課題と価値観を把握した上で、3年後の理想の組織をイメージします。理想の組織に至るまでに、どのような課題があるのか。その課題は、「どのような行動や価値観を持っていれば乗り越えることができるのか」「社員にどのような行動をしてほしいのか」を考えます。すると、自ずと浸透させるべきバリューが見えてきます。
■ 3カ年ロードマップの策定
プロセス面と価値観の側面の両面から開発組織のビジョン（あるべき姿）を策定します。その後、組織を変革させるための具体的なロードマップを策定します。実際に価値観のレベルまで組織を変えるには、3年程必要です。それ以上の期間が必要な場合は時間の掛けすぎです。逆に、3年未満だと定着まで至らないでしょう。そのため、3年間で、各年に何を達成させるのかを考え、ロードマップを組み立てていきます。
会社のフェーズや課題によって、どの順番で課題解決を行うべきかは異なりますが、過去の経験では、以下の流れで進めていきました。
【1年目】
1年目の前半では、組織状態と課題の把握を行います。そして、プロダクト面と組織面のどちらから着手すべきかを決め、優先度が高い方のビジョンを描きます。プロダクトのビジョンがない場合は、まずはプロダクトから着手すべきです。なぜならば、どのようなプロダクトを作るべきかが決まっていない状態では、どのような組織を作るべきなのかが定まらないからです。
そして、1年目の後半には、あらゆるものの仕組みを整えていきます。プロダクトをグロースさせるための仕組み、組織をスケールさせるための仕組み、両面の仕組みを構築します。
プロダクトをグロースさせるための仕組みとして、以下のものが挙げられます。
・KPI設計
・CI/CD導入
・開発ツール整備
・スクラム開発導入
また、組織をスケールさせるための仕組みとして、以下のものが挙げられます。
・採用基準の策定
・給与テーブルの策定
・評価制度の整備
・採用ブランディング強化
【2年目】
2年目は、1年目に構築した仕組みやオペレーションの磨き込みを行います。実際に運営してみた結果を受け、改善点や不足点に取り組んでいきます。
同時に、各セクションのリーダーの育成や採用を進め、権限移譲を進めていきます。
【3年目】
3年目は、1〜2年目に構築してきた仕組みの成果が見えてくる時期です。その成果を確認し、例え自分が居なかったとしても組織が成り立つ状態を目指します。
成果の確認は、エンジニア採用の増加人数を可視化したり、GitHubやJiraのチケットから一人あたりの生産性の向上の様子を可視化したりして行います。
また、2年目までには着手できなかった、より全社的な課題にも着手します。例えば、セキュリティ対策やリモートワーク環境の整備、フルフレックスが可能な労務制度や、福利厚生の充実といった課題です。
そして、制度面だけでなく、より若手の採用や育成に注力します。「採用して終わり」ではなく、若手にも抜擢の機会を提供することが重要です。若手を抜擢し、育成チャンスを提供することで、組織力の底上げが可能です。
Step 2. 人事制度と組織体制を見直し
このStepでは、人事制度や組織体制の見直しを行います。変革を推進するために、人員配置や人材採用だけでなく、評価制度や給与テーブルも見直します。
具体的なタスクの一部を紹介します。
■ 評価制度と給与テーブルの見直し
評価制度は非常に重要です。組織としてどのように成長していくのを正とするのかを定義します。そして、「優秀なエンジニア」の共通認識を揃えることができます。つまり、評価制度は組織の羅針盤だと言えます。
具体的には、評価制度の定義は、等級ごとの行動規範と給与レンジを定めていきます。等級制度は「ジェネラリスト」と「スペシャリスト」で、それぞれ異なる行動規範を定義します。そして、各等級ごとの具体的な行動規範に、前述のバリューを組み込んだものを定めていきます。
例えば、「Respect」というバリューがあったとします。リーダーに対しては「他部門に対して敬意を払い、丁寧なコミュニケーションを取る」のような、具体的な行動規範を定義します。一方、テックリードに対しては「周りのエンジニアに対して、技術やシステムの説明を丁寧にする」といった異なる行動規範を定義します。
そして、給与テーブルの設計時には、「どのレベルの組織を目指したいのか」を明確化することが重要です。GAFA、外資系企業、国内メガベンチャー、一般的なWeb企業、どのレベルのエンジニアを集めたいのかを定めると、自ずと給与テーブルの組み立て方も定まってきます。給与のベースラインは、求人情報としてオープンになっている情報から調べられます。
■ 組織体制の見直し
組織体制に正解は存在しません。しかし、特にM&A直後には、CTO直下にエンジニアを全員集約するのが良いでしょう。M&A直後は2つの組織を統合し、新しい文化を醸成していく必要があるため、各事業部にメンバーが散らばっている状態で、その文化醸成を実現させることは困難です。
また、階層もなるべく少なくするべきです。CTOとコミュニケーションを取るための階層が深くなれば、情報を適切に伝達する難易度に上がっていきます。階層が1つ深くなると、伝わる情報量が50%程度に低下します。CTO配下の階層は、部長・マネージャー・メンバーの3階層程度にすると良いでしょう。
そして、階層を減らすだけでなく、最初は2階層下のレイヤーまでは、CTOが直接コミュニケーションを取ることを推奨します。BuySell Technologiesでも、2階層下の部長・マネージャーレイヤーまでは、毎週1on1を実施しています。そして、定例MTGも部長とマネージャー陣まで実施しています。もちろん文化や仕組みの浸透が進めば、徐々に権限移譲も進めていきます。
しかし、部長・マネージャーのレイヤーまで直接見るにはコストが掛かります。そのため、業務負担を減らすために、CTO室などを組成し、作業をCTO個人ではなく、チームとして取り組める体制にすることも効果的です。
組織体制の見直しが完了したら、変化を促進する人材を重要なポストに登用していきます。既存のマネージャー陣の中には、変化に対して積極的な人と消極的な人がいます。周りから慕われていて、変化の要になるような人をチームの責任者に登用し、消極的な人は重要ではないチームの責任者にずらすことも検討します。場合によっては、若手層からの抜擢も行います。
Step 3. 社員へ文化を浸透させる
最後のStepでは、これまでに策定してきたビジョンや制度を、新しい組織でカルチャーとして浸透させ、具体的な変化を促し続ける段階です。時には、組織間のハレーションが生じることもあります。しかし、これらの問題を乗り越え続けることで、組織全体の変化が実現されます。
具体的なタスクの一部を紹介します。
■ 経営陣と社員からの信頼の獲得
組織に変化を促すためには、経営陣や社員からの信頼を獲得する必要があります。信頼を得るためには、結果を出すしかありません。その「結果」も定義は様々です。業績も結果の1つですが、開発プロセスを良い方向に改善することも結果と言えます。また、誰も解決できなかった技術課題を解決することも結果です。
なお、信頼を得ていくためには、経営陣が期待することをしっかり実現していくことが先決です。
■ マネージャー陣への変化の促進
特に、マネージャー陣には「変化しないと死ぬ」という危機感と、「変化をリードしなければならない」という責任感を醸成する必要があります。そのため、常に様々な角度からメッセージを伝えていきます。
変化に積極的なマネージャーもいれば、消極的なマネージャーもいます。後者のマネージャーに対しては、「あなたが変わらないのは自由だけど、メンバーが変わる機会は奪わないように」と、厳しいメッセージを伝えることも必要です。それでも変化できなかったり、周囲の変化に対してマイナスの影響を与えているマネージャーに対しては、ポジションを変えていくことも行います。
■ データを用いた建設的な衝突
社員の中には、今までのやり方に固執しすぎて、新しい環境で結果が出せていないケースもあります。その場合は、データを元に建設的な議論をすることが重要です。
本当にこだわりを持っていて、自信があるならば、その結果が何かしらの数値として表れているはずです。データを用いた議論をすることで、データドリブンなカルチャーの醸成も同時に進んでいきます。
例えば、UIデザインの意思決定時に、デザイナーとエンジニアが揉めることがあります。「デザイナーの感覚ではA案が良いが、エンジニアとしてはガイドラインに則ったデザインで実装したい」といったケースです。そのような際には、A/Bをテストを実施し、実際のデータを見て決めていきます。
A/Bテストを実施しない場合には、デザイナー側が妥協するケースが多いです。しかし、データを元にした意思決定をすることで、お互いが納得の上で結論を出せます。そのため、なるべくアイディアは否定せずに、A/Bテストなどで実際に試してみることを推奨します。
■ 変化への評価の継続
社員に変化を促進するためには、評価制度を有効活用することが肝です。評価の度に、「前期にはできなかったが、今はできるようになったこと」を記録し、評価・フィードバックをし続けます。 ZOZOに在籍していたときは、3年間、エンジニア全員の評価面談を実施し続けましたが、絶大な効果がありました。
また、その際に、「褒める」のではなく「感謝する」ことを心がけています。「褒める」という行為は、上から目線であると感じるので、「感謝する」ことにしています。
■ 社員同士の揉め事の解決
当然、異なる文化で、異なるプロセスを持つ集団と混ざることは、エンジニアのモチベーションを下げ、揉める要因が増加します。しかし、M&Aは自分たちだけでは実現できない、大きなチャレンジを可能とする機会でもあります。
そのため、「M&Aによって、プロダクト面・技術面でどのような大きなチャレンジができるのか」をしっかりメンバーレイヤーにも説明することが重要です。また、文化が異なっていても、目指しているゴールは一緒です。敵対視したり、揉める必要がないことを、逐一説明することも重要です。
それらを乗り越えた先に、プロダクトや組織の大きな成長が待っています。
おわりに
M&Aは、成立後のPMI（Post Merger Integration）が最も重要です。PMIのプロセスでは様々な問題に直面しますが、それを乗り越え、価値を生み出すことがCTOには求められます。それは、難しくもありますが、やりがいのあるチャレンジです。
組織によって状況は異なるので、各組織でぞれぞれの施策を考えていく必要があります。その際に、本記事で紹介したノウハウが参考になれば幸いです。