連携型 vs 統合型のプロダクトスタック

統合とは、複数の専門ツールを、ロードマップから分析、カスタマーサポートまでを一手に担う単一のプラットフォームに置き換えることだ。魅力は明らかだ——ログインは1つ、請求も1つ、データモデルも1つになる。トレードオフは、単一のプラットフォームがすべての機能で最良であることはほとんどなく、チームはしばしばあらゆる面で最大公約数的なワークフローに落ち着いてしまうことだ。

連携は異なる立場をとる。チームが既に頼っているツール——Jira、Linear、Stripe、GitHub、Intercom、Zendesk、Slack——をそのまま残し、そのデータを共有の基盤に取り込むことで、収益、プロダクトの作業、顧客フィードバック、コードの変更をひとまとめに見えるようにする。チームは自分たちの深さを保ち、組織は結合を得る。

連携されていないスタックの本当のコストは、ツールの数ではなく、部門を横断する問いに答えるために必要な手作業だ。最も多く払っている顧客は、最も多くバグを報告している顧客でもあるのか？離脱しつつあるアカウントから来ている機能リクエストはどれか？こうした問いに答えるには、通常CSVをエクスポートしたり、その場限りのSQLを書いたり、あるいは単に推測するしかない。連携型のアプローチは、この結合を自動化する。

AIOProductOSのようなプロダクトのオペレーティングシステムは、まさにこの考え方を中心に構築されている。その基盤は、顧客、収益、フィードバック、プロダクトの作業、分析、コードベースのデータを一か所に集め、結びつける。そのため、1つのアカウントを見れば、その顧客が何を払い、何をリクエストし、そのために何の作業が進んでいるかが分かる。Stripe、GitHub、Linear、Jira、Slack、Intercom、Zendeskなどを含むコネクタのカタログは、チームに使っているツールを手放すよう求めることなく、データを取り込む。そのポジショニングは明確だ——連携している、統合されているのではない。

統合が理にかなうのは、チームが小さく、ワークフローが単純で、運用オーバーヘッドの削減が専門的な能力の損失を上回る場合だ。初期段階のスタートアップは、しばしば大胆に統合し、それに成功する。リスクが現れるのは規模が大きくなったときで、統合されたプラットフォームが、専門ツールがそのカテゴリで提供する深さに追いつけなくなる。

連携の方がスケールに強いのは、それが仕事を置き換えるのではなく、仕事に沿っていくからだ。プロダクト組織が成熟し、優先順位付けや実験、分析のために専用に作られたツールを採用していくにつれ、連携された基盤は、あるカテゴリでより良いツールが現れるたびに全面的な置き換えを強制することなく、全体像を一貫したものに保つ。