Salesforce 導入後のブラックボックス化について

合同会社AtWILL

はじめに

合同会社AtWILL と申します。
弊社は様々な企業のシステム導入・運用をサポートしています。
今回は弊社がコンサルタントとして参画させていただいたプロジェクトで出会った「導入後の Salesforce 環境のブラックボックス化」現象についてお話しします。


プロジェクトの背景

　あるクライアントから『Salesforce を導入して数年が経ったため、業務の変更に伴う改修や新たな外接システムとの連携をしたい』というご要望をいただきました。
　そこで弊社は現状業務整理、Salesforce 環境の現新比較整理などをご支援させていただきました。

Salesforce 環境のブラックボックス化

ブラックボックスとは
「内部構造や仕組みがわからなくても使うことができる装置」
「中身が複雑に入り組んでおり、専門的な技術がないと読み解けないもの」
を意味する言葉です。

ブラックボックス化しているシステムに見られる特徴を以下に示します。

  • 現行業務は実現できているが、中身がどうなっているのかわからない

  • どこで何が動いているのか、どのような制約があるのか、を完全に理解するのに時間を要する

  • 上記の理由から、業務からの改修要望があってもなかなか対応できない

　実際、弊社が今回の運用改善プロジェクトに参画した際にも、現状を把握するためには実際の画面を見ながらご説明いただくか、構築済みの環境から作成意図を読み取る必要があり、To-Be像を検討するためのスタートラインに立つまでに多くの時間を要しました。
　さらにはブラックボックス化された Salesforce 環境に固有の問題として

  • Salesforce を導入したものの、事業会社側が Salesforce を使って実現できること・管理すべきことを十分に理解できていない。

  • 設計意図や仕様の背景が不明瞭であり、パートナー企業が作成した機能をフルに活用できていない。

といった状況も見られ、改善方針を決めるのに頭を悩ませました。

恐ろしい話で、実際に以下のような会話も発生しており、この状況は全国の企業で大小あれど、発生しているのではないでしょうか

弊社（AtWILL）：「この項目はどういう運用を想定して作成されたんですか？」
クライアント：「パートナー企業さんが導入時に作られたものなので、我々もわからないんですよね。」
弊社（AtWILL）：「あっ…承知しました。確認しておきますね。」


課題の原因と解決策

　こうした事態はひとつの原因で説明できるものではありません。導入時のコミュニケーション不足であったり、事業会社側での引継ぎが十全になされなかったりといった様々な理由が考えられます。
　しかし、その中でも原因の大きな割合を占めているのが

納品成果物が構築されたSalesforce環境のみである

だと考えています！！
　Salesforceは優れたサービスなので正直環境さえ渡せば後は構築期間中の会議やトレーニングで十分に理解できるという気持ちはわかります。
ただ、実際にシステムを利用する事業会社が運用に必要な情報を有していない状態が健全でないことは断言できます。


解決策：運用に最低限必要な情報をドキュメント化し納品物に追加するべき

　「業界全体のスタンダードとしてこうあるべき」という主張ではありませんが、弊社では事業会社の運用担当者様の負担を軽減するためにも、以下の構成をベースとして納品物を定義しています。

  • オブジェクト定義書
     各オブジェクトの用途と項目の説明が記載されている資料。
     DevTools から出力したオブジェクト定義書で十分。

  • 画面仕様書
    構築バージョンにおける画面の構築方法が記載されている資料。
    （現在最新バージョンのSummer '23であれば、Lightningアプリケーションビルダーでの動的フォーム・動的アクションの設定、レコードタイプごとのLightningページの割り当て等の概略。）
    システムベンダーが作る画面仕様書のような重厚なものは不要。

  • フロー一覧
    フロートリガーと処理の概要が一覧化されている資料。
    自動化されている設定を大まかに一目で把握できる。

  • フロー定義書
    フロートリガー、インプット、アウトプット、関連オブジェクト、関連項目が記載されている資料。
    改修する際に影響範囲が調査できるだけの内容。
    （そのため詳細設計レベルでのフローの説明は不要）

  • Apex一覧
    Apexクラス名、テストクラス、用途が一覧化されている資料。
    フロー一覧と同様、一目で大まかな内容を把握できる内容が必要。

  • Apex定義書
    呼び出し箇所、インプット、アウトプット、関連オブジェクト、関連項目が記載されいる資料。
    フロー定義書と同様、影響範囲を読み取れるだけの内容。

  • ユーザマニュアル
    業務の中で認識しておくべきオブジェクト、自動化処理、画面遷移がキャプチャを交えて操作説明されている資料。
    PowerPointで作る程度の簡単なもので良い。

　各項目をご覧いただければお分かりだと思いますが、最低限の用途が果たされれば良いため、成果物とは言っても大きく工数を割く必要はありません。
　幸いにも SalesforceにはTrailheadという心強いサポートが存在するわけですから、Salesforce の標準機能についての説明は簡略化しても問題ありません。つまり「事業会社向けに標準機能からのどのようにカスタマイズを施したのか」を一覧化して残しておきさえすれば運用を始めたときに、どこでどんな動きをしているかを調べる時間がぐんと減るようになります。

　上記のような資料を用意しておく労力だけで、ブラックボックス化を防止し、ユーザトレーニングや将来の運用改善に効果を発揮することが期待できます。


まとめ

今回は納品成果物に主眼を置きました。
次回は導入中および改修中のプロジェクトの進め方について記事を投稿していきます。

Salesforceの導入は、単なるシステムの導入以上の意味を持ちます。納品物の観点だけでなく、プロジェクトの進行方法やコミュニケーションのとり方も含め、事業会社の利益となる方法を常に考え、適切な提案を行う必要があります。

私たち合同会社AtWILLとしては、そのような課題解決のパートナーとして、企業の皆様のサポートを続けて参ります。

Salesforceに限らず、システムの導入や運用・改善で悩み事があれば、お気軽にご相談ください。

お問い合わせページ：https://www.awll.jp/contact/