【買収プロダクトを"統合できる状態"へ】
中古車オークション×共有在庫を、同一技術スタックでリプレイスし「シナジーが生まれる土台」をつくる

1. 本事例の背景（相談の入口）

M&A（企業買収）を経て、新たなシナジーを生むはずだったそのプロダクトには、深刻な課題が潜んでいました。ミッションは、中古車オークションと共有在庫という2つの巨大システムを同一の技術スタックでリプレイスし、統合すること。

ところが現場では、前提そのものが揃っていないというのが現実でした。特に共有在庫側は外部開発の比重が高く、過去の経緯や設計意図を把握しづらい領域が残っている状態。一方で中古車オークション側は、人数は限られるもののドメイン知識を持つメンバーはいましたが、体制の都合で外部委託を含む形に広がっていった背景がありました。

その結果、とりわけ共有在庫側の一部領域はブラックボックス化しており、影響範囲の特定が難しい状態でした。些細な変更でも調査工数が膨らみやすく、判断が重くなりがちだったのです。

現場に漂っていたのは、「下手に触ればシステムが壊れるかもしれない」という強い閉塞感。この「負の遺産」を、再び企業の成長を支える「資産」へと変えるための、極めて難易度の高いプロジェクトが動き出しました。

2. 課題（支援先で起きていたこと）

本プロジェクトの難しさは、単なる開発規模の大きさだけではありません。買収した共有在庫側はもちろん、一部領域がブラックボックス化しており、調査や認識合わせのコストが膨らみやすい状態でした。一方で中古車オークション側は、人数は少ないもののドメイン知識のあるメンバーはいましたが、最大15名以上規模の体制で進める中では、ドメイン知識が薄いメンバーもアサインされる前提になります。ここで「知っている人の頭の中」だけに寄せると、実装が止まる・品質が揺れる、といったような障害が起きやすくなります。

この状況がつらいのは、単に「分からない」だけではない点です。影響範囲の特定に時間がかかるほど、関係者の意思決定も重くなり、「結局、どこから手を付ければいいのか」が曖昧なまま時間だけが過ぎていきます。現場では、やりたいことがあっても「調べないと分からない」「誰が分かるの？」が先に立ち、改善が後回しになりがちです。結果として「前に進めたいのに進めない」という停滞が生まれやすい状態でした。

そのため、プロジェクト前半の約半分という膨大な時間は、要件定義よりも前に「既存の挙動を仕様書・設計書として可視化すること」にしっかり時間を使いました。これは「ブラックボックスを解く」だけが目的ではなく、KSRを含め大人数で、ドメイン知識が薄いメンバーもアサインされる状況でも実装を進める必要があったためです。どのメンバーであっても知識量に左右されず、ドキュメントを起点に実装できる環境を整えるために、仕様書の作成に投資することで、全員が共通認識を持てる"地図"を作りました。

さらに、最大15名以上という大規模な開発体制が、さらに難易度を引き上げました。KSRは副業やスポット参画のメンバーが多く、開発のフェーズによって必要なメンバーを柔軟にアサインすることができるので、次第にメンバーや参画人数が変わっていきます。だからこそ後続のメンバーのためにも、仕様を「ブロック化」して切り出して定義し、誰でも迷わず作業を分担できる状態を作ること。それが大規模体制を機能させるための解決策でした。

3. ゴール（何を"できる状態"にするか）

「シナジーを創出する」ことがゴールであるものの、久保田さんはこのゴールの抽象度の高さをできるだけ具体的かつ現実的に理解をして、プロジェクト推進するよう心がけました。

プロジェクト発足当初、クライアント側が描いていたシナジーの具体像は、必ずしも明確なものではありませんでした。ここで優先事項として掲げられていたのは、先方PMの方が中心になって進めていた「アカウント基盤をはじめとするプラットフォームの共通化」です。そして、その大前提として「今できることを、新しい環境でもそのまま実行できる状態（現行再現）」が重要なゴールになっていました。そのうえで久保田さんが担ったのは、後続でアサインされる実装メンバーがスムーズに入れるように、既存システムの挙動をより正確に仕様書に落とし込み、リプレイスの課題となっていた要件も織り込んだ仕様を定義することでした。

今回のミッションにおける真の成功とは、不確実な最終形をいきなり決め切ることではありません。まずは迷走していた足元を固め、統合という大きな目標に向けて確実に前進できる"戦える土台"を作り上げること。この冷静な現状分析に基づいた段階的なゴール設定こそが、巨大プロジェクトを瓦解させないためのベースとなりました。

4. 進め方（要件定義でやったこと）

4-1. まず"仕様をつくる"から始める（リバースエンジニアリング）

「要件を決めてから作る」という一般的な順序で始めることはせず、既存コードをリバースして仕様書へ落とし込む作業からスタートしました。大人数な大規模体制において、仕様を「ブロック化」して分担可能な形に切り出さなければ、開発は一歩も前に進まないためです。「仕様を熟知した誰かが、それを細切れのブロックとして各メンバーに渡し、コツコツと積み上げて一つの形にする」。この開発サイクルを成立させるための土台づくりに、全力を注ぎました。

ここで狙っていたのは、「分かる人がいないと進まない」状態を作らないことです。後続でアサインされる実装メンバーがスムーズに入れるように、既存の挙動をできるだけ正確に仕様書へ落とし込み、ドキュメントを起点に実装へ進める状態を整えました。結果として、大人数でも分担しながら前に進める土台になっています。

4-2. システムを見るだけでなく「人に聞く」をセットで回す

コードを追うだけでは、実装背景にある「真の意図」が見えない箇所が必ず出てきます。そこで久保田さんは、数少ない現行エンジニアだけでなく、営業や各セクションの担当者、時にはクライアントの代表にまでチームで直接ヒアリングを実施。挙動の意図や背景を確認し、仕様書化とヒアリングを往復させることで、理解を揃えながら前に進める形を作っています。

ここでの仕様化・設計書化は、単なるドキュメント作成ではありません。関係者全員の理解を揃えるための、極めて濃密な「要件定義」そのものです。この工程に徹底的に時間を投下したからこそ、後半の実装・推進フェーズが揺るぎないものとなりました。

4-3. スコープは「地道な対話」によって絞り込む

システムのリプレイスにおいて、必ず噴出するのが「ついでにここも直したい」という追加要望です。しかし、タイトなスケジュール下で際限なく要望を積み上げれば、プロジェクトは失敗へと向かってしまいます。ここで取った方針は、現行再現を徹底し、不要な機能は削ぎ落とす。コストに影響しない範囲でのみ微調整を許容する。この線引きを守るために、先方PMと共に、KSR側の複数PM（計4名）や仕様作成メンバーも含めた体制で1つのチームで一丸となって、オペレーション担当や顧客代表、営業担当といったステークホルダーに対して、要望の背景と必要性を地道に確認して回りました。

久保田さん自身、プロジェクトを振り返りながら「1つ1つ丁寧に合意を取りながら進めるのが、大事でしたね。」と語ります。その「当たり前の徹底」こそが、巨大なスコープをコントロール下に置く唯一の鍵となりました。

5. 工夫点（意思決定を前に進めたポイント）

5-1. スプリントを1週間から2週間へ変更し、稼働実態に最適化する

当初、プロジェクトは1週間単位のスプリントで運営されていました。しかし、副業参画メンバーが多いKSRのチーム構成では、週末に稼働が集中しやすく、週半ばに不明点が生じると次週まで進捗が停滞するという課題がありました。

そこで久保田さんは、スプリント期間を2週間へ延長することを提案。自らが2週間周期でも確実にアウトプットが出せることを体現し、クライアントを説得しました。この"足場"を先に整えたことが、後に参画するメンバーの合流をスムーズにする決定打となりました。

5-2. "昼間に動けるPM"を追加し、意思決定の目詰まりを解消

チームが10名以上の規模に拡大すると、副業PM一人ではコミュニケーションの物量が限界を迎えます。特に日中の情報収集や即時対応がボトルネックとなり、夜間に稼働するエンジニアの手が止まるリスクがありました。

そのリスクを解消するために、KSR側での「日中にフル稼働できるPM」を新たにアサインし、役割分担を再設計しました。この体制変更が、後半フェーズの安定運用を支える強力なエンジンとなりました。昼間に動けるPMを補強したことで、その詰まりを減らし、結果としてスプリントのリズムを保ちやすくなりました。

5-3. "分からない"を許容する関係性が、手戻りを未然に防ぐ

プロジェクトの成功を支えた目に見えない要因は、社内外の垣根を取り払った「ワンチーム」の空気感です。特に今回は仕様がブラックボックス化していたため「分からないまま進めること」が最大の経営リスクでした。

だからこそ、疑問をその場で口に出し、即座に確認・判断へと繋げられる関係性の構築を徹底しました。遠慮なく質問し、必要なことを率直に言い合える。この心理的安全性の土台があったからこそ、意思決定のスピードは加速し、手戻りを未然に潰しながら、全員が同じ前提に立って開発を積み上げられる状態を実現できました。

6. AI活用（久保田さん自身の実践）

プロジェクト後半、推進力を爆発的に高めたのが徹底したAI活用です。

コーディングや設計、仕様書の作成はもちろん、15名以上という大規模体制において「誰が何を実装し、どこに影響が出るか」といった複雑な状況把握や調査まで、あらゆる工程にAIを介在させました。これにより、PMとしての意思決定のスピードと精度が飛躍的に向上したと言います。

久保田さんが強調するのは、この1年でAIが遂げた劇的な進化です。かつては補助的なツールに過ぎなかったAIが、今や「実務レベルの仕様をゴリゴリと生成してくれる」パートナーになりました。だからこそ、AIを単なる"部分的な便利ツール"として扱うのではなく、仕様整理から調査、意思決定のプロセスまで含め、最初から「AI活用前提」でプロジェクトの回し方を設計すること。そのパラダイムシフトこそが、現代のPMに求められる最も重要な資質であると、久保田さんは語られていました。

7. 成果

7-1. ブラックボックス化した既存仕様の「資産化」

プロジェクト前半で「仕様をつくる」ことに集中的に投資した結果、誰も正解を知らなかった既存仕様を、仕様書・設計書として完全に可視化しました。誰でも内容を把握・メンテナンスできる状態へと再構築したことが、後半フェーズにおける実装スピードの加速と、大規模体制での確実な推進を支える揺るぎない土台となっています。

7-2. 大規模開発を停滞させない「高効率な運用体制」の確立

スプリント期間を2週間へ最適化し、日中にフル稼働できるPMを補強したことで、情報の目詰まりを大きく軽減しました。副業エンジニアが主力のチームでありながら、意思決定が滞留しない「大規模でも淀みなく回る運用モデル」を成立させたことは、今後の組織運営における大きな指針となりました。

8. 振り返り

8-1. 知見を惜しみなく「先出し」し、共通前提を最速で揃える

大規模プロジェクトほど、情報の非対称性や判断の遅れが後工程での致命的な手戻りを招きます。だからこそ、「この段階ではここまで」と出し惜しみをするのではなく、PMが持つ知見、気づき、そして判断の軸を最初からすべて開示すること。

「情報の全量公開」によってチーム全体の共通前提を早期に構築することが、結果として意思決定の速度と品質を劇的に高める最短ルートになります。

8-2. プロジェクト運営そのものを「AI前提」で再設計する

この1年でAIが遂げた飛躍的な進化により、仕様の整理、調査、さらには意思決定の材料作りまでが実用レベルへと到達しました。今やAIは個人の生産性を上げる「ツール」の域を超えています。

久保田さん自身は、設計・実装・調査などでAIをかなり活用しています。重要なのは、AIを"個人の便利ツール"で終わらせず、必要な場面でちゃんと使えるようにしていくこと。調査や整理の負荷が高い局面ほど、AIをうまく使えるかで判断の速度が変わる。そんな実感が語られていました。

9. 最後に（総括）

買収によって獲得した「共有在庫」と、既存の「中古車オークション」。プロジェクトの最前線に立ちはだかったのは、「そもそも仕様が分からない」という過酷な現実でした。

だからこそ本プロジェクトは、一般的な要件定義の前に、まず"仕様を再構築する"ことから始まりました。ソースコードを読み解き、ドキュメントへ落とし込み、関係者一人ひとりに実装の意図を確認する。チーム全員が同じ「地図」を持って動ける状態を、泥臭く整えていきました。そのうえで、現行再現を軸に「本当に必要な機能か」を現場で精査し、膨張しがちなスコープを地道に絞り込んでいったのです。

さらに、副業メンバー主体の稼働実態に合わせ、スプリントを2週間へ最適化。日中にフル稼働できるPMを補強することで、意思決定を停滞させない鉄壁の体制を構築しました。プロジェクト後半には、久保田さん自身がAIを積極的に活用し、仕様策定から設計・実装、状況把握や調査までを加速させ、十数名規模でも淀みなく回る運用モデルを成立させました。

特に今回の支援で大きかったのは、既存の挙動を仕様として再現し、後続の実装メンバーが迷わず入れる状態を整えたことです。「知っている人の頭の中」に寄せず、ドキュメントを起点に大人数でも前に進める土台を作った点が、統合フェーズへ進む前提になっています。

久保田さんは「知見を出し惜しみせず、最初からすべて出し切ること」、そして「進化したAIを前提に、プロジェクト運営そのものを組み替えること」。この2点こそが、高難度な案件を完遂させるための再現性の高い急所でした。

統合による真のシナジーは、揺るぎない「土台」があって初めて生まれるかと思います。今回の支援の本質的な価値は、その土台を要件定義の段階から作り切り、次なる統合フェーズへと突き進むための「最強の武器」をクライアントへ手渡した点にあります。