大規模SaaSプラットフォーム製品アーキテクチャの設計アイデア

「アーキテクチャ」を検索すると、組織構造、ビジネス アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、セキュリティ アーキテクチャ、製品アーキテクチャ、デプロイメント アーキテクチャなど、多くのアーキテクチャの画像が表示されます。

建築とは何でしょうか?通常、アーキテクチャについて話すときは、ソフトウェア アーキテクチャについて言及しています。アーキテクチャとは、ソフトウェアの基本構造、これらの基本構造を作成するための原則、およびこれらの構造の説明を指します。この定義に基づくと、建築とは多くの場合、物事の主題の構造的記述であると簡単に理解できます。

製品アーキテクチャは、製品の構造的な説明です。一般的には、フロントエンドシステム、業務管理、運用管理、基本サポートなどのサブ製品またはサブシステムが含まれ、各サブ製品またはサブシステム間の関係が記述されます。

企業全体の戦略のもと、企業戦略など複数の要素に基づいて組織構造を設計する必要があります。組織構造はビジネス構造に影響し、ビジネス構造は製品アーキテクチャに影響し、製品アーキテクチャは技術アーキテクチャに影響します。

このチェーンから、製品アーキテクチャはビジネス アーキテクチャに基づいていることがわかります。製品アーキテクチャを実行する前に、ビジネス アーキテクチャを明確に理解する必要があります。

1. ビジネスアーキテクチャが製品設計に及ぼす 5 つの影響

ビジネス アーキテクチャは組織構造に基づいて設計されます。ビジネス アーキテクチャは、企業のビジネス戦略を日常業務に変換するためのチャネルです。ビジネス戦略は、ビジネス運用モデル、プロセス システム、組織システム、リソース配分などの内容を含むビジネス アーキテクチャを決定します。

ビジネスアーキテクチャは比較的専門的な研究テーマです。技術者は一般的に、ビジネス アーキテクチャにはあまり注意を払わず、製品アーキテクチャと技術アーキテクチャにもっと注意を払います。ここで、ビジネス アーキテクチャとは何かを簡単に説明します。これらのアーキテクチャは実際に当社の製品アーキテクチャ設計に影響を与えます。下の図 5-1 は、ビジネス アーキテクチャ設計の 1 つを示すフレームワーク図です。

ビジネスアーキテクチャ図

ビジネス アーキテクチャは、企業の収益モデル、支出コスト、顧客グループ、顧客関係、必要なリソース、主要なアクティビティ、およびパートナーを設計および説明します。

ビジネス アーキテクチャが製品アーキテクチャに与える影響は、主に次の側面に反映されます。

1. システム参加者

通常、ビジネス構造によってユーザーの範囲が定義されます。チャネルディーラーや代理店、主要顧客営業チームなどのマーケティング側の参加者。アフターセールス、カスタマーサクセス、その他のチームなどの運用側の参加者。サードパーティの協力プラットフォームなどのパートナーの参加。各ロールは、必要に応じて対応する端末で設計されます。

2. システム運用プロセス

ビジネスアーキテクチャには、アカウントの開設、更新、解約、変更、販売前および販売後の作業注文処理、在庫の入出庫処理、契約処理、請求処理などの運用プロセスが明確に定義されています。SaaS プラットフォームを構成するこれらの運用プロセスは、製品が商業的価値を実現するための重要な手段であり、製品リンクには通常、対応する処理が必要です。

3. コアバリュー

ビジネス アーキテクチャでは、SaaS サービスが顧客にもたらす価値を明確に定義する必要があります。この価値は、多くの場合、製品側を通じて提示される必要があります。ビジネス アーキテクチャの価値の説明は、主に当社の製品構築の焦点です。

4. 周辺システム

ビジネス アーキテクチャ内のパートナーとリソースは、ある程度、製品と対話する必要がある他のシステムを反映しています。これらの「その他のシステム」には、製品に必要な基本的な機能 (テキスト認識、コンピューティング能力など)、データ (認証データ、ビジネス データ)、プロセス (管理プロセス、運用プロセス) などがあり、これらの機能はパートナーまたは会社の既存のリソースによって提供される必要があります。これらの周辺システムは、さまざまな方法で製品の操作をサポートします。

5. 課金モデル

ビジネス アーキテクチャは通常、収益とコストのモデルを記述します。収益処理プロセスは運用製品の設計に影響します。たとえば、企業がオフラインで支払いを収集する場合、製品ではユーザー アカウントの可用性または有効期間を制御するだけで済みます。会社がオンラインで支払いを収集する場合は、有効化と更新のためのオンライン支払いプロセスを設計する必要があります。一部の SaaS 製品では、財務処理を容易にするために収益と費用の償却も行われ、そのような計算も製品内で完了する必要がある場合があります。

あなたの会社に明確な事業構造がなかったり、いくつかのリンクが欠落していたり​​したらどうしますか?ご案内できる場合は、事業部門が関連リンクを改善するよう全力を尽くしますが、変更できない客観的な状況もいくつかあります。既存の構造に応じて情報を収集して整理し、全体的な構造設計を適切に行うことで、拡張性を確保し、後続のニーズに対応できるようになります。次に、各ビジネスリンクの成熟度に応じて製品アーキテクチャを設計し、段階的に実装します。

2. 製品アーキテクチャ

SaaS 製品のアーキテクチャを設計するときは、モジュール設計とプログレッシブ設計を検討できます。

2.1 モジュール設計

モジュール化とは、ビジネス間の結合を減らすことを意味します。低結合と高凝集は技術アーキテクチャの重要な設計原則であり、製品側でも学ぶ価値があります。

モジュール設計は、システムモデリング、テクノロジーの実装、アップグレードの反復、ビジネスの促進に非常に役立ちます。モジュール設計は、最小化シナリオ (MVP) の効果的なサポートでもあります。

企業が成長するにつれて、SaaS 製品のビジネス範囲と機能はますます大きくなりますが、顧客は機能の一部しか必要としない場合があります。機能間の結合が多すぎると、顧客の機能選択に対する制約が増加します。販売方針の策定にも制約が生じ、商品を柔軟に組み合わせて販売することができなくなり、事業推進にも一定の影響が出ることになります。

モジュラー設計を行うにはどうすればいいですか?

モジュラー設計は、独立した再利用可能な業務や機能を抽出し、機能セットを製品にパッケージ化して販売促進や使用に役立て、顧客がニーズに応じて製品を組み合わせるのに便利にします。モジュール設計は従来のソフトウェアでも非常に重要です。

（１）分類と抽象化

類似の機能やシナリオは分類し、設計のために抽象化する必要があります。ソフトウェア設計の分野では、低レベルのものほど再利用が容易になり、アプリケーション指向のものほど再利用が困難になります。たとえば、ソフトウェア サービスのセットには、サーバー ハードウェア、アプリケーション サービス ミドルウェア (データベースなど)、さまざまなマイクロサービス、ビジネス プロセス、外部ポータルなどが含まれる場合があります。このソフトウェア アーキテクチャでは、サーバー ハードウェアはアーキテクチャの下部にあり、比較的基本的で汎用性が非常に高くなっています。アプリケーション ポータルはアーキテクチャの上位レベルにあり、形式は比較的柔軟で、再利用性は低いです。製品側でも同様です。人事や組織などの基本的な情報が基本情報に該当します。異なるシステム内の同じ組織の構造は一般的に同じであり、再利用性が非常に高くなります。 2つ目は、さまざまなビジネスプロセス、そしてビジネスフォームです。

私たちがやりたいモジュラー製品設計とは、さまざまなユーザーのニーズに応じて、あるビジネスを完結するためのシナリオを分析、分類、抽象化し、共通部分を抽出して、複数の組み合わせを実現できる製品形態を作ることです。

（２）データインターフェース

システムは一般的に、ロジック (アルゴリズム) と情報の 2 つの部分で構成されます。情報はさらにコンテンツとデータに分けられます。ロジックはソフトウェア機能を構築するための骨組みであり、コンテンツとデータはその血肉であり、その中でも特に重要なのがデータです。

ソフトウェアのモジュール化とモジュール間の独立性を実現したい場合、まずロジック（実装方法）を放棄する必要があります。ロジックが存在するということは、2 つのモジュールが互いに分離不可能であり、独立しているとは言えないことを意味するためです。

これら 2 つのモジュールを関連付ける必要があるが、論理的に相互に干渉することが許可されていない場合、最善の方法は、それらに含まれるデータを抽象化し、標準化されたインターフェースを形成し、データ呼び出しの形式で 2 つのモジュール間の相互連携を実現することです。

モジュール性の特徴の 1 つは再利用です。製品設計において、再利用とは複数のシナリオを組み合わせることを意味します。シナリオが 1 つしかない場合は、再利用ではありません。複数のシナリオで必要になった場合は、データのやり取りが必要になります。モジュール設計とは、共通するものを抽出し、データのやり取りのための標準インターフェースを提供することです。この共通のものは、フィールドまたはルールになります。

誰もが普段理解している SDK も、モジュール設計の現れです。モジュール式製品は、インターフェース、機能、またはサブシステムになります。

2.2 プログレッシブデザイン

SaaS 製品は徐々に反復され、製品の設計を一夜にして実現することはできません。継続的なプロセスが必要です。プログレッシブデザインは SaaS 製品に非常に適しています。例えば、当社の製品には、法人顧客、団体顧客、代理店、プラットフォーム運営者、アフターセールス担当者などが関わってきます。システムを設計する過程では、一度にすべての作業が完了するわけではありません。このサイクルは長すぎるため、製品と市場の適合性を迅速に検証するのに役立ちません。したがって、製品アーキテクチャは自然に段階的な設計プロセスになります。

インクリメンタル設計では、その後の製品拡張のニーズを満たすために、将来の製品の全体的な状況を可能な限り考慮する必要があります。

私がかつて携わった製品を例に挙げてみましょう。製品のユーザーは3つのカテゴリに分類でき、関係は次のとおりです。

製品関係の例

製品アーキテクチャを構築する過程では、こうした基本構造を理解した上で、優先順位に従って段階的に製品の開発を進めていきます。図に示すように:

製品アーキテクチャ例図

まず、ユーザーが利用できるように、エンタープライズ版の製品とシンプルな運用管理システムを構築しました。その後、エージェントの力が増大し続けるにつれて、エージェントの管理システムを設計する必要が生じました。エージェントシステムは、会社の運用管理システムに依存する必要がありました（エージェントは運用の初期段階で会社に加わり、運用管理プラットフォームには、顧客が所属するエージェントをマークできる最も単純なエージェント管理機能しかありませんでしたが、エージェント管理システムは開発されておらず、拡張機能のみが予約されていました）。

プラットフォームの発展に伴い、ユーザーグループは拡大し続けており、グループ顧客数も増加しています。同社では、グループ法人顧客のニーズに応えるため、エンタープライズ版製品をベースにグループ版製品を開発。

エージェント管理システムと会社運営管理システム全体も、初期の企業登録審査から、ユーザーの作業指示管理、決済・更新管理、そしてグループバージョンのアクティベーション管理プロセスと決済プロセスの追加まで、数年をかけて反復的に進められました。製品の全体的なアーキテクチャは、徐々に現在のシステムになるまでに複数のバージョンの反復を経ており、現在も改善が続けられています。

製品アーキテクチャの増分設計は、最小限の実行可能な製品 (MVP) と同じではありません。製品アーキテクチャの増分設計は、製品の着実な進歩と拡張性を確保することを目的としています。まず、現在の重要なニーズと問題の解決に重点を置きます。再構築が必要になる可能性のある MVP で表現されるすべてのプロセスではなく、蓄積された製品結果が将来の製品開発の基礎となります。

MVP の非常に鮮明な例があります。ユーザーの需要が自動車である場合、自動車の MVP と製品進化プロセスは、以下の図 5-5 の 2 番目の部分に示すようになります。

MVPの進化

製品アーキテクチャのプログレッシブ設計と製品の MVP との間にはどのような関係があるのでしょうか?実際、それらは 2 次元上の 2 つの物体です。製品アーキテクチャの進歩的な設計は、現在のビジネスへの迅速な対応と将来のビジネス拡大のサポートとなります。

MVP は、反復中のさまざまな段階でリファクタリングが必要になる可能性がある製品です。上記の例はいくつかの製品フォーラムで説明されており、MVP の非常に正確な説明です。最小限の実行可能な製品は、各反復で完全に利用可能である必要があります。利用可能なシナリオのクローズドループは、MVP の中心的な指標です。これは、製品を0から1まで検証するのに効果的な方法ですが、このような再構築は必ずしも必要ではないと思います。

多くのソフトウェア製品は、反復プロセス中に元のベースで拡張されます。実際、製品アーキテクチャは柔軟かつ拡張可能であり、これは優れた製品マネージャーに必要な能力です。結局のところ、歴史的な投資にはコストがかかります。優れたデザインは、最初からやり直すのではなく、元の基盤を拡張したものであるべきです。

Bサイド製品の開発プロセスでは、製品とサービスの組み合わせに重点が置かれます。このサービスは、製品をサービスとして提供するという意味ではありませんが、初期の製品が完璧でない場合、一部のリンクはオフライン サービスによって補完されます。これも SaaS 製品開発の一形態です。

製品アーキテクチャは、システム間の関係を一般的に説明できますが、製品アーキテクチャ図では特定の製品プロセスを明確に表現できないため、システムフローチャートを使用して説明する必要があります。