PM視点で読み解く 基幹システム運営録 4： 現在の構成を読み解く — くらめそ基幹システムアーキテクチャの全体像
本連載ではこれまで、基幹システム運営をPMの視点から整理し、年度設計による管理や、アーキテクチャを「意思決定の履歴」として捉える考え方を紹介してきました。
では、実際に現在の基幹システムはどのような構成になっているのでしょうか。
本稿では、クラスメソッドの基幹システムを例に、アーキテクチャを俯瞰しながら各システムの役割や依存関係を整理します。社内メンバーが参照できるリソースとしても利用できるよう、現行構成の全体像をまとめていきます。
1. 基幹システム全体像
まず、現在の基幹システム構成の全体像（一部抜粋）を示します。
この構成は大きく次の領域に分けることができます。
- 営業・顧客管理
- 契約・請求管理
- サポート管理
- 財務会計
- 稼働管理
それぞれのシステムが役割を分担しながら連携しています。
以下では、幾つかの特徴に着目して、その構成の背景を述べていきたいと思います。
2. 基幹システム構成の特徴とその背景
HubSpotとSalesforceの併存
SFA/CRMのSaaS、HubSpotとSalesforceを両方使っています。普通にみるとかなり違和感のある構成だと思います。ほぼ同じ機能、役割を有するSaaSをなぜ二つ使っているんだ？と。
ここを理解していただくには歴史を語る必要があります。
クラスメソッドはSalesforceを約10年程前に導入しています。私はまだ入社前のことになりますので聞いた話になりますが、この頃のクラスメソッドはAWSリセール事業が著しく成長してきており、お客様に発行する請求書の作成（当時300枚/月）が追いつかず、担当が残業・休日出勤を繰り返すような状態であったそうです。
作業のボトルネックとなっていたのは様々なファイルやシステムに情報が分散することでデータの一元管理がなされていなかったこと。これにより、
- 曖昧な業務フロー
- 顧客マスタ、請求先部署マスタの散財、表記揺れ
- 契約情報が散財しマスタに紐づいていない
- 台帳ごとのデータの食い違い（開始日、契約数）
- これらに伴う数多くの人間による確認、コミュニケーションの発生
といった問題が生じていました。
ここにSalesforceを導入することでデータの一元管理を進めて、業務フローを整理し、自動化を促進したという歴史があります。
この辺りは詳しくは植木さんが書かれた次の記事もご参照ください。
Developers.IO 2017セッション「A1. クラメソの請求を支える技術 〜40歳中年エンジニアの生存戦略〜」#cmdevio2017
重要なポイントは、クラスメソッドにおいてはSalesforceはAWSリセールの請求課題の解決という文脈で導入したということです。
HubSpotの導入
前節の通り、SalesforceをAWSリセールの請求課題の解決というニーズで導入しました。これにより、顧客マスタ、請求データがSalesforceに一元化され貯まるようになっていきました。しかし、さらにビジネスが発展するに従って次のような問題が生じるようになってきました。
- AWSリセールの請求に特化したカスタマイズが邪魔して、SFAとしての活用がしづらい
- セールスの人員増に正比例して増加するSaaSライセンス費（Salesforceライセンス）のコスト負担が重い
- 全社で営業情報を共有して活用（クロスセルの促進や解約抑制など）がしづらい
これらの問題を解決するため、データの参照にコストがかからないライセンス体系であったHubSpotの導入を行うことになりました。また、あわせてPardot+Salesforceを使っていたMA（Marketing Automation）もHubSpotに移管を行いました。これにより、AWSリセールに縛られないSFA環境とコスト抑制、データの全社活用が進みました。
HubSpotとSalesforceを繋ぐ営業ポータル
HubSpotの導入により、既存ビジネスに縛られないSFA活用が進みました。しかし、同時に、Salesforceの「顧客（取引先）」とは別に「会社」という似た情報がHubSpotに蓄積され、二重管理されるといった新たな問題群も生じてきました。
これまでの流れで、HubSpotには営業・提案中の状態も含めた「柔らかい情報」を保持し、Salesforceには成約済み・請求対象のみの「固い情報」を置くようになったと理解いただければと思います。問題はデータの分散と二重管理で、特にSalesforceはライセンス保持している少数名しかアクセスしないようにしたため、なんらかの連携の仕組みが必要になってきました。
そこで、HubSpotとSalesforce、および営業活動に必要な他の情報リソースを横断的にアクセス可能にする仕組みとして、Reactベースのスクラッチで営業ポータルというWebアプリを開発しました。新規SaaSを採用していないのは、利用者（≒社員数）の増加に伴ってライセンス費増とならないようにするためです。また、認証認可をEntraID+AWS Cognitoで実現することにより、営業ポータル自身も全社で使えるようになっています。
3. Salesforceの役割
ここまで見てきたように、営業活動の入り口はHubSpotが担っています。一方で、基幹システム全体の中で中心的な役割を担っているのはSalesforceです。
Salesforceでは主に以下の情報を管理しています。
- 顧客マスタ
- 商談・案件
- 契約情報
- 請求情報
これらは、営業活動の結果として確定した「業務データ」と言えるものです。HubSpotが営業活動の途中段階の情報も含めた「柔らかい情報」を扱うのに対して、Salesforceには契約や請求といった「固い情報」が集約される構造になっています。
このような役割分担になっている理由は、Salesforceが元々AWSリセール事業の請求課題を解決するために導入されたという背景によるものです。そのため、現在の基幹システム構成においても、Salesforceは営業ツールというよりも、契約・請求を中心とした基幹データ管理システムとして機能しています。
また、図を見ても分かる通り、Salesforceは他のシステムとの連携のハブとしても機能しています。営業ポータルやクラウドリセールサービスサイト、財務基幹システムなど、複数のシステムがSalesforceを経由してデータ連携を行っています。
4. 周辺システムとの連携
基幹システムはSalesforceだけで完結しているわけではなく、複数の周辺システムと連携することで業務全体を支えています。
まず、サポート業務についてはZendeskを利用しています。Zendeskでは主にサポートケースの管理を行っており、クラウドリセールサービスサイトと連携しています。これにより、契約中のお客様からの問い合わせ対応を一元的に管理することができます。
また、売上や債権の管理については財務基幹システムが担当しています。Salesforceで管理されている請求データはCSV形式で連携され、財務基幹システム側で売上・債権管理が行われています。
さらに、稼働管理システムでは計画工数や実績工数を管理しています。これらの情報は営業ポータルから参照され、営業活動や案件管理の補助情報として利用されています。
このように、基幹システムは単一のシステムではなく、複数のシステムが役割を分担して構成されていることが分かります。
5. 現在の構成の特徴
ここまで見てきた構成には、いくつかの特徴があります。
まず一つ目は、SaaSを中心としたシステム構成になっていることです。HubSpot、Salesforce、ZendeskといったSaaSを組み合わせることで、それぞれの領域に適した機能を利用しています。
二つ目は、システムごとに役割が明確に分かれていることです。
HubSpotは営業活動の情報管理、Salesforceは契約・請求などの基幹データ管理、財務基幹システムは売上・債権管理、といった形で責務が分担されています。
三つ目は、システム連携の方法が複数存在していることです。
HubSpotとSalesforceの連携ではREST APIが利用されていますが、財務基幹システムとの連携ではCSVファイルによるデータ連携が使われています。このように、API連携とファイル連携が混在している構成は、実際の業務システムでは比較的よく見られるものです。
そしてもう一つ重要なのは、この構成が最初から設計されたものではないという点です。
事業の成長や業務課題への対応の中で、新しいシステムを導入したり、既存システムの役割を調整したりすることで、現在の形に至っています。第3話でも述べた通り、アーキテクチャは「最適解」から作られるというよりも、意思決定の積み重ねによって形成されていくものと言えるでしょう。
6. まとめ
本稿では、現在の基幹システムの全体構成と、その背景について整理しました。
クラスメソッドの基幹システムは、Salesforceを中心に複数のSaaSや周辺システムが連携する形で構成されています。この構成は、一度に設計されたものではなく、事業の成長や業務課題への対応の中で段階的に形成されてきたものです。
このような既存システムを運営していく上では、理想的なアーキテクチャをゼロから設計するというよりも、現在の構成を理解し、その上で改善を重ねていく視点が重要になります。
次回は、このような既存の基幹システム構成を前提として、どのように改善や進化を進めていくのかについて、PMの視点から整理していきます。
