SaaS 製品の場合、製品アーキテクチャを 0 から 1 に構築することが非常に重要です。

SaaS 製品のアーキテクチャが適切に構築されていない場合、最も直接的な結果は次のようなものになる可能性があります。

• 顧客が特定のタスクを完了しているとき、操作プロセス全体を通じて顧客の操作ページに無関係な機能が多数表示され、顧客が効率的に作業を完了できなくなります。
• 製品アーキテクチャガイダンスのフレームワークがなければ、新しい要件や新しい機能が後続の製品マネージャーによって恣意的に分類されたり、新しい問題を解決するために新しい分類が作成されたりして、より混乱した製品になる可能性があります。
• 要求が増えると機能が増え、機能の結合度が増し、開発の難易度がさらに高まり、アーキテクチャを再構築しなければならない状況に直面することがよくあります。

逆に、アーキテクチャが適切に構築されていれば、少なくとも次のような利点がもたらされます。

• 顧客にとって、表示されるページは簡潔で、タスクを効率的に完了できるため、顧客に価値をもたらし、ビジネスに商業的価値をもたらします。
• 無理なアーキテクチャ構築による再構築を心配する必要はなく、新しい要件と新しい機能は基本的にアーキテクチャ内で適切な場所を見つけることができます。
• それは達成可能であり、企業はより低いコストでさまざまな顧客のさまざまなニーズを満たすことができます。

建築工事の品質がビジネスに比較的大きな影響を与えることがわかります。

「SaaS 製品のアーキテクチャを 0 から 1 に構築するにはどうすればよいか」について説明する前に、まずアーキテクチャを定義しましょう。

「アーキテクチャ」の定義を百度百科事典で検索したところ、理解しにくい専門用語の説明が多く含まれていることがわかりました。

そこで、私自身の理解に基づいて新しい定義を作成しました。

アーキテクチャの定義は次のとおりです。「アーキテクトは、ビジネスに対する理解に基づいて、1 つのモジュールから始めて別のモジュールを派生させ、さらに 1 つのモジュールから始めて別のモジュールを派生させ、製品全体に含まれるモジュールの順序をできるだけ明確に整理し、それらを接続して特定の種類の問題を解決します。これが製品アーキテクチャです。」

この定義には 3 つの重要なポイントがあります。

• ビジネス モジュールが 1 つずつ続きます。つまり、N 個の複数のビジネス モジュールが存在します。
• モジュール間には接続関係という関係があります。
• モジュールは目的のために相互に接続されており、特定の種類の問題を解決するために存在します。

追記：これもまたシステム思考の応用ではないでしょうか？ 興味のある方はご自身で関連情報を確認してください。 ここではシステム思考について詳しくは紹介しません。

• N 個のビジネス モジュールを見つけるには、構造的な思考が必要です。
• モジュール間の接続関係を整理するには論理的思考が必要です。
• あるカテゴリーにおいてどのような問題を解決する必要があるかを知るには、戦略的な計画が必要です。

つまり、SaaS 製品を 0 から 1 まで構築したい場合は、次の 3 つの側面から総合的に考える必要があります。

• 戦略策定;
• 構造的思考;
• 論理的思考。

これら 3 つの側面を理解することで、製品アーキテクチャを 0 から 1 まで構築する全体的な理解が得られると考えます。

では、一つずつお話ししていきたいと思います。

1. 戦略策定

記事の前半で述べたように、製品アーキテクチャを構築し、製品モジュールを次々に組み合わせて接続する目的は、特定の種類の問題を解決することです。

SaaS 製品の場合、この「特定の種類の問題」は戦略的な問題です。

この「特定の種類の問題」がなぜ戦略的な問題なのかを推測してみましょう。

0から1までのSaaS製品から、モジュール同士の組み合わせや接続によりシステムを形成し、クローズドなビジネスループを実現できるSaaS製品です。

SaaS 製品はどのようにして生まれるのでしょうか?

SaaS 製品は、戦略的ガイダンスに基づいて戦略を実装するためのロードマップです。

そのため、ここでこの「特定の種類の問題」は戦略的な問題であると私たちは言います。

製品戦略、あるいは製品マネージャーにとって最も重要な役割は、何をすべきか、何をすべきでないかを知ること、そして解決すべき問題の境界がどこにあるかを明確に、あるいは大まかに知ることです。そして、その境界内で製品を定義および設計し、顧客に価値をもたらし、ひいては会社にビジネス価値をもたらすことです。

戦略的な課題をどのように整理するかについては、以前書いた記事「To Bビジネスの戦略をどう整理するか？」を参考にしてください。 」では、戦略的な問題をどのように整理するかについてはここでは詳しく説明しません。

各企業の各事業の戦略は、業種、機会、自社の能力に応じて基本的に異なる場合があります。

しかし、これらすべての違いを抽象的に考えて分類すると、企業が作成するすべての SaaS 製品は基本的に次の 2 つのカテゴリに分類されることがわかります。

• ビジネス垂直型;
• 業界垂直。

PS: もちろん、スタートアップのビジネスが成長するにつれて、これら 2 つのカテゴリは 1 つに統合され、SaaS 製品には複数の垂直産業における複数のビジネス シナリオに対応する複数のソリューションが含まれるようになります。

1. ビジネス分野

ビジネスの垂直性は、SaaS 製品が解決する必要がある問題は、企業のビジネス システム内の特定のシステムである (解決する問題は、企業のバリュー チェーン内の特定のリンクの問題であるとも言えます) と理解できます。

少し抽象的でわかりにくいかもしれませんので、2つの例を挙げて説明しましょう。

例えば：

• 製造業では、企業のビジネスシステムは、研究開発 - 調達 - 製造 - マーケティング - 販売 - サービスというようになります。
• 広告業界における企業の業務システムは、媒体の購買→顧客の開拓→商品企画→販売企画→広告制作→実施・検討といった流れになります。

これら 2 つのケースは、製造業と広告業のビジネス システムの紹介 (または、製造業と広告業のバリュー チェーンの関連リンクの紹介) です。

SaaS スタートアップ企業は、大規模なビジネスシステム全体から 1 つまたは複数の小規模システムを抽出し、それに応じた SaaS 製品ソリューションを提供します。これが垂直型ビジネス タイプです。

さまざまな業界の業務システムにおける小規模システムを抽象的思考によって抽出し、共通の小規模システムを見つけ、これらの小規模システムに必要な SaaS 製品ソリューションを提供します。

主流の一般的なビジネス垂直 SaaS 製品は現在、次のビジネス シナリオを解決します。

• CRM;
• 人事;
• ERP;
• プロモーションマーケティング;
• 財務および課税;
• OA等

特定の業種に関連するビジネスを解決する場合は、業種シナリオごとに、関連する書籍、競合製品、関連するベンチマーク企業のワークフローなどを参照して理解し、最終的に一定のビジネス認識を形成できます。

これは、後で製品アーキテクチャを構築する際に非常に役立ちます。

2. 業界別

業界の垂直性とは、会社の SaaS 製品が解決しようとしている問題が、特定の垂直業界に関連していることを意味します。

例えば：

• 小売り;
• 食べ物;
• 旅行;
• 教育する;
• 医療;
• 物流など。

業界固有の問題を解決する場合、考慮すべきフレームワークが 2 つあります。

産業チェーン+企業バリューチェーン。

まず、業界チェーンについて考えます。その結果、業界チェーン内のどの事業体が会社のビジネス上の問題を解決する必要があるかが明確にわかります。

どの事業体の問題を解決する必要があるかを把握した後、次に考えるべきことは、事業体の問題のどのバリュー チェーン リンクを解決する必要があるかということです。

例えば：

観光という垂直産業に参入したい場合、まずは産業チェーンを分析する必要があります。観光産業チェーン全体は、おおまかに 4 つのリンクに分けられます。

上流サプライヤー（観光地、ホテルなどを含む） - チャネルディーラー - メディアおよびマーケティングプラットフォーム - ユーザー。

さまざまな分析を行った後、景勝地運営者がビジネス関連の問題を解決するのを支援することにしました。

次に、景勝地の解決を支援するためにどのようなビジネス上の問題を支援する必要があるかについてさらに考えますか?

この時点で、観光地のバリューチェーンに含まれるモジュールを整理する必要があります。整理した後、大まかに生産、マーケティング、販売、物流、サービス、人的資源管理、財務管理などが含まれていると結論付けることができます。

さまざまな分析を行った後、観光地のマーケティングとサービスリンクの問題を解決し、最終的に観光地のマーケティングとサービスリンクの問題を解決するための SaaS 製品を設計することを決定しました。

これら 2 つのシナリオに到達した後、関連する書籍、競合製品、および関連する観光スポットのワークフローを参照して理解し、最終的に一定のビジネス認識を形成できます。これは、垂直産業の SaaS 製品がビジネスの問題を考える際の思考プロセスです。

2. 構造的思考

戦略が策定されたら、製品フレームワークの構築を開始します。

戦略策定モジュールで議論された内容では、ビジネス垂直型 SaaS 製品であっても、業界垂直型 SaaS 製品であっても、最終的にはバリュー チェーンの特定のリンクに戻って検討する必要がある状況が見つかります。

バリューチェーンの特定のリンクに戻るときは、異なるリンクで構造的な思考を形成する必要があります。

構造的思考とは何ですか?

構造的思考とは、大きな問題に遭遇したときに、それを自分が理解できる小さな問題に分解し、それらの小さな問題を一つずつ解決することを意味します。この考え方と問題解決の方法が構造的思考です。

ここで、SaaS 製品に戻り、構造化思考を使用して製品アーキテクチャ内の N 個以上のビジネス モジュールを識別する方法を見てみましょう。

SaaS 製品で通常使用される構造化された思考フレームワークは次のとおりです。

つまり、さまざまな方法を通じて、最終的には、特定の種類の問題に対して、SaaS 製品の第 1 レベルのビジネス モジュールにどのモジュールが含まれ、第 2 レベルのモジュールにどのモジュールが含まれるかという結論に到達できます (さらに複雑な製品は、第 3 レベル、第 4 レベル、およびその他のビジネス モジュールに細分化できます)。

例:

ここでは、記事で言及されている景勝地を例に挙げ、構造化された思考を通じて、景勝地のマーケティング問題を解決する SaaS 製品を見て、第 1 レベルおよび第 2 レベルのモジュールにどのようなビジネス モジュールが含まれているかを確認します。

景勝地のマーケティングの問題を解決するには、次のようなことが考えられます。

• つまり、オンラインでチケットを購入する場合は、チケット管理モジュールが必要です。
• それをユーザーにどのように表示するか? オンラインストアを通じて、ストア管理モジュールが必要です。
• すると、突然、売上金を表示し、観光地が現金を引き出せるようにするモジュールが必要で、そのためには金融センターが必要だと考えます。
• 次に、競合他社を分析し、閉じたビジネス ループを形成するには注文モジュールが必要であることがわかり、注文モジュールなどが存在することになります。

つまり、ビジネスの理解、業界知識、関連する競合他社の参照、ベンチマーク企業の調査など、さまざまな方法を通じて、製品アーキテクチャに必要な第 1 レベルおよび第 2 レベルのモジュールを整理したことになります。

整理した結果、観光地 SaaS 製品の第 1 レベルおよび第 2 レベルのモジュールは次のようになると結論付けました。

PS: 理解を容易にするために、上記の第 1 レベルおよび第 2 レベルのモジュールの詳細は省略されています。

3. 論理的思考

構造的思考を通じて、製品の第 1 レベルおよび第 2 レベルの複数のモジュールを考案します。

この時点では、各製品モジュールが独立しており、相互に接続されていないため、製品システムの全体的な考えがまだ完成していません。その結果、効果は発生しません。

さまざまなモジュールを効果的に接続することによってのみ、目標を達成し、問題を解決することができます。

このとき、論理的思考が必要になります（論理的思考は基本的にすべてのプロダクトマネージャーに必要な思考方法です）。

あなたはこう考えているかもしれません:

• 観光地がチケットを販売したい場合は、まずチケット管理モジュールのセカンダリモジュールにチケット追加モジュールを設置する必要があります。
• チケットを追加した後、観光客に提示して閲覧および購入してもらう必要があります。そのため、店舗管理には店舗装飾用の二次テンプレートが必要です。このテンプレートによって解決される問題は、ユーザーに提示したい店舗を装飾することです。
• 観光客がストアを通じてチケットを購入した後、注文を確認し、注文操作関連の問題を完了するための注文管理モジュールがバックグラウンドで稼働している必要があります。
• 同時に、チケットを購入した後、ユーザーはユーザー情報、関連データ、資金到着の結果を残すため、ユーザー管理、財務管理、データセンターのモジュールがあります。

最終的に、分類を通じて、観光スポット SaaS 製品のさまざまなモジュール間の接続関係は次のようになると結論付けました。

追記：理解しやすいように、上記の論理的思考図を編集しました。

上記の戦略策定、構造的思考、論理的思考の 3 つのモジュールを理解することで、0 から 1 までの製品アーキテクチャの構築を総合的に理解できると考えています。

アーキテクチャ能力を持つことは、プロダクトマネージャーにとってだけでなく、職場のすべての人にとって非常に重要であることがわかりました。

たとえば、この記事の執筆プロセス全体では構造的な力が使われています。

• この記事を書く目的は、「0 から 1 までの SaaS 製品アーキテクチャ」についての私の理解を整理し、「0 から 1 までの SaaS 製品アーキテクチャを構築するには?」というテーマで読者のために質の高い記事を書くことです。
• 使用されたモジュールは、戦略策定、構造的思考、論理的思考の 3 つです。
• これらのモジュール間の論理的な関係は、戦略策定を通じて構造的思考と論理的思考を導きます。

例えば、最近、友人から、会社のチームの同僚が最近、いくつかの資料を次から次へと書いていたが、無理なアーキテクチャ構築のため、資料の特定の部分を変更すると多くの場所を再構築する必要があり、関連資料の完成までに多くの時間がかかっていると話していました。

構造的な力は本当に良いものです。

役に立たないけれども、何にでも使える。

著者: 馮 賢飛

出典: Xiao Fei Ge のノート