SaaS企業のインプリベンダーとしてDXのプロジェクトを考えてみた

2020年3月23日 11:57

みなさまはじめまして！！

RevComm 小松さん（@ShoheiKomatsu）のリレーブログ企画に参加させていただきました！ #SaaSLovers の23日目を担当します。

私はタンバリンという開発会社で小売や消費財メーカー(B2C/D2C)のコンシューマ向けブランドのEコマースやデジタルプロダクト開発、データマネジメント/分析のためのクラウドインテグレーション事業をおこなっています。

SaaSビジネスとの関わり

前職に在籍していた、2006年頃からセールスフォース・ドットコム社のコンサルティングパートナーとして、主に大手企業のウェブサービスやEコマースからSalesforceのCRMデータに連携するシステムを開発してきました。SaaS企業のインプリベンダーとしてあっという間に10年以上が経ってしまいました。

2006年当時のSalesforceのプラットフォームにはいわゆるカスタマー/コンシューマ向けサービスは少なく（Marketing Automationも存在しませんでした）、現在では考えられないほどに限られた手段でしかコンシューマ向けにSalesforceの顧客データを活用することができませんでした。

そのような状況の中で、いわゆるユーザ属性に応じた会員向けウェブサービスのコンテンツの出し分けやコールセンターへの連携、広告配置システムへの連携などは基本的にAPI連携とSalesforce内の内部ロジックを駆使してカスタマイズしたプログラムをプロジェクト毎に組んでいました。

潮目が変わったと感じたのは2010年のHerokuの買収と、2013年のExactTarget（Pardot）の買収でした、特にHerokuというPaaSのプラットフォームが加わったことで一気に/コンシューマ向けサービス開発の自由度があがり、さらにSalesforce内の顧客データとの連携によって効果的なメール配信やオートメーション・プログラムが書けるようになりました。

最近では2016年にDemandware（CommerceCloud）、2019年にTableauなども加わって、我々がやりたいと考えていた、B2C/D2Cビジネスを加速するための効率的なプロダクト開発やデータインテグレーションが実現可能な環境になってきていてとても幸せです。

SaaSテクノロジーで実現できることの質が高まってきた

SaaSやPaaS（IaaSも）などの人々の課題となる問題を提起し、実際に問題を解決に導くことができるウェブベースのプラットフォームの出現により、SIのビジネスは大きく変わりました。

例えばグローバルな配車サービスをつくる場合に必要な技術的な要素、例えばGPSと連動した地図のサービス、テキストメッセージ、膨大な位置情報や（IoT）機器情報を格納するデータストレージ、決済関連のサービスなど、すでに存在している技術的なコンポーネントを組み合わせてサービスを構築することができます。

特に、Salesforceはデジタルプロダクトの開発効率だけではなく、マルチクラウド上に存在する顧客やサービスの情報をどう可視化し、活用するかという観点で、信頼できる唯一の情報源（SSOT：Single Source of Truth）をどのように構築するかについて長年データ連携や統合のノウハウを蓄積してきました。

このような流れはPeter Yaredさんが下記の記事で言ってるような、時代がフルスタックな技術者ではなく、フルスタックなインテグレーターを必要としている背景と言えると思います。

SaaSやPaaSなどのプラットフォームの登場によって、クライアントワークにおいてのインスピレーションとアイデアを試すコスト、プロトタイピングのコストは下がり、テクノロジーで実現できることの質は劇的に上がってきたと感じています。

ベンダー間の垣根を超えて仕事を進めるチームを構築することの重要性

いわゆるDX（デジタル・トランスフォーメーション）という概念には下記の3つの目的があります。

- ビジネスモデル変革
- 新ビジネスの創出
- 新しい顧客との関係を価値を創出

現場の世界に精通しているクライアントが先頭に立ってSaaSやPaaSなどの技術的なツールを使い、新しい適応方法をトライできるように支援しなければいけませんが、その一方で、クライアントのビジネス部門があらゆる領域のテクノロジーを理解してDXプロジェクトをすすめることはまだまだ難しい状況です。

このような点から今後どのようなアプローチが有効なのか考えていたところ、VCにいらっしゃるANRIのナカジさん（@nakajish）の記事では高価なERP・基盤システムをクラウド化し、SMBにもその恩恵をもたらしたDX2.0（Horizontal SaaS）から、DX3.0ではビジネスオペレーションやサプライチェーンマネジメント、CX（カスタマーエクスペリエンス）の変革を実現するには、SaaSベンダーが持つテクノロジーや知見（アセット）を基軸にしてEnterpriseとの協業が進むのではないかと分析されています。

我々のようなインプリベンダーもSaaSやPaaSを活用したマルチクラウドでの開発手法やインテグレーションの知見を共有し、クライアントが素早くアイデアの検証にトライできる状況を作り、DXを推進したいクライアントとの共創のプロセスをSaaSのベンダーも含めて、クロスファンクショナルチームでプロジェクト進めていかなければなりません。

特にDX化される知的作業や業務のなかで因果関係が認識できるケースはベストプラクティスに落とし込める可能性が高く、SaaSのプラットフォームにうまく適応することができればプロジェクトの成功率は格段に上がってくると思っています。

今後SaaSベンダー側の知見やベストプラクティスに則ったプロジェクト推進のテンプレート提供やSaaSベンダー側からDXのプロジェクトをアセスメントしたり監査したりするケースも増えてくるのではないでしょうか。

プロジェクトの基本構成
- 規律/コミュニケーション戦略
　- ワークアグリーメント
　- アジャイル/スクラム開発
- 開発手法等
　- OOUI
　- Atomic Design
　- DDD
　- TDD
　- service-oriented architecture(SOA)
- ツール/サービス/プラットフォーム
　- SaaSやPaaSなどのクラウドプラットフォーム
　※SaaSベンダーが持つテクノロジーや知見（アセット）を提供してもらう
- 外部ネットワーク
　- 戦略コンサルティングやクリエイティブチーム

一方、AIなどを活用した予測モデルができたとしてそれを「どれくらいの精度であれば顧客にむけたサービスつかえるか」というような、状況が複雑な場合にはうまく判断ができないケースが存在します。

DXを推進するクライアント側の体制や意識決定をおこなうフローをどう構築するのかという点は常に課題であり、SoE的な人材が圧倒的に不足しています。

また多くのプロジェクトは場合は要件を満たしたシステムを作って終わりというわけではなく、絶え間なく変化するビジネス課題や最新の技術要素の検討、市場調査、ユーザーヒアリングを繰り返し、フィードバックを受けながらプロジェクトをすすめて行く必要があります。

スクラム開発やサービスデザインなどの共創メソッドを活用し、柔軟に状況に対処しながら、インプリベンダーSaaSベンダー間の垣根を超えてチームを構築し、ともにプロジェクトを進めることの重要性が高まってきていると感じています。

この記事が気に入ったらサポートをしてみませんか？