シリーズB以降の構造の変え方

シリーズBを迎えるころ、多くの会社が同じ論点に直面します。一本目のプロダクトが伸びている一方で、成長率を維持するには二本目が要る。あるいは、既存顧客からの要望が「もう一つの業務も見てほしい」という方向に広がっている。ここで構造をどう変えるかの判断が、その後の数年の開発速度を決めます。

本記事では、単一プロダクトから複数ラインへ広げる段階で何を共通化し、何を分けたままにするかを整理します。フェーズごとに体制と契約をどう変えるかは資金調達フェーズ別に見る、開発パートナーとの関わり方にまとめています。

二本目を出す理由を言語化する

構造の話に入る前に確かめたいのは、二本目を出す理由です。理由によって、共通化すべき範囲が変わります。

• 既存顧客への追加販売が目的：顧客は同じです。アカウント、請求、権限、通知といった顧客に触れる部分は共通であるべきで、共通化の優先度が高くなります。
• 新しい市場を取りに行くのが目的：顧客も購買プロセスも異なります。この場合、共通化して得られるものは少なく、むしろ一本目の前提が二本目の足を引っ張ります。
• 既存プロダクトの一部を切り出して単体で売るのが目的：実装は共通化済みですが、価格体系と利用規約が分岐します。共通化すべきは実装であって、事業の条件ではありません。

この区別を曖昧にしたまま「プラットフォーム化」という言葉を使うと、議論が噛み合いません。誰に何を売るための構造変更なのかを一文で書けるところから始めてください。

早すぎる共通化が何を壊すか

この段階でもっとも多い失敗は、機能が足りないことではなく、共通化を早く始めすぎることです。

二本目の輪郭がまだ定まっていない時期に「将来三本目、四本目も出すのだから、今のうちに共通の土台を作っておこう」と判断すると、次のことが起きます。

まず、共通化した部分を変更するたびに、既存プロダクトへの影響確認が必要になります。一本目はすでに顧客が使っているため、確認は慎重にならざるを得ません。結果として、まだ仮説検証の段階にある二本目が、成熟した一本目の慎重さに引きずられます。

次に、共通の土台が「まだ一つのプロダクトしか使っていない抽象」になります。実際の要件が一つしかない状態で汎用的な形を設計すると、その形は想像に基づいたものになります。二本目の要件が見えたときに合わないことが分かり、土台ごと作り直すか、例外処理で逃げるかの選択になります。どちらも技術的負債として残ります。

想定例：ある会社が、既存の業務システムに加えて分析ツールを出すことにしたとします。最初から「共通データ基盤」を設計し、両プロダクトがそこを参照する構成にしました。ところが検証を進めるうち、分析に必要なデータの粒度が業務システムの記録と合わないことが判明します。基盤を直せば業務システムに影響し、分析ツール側で変換すれば基盤の意味が薄れる。この会社が取った対応は、分析ツールを一度独立させ、必要なデータを日次で複製する形に戻すことでした。

原則として、二本目は分けて作り、重複が実際に痛みを生んでから寄せるほうが安全です。共通化は後からできますが、早すぎた共通化をほどくのは難しいためです。

共通化の判断基準

では、いつ寄せるのか。実務で使いやすい基準は二つあります。

一つは「三度目」です。同じ性質のものを三度書くときが共通化の目安になります。二度では偶然の一致かもしれませんが、三度重なると、それは本質的に共通のものだと判断できます。

もう一つは「痛みが出たとき」です。一つの仕様変更のために複数箇所を直している、片方だけ修正して不整合が起きた、といった具体的な痛みが観察されたときが、寄せるべき合図です。

そのうえで、共通化してよい領域とそうでない領域を分けます。

大まかには、事業の違いに左右されない領域は共通化してよく、事業の違いがそのまま現れる領域は分けたままにするという線引きになります。

組織と構造を対応させる

構造の話は、組織の話とセットになります。共通の土台を作ったなら、それを持つ人が要ります。

よくないのは、共通部分に持ち主がいない状態です。どのラインのチームも自分の都合で手を入れ、誰も全体を見ていない。この状態では、共通化したはずの部分が分岐だらけになり、最終的には各ラインが自分用のコピーを持つのと変わらなくなります。

現実的な形は、次のいずれかです。

• 共通の土台を担当する小さなチームを置き、各ラインからの要望を受け付ける窓口にする
• 共通部分の変更は、変更したいラインが実装し、土台の責任者がレビューする
• 当面は共通化せず、各ラインが自分のものを持ったまま、四半期ごとに重複を棚卸しする

三つ目は妥協案に見えますが、チームが三つ未満の段階では合理的です。共通の土台を持つチームを置くには、その人件費を正当化できるだけの重複が必要です。重複より運営コストのほうが大きいなら、まだ早いということです。体制の考え方は少人数開発チームの体制設計もあわせてご覧ください。

AI機能を複数ラインに広げるとき

複数プロダクトを持つ段階で、AI機能を横断的に使いたいという話がよく出ます。要約、分類、問い合わせ応答といった機能を、各ラインが個別に外部のAI APIを呼ぶか、社内で一本化するかという論点です。

ここで共通化に向くのは、事業ロジックを含まない部分に限られます。どの提供事業者のAPIを使うかの切り替え、利用量と費用の集計、送信してよいデータの制限、障害時の代替動作といった運用面です。これらは事業の違いに左右されないため、一箇所にまとめる価値があります。

一方、プロンプトの内容、出力をどう検証するか、どの業務に当てはめるかは、事業ごとに違います。ここまで共通化しようとすると、各ラインが例外を積み上げる結果になりがちです。

現実的な順序としては、まず各ラインが既製のAPIをそのまま使って試し、複数ラインで同じ運用上の困りごと（費用が見えない、送信データのルールがばらばら、など）が出てから、その運用部分だけを寄せる形が安全です。多くの場合、必要なのは新しい基盤ではなく、利用状況が見える設定と社内ルールです。

構造を変える前に、変えない理由を潰す

シリーズB以降の構造変更で失敗しやすいのは、構造そのものより順序です。二本目を出す理由を言語化し、まずは分けて作り、重複の痛みが実際に出てから寄せる。寄せるときは、事業の違いに左右されない領域に限り、共通部分の持ち主を決める。この順序なら、構造変更が開発速度を落とす期間を短くできます。

逆に、「将来を見越して」という理由だけで共通化を始めるなら、一度立ち止まってください。その将来が来る前に、事業の前提が変わる可能性は十分にあります。

現在の構成をどこまで共通化すべきかの判断に迷う場合は、Webシステム開発やモダナイズ・リプレイスの観点から状況を伺います。お問い合わせからご相談ください。ご相談・お見積りは無料です。