プロダクト戦略から考えるアーキテクチャ選定

新しいプロダクトを立ち上げる際、どのようなソフトウェアアーキテクチャを採用するかは重要な意思決定です。これまで先人たちが築き上げてきた代表的なパターンは多くありますが、唯一の正解が存在するわけではありません。プロダクトの目的や市場、組織の性質によって最適解は異なります。

PeopleXで1年半の間に5つのプロダクトを立ち上げた経験をもとに、アーキテクチャ選定の考え方について説明していきます。

目的から出発し、実践との相互フィードバックを重ねる

これはアーキテクチャに限らず多くの意思決定に共通しますが、「プロダクトゴールを起点とし、現場からのフィードバックを重ねて実践知化していく」ことが出発点です。

トップダウン型では現場のリアリティや暗黙知が共有されにくく、ボトムアップ型では全体の方向性を見失い、局所最適に陥りがちです。だからこそ、両者の視点を往復しながら「目的志向のアーキテクチャ」を磨くことが重要です。

主要なアーキテクチャパターンや先行事例を学ぶことは重要ですが、「有名企業が採用しているから」という理由だけで真似をするのは、サイコロを振って出目を祈るようなものです。自分たちのプロダクトのゴールやチームの構成を踏まえて、最適な選択を探ることが大切です。

マーケットからリアリティのある未来予測を行う

アーキテクチャの議論では、「モノリスかマイクロサービスか」「MVCかクリーンアーキテクチャか」といった設計論に注目が集まりがちです。しかし、その前に立ち止まり、自分たちが参入するマーケット構造と制約を深く理解する必要があります。

理想主義的な設計思想は重要ですが、アーキテクチャは理想主義に過ぎてはいけません。新規事業の成否は、しばしば市場構造や産業成熟度といった外部要因に大きく左右されます。

現代のインターネット市場を見渡すと、マス向けの巨大市場はすでに90〜00年代に押さえられています。金融、EC、採用といった領域では先行プレイヤーが圧倒的なシェアを持ち、スマートフォン以降の変革も限定的でした。スタートアップはこうした状況に挑む存在ですが、参入市場によってはTAM（最大市場規模）が明確に予測できる場合もありますし、技術的優位が市場に求められないケースも少なくありません。

だからこそ、マーケットを丁寧に学び、リアリティのある未来予測を立てることで、プロダクトと組織の“攻め方”の方向性が定まっていきます。

モノリスか、マイクロサービスか

ここから少し具体的な思考パターンに踏み込みましょう。代表的なテーマである「モノリス vs マイクロサービス」について整理します。

パターン	Pros	Cons
モノリス	構成がシンプルで全体像を把握しやすい。 同一トランザクションでCRUDが可能なためデータ整合性の問題が少ない。 ローカル環境の構築が容易。	異なるドメインが同居しやすく、後から分離が難しい。 全体を理解しないと開発が進めにくく、認知負荷が高い。
マイクロサービス	各サービス単位で最適化でき、チーム分業に強い。 小さな単位で素早くリリースできる。 サービスごとに最適な技術を選択できる。	サービス間の整合性や依存関係の管理が難しい。 ローカル環境構築が複雑化しやすい。 メンテナンスするサービスの数が増える。

よく「まずはモノリスから始め、必要に応じてマイクロサービスに移行すべき」と言われますが、私は次のように整理しています。

製品が市場に受け入れられるか不確実ならモノリスから。
市場が大きく、初期から大規模展開が前提ならマイクロサービスから。

たとえば他社プロダクトの例で恐縮ですが、PayPayは後発ながら巨大市場を短期間で取りにいく戦略を採用しており、当初からマイクロサービス構成を前提にしていました。一方、新しい市場を切り拓くタイプのプロダクトでは、初期の不確実性が高く、モノリス構成で素早くMVPを出すほうが合理的です。

新市場創出型のプロダクトでは、事前に適切なドメイン境界を定義すること自体が難しいため、マイクロサービスを“理想通り”に運用するのは非常に困難です。この点は実務経験上、強調しておきたいポイントです。

市場規模から逆算する

先ほど触れたTAM（最大市場規模）の視点から、アーキテクチャの方向性を逆算することもできます。

たとえば、国内で1,000億円規模の市場を単一プロダクトで狙うなら、必然的にtoCの大規模サービスや広告・金融・ECといった領域になります。
一方、国内BtoB SaaSでは、複合でなく単一プロダクトで100億円を超える例はごくわずかです。そのため、規模を狙うか、利益率重視で小回りを効かせるかは構造的に異なる戦略になります。

市場の成熟度や事業ポートフォリオ（PPM）を踏まえ、

「マイクロサービスで拡張を前提に大きな市場を作り続ける」
「マーケット規模を考慮して、モノリスのまま少人数で高収益を維持する」

といった方向性を意識的に選ぶことが重要です。

レイヤー設計の考え方

同一アプリケーション内でレイヤーをどのように分割するかは、アーキテクチャ設計におけるもう一つの大きな選択です。
スタートアップでは、かつてRuby on Railsに代表されるMVCパターンが主流でしたが、近年はより責務の明確化と依存方向の制御を重視するクリーンアーキテクチャなどのパターンが普及してきました。

こうしたパターンには、代表的なものとして次の3つがあります。

• クリーンアーキテクチャ
• オニオンアーキテクチャ
• ヘキサゴナルアーキテクチャ

これらはいずれも4層以上のレイヤー構造を持ち、ドメイン（ビジネスルール）を中心に据えた設計を共通の思想としています。さらに、依存性逆転の原則（DIP） を用いて、「外側（インフラやUI）→内側（ドメイン）」への依存方向を保つ点が特徴です。
これにより、ドメイン層がインフラやフレームワークに依存せず、テスト容易性・保守性・変更耐性を高めることができます。

また、これらの設計はデータ中心ではなくドメイン中心の発想を採用しています。
すなわち、「データベースのスキーマ設計」と「ビジネスルールの表現」を切り離すことが推奨されます。これにより、ビジネスロジックが永続化の仕組みに縛られず、変化に強い構造を保てます。

PeopleXでの実践と考え方

PeopleXでは、プロダクトごとにレイヤー設計の適用度や構造を意図的に変えています。
例えば、HRプラットフォームの「PeopleWork」では、ビジネスロジックが複雑化しやすいため、DBスキーマとドメインモデルを分離し、リポジトリ層で依存性逆転（DIP）を適用して、ドメインロジックをデータアクセス層から独立させる設計を採用しています。

一方で、「AI面接」プロダクトのように、データ自体が主軸となる場合は別アプローチを取っています。この場合は、データ構造がそのまま業務ロジックを表現することが多く、ORMのスキーマ型をドメインモデルとして直接利用し、DIPのような複雑な抽象化は採用していません。これは、データ駆動型アプリケーションでは「スキーマ＝ドメイン」と見なすほうがシンプルかつ効率的だからです。

ドメインの複雑さとレイヤー構造の関係

ドメインが複雑であれば、クリーンアーキテクチャのようなレイヤー分離が有効です。
一方で、ビジネスロジックが単純な場合に多層構造を採用すると、モデルが「貧血化」し、実質的にデータの詰め替え処理だけを行うドメイン層になりがちです。

また、リポジトリ層をどう捉えるかも設計思想によって変わります。
「ドメインを表現するための抽象インターフェース」とする場合もあれば、単に「データ受け渡しのヘルパー」として扱う場合もあります。どちらが正しいというものではなく、プロダクトの性質・チームの文化に依存します。

プロダクト特性による選択

レイヤー構造を考える上で重要なのは、「プロダクトが潜在市場に挑むのか、既存市場に後発参入するのか」という文脈です。

潜在市場向けの新しいプロダクトでは、ユーザーがその製品に初めて触れることが多いため、複雑なビジネスルールを実装しても使いこなされにくい傾向があります。結果として、プロダクトのビジネスロジック自体も初期は単純で、レイヤー構造も簡素な方が現実的です。

対して、既存市場に参入する後発プロダクトでは、顧客要求や業務ルールが複雑で、初期段階から高いドメイン表現力が求められます。このような場合、初期からドメイン中心の設計を意識することが長期的に有効です。

どちらのタイプであっても、5年・10年と時間が経てばビジネスルールは必ず複雑化します。特に前者では成長に合わせて段階的にレイヤーを拡張していく「進化的アーキテクチャ」の発想が望ましいといえます。

しかしながら前者のタイプにおいて、いずれ複雑化するなら最初から備えておくという考えはあまり推奨しません。新しいプロダクトが5年・10年と生存する可能性は決して高くなく、マーケットの性質上、そもそも複雑なレイヤーが要求されないこともあるためです。

まとめ:早期適応の重要性

アーキテクチャを後から根底から変更することは容易ではありません。開発を数ヶ月止めるような変更は経営マターになり、現実的にはほとんど起こりません。
だからこそ、決定した設計を絶対視せず、ズレを早期に察知して素早く適応する姿勢が不可欠です。

PeopleXの「AI面接」もリリース後5ヶ月で、レイヤー再設計・モジュール再配置・バリデーション方式の変更などを複数回実施しました。成長が早いからこそズレも早期に顕在化し、開発を止めず迅速に対応できたのは、チーム全体で合意形成しパワープレーを厭わず進めた結果です。

アーキテクチャには絶対的な正解はありません。
プロダクトと組織の変化にあわせて、継続的に適応し続けることこそが唯一の「正解に近づく道」 です。