なぜ多くのSalesforce導入は失敗するのか

偽アジャイルというプロジェクト進行の罠

　アジャイル開発の本質は「柔軟性」や「探索的プロセス」にありますが、これらが誤って解釈され、プロジェクト管理の怠慢を正当化する口実として使われることがあります。具体的には、要件の曖昧さを放置したり、適切な計画や合意なしにプロジェクトを進めることを「アジャイルだから」と誤魔化すケースがこれに該当します。

　Salesforceのプロジェクトにおいても、このような偽アジャイルな進行により、問題が起きることも珍しくありません。たとえば、「プロジェクト終盤であるUAT（ユーザー受け入れテスト）フェーズになっても新しい要望が止まらず、新たに要件定義を始めているような状態」というのはプロジェクトマネージャであれば、多くの現場で見たことのある光景でしょう。

　Salesforceは、顧客データを軸としたSFAやMA（マーケティング活動支援）など各種業務アプリケーションのプラットフォームという側面もありますが、柔軟なカスタマイズ性に加え、ローコード開発やアドオンでの拡張が可能なことから「スピーディで・変更容易なアプリケーションプラットフォーム（aPaaS）」という強みを併せ持っています。この強み故に、「Salesforceはアジャイルで導入できるので柔軟に要望を具体化できますし、非IT部門のユーザーさんでも安心」と思われがちです。

　決して間違いではありませんが、正確ではないと考えています。正確に言えば、Salesforceの製品特性を活かすことで得られるメリットは、「アジャイル」ではなく「プロトタイピング」です。古くからパッケージを活用したプロジェクトの要件定義フェーズで用いられてきたCRP（Conference Room Pilot）というプラクティスを取り入れて進行できます。

　SFAやMAなどのアプリケーションが提供されるSalesforceプラットフォームには、ローコード開発基盤が備わっているため、実際のアプリの実行環境上で、すぐに画面項目の追加やレイアウト変更や集計・分析機能の実装などが行えます。要求を仕様に落とす際の実現イメージの確認も行える上、プラットフォーム標準機能の範囲であれば基本的に単体レベルのバグは起きませんので、もしイメージがすり合えば実装やテスト工数も省略できてしまいます。要件洗い出し、実現性検証やユーザー参画を通じて、リスク・実用性を担保できるのは大きなメリットです。

　一方で、多くのSalesforce導入プロジェクトはいわゆるV字モデルを一定期間で完了させるウォーターフォール型です。前述した検討プロセスの経緯もあり、年額のライセンスコストと初期導入費用や運用費を固定して予算を確保したいユーザー企業が多く、導入支援にあたるパートナー側も一定の開発規模や期間の見積りの中で人員をアサインし、プロジェクトを進行する必要があるためです。

　そんな中で、プロトタイピングが可能な製品特性が悪い方向に働き、ウォーターフォール型の手順や合意プロセスを曖昧にしたまま進行すると、本来得られたCRPによる要件定義のメリットを喪失してしまう形で炎上プロジェクト化していきます。

　Salesforceに限らず、製品やツールを選定していると、イケていない部分をネガティブに評価しがちですが、むしろ便利でポジティブに映る点が人に"甘え"をもたらし新しいリスクを生む、という点はコンサルへの丸投げ問題然りで、認識しておくべき点でしょう。