プロマネの車窓から 3 〜 Salesforce 導入アプローチの観点 〜

October 26, 2020 Koji Komatsu

こんにちは、アピリオの小松です。
今回は、Salesforce 導入プロジェクトのアプローチを検討する際の「観点」をテーマに、ご紹介します。

1日でも早く

まず、Salesforce 導入を検討されているお客さまの視点から考察してみます。
Salesforce のようなサブスクリプション型のクラウドサービスの場合、利用開始時点から課金が発生します。そのため、投資に対する効果を少しでも早く享受したいということは、ほぼ例外なく求められますので、我々ベンダー側としては、そのシナリオをどのように組み立てるのか?を考えることになります。MVP(実用最小限の製品 - Minimum Viable Product) も、その一つの考え方になりますが、最終的にはお客様が求める「最小限・最低限の形とは何なのか?」を模索し、仮説を組み立てることを実施していきます。そして、そのゴールに最速で辿り着くための道筋を、現在地との対比から組み立てていくことになります。
この「現在地の把握」については、また別の機会に触れたいと思います。

SaaS vs. PaaS

Salesforceのプロジェクトと一口で言っても、利用するライセンス形態やお客様の期待値のコンディションによってアプローチが異なります。
Sales CloudやService Cloudに代表される「SaaS型」のライセンスをベースにビジネスプロセスの構築を行っていく場合、ベースとして提供されるオブジェクトや機能を理解した上で、お客さまの期待値をどの程度満たせるのか仮説を設定し、必要なコンフィグレーションとギャップに対するソリューションの組み立てを実施した上で、提供機能の全体感を組み立てていきます。
一方で、プラットフォームライセンスをベースとする場合や、Community Cloud 上でカスタムページを前提としたアプローチとなる場合、Salesforce であっても通常のカスタム開発に近いイメージで機能一覧を組み上げ、各機能ごとの想定仕様を設定し、その積み上げで提供システムの全体感を構成していきます。
それぞれの特性に合わせて、最適な要求仕様確定までの工程のシナリオを設定し、プロジェクトの進め方の骨子に仕上げていくようになります。

ウォーターフォール開発 vs. アジャイル開発

Salesforce 導入プロジェクトに適しているのはどちらなのか?
私もいろいろなプロジェクトを経験してきましたし、アピリオでも両方それぞれ存在するというのが実情です。
一定レベルでのベースラインが存在し、かつクラウドソリューションということもあるので、アジャイルの方が適しているのでは?という声もあるのですが、初期導入において一定の塊の機能群を実装することで初期スコープが成立する、という場合ではウォーターフォールに近い考え方の方が適している場合もあります。
一方で、要求仕様そのものが確定していない中で、段階的にリリースしていくことで効果が享受できるようなシナリオが成立する場合には、アジャイルの方が適しています。
アピリオでは、この課題に対応するためのアプローチとして「ハイブリッド・アジャイル」という考え方を採用するケースが多く、初期導入の多くのケースで採用しています。

方法論

アピリオにも「Appirio Way」というシステム導入方法論が存在します。
程度の差はあっても、我々のビジネスの組み立ての際には基本的にはこの方法論をベースに、実際の案件で「どのように適用できるか?」を考えていきます。
まれに誤解されることもありますが、方法論の内容をそのまま当てはめれば良いか?というと、決してそんなことはありません。「Apprio Way」に限らず、世の中の方法論は通常、一定の汎用性を備えた内容になっていますので、案件の規模やコンディションなどに応じて取捨選択しながら適用のための形を調整していく作業が必要になります。

カスタマイズ vs. 標準機能

お客さまからよく言われるキーワードの一つとして「カスタマイズ無しで標準機能で導入して欲しい」というものがあります。意図としては、カスタマイズを多用することで、初期構築コストの増加や保守性の低下、アップグレード対応性の低下等を懸念されていらっしゃいます。これらの話はカスタマイズの有無以外にも様々な要因が関連してきますので、私個人としてはあまりこれに固執しすぎると本質を見失うという考えです。
そもそも、Salesforce におけるカスタマイズとは何を指すのか?
これも明確な定義はありません。APEX や VFPAGE での実装を示す場合が多いかもしれませんが、これも使い方を間違えなければ、全く問題ありません。これらを適用することを回避するために、他の仕組みを濫用し、結果的に可読性の低下を招くこともあります。
Salesforce というプラットフォームを用いて実現する要求仕様に対し、その妥当性を検証・判断し、適切な対応方法に導くということを軸足に据えることが大切です。

ドキュメンテーション

Salesforce のプロジェクトにおいて、どのようなドキュメントを作成すべきなのか?これも頻繁に聞かれるテーマの1つです。これも一概にこうだというものはなく、前述の観点との組み合わせで決まります。Salesforce プラットフォームを用いて、画面系機能はスクラッチ開発に近い形で実装する場合には、通常のWeb開発と同じような画面設計の工程は必要になりますので、その場合には画面仕様を決定するためのドキュメントが必要になります。
一方で、Salesforce 標準の画面構成機能を用いて実装していくケースにおいて、ドキュメントありきでアプローチしていくのはリーズナブルな選択肢とはいえません。そのような場合にはモックアップベースで仕様を確定させていく、というアプローチをとります。
私が通常、どのようなケースでも作成するようにしているドキュメントとして「Solution Blueprint」があります。Salesforce そのものが非常に多岐にわたる実装のしくみを提供しており、その中からどのようなものを選択して適用し、どのようにコンフィグレーションを施し、どのようなビジネスロジックをどのような技術要素を用いて実装するのか、これらを包含した「全体地図」を、プロジェクトの進行中から作成しながら、完成形のイメージを共有していく、といった工夫をしています。

準委任契約 vs. 請負契約

これも、ほとんどのケースで議論となるテーマの1つとなります。
日本の場合、お客様から明示的に請負契約を前提とした提案を要望されるケースが多いようですが、アピリオでは両方の契約形態も対応しています。請負契約の場合、当然のことながら「対象の成果が明確であること」が大前提となりますので、それが定義できる場合は良いのですが、ほとんどの場合には一定量の流動的要素を含むので、個人的には通常、準委任契約をおすすめします。
Salesforce プラットフォームを用いた場合に、お客様の期待値を満たすためにどのような最終形が望ましいのか?は、ある程度の形が見えてきて初めてお客様自身も明確できる場合が多く、その過程において様々な調整が入りながらゴールを目指すことが、その理由の1つとなります。
予算を確定する必要がある、それが請負契約をご所望される理由の1つになると思います。最終ゴールがお互いに見えていない中で請負契約の形をとったとしても、結果的に変更要求のボリュームが肥大化することにもなりかねないため、案件個別のコンディションを見極めて適切なアプローチをご提示することになります。

ベストプラクティス

SCM や ERP の導入全盛期に頻繁に聞かれたキーワードの1つでしょう。Salesforce の導入においてもこの話題が出ることがあります。
誤解を恐れずに見解を述べさせていただくと、CRM を中心とした Salesforce の領域においては、正直あまり対応しないと思います。たしかに、Sales CloudやService Cloud等の機能群の前提となる「使われ方の前提思想」であったり、Industry Template 等のようにある程度の適合性を見越した事前セット的なものは存在します。しかしながら、顧客接点のあり方という観点で見た場合に、どのようなお客様でも一律で当てはまるものがあるのか?と言われると、それは少し違うと思います。
もちろん、他業種の事例等をベースに「活用できる要素」はいろんなケースで考えられますので、それらを要素分解して、他の案件へ組み合わせて適用していく、という工夫が必要です。

いつ考えるのか?

ここまで記載してきた観点に関して、「いつ、どのタイミングで考える必要があるのか?」ですが、ご察しの通り、プロジェクトが始まってから考えるのでは、時すでに遅し、となります。

企業によってPMの担う職務範囲に違いもあると思いますが、プロジェクト開始前、つまり「提案時点」でこれらの観点を盛り込んだ「方針」はしっかりと明確化しておくことが重要となります。実際の実行時点から参画する場合もありますが、その場合には上記観点に照らし合わせて「アプローチの考え方」を理解し、プロジェクトに臨むことが重要です。

プロマネの車窓からシリーズを寄稿しています。
次回、「プロマネの車窓から 4 〜 計画の勘所 〜」をおたのしみください。

プロマネの車窓から 1 〜 PMキャリアの魅力 〜
プロマネの車窓から 2 〜 Salesforce PM の魅力 〜
プロマネの車窓から 3 〜 Salesforce 導入アプローチの観点 〜
プロマネの車窓から 4 〜 計画の勘所 〜
プロマネの車窓から 5 〜 計画と現実のギャップ 〜
プロマネの車窓から 6 〜 プロジェクトの終わり方 〜


・・・・・・・・・・・・

一緒に働きませんか?

現在弊社では、プロジェクトマネージャー、シニア・コンサルタント、コンサルタント、ソリューションアーキテクト、アカウントエグゼクティブの5つのポジションの採用を行っております。

アピリオの仕事にご興味のある方は、こちらをご覧ください。
アピリオのリソースハブにもさまざまな資料を掲載しています。

著者について

Koji Komatsu

前職時代から通算で15年以上、CRMの領域でプロジェクトマネージャーを中心にプリセールス、ビジネスアーキテクト等、幅広い役割を担うことを信条として日々精進しております。Appirioに参画後もSales Cloud、Service Cloud、Field Service Lightning、Einstein AnalyticsやHeroku、時にはAWSやZuoraまで、様々なクラウドプラットフォームを手掛けて来ました。未知のプラットフォームを導入される場合は是非お声がけを!

Linkedin をフォロー Koji Komatsu のコンテンツをもっと見る
戻る
プロマネの車窓から 4 〜 計画の勘所 〜
プロマネの車窓から 4 〜 計画の勘所 〜

PM を目指してみようという方、既に PM 経験がある方で Salesforce のプロジェクトにチャレンジしてみたいと思っている方に、少しでもお役に立てればということで、「プロマネの車窓からシリーズ」を寄稿してい...

次へ
プロマネの車窓から 2 〜Salesforce PMの魅力〜
プロマネの車窓から 2 〜Salesforce PMの魅力〜

PM を目指してみようという方、既に PM 経験がある方で Salesforce のプロジェクトにチャレンジしてみたいと思っている方に、少しでもお役に立てればということで、「プロマネの車窓からシリーズ」を寄稿してい...