はじめに
LITALICOの亀田( @kamesennin ) です。執行役員VPoEとして様々なことを行っています。
※ LITALICO Engineers Advent Calendar 2021 カレンダー2 の19日目の記事です。
本記事は「M&Aで役立つリバースエンジニアリング」と非常にニッチです。
どれくらいかというと毎年日本で行われるM&Aは3,000-4,000件のようです。
参考：日本企業のM＆Aが過去最多 2021年上半期 by 日本M&Aセンター
（よって大多数の方の役には立たないな？と書き終わりの段階で気づきましたが）
・Googleで調べると近しい情報はあまり見当たらないので、役に立つ可能性はありそうという思い
・貴重な機会だったため、学びを整理すれば、新たな気付きがあるのではという願い
という理由から、以下整理しました。
--
今年2021年の頭にLITALICO初のM&A（企業の合併と買収）による完全子会社化を行いました。
福祉ソフト株式会社 という福祉事業所向けの業務支援SaaSプロダクトを展開している長崎県の会社です。（主に請求業務の負担削減を担うプロダクト）
画像引用元：株式会社LITALICO 2021年３月期 第3四半期決算説明資料
僕は、PMI（M&A後の統合プロセス）でのプロダクト・システム・開発組織周辺を担当しています。
過去に事業譲渡や事業授受は何度か経験はありますが、グループ会社として一体となること、小さくはない規模で受け取る側になることは初めてでした。
前提の補足
福祉ソフト株式会社について
- プロダクト/システム
- 障害福祉領域の事業所向けで、国内No1の請求支援ソフト（2021年2月1日時点）
- システムは10年以上稼働、メインのエンジニアの方1名がほぼ開発（圧倒的リスペクト）、専任のデザイナー/PdMは不在
- 多くの業態に対応しているが、請求機能に特化したシンプルさが特徴（1名でほぼ開発できた理由）
- ドキュメント等はあまりない（長い時間1名体制だったので、優先度が上がりづらいだけ）
- 組織
- 社員16名、エンジニアは5名（メインの方が1名+新卒の方も含めて4名）
- オフィスは佐世保、みなさん佐世保で勤務
- 社長さんは交代、LITALICOから数名が経営に入る
PMIの体制
- 人数規模
- 初めの1ヶ月はLITALICO社から役員3名（ビジネス1名、エンジニア2名）で動く
- 徐々にLITALICO社の営業/CS/開発などのコアメンバーも参加し5~6名を中心に動く
- 役割分担
- ビジネスの役割：事業戦略、営業戦略、CSや営業組織、労務/法務/人事/財務/経理周り
- エンジニアの役割：システム/プロダクト戦略、開発組織、セキュリティ、ITインフラ周り
時系列の流れ
- 2020年冬：M&Aが合意され、僕へその旨が通達
- 2021年1月：PMIの担当となり、人生で初めて佐世保へ（ご飯が美味しい&人が優しく感動）
- 2021年2月~4月：現状把握に猛進し、向こう1年の戦略をプランニング & 仲良くなる
- 2021年5月~12月：仲間を集めながら20名ほどの開発チームで進行
本題に入る前に
どういうプロセスで進むのか
新しいPJを進める時には
- 現状把握 → 戦略策定/目標設定 → 具体のプランニング → 実行
といった順番で進めることが多いのかなと思います。そして本記事のスコープは「現状把握」です。
現状把握のゴールは、「次の戦略策定ですべき以下2点を行うために必要な情報の整理」です。
その2点とは
- LITALICOの統制上必要なセキュリティ等のシステム水準を満たすべく対策の有無、その内容の決定
- 現実的な短期のあるべきと、LITALICO社を含めたプロダクト/システム戦略の策定
として、上記2点を行うために必要な情報とは
- プロダクト/システムのリスク（ex.セキュリティ、技術負債）とポテンシャル（ex.追加開発余地、データ等の資産価値）の一覧
- 福祉ソフト社とLITALICO社それぞれのチームの強みと苦手（ex.技術力、ドメイン知識）の一覧
と整理しました。
では、上記を理解するために、会社全体を改めて俯瞰して、どこを調査すれば良いのかを考えます。
会社全体の構造を頑張って整理してみると以下です。（ツッコミどころは多そう）
そして本記事での現状把握のスコープは、上記の緑/★の部分」かなと考えています。
よって現状把握のゴールは
- "カルチャー・プロダクトチーム・システム/データ" がどういう構造・仕組みで機能しているか を把握すること
と定義をします。最終的にどういうアウトプットかまで噛み砕くと
- カルチャー
- 内容：会社全体の思想や価値観、社員の皆さんが会社・プロダクト・日々の仕事で大切にしていることは何か？
- 理由：チームの思想や価値観は、組織を通じてシステムの設計思想へ直接的な影響を与えるため
- プロダクトチーム
- 内容：メンバー構成や得意・苦手、何を目指したいか、開発スタイルやコミュニケーションの流れはどうか？
- 理由：ケイパビリティやコミュニケーションのあり方はシステム設計や実態に影響を与えるため（コンウェイの法則）、また体制検討に当然必要なため
- システム/データ
- 内容：どういう仕組みで動いているのか、どういうデータが取り扱われているのか
- 理由：システムのリスクとポテンシャルを理解すべきために当然必要な項目
としました。
カルチャーとプロダクトチームの理解は、システム/データ理解の前段階にやっておくと良い部分で、それはそれで以下に記載するとして、一番本題のシステム理解を行う「リバースエンジニアリング」の定義だけ、少し整理します。
リバースエンジニアリングとは
「リバースエンジニアリング」の定義はwikipediaで調べると
- 機械を分解したり、製品の動作を観察したり、ソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図などの仕様やソースコードなどを調査することを指す。（参照元：リバースエンジニアリング - wikipedia）
とのことです。他にもいくつか見てみました。
- リバースエンジニアリングは精神と時の部屋で修行するようなものだ
- How to Reverse Engineer Software (Windows) the Right Way?It was originally published on https://www.apriorit.com/
総じて「自社にはない、他社のソフトウェアやアプリケーションの仕組みを知ること」の観点で書かれていました。確かに多くの場合だとそうだろうなぁ。自社だと何かを知っている誰かがいるし、（ない場合もあるけど）何かドキュメント残っているし。本件は
- （M&Aにより）内情に全てアクセス出来るが、我々はどういう状態か全く分からない
という絶妙なパターンだなと認識しました。ただしリバースエンジニアリングの定義からは外れないので、主題でも「リバースエンジニアリング」を使うことにしています。
初めの3ヶ月とは？
M&Aは変化の大きな話なので、社員が早くより安心して働けて、会社間のシナジー最大化に向けて早く物事が進むようにすべきで悠長に過ごす余裕はなく、ある程度スピード感を持つことが重要です。
そのため、丁寧にすべてやることは難しく
- 初めの3ヶ月でいかに精度高いプロダクト/システム戦略策定が行えるか
と制限をかける中で、優先的に何をどこまですべきか？を選定することにしました。
（期間も限られ、情報を集約して検討すべきなので、少人数で一気に進められることも意識）
記事の目的とゴール
前提の説明が長くなったので改めて
記事の目的
- M&A等で会社が一緒になる機会があった時、カルチャー・組織・資産の面でお互いのシナジーを生かした戦略を描くために必要な現状把握には何をすべきかが分かる
記事のゴール
- M&A等で会社が一緒になる機会があった時の現状把握のために、担当者が何を押さえれば良いのか？の参考材料になっている
本題. 具体的に何を現状把握するのか/リバースエンジニアリングするのか
上記前提を踏まえて、プロダクト/システムの観点で「現状把握のために、何をドキュメント化/アウトプットして、何をリバースエンジニアリングする必要があるのか」の全体像を整理してみました。（もっとよく表現できる気はする）
緑の部分（括弧がついていない部分）はプロダクト/システム担当が主体的に分析する必要ありではと考えている所です。（= 今回は僕が頑張った所です）
こちらを参考に以下、各現状把握をどう行ったかを記載します。
（アウトプットには全てモザイクかけています...）
本題. 各分析について（カルチャー、プロダクトチーム編）
理念・ビジョン・カルチャーの言語化
- 何を作るか
- 理念、ビジョン、カルチャーなどの言語化
- なぜ作るか
- カルチャー、特に良い部分を理解し、プロダクトへの強みにつなげるため
- 何で作ったか
- Googleスライド
- どう作ったか
- 皆さんとの1on1を通してご経験や不安や期待などを話して理解を進める
- まずは一部のリーダー陣でワークを行う（ex.福祉ソフト社で何を大切にしたいか、どうありたいか）
- 全社でワークを行う（ex.理念への想い、どう解釈しているか、サービスの何が誇りか、どうなったら嫌か）
- 上記を繰り返して資料として言語化、図化してみなで見える所に置く
- 何ができたか
- 何がわかったか
- 単純に仲良くもなれたし、根本の想いを聞くことでM&Aへの不安や、強みの理由や組織構造の思想などが少し見えた
- お客様に届いている価値で、お客様から聞くだけでは見えてこなかった部分が見えた
- LITALICO社が力になれること、LITALICO社にない強み、が見えた
プロダクトチームの状況
- 何を作るか
- 組織図と意思決定プロセス
- なぜ作るか
- 誰がどこでどう判断されて、何が決まっているのかはシステム設計に大きく影響を与えるため
- 何で作ったか
- Googleスライド
- どう作ったか
- 福祉ソフト社の皆さんから組織体制やプロダクト周りでの意思決定の流れ（誰がどう判断して決めているか）ヒアリング
- 何ができたか
- 何が分かったか
- チームの誰に負荷がよっているかが分かり、良い連携の流れが見えた
- 誰の目が入って、設計や開発やリリースの判断がなされているかが分かり、より良く出来る点やリスクが見えた
本題. 各分析について（領域編）
ドメイン理解に必要な情報
- 何を作るか
- システム理解に必要なドメイン知識をまとめたもと
- なぜ作るか
- ドメイン知識がないとそもそも業務プロセスやデータの価値が正しく読み解けないため
- 何で作ったか
- Googleドキュメント
- どう作ったか
- 領域の公式ドキュメント（厚労省などの資料）を読み解く
- 福祉ソフト社の皆さんから必要なドメイン知識を困ったベースでヒアリング&ドキュメント化
- どれくらいかかったか
- 1.5-2.0ヶ月、30-40時間
- 何ができたか
- Googleドキュメント全23ページの分量になる教科書ができた
- 何が分かったか
- 技術力とは別のドメイン知識といった観点での専門性の高さとその価値の高さに気づく
- 以下現状把握をするためのそもそもの前提知識を得られる
ユーザーの声・利用実態
- 何を作るのか
- お客様のプロダクトに対する、評価（満足している点、更に期待している点）を一覧化
- お客様の具体的なペルソナを複数作成（こちらはデザイナーの方により）
- なぜ作るのか
- 内部仕様だけでなく、お客様から見えているソフトウェアの主な振る舞いを把握し、機能の取捨選択やマージへの参考材料とするため
- 何で作ったか
- Googleスプレッドシート
- どう作ったか
- ヒアリングシートを作成（全体的な良い点、課題点、導入理由、機能仮説を諸々）
- ヒアリング（セグメントごとに複数聞けるように、結果15法人にヒアリングさせて頂く）
- ヒアリング結果を整理、皆で議論しながら仮説を立てる
- どれくらいかかったか
- 期間1ヶ月、総工数35-40時間
- 何ができたか（以下は一部）
- 何が分かったか
- 当初想定の強みや弱みの仮説の精度がより上がったこと
- 意外とここが強みである、逆に課題感があった、ここは使われている/いないが見えてきたこと
競合情報
- 何を作るか
- 競合との比較が確認できるリストを作成（導入数、企業名、機能概要、強み、弱み、競合度など）
- なぜ作るか
- プロダクト/システムのポテンシャルとリスクは競合に影響を受けるため
- 自社だけでは得られない、客観的な領域全体のプロダクトのポイントに気づけるためめ
- 何で作ったか
- Googleスプレッドシート
- どう作ったか
- インターネットに出ている情報から調べる、詳しそうな人に聞いてみるなどなど
- どれくらいかかったか
- 期間1週間、総工数5-10時間
- 何ができたか
- 何が分かったか
- 比較をすることで、見えていなかったプロダクト/システムの強み、弱みがこれかと気づけた
- どこを追いつくのか、どこをより強化するのか、どこは優先度を落とすかの大きな参考材料となった
本題. 各分析について（システム/データ編）
業務フロー図（ユーザー中心編）
- 何を作るのか
- ソフトウェア利用箇所だけでなく、その前後のお客様の業務全体を可視化
- なぜ作るのか
- お客様とソフトウェアの現状の振る舞いを理解するため
- 何で作ったか
- astah
- どう作ったか
- まず業界のスタンダードである業務フローを土台としておこす
- 福祉ソフト社の営業/CS/エンジニア/経理の方とお客様へのヒアリングを通して土台を編集
- そもそもの業務は何か、福祉ソフト社を使っている点はどこか、社内サポート（管理業務）はどこかを色で分類
- どれくらいかかったか
- 期間1ヶ月、総工数15-20時間
- 何ができたか
- 何が分かったか
- 細部の修正を繰り返すことでかなり手触り感を持った業務状況が把握できたこと
- 領域特性上、複雑な業務ではあるが、的確な場所へサービス提供できているし、更に価値を上げられそうな点に気づけたこと
業務フロー図（社内中心編）
- 何を作るのか
- 上記業務フロー図の中で管理業務を具体化した図
- なぜ作るのか
- 事業全体に必要な業務とシステムを把握するため
- 何で作ったか
- Googleスライド
- どう作ったか
- 福祉ソフト社の営業/CS/エンジニア/経理の方へのヒアリング
- どれくらいかかったか
- 期間2週間、総工数5-6時間
- 何ができたか（以下一例）
- 何が分かったか
- コストや時間的に効率化出来そうな業務があること
- 顧客価値に大きくヒットする重要な業務フローに気づき、プロダクトの改善と同等にその業務フローの改善が重要である点に気づけたこと
アクセス実績一覧
- 何を作るか
- アクセスログ等から、機能や画面ごとに利用実績を定量的に可視化
- なぜ作るか
- どれくらいどの機能が使われているかを把握するため
- どう作ったか
- わけあってapachelogから解析
- どれくらいかかったか
- 1週間、2-3時間
- 何ができたか
- 何が分かったか
- いわゆるパレートの法則がやはりあったこと（全体の80%の利用は、全機能の20%で行われる）
- きっとこうではと考えていた業務の重要性だけでなく、福祉ソフト特有の利用量（アクセス量）から、改善の優先度をより正しくおけるようになったこと
ER図、テーブル定義書
- 何を作るのか
- いわゆるER図と、テーブル定義書（そのまま）
- なぜ作るのか
- 保有するデータとその流れはサービスの価値を大きく理解することに繋がる
- 何で作ったか
- astah
- どう作ったか
- 何もなかったので、レコードを抜いたsqlを頂く
- astahの機能（DBリバースプラグイン）を利用してsqlからER図のたたきを作成し修正
- astahの機能（エンティティ定義書)でER図からテーブル定義書をexcel形式でエクスポートし、スプレッドシート化
- 命名規則や各テーブルの利用箇所や目的などの情報を一覧で補足
- どれくらいかかったか
- 期間1ヶ月、総工数15-20時間
- 何ができたか
- 何が分かったか
- 保有できているデータ = 顧客への付加価値を理解できた
- テーブル構成等からシステム設計のクセや重視されている点が理解できた
機能一覧図
- 何を作るのか
- 機能カテゴリ、機能概要、URL、利用状況、要る要らないなどの一覧
- なぜ作るのか
- お客様が求める価値を実現する手段として今何を有しているのかを把握するため
- 何で作ったか
- Googleスプレッドシート
- どう作ったか
- 自分の手で一通り触って、一覧化する
- マニュアルを読んで補足する
- 福祉ソフト社のエンジニアの方へヒアリングをして細部を詰める
- どれくらいかかったか
- 期間1ヶ月、総工数10-15時間
- 何ができたか
- 何が分かったか
- 機能数は表から見えていたものより1.5-2.0倍近くあって、気づかなかった価値に気づけた
- 顧客ヒアリング時のぱっとは見えなかったが、実は重要だった価値の仮説が立った
インフラ構成図
- 何を作るのか
- サービス全体のクラウドインフラの構成を図化
- なぜ作るのか
- どういう環境でシステムが動いているかはコストやリスクの把握に重要なため
- 何で作ったか
- Googleスライド
- どう作ったか
- 「福祉ソフト社のエンジニアの方」へヒアリングをしながら一緒に図化
- どれくらいかかったか
- 1週間、2-3時間
- 何ができたか
- 訳合って割愛します
- 何が分かったか
- インフラ構成上のリスクと今後の対応方針が見えた
上記現状把握の後に何をしたか
システムとプロダクトと組織の評価と今後のプランニングをします
- リスク
- 可用性、機密性、属人性、更新性、などの観点から評価と改善案（いつまでに、どういう状態へ）を計画
- ポテンシャル
- プロダクトの強みやお客様からの期待値から、短期で追加すべき機能は何かを計画
- 組織
- プロダクト開発がより強化されるLITALICO社のフォロー体制を計画
これらを踏まえて、短期（半年~1年後）のプロダクト/やシステムの計画はどうするのか、どれだけ投資して、どういう状態にするか、を企画していきました。
学びや気付き
補足
- もうちょい踏み込んで全体をみるDFDや、RDRAなどでの分析はしなかった
- 機能数は割と多いが、もっている状態やデータの流れはかなりシンプルなため、また時間とのバランスを見てtoomuchになると判断し未作成
- もう少し複雑な業務やビジネスプロセスが発生したり、複雑なデータの流れが発生したりする場合はやると良いだろう
- Githubからコードの全体をさらったが、細部まで見たり、ドキュメント化したりまではしなかった
- 期初はPdMとTechLeadの両役割を担っていた自分がみるしかなく、予算策定等の時間的にやる余裕がなかったので、全体をさらって大枠のシステム設計や予算策定の参考材料のみに終わった
- またデータモデルの分析により、コードベースの調査は初めの3ヶ月の期間では不必要と判断
- ただし、既存プロダクト改修に取り組みだすと、期初より予算は膨らむ、想定とは少し異なるシステム戦略を取るなどは発生（ただし大きな問題はなく、時間的に許容範囲な話ではある）、ここはリスク・リターンを見て判断
- 正直システム分析の経験は浅いので、もっとよいやり方はいくらでもありそう
- 2022年3月にキリが一旦つくので、そのタイミングで振り返りと再学習をします。
気づき・学び
- ドキュメントを作ることが目的ではなく、戦略策定のための現状分析をすることが目的であることを忘れない
- 見えないものが多く、分析手法も多く、時間も限られている中で、何が分かりたいのかをまず明確にすることが重要
- とりあえず作ってもあんまり意味がない、使われないことも発生しうる。そうなったら悲しい
- 実際には分析しながら戦略策定を同時に行う、戦略策定の確度に不安な部分等に合わせて何を分析すべきかと考え、そのために何が分かるべきかを考えながらやると効率的に進められそう
- 数を重ねることで、「ここはきな臭い、この辺にリスクが潜んでそう」がより見えるので、整理対象の情報に何があって、分析手法がなにかを知っておくことで、その精度は高まるが、案件数が少ないので、1つ1つをちゃんと学びに繋げることを普段以上に意識
- 規約や契約書、販売顧客一覧などの現状把握も他の方が行ったアウトプットを読み込むことも当然重要
- 規約や契約書でどういう約束をしてきたかは、今後の改善計画に結構影響を与えるので、ちゃんと読むこと
- サービス変更のお約束、責任と賠償、個人情報の取扱いなどは特に大きい
- 顧客一覧からはアカウントや契約の意外な利用状況、使われ方にも気付けるし、契約管理やアカウント管理のシステム改善に結構な影響を与える
- 初期段階では70-80%程度しか見えない前提に立って、後の改善計画の見積もりを立てること
- システムやサービス提供の歴史が長いほど個別対応をしている事例や機能が存在する可能性あり
- 戦略策定後の具体的な改善策やシステム設計を進めるとだいぶ出てくる、3~6ヶ月程度は出るつもりでいる
- そういった可能性を加味して改善計画を立てないと苦労するので、気をつける
- 巻き込める人が多いなら、もっと役割分割して効率良くしできたなと思う
- 今回は諸々の状況より、また業務分割できるほど初期に全体像のイメージが湧かなかったこと、1人でもなんとかなる分量なので、自分がまるっとやったが、規模がでかいと無理なので、今回行った構造化に基づいて役割分担を行いチームで勝てるように次はする
- PdMチーム：プロダクト戦略、プロダクト分析
- コーポレートエンジニアチーム：業務プロセス、ビジネスプロセス
- アプリケーションエンジニアチーム：細部のシステム構成、データ周辺
- SREチーム：インフラ構成
最後に
福祉ソフトの皆さんが本当に素晴らしい方々で、異なる企業文化を軸に建設的な議論も通して、お互いのカルチャーを進化させるきっかけもつくれました。
学ぶ所も非常に多く、お互いに保管し合える関係性なのではという点から、ご一緒でできてよかったと強く感じ、ありがたいなという気持ちでいっぱいです。もっと良いプロダクトに出来るよう、共に頑張って参ります。
最後の最後に、本案件を進める中で多大なるアドバイスを下さった僕の師匠 @kazuis からの金言
データフロー、データがいつ生まれて、どう使われていくのか（価値がうまれるのか）を知るのがリバースエンジニアリング。システムやチームの大事にしている事の中に暗黙的な設計思想が隠れている。これを知るとビンテージワインのように歴史を楽しみ・大切にできる領域に達する。 その上に新しいものをつくるのです。 これは破壊ではなく、進化させるためのシステムとの向き合い方です。
よく言われていることではありますが、会社のカルチャー、チームの思想や構成、にシステムは大きく影響受けるなぁ。と今回非常に強く実感しました。自身の役割としてLITALICOでもその改善、進化を改めて力を入れねばと感じたところでした。
頑張ります。
それでは、明日は @sayanaga さんの予定です！！
では残りも少なくなってきましたが、引き続きLITALICOのアドベントカレンダーをよろしくお願いします＾＾