M&A後にエンジニアが大量離職する最大の引き金は「技術的な裁量の喪失」だ。Day 1のCTOメッセージで意思決定プロセスとスケジュールを明示し、最初の100日でキーパーソンを特定してリテンション施策を実行することが離職連鎖を防ぐ鍵になる。技術スタックの統合計画よりも先に、誰が何を決めるのかを明らかにする——これがPMI（Post Merger Integration）における技術組織マネジメントの原則だ。

TL;DR（この記事の要約）

• M&A後にエンジニアが大量離職するのは珍しくない。技術人材の流出は買収価値の毀損に直結する

• PMIの成否はエンジニア組織の統合設計にかかっている。財務・法務の統合より難度が高い

• 統合初期の「100日計画」で技術スタック・開発プロセス・評価制度の統合方針を明示することが離職防止の鍵

• エンジニアが最も不安を感じるのは「自分の技術的な裁量が奪われること」。意思決定権の所在を早期に明確にする

• リテンションボーナスは有効だが単独では効かない。技術的裁量・キャリアパスとセットで設計する

• 買収側・被買収側の対等な技術文化の融合を設計し、一方的な吸収にしないことが長期的な成功条件

このページでわかること

M&Aによる技術組織統合（PMI）において、エンジニアの離職を防ぎながらチームを統合するための実践手法を解説する。

• M&A後にエンジニアが辞める構造的な理由

• PMI初期にやるべきエンジニア向けコミュニケーション設計

• 技術スタック・開発プロセスの統合判断フレームワーク

• 評価制度・報酬体系の統合で注意すべきポイント

• 統合後の採用戦略の再構築とKPI設計

前提となる市場環境

統計データ：経済産業省「IT人材需給に関する調査」（2019年3月公表）によると、2030年時点で国内のIT人材は最大約79万人が不足すると試算されている。

この需給ギャップがPMIの難度を押し上げている。転職市場が売り手優位である以上、統合に不満を持ったエンジニアは「辞めても次がある」状態にある。買収によって獲得したはずの技術人材が、統合プロセスの設計ミスだけで流出するという構図だ。とりわけAI・DX関連のスタートアップ買収では、技術と人材をまとめて獲得する「アクハイヤー型」の性格が強く、人材が残らなければ買収の目的そのものが失われる。

1. M&A後にエンジニアが辞める5つの構造的理由

M&Aの発表直後から、エンジニアの頭の中では「残るか、辞めるか」の計算が始まる。エンジニアの離職理由は一般社員とは異なる構造を持っている。整理すると次の5つに集約される。

1. 技術的な裁量の喪失への恐怖：エンジニアにとって最重要なモチベーション源は「技術的な意思決定権」だ。使用する言語・フレームワーク・アーキテクチャの選定、開発プロセスの設計——これらが買収側の方針で一方的に制限されると、優秀なエンジニアほど早期に離職する。スタートアップで「自分たちが選んだ技術スタック」で開発してきたエンジニアにとって、大企業の標準化されたスタックへの強制移行は「技術者としてのアイデンティティの否定」と受け取られることがある。

2. キャリアパスの不透明化：統合後の組織でどのようなポジションになるのか、昇進の基準がどう変わるのかが見えなくなる。キャリアパス設計が統合後に再構築されていない場合、将来への不安が離職のトリガーになる。

3. 文化的な衝突：開発文化の違いは技術スタックの違い以上に深刻だ。コードレビューの厳しさ、デプロイ頻度、ドキュメント文化、心理的安全性のレベル——こうした「日々の当たり前」が変わることは大きなストレスになる。スタートアップのスピード重視の文化と、大企業の承認プロセス重視の文化が衝突するのは典型的なパターンだ。

4. 報酬・待遇のミスマッチ：買収側と被買収側で報酬体系が異なる場合、統合プロセスで不利益を被る側が離職するのは当然だ。特にストックオプションが関わる場合、M&Aによってオプションの条件が変わることがエンジニアの不満の火種になる。

5. 「仲間」の離脱による連鎖退職：エンジニアチームでは、信頼するリーダーやメンターの退職が連鎖退職を引き起こしやすい。1人のキーパーソンが辞めると「あの人が辞めるなら自分も」という心理が働き、チーム全体が崩壊するリスクがある。コアメンバー1人の離職が複数名の連鎖退職に発展することも珍しくない。

この5つのうち、金銭で解決できるのは4だけだ。残る4つはコミュニケーション設計と組織設計の問題であり、だからこそPMIは「お金をかければ何とかなる」領域ではない。

2. PMI初期の100日計画｜エンジニア組織統合のロードマップ

M&A成立後の最初の100日は「ゴールデンタイム」と呼ばれる。この期間に適切なアクションを取れるかどうかが統合の成否を決定づける。逆に言えば、この100日で不信感が定着すると、その後どれだけ手厚い施策を打っても回復には数倍の時間がかかる。

Day 1〜7：安心感の提供とビジョンの共有

M&A発表直後、エンジニアが知りたいのは3点だ。①自分のポジション・チームはどうなるのか、②使っている技術スタック・開発プロセスは変わるのか、③報酬・待遇に変更があるのか。これらに対して、決まっていることは明確に、決まっていないことは「決定プロセスとスケジュール」を伝えることが重要だ。「未定」と「未定であることを伝えていない」はまったく違う。

Day 1にやるべきこと（優先順）:

1. CTOまたは技術責任者から全エンジニア向けのメッセージ発信（文章＋ライブQ&A）

2. FAQ文書の作成と共有（報酬・ポジション・技術方針について）

3. 1on1の実施スケジュールの告知（全エンジニアと2週間以内に実施）

4. Slackなどでの質問受付チャネルの開設（匿名投稿を可能にする）

5. 「統合に関するアップデートは毎週○曜日に発信する」というリズムの宣言

特に5は軽視されがちだが効果が大きい。情報が出てくる頻度が約束されていれば、エンジニアは「次の金曜には何か分かる」と考えて待てる。約束がなければ、沈黙のたびに最悪のシナリオを想像することになる。

Day 7〜30：1on1による個別ケアとキーパーソン特定

全エンジニアとの1on1を通じて把握すること：現在の業務内容・技術的な強みとキャリア志向・M&Aに対する率直な不安・残留意向と条件。この過程でチームにとって不可欠な「キーパーソン」を特定し、優先的にリテンション施策を講じる。

注意すべきは、キーパーソンが必ずしも役職者と一致しないことだ。組織図の上位者ではなく、Slackで最も質問が集まる人・レビュー依頼が集中する人を見ることで、実態としてのキーパーソンが浮かび上がる。

Day 30〜100：技術統合方針の策定と実行

技術スタック・開発プロセスの統合方針を策定し、統合後の評価制度・報酬体系を整備する。100日の終わりに目指す状態：①全エンジニアが統合後の組織構造と自分のポジションを理解している、②技術スタック・開発プロセスの統合ロードマップが共有されている、③キーパーソンのリテンション施策が実行済み、④両チームの混成プロジェクトが少なくとも1つ始動している。

100日計画チェックリスト（抜粋）:

3. 技術スタック・開発プロセスの統合判断フレームワーク

技術スタックの統合は、PMIで最も慎重に進めるべき領域だ。拙速な統合はエンジニアの離職を加速させ、段階を踏まない統合はシステムの信頼性を損なう。

4つの統合パターンと選択基準

統合の選択肢は「全部統合するか、しないか」の二択ではない。実務上は次の4パターンから選ぶことになる。

1. 完全統合：一方のスタックに全面移行する。技術スタックが類似しており、片方が明らかに優位な場合に適する。移行コストは高いが、統合後の運用は最もシンプルになる。

2. 段階的統合：新規開発から順に統一し、既存システムは当面維持する。異なるスタックだが長期的には統一したい場合の現実解。移行期間中は両方のスキルセットが必要になる点に注意する。

3. 共存型：両方のスタックを維持し、API連携でつなぐ。事業ドメインが異なり統合メリットが薄い場合に適する。「統合しない」という意思決定も立派な戦略だ。

4. ベスト・オブ・ブリード：両社の良い部分を選択的に採用する。両社にそれぞれ強みのある技術領域がある場合に機能するが、選定プロセスの公平性を担保しないと政治問題化しやすい。

統合判断で考慮すべき主要観点は3つある。ビジネスインパクト（統合コストとメリットの天秤）、エンジニアの感情的インパクト（技術スタックはアイデンティティの一部。統合理由を論理的に説明し学習支援を手厚く）、採用市場への影響（レガシースタックへの統一は新規採用を困難にするリスクがある）。3つ目は特に見落とされやすい。統合の結果として採用競争力が落ちれば、離職の穴を埋めることすらできなくなる。

開発ツール・インフラの統合優先度

一度に統合するのではなく、優先度をつけて段階的に進めることが現実的だ。

優先度：高（1ヶ月以内）：コミュニケーションツール（Slack/Teams）、チケット管理（Jira/Linear）、インシデント管理ツール。ここが分断されていると、そもそも協働が始まらない。

優先度：中（3ヶ月以内）：ソースコード管理（GitHub/GitLab）、CI/CDパイプライン、モニタリング・オブザーバビリティツール。

優先度：低（6ヶ月以上）：IDEやエディタ（統一を強制しない）、社内ドキュメント基盤、開発用マシンスペック。エディタの統一を求めるのは統合の中で最も反発を買いやすく、かつ得るものが最も少ない。

4. エンジニアのリテンション施策｜キーパーソンを守る具体策

リテンションボーナス（Stay Bonus）の設計

M&A後の離職防止に最も直接的な手段だ。設計のポイントは次の4点になる。

1. 支給条件：統合完了後12〜24ヶ月の在籍を条件とする

2. 金額水準：年収の20〜50%を基本とし、キーパーソンには50〜100%を提示するケースもある

3. 支給タイミング：一括ではなく分割払い（6ヶ月後50%・12ヶ月後50%）が長期定着に効果的

4. 対象範囲：全員に薄く配るより、キーパーソンに絞って手厚く設計する方が費用対効果が高い

ただしリテンションボーナスには副作用がある。ベスティング期間が終わった瞬間に「義務は果たした」として離職する、いわゆる計画的離職を誘発しうる。金銭は離職を防ぐのではなく、離職を先送りにする施策だと理解しておくべきだ。先送りした期間中に、次に挙げる非金銭的な施策で本質的な定着理由を作れるかが勝負になる。

技術的な裁量の保証

金銭的インセンティブだけではエンジニアは残らない。技術的な裁量の保証はリテンションボーナス以上に重要な場合がある。

1. 統合後も一定期間（最低6ヶ月）は既存の技術スタックでの開発継続を約束する

2. 新スタックへの移行が必要な場合は学習支援制度を手厚く整備する

3. 技術的な意思決定に被買収側のエンジニアも参画できる仕組み（アーキテクチャレビュー会への常任参加など）を作る

キャリアパスの早期提示

統合後の組織で被買収側のエンジニアがどのようなキャリアを歩めるかを具体的に示す。統合後の技術組織図と各ポジションの役割を公開し、統合を機に新しい役割（統合プロジェクトリーダー、横断的なアーキテクト等）を設けると被買収側にキャリアアップの機会を示せる。統合は既存ポジションの奪い合いだと受け取られがちだが、新しい役割を作れば「統合したからこそ生まれた機会」に転換できる。

メンター・バディ制度の導入

買収側と被買収側のエンジニアを1対1でペアリングするメンター・バディ制度は、文化の融合を加速させる有効な手段だ。技術的なスキルレベルが近い者同士をペアリングし、週1回以上の定期的な交流・共同タスク（コードレビュー・ペアプロ）を組み込むと自然な関係構築が進む。上下関係を持ち込まないため、あえて「メンター」ではなく相互バディとして設計するのも一案だ。

情報の透明性と定期的なアップデート

週次または隔週の「統合アップデート」ミーティングを開催し、統合プロセスの進捗を定期的に共有する。エンジニアからの質問・フィードバックを匿名で受け付ける仕組みも重要だ。

リテンション施策の中で見落とされがちなのが、この「継続的な情報共有」だ。組織変更のアナウンス直後だけ丁寧に説明し、その後フェードアウトしてしまうパターンは、M&Aに限らず組織変更全般でよく起きる。私自身、採用支援の立場で組織再編期の企業と関わる中で、候補者面談の場で「実は社内で何が起きているのか自分たちも聞かされていない」と語られたことが何度かある。情報がない状態そのものが不満の温床になるのは、組織の存続に関わるM&Aでは特に影響が大きい。

具体的には次の3点を最低限実施する。

1. 統合に関する意思決定の経緯と理由をオープンに共有する

2. エンジニアからの質問・フィードバックを匿名で受け付けるSlackチャンネルを開設する

3. 統合の進捗をドキュメント化し、いつでも遡って確認できる状態にする

5. 報酬・評価制度の統合｜公平感と納得感の設計

報酬統合の3つのアプローチ

どのアプローチでも共通するのは、下方修正は事実上不可能だという点だ。報酬を下げれば該当者はほぼ確実に離職する。したがって統合の検討段階で「上げるコスト」を織り込んだ試算をしておく必要がある。

ストックオプション・RSUの扱い

スタートアップのM&Aでは被買収側のストックオプションの扱いが極めて重要だ。ベスティング条件の継続（M&Aによってリセットされると不満が爆発する）、買収側の新株予約権への公正な転換比率設計、現金化オプションの提供が主要な対応策になる。ここは法務・税務の論点でもあるため、技術組織の観点から「エンジニアが何を不公平と感じるか」を早期にインプットしておくことが望ましい。

評価制度統合の3原則

1. 移行期間を設ける：統合直後に新基準を適用しない。最低6ヶ月は旧基準を維持するか、新旧併用の移行期間を設ける

2. 被買収側の実績を正当に評価する：「買収されたから格下」という扱いをしない。等級のマッピングは技術的な実力ベースで行う

3. 透明性を確保する：評価基準・昇進条件・報酬レンジをすべて公開する。不透明さは不信感の最大の原因だ

6. 組織文化の融合｜一方的な吸収にしない統合設計

技術組織の統合で最も難しいのは「文化」の統合だ。技術スタックや報酬は数値化・比較できるが、文化は定量化が難しく、かつエンジニアの日々の幸福度に最も大きな影響を与える。

典型的な失敗パターン：「うちのやり方に合わせてください」型（被買収側のモチベーションが急降下）、「何も変えません」型（短期的に摩擦は少ないがサイロ化が進む）、「いいとこ取りを宣言するが実行しない」型（期待を裏切り信頼を失う）。3つ目が最も罪深い。宣言した以上は実行されると期待されるため、裏切られたときの落差が大きい。

文化融合の実践ステップ：

ステップ1：両社の開発文化を「見える化」する 意思決定プロセス（トップダウン vs ボトムアップ）、コミュニケーションスタイル（同期 vs 非同期）、品質基準（テストカバレッジ・コードレビューの基準）、開発速度の優先度、失敗への態度（ポストモーテム文化の有無）を整理して両チームに共有する。まず違いを可視化しないと、統合の議論が「どちらが正しいか」の水掛け論になる。

ステップ2：「統合ワーキンググループ」を組成する 両チームからエンジニアを選出し、文化統合の方針を一緒に議論・決定する場を作る。買収側だけで決めない、というのが最も重要な原則だ。ワーキンググループにはミドル層・ジュニア層も含めると多様な視点が得られる。

ステップ3：「共通の成功体験」を作る 文化の融合は議論だけでは進まない。両チームが混成チームとして一つのプロジェクトに取り組み、成功体験を共有することが最も効果的だ。統合後の新プロダクト・新機能の開発を混成チームで実施する、ハッカソンやテックイベントを合同で開催するなどの施策が有効だ。最初の混成プロジェクトは、あえて難度が低く成果が早く出るテーマを選ぶとよい。

7. 統合後の採用戦略の再構築

M&A後は採用戦略を根本から見直す必要がある。統合によって組織の規模・技術スタック・採用ブランドが変わるためだ。

採用ブランディングの再設計：「両社の技術力を統合し、より大きなプロダクトに挑戦できる環境」をアピールする。被買収側のブランドが技術力で知名度があれば安易に消さない。統合ストーリーをキャリアページやテックブログで発信し候補者の信頼を獲得する。候補者は必ず統合のニュースを見た上で応募してくるため、こちらから語らないと憶測で埋められる。

統合に伴う新たな人材ニーズ：両社のシステムを理解して連携を推進できる「ブリッジエンジニア」、インフラ・CI/CDの標準化を推進するプラットフォームエンジニア、大きくなったチームをリードできるテックリードが新たに必要になるケースが多い。

被買収企業の採用力を活かす：被買収企業が持っていた採用チャネル・タレントプール・リファラルネットワークは統合後も継続して活用すべき資産だ。被買収企業のエンジニアのリファラルネットワークを新組織の採用に活かすことが特に効果的だが、これは在籍エンジニアが統合に納得している場合にのみ機能する。不満を抱えた社員が知人を誘うことはない。リファラルの稼働状況は、統合の満足度を測る先行指標としても使える。

8. M&A特有の落とし穴と対策

落とし穴1：DDで技術組織を軽視する M&Aのデューデリジェンス（DD）では財務・法務・事業面に注目が集まり、技術組織の評価が不十分になりがちだ。DDの段階で「テクニカルDD」を実施し、次の観点を評価しておく。

1. 技術的負債の状態（アーキテクチャの健全性・テストカバレッジ・依存ライブラリの保守状況）

2. 属人化リスク（特定エンジニアしか触れない領域の有無とその範囲）

3. エンジニアの残留意向（可能な範囲でのキーパーソンの意向確認）

4. 技術スタックの採用市場での競争力（統合後に人を採れるスタックか）

落とし穴2：コミュニケーションの遅れ・不足 M&Aに関する情報が経営陣だけに留まり、現場のエンジニアに十分な情報が届かないことは非常に多い。法的な制約の範囲内で可能な限り早く、頻繁にコミュニケーションする。「決まったことだけ伝える」のではなく、「まだ決まっていないが、いつまでに決める」というスケジュールの共有も重要だ。

落とし穴3：統合を急ぎすぎる 「早く一つにしたい」という焦りから、エンジニアの感情を無視して統合を推し進めるケースがある。技術統合のロードマップは最低でも12〜18ヶ月の時間軸で計画する。

落とし穴4：被買収側を「二級市民」扱いする 意図的でなくても、統合後の意思決定プロセスで被買収側の意見が反映されにくい構造が生まれると、「自分たちは二級市民だ」という感覚が蔓延する。統合プロジェクトのリーダーシップに被買収側のエンジニアを意図的に起用することで、「一緒に作っている」という実感を生む。

落とし穴5：統合完了後にフォローをやめる 100日計画が終わり、形式的な統合が完了した後にフォローが途切れると、潜在的な不満が表面化して「遅延退職」（統合後6〜12ヶ月での離職）が増える。統合後6ヶ月・12ヶ月のタイミングでエンゲージメントサーベイを実施し、潜在的な問題を早期に検知する。

100日以降のフォロー設計

100日計画は「統合のスタートライン」であってゴールではない。むしろ離職リスクが再上昇するのは統合から6〜12ヶ月後だ。この時期には初期の混乱が収まる一方で、「結局この統合で自分の環境は良くなったのか」という冷静な評価が下される。

Day 100以降に設計しておくべき定点観測は次の通りだ。

1. 6ヶ月時点：エンゲージメントサーベイの実施と、統合前スコアとの比較。全社平均ではなく、買収側・被買収側を分けて集計することが重要

2. 9ヶ月時点：技術統合ロードマップの進捗レビュー。約束したスケジュールが守られているかを当事者に開示する

3. 12ヶ月時点：キーパーソン残存率の確認と、リテンションボーナス期間終了に向けた次の動機付けの設計

特に3は先手を打つ必要がある。ベスティング満了の直前に慌てて条件提示をしても、その時点で候補者はすでに他社の選考が進んでいることが多い。満了の3〜6ヶ月前には次のキャリア機会を提示する会話を始めておくべきだ。

9. 被買収企業が事前にできる準備

M&Aは買われる側にも準備が必要だ。スタートアップのCTO・経営者がM&A前にできることを整理する。

• エンジニアへの事前コミュニケーション：成約が決定した段階で、外部発表前にエンジニアチームへ直接説明する場を設ける。「ニュースで知った」は最悪だ

• 技術資産のドキュメント化：アーキテクチャ図・システム構成・ナレッジを整備し、特定エンジニアへの依存度を下げる。これは買収価値の向上にも直結する

• キーパーソンとの事前合意：主要エンジニアと「統合後も一定期間残る」という合意を取り付ける

• 企業文化の言語化：大切にしている価値観・開発の原則を言語化し、統合交渉で「これだけは守りたい」という主張の根拠にする

文化の言語化は交渉カードとして機能する。「弊社はデプロイ頻度を週次以上に保つことを重視してきた」と具体的に示せれば、統合後の開発プロセス設計で守るべきラインとして議論のテーブルに載せられる。

10. PMI成功度を測るKPI

KPIは経営会議に上げるだけでなく、エンジニア本人にも開示することを推奨する。「自分たちの状態が測られていて、経営がそれを気にしている」という事実そのものがメッセージになるからだ。

FAQ（よくある質問）

Q1. M&A後にエンジニアが辞めるピークの時期はいつですか？

一般的に2つのピークがある。①M&A発表直後の1〜3ヶ月（不安・不満による即時離職）と、②リテンションボーナスのベスティング期間終了後（12〜24ヶ月後）の「義務は果たした」計画的離職だ。前者はコミュニケーション設計で、後者はキャリア機会の提示で対処する。

Q2. リテンションボーナスの相場はどのくらいですか？

年収の20〜50%が一つの目安で、キーパーソンには年収の50〜100%を提示するケースもある。ただし金銭だけではエンジニアは残らない。技術的な裁量やキャリアパスとセットで設計することが重要だ。金額の大きさより、支給条件の分かりやすさと支給タイミングの設計が定着率を左右する。

Q3. 技術スタックが全く異なる場合、統合すべきですか？

必ずしも統合する必要はない。事業ドメインが異なる場合や統合コストがメリットを上回る場合は、共存型（API連携）を選択するのが合理的だ。「統合しない」という意思決定も立派な戦略であり、むしろ明示的に「統合しない」と宣言することでエンジニアの不安を解消できる。

Q4. 被買収側のCTOのポジションはどうすべきですか？

被買収側のCTOがチームのキーパーソンである場合が多く、処遇は慎重に検討する。VP of EngineeringやPrincipal Engineerなど明確な役割を用意するか、統合プロジェクトのリーダーに起用するのが効果的だ。「肩書きだけの閑職」は最悪の選択で、本人が辞めるだけでなく、周囲のエンジニアに「この会社は被買収側を大事にしない」という強いシグナルを送ってしまう。

Q5. 小規模なアクハイヤーでもPMIは必要ですか？

必要だ。むしろアクハイヤーは「人材の獲得」が目的なので、その人材が辞めては意味がなくなる。規模が小さい分、全員との1on1やリテンション施策を手厚く実施しやすいという利点を活かす。人数が少ないほど1人の離職がチームに与える打撃は大きい。

Q6. エンジニアの転職市場が活発な時期にM&Aが重なった場合、どう対応すべきですか？

エンジニアの転職活発期（1〜3月、7〜9月）にM&Aが重なると離職リスクが高まる。リテンション施策を前倒しで実行し、競合他社からのスカウトに対抗できる条件提示を迅速に行うことが重要だ。

Q7. 統合後の採用活動はいつから再開すべきですか？

統合方針が固まり組織構造が明確になった段階（一般的にDay 60〜100以降）から再開するのが望ましい。統合中に新規採用を行うと「自分たちの処遇より新規採用を優先するのか」という不信感を既存エンジニアに与えるリスクがある。

Q8. テクニカルDDは誰が実施すべきですか？

買収側のCTOまたはVP of Engineeringが主導し、必要に応じて外部の技術顧問を交えるのが一般的だ。財務DDの担当者が技術の健全性を評価するのは無理があるため、技術組織の評価は技術者が行う体制を確保する。DDの段階でキーパーソンの顔と役割を把握しておくと、Day 1以降のリテンション施策の立ち上がりが大きく変わる。

まとめ：エンジニア組織の統合は「技術」ではなく「人」の問題

M&A後のエンジニア組織統合は技術的な課題以上に人間的な課題だ。技術スタックの統合計画がいかに優れていても、働くエンジニアが離職してしまえば何の意味もない。

統合成功のための3原則：

1. 透明性：決まっていることもいないことも、誠実に伝え続ける

2. 対等性：買収した側・された側の上下関係を組織文化に持ち込まない

3. 段階性：急がず、エンジニアの感情と現場の実態に合わせて段階的に進める

M&Aは成長のための手段であり、ゴールではない。買収で得た技術と人材を最大限に活かすためのPMI設計が、M&Aの真の成否を決める。

エンジニア組織の統合やリテンション施策にお悩みの方は、techcellarの採用支援サービスにご相談ください。エンジニア採用の専門家が、M&A後の組織づくりもサポートします。