はじめまして。
ＮＴＴデータ九州ビジネス共創部デジタルビジネス推進室の村尾です。
当部門では、Salesforceを活用したDX推進を支援しています。AI・データ活用、双方向マーケティングなど、最新トレンドを踏まえた取り組みを発信していきます。
今回は、私がNTTデータ九州でSalesforce担当として働いてきた中で感じたことや得た知見を共有します。
拙文ではございますが、ぜひご一読ください。
執筆日：2026年1月5日
1. はじめに
まずは簡単に、私の背景について触れておきます。
- バックグラウンド：情報系の大学を卒業、プログラミングの基礎は習得済み。
- 現状：「Salesforceって何？」という状態で当部門に配属され、現在入社二年目。
- 担当業務：上流から下流まで包括的に担当し、主として保守を担当。
恥ずかしながら、配属当初の私はSalesforceがどういうものかを全く知らず、一体何ができるの？？という状態からのスタートでした。
そんな中「Salesforce World Tour Tokyo」1に参加し、イベントの規模や、様々な導入事例の紹介、Salesforceの描く未来、といったDXの最前線を目の当たりにした初心者の私は素直に感動したことを覚えています。
特に、イベントの目玉でもあった「DataCloud」やAI(Einstein)のデモンストレーションは衝撃でした。
膨大なデータをリアルタイムに統合し、AIが次に取るべきアクションを先回りして示してくれる。
AIが自分専用の秘書になってサポートしてくれているような感覚でした。
エンジニアの卵だった私は「これさえあればなんでもできるのでは？」という感覚さえ覚え、Salesforceは単なるツールでは無く、導入するだけで企業を劇的に変える、ある種の 「魔法」のようなものに見えていました。
おそらく学生の方や、これからDXを進めていこうと考えていらっしゃる企業様の中にも同様の考えをお持ちの方がいらっしゃるかもしれません。
しかし、Salesforceについて理解を進め、実際にプロジェクトの現場に関わるようになり、特に「保守」という最もユーザーに近い場所で業務に携わるようになると、当初の印象は少しずつ変化していきました。
1.1 現場で知った「DXの現実」
当初、イベントで見たような、AIが瞬時に答えを出し、美しいグラフが並ぶダッシュボード。
そういった「魔法」を実現するためにまず必要だったのは、最新機能の操作ではなく、地道な「データのクレンジング」でした。
私が保守の業務に従事する中で、これを強く実感したのは、「顧客情報の集計が正しくできていない」というお問い合わせに対応したときでした。
その事象の原因は顧客情報を入力する際に一部自由入力となっている項目があり、その項目で表記揺れが頻発していることでした。
上記のような問題は、自由入力の項目をあらかじめ用意された選択肢から選ぶ形式に変更することで抑制できます。
ただ、それを実装するとしても、選択肢となるリストを作成するために一度は必ずこの問題に立ち向かう必要があり、いくつものExcel、PDF等とにらめっこを続け、データのクレンジングを行うこととなりました。
最新の機能やAIによるサポート、そういった華々しいDXの裏にはこのような地道な作業が積み重ねられているのだなと痛感することとなりました。
1.2 データの正確性という障壁
こうして、データのクレンジングに追われる中で、このデータ利活用の前段となるこの「データの正確性」こそ、多くの企業が直面している構造的なハードルなのだと気づきました。
「Salesforceを導入すれば、自動的にデータが整理され、魔法のように様々な分析ができる」
そのように期待して導入を考えるお客様は少なくないと思います。実際私も初めはそのように印象を持っていました。
しかし現実は、その真逆です。
- 各所に散らばった情報
営業担当のExcelファイル、基幹システムのCSV、個人のメモ帳、情報は様々な媒体に散らばっていて、
無理やり一つに集約しようとしても、形式やルールがバラバラ。- 「入力」という高い壁
現場のユーザーにとって、正確なデータを一貫して入力し続けるのは我々の想像以上に重労働です。
実際に、お客様の中には入力にまつわる作業に時間がかかり、残業時間が増えているといった声もありました。
すぐに入力できないことで情報鮮度が落ちたり、旧来のメモに留まり入力をしてくれなかったり、このような積み重ねがやがてシステム全体を蝕む「信頼できないデータ」の蓄積へとつながります。
このように、データの集約や入力にもなかなかに高いハードルがあり、こういった点にも何か打ち手を考える必要がありました。
そこで私はここまでのデータクレンジングの苦労を繰り返さないために、より強力な入力規則を設定して蓄積されるデータの形式を縛ってしまおうと考えました。
いわゆる「Fit to Standard」(標準機能への適合)という考え方です。
これにより、入力されるデータの質はある程度担保され、より信頼できるデータが蓄積されるだろうと。
しかし、そこにはさらに高い「現場の使い勝手」という壁が待ち構えていました。
2.SalesforceにおけるFit to Standard
[Fit to Standardとは]
開発によってシステムを業務プロセスに合わせていくFit&Gapに対して、システムの標準機能に合わせて業務プロセスを変えていくアプローチのことです。 元々はSAPなどのERP導入で使われていた言葉ですが、近年はSalesforce導入においても「ベストプラクティス（成功の定石）をそのまま取り入れる」手法として強く推奨されています。
「Fit to Standard」は、Salesforce導入における王道だと認識しています。理由は主に以下の3つです。
1. 常に最新のイノベーションを享受できる
- Salesforceは年3回（Spring, Summer, Winter）の自動アップデートを行いますが、過度なカスタマイズ（独自のコード開発など）を行うと、アップデート時に不具合が起きたり、新機能が使えなくなったりします。標準機能中心に構築すれば、常に最新機能をスムーズに使い続けることができます。
2. コストの削減
- 作り込みを行うと、導入時の開発費だけでなく、その後の修正やメンテナンス、担当者が交代した際の後継ぎコストが膨れ上がります。
標準機能（ノーコード/ローコード）で構成することで、保守費用を劇的に抑えられます。
3. ベストプラクティスの導入
- Salesforceの標準機能は、世界中の何十万社もの企業の要望を反映して作られています。独自のやり方にこだわるよりも、標準機能（＝世界標準の効率的なプロセス）に合わせる方が、結果的に業務効率が向上し、グローバル展開も容易になるとされています。
2.1「標準」という名の不自由
私は、いわば教科書に書いてあることに従うような気持ちで「標準機能」の枠組みの中で入力規則を設定し、データの正確性を担保しようとしました。
今回実装したのは、これまでテキストで自由に入力していた項目を表示された選択肢から選ぶ形式に変更するといったものです。
これにより、
1.自由入力に起因していた表記揺れの是正
2.集計、分析の正確性の担保
の2点を実現できました。
しかし、実際に標準機能の範囲で実装した画面をお客様に使っていただいた結果、返ってきたのは戸惑いの言葉でした。
それはなぜかというと、下記のイメージ画像のように選択肢が多くなりすぎてしまい、逆にユーザビリティが低下してしまうという結果になったためです。
※現在の知識量では、参照関係とルックアップ検索条件を使用してテキスト入力による検索と選択肢から選ぶことによる表記揺れの是正を両立できますが、当時は知識不足でこの方法をとることができませんでした…
このように、Fit to Standardを何とか推し進めたいベンダー側の思想とユーザー側の本音や満足度の間に乖離があったことが原因の一つでした。
こういった場合、開発者が取れる選択肢は2つです
1. コストをかけてシステムを改造する。
2. 人間の動きを変えてもらう。
そして多くの場合、現実的な妥協案として2が選ばれ、ある意味魔法の言葉である「運用でカバー」という言葉を使うことになります。
2.2 「運用でカバー」のツケは誰が払うのか
Fit to Standardを優先しようとすると、どうしても「システムでは実現できないこと」が出てきます。
そんな時、会議室では往々にして「運用でカバーしましょう」と発言することになります。
- 会議室での会話
「カスタマイズするとコストがかさむので、この入力ルールはマニュアルを徹底してもらうことにしましょう」(運用でカバー)- 現場の現実
現場のユーザーにマニュアルが周知されたとしても、その隅々までを理解し、システムが強制してくれないルールを全員が守り続けるのは至難の業
(かといって強制しすぎるとユーザビリティが低下する)
このようなジレンマを抱えながら開発を進めると、結局「運用でカバー」が漏れた結果1章にあったような表記揺れ、データの正確性の低下、のような形で保守担当である私のもとにブーメランのように戻ってくるわけです。
ではなぜこのような現場に無理を強いる運用が発生してしまうのかを考えたときに、ある根本的な原因にぶち当たりました。
それは我々エンジニアの言う「できます」という言葉の認識について我々とお客様の間で大きくズレていたということです。
2.3 エンジニアとお客様の認識の溝
上流から下流までを一貫して経験することで気づけたのは、エンジニアとお客様の間にある言葉の認識のズレです。
特に「できます」や「可能です」といった言葉には以下のような深い溝があったなと感じています。
- エンジニア：標準機能の範囲内で、システム的に実装可能です。
- お客様：今の業務フローを壊さず、もっと直感的に楽に仕事が回せます。
この認識の溝を埋めないままにFit to Standardを強行してしまうと、完成した機能をテストする際に、「思ってたのと違う」といったようなことになるわけですね。
情報系出身の私は当初「仕様通りに作ること」が正解だと考えていました。
しかし、ことDXの現場における正解は「エンジニアとしての正論」と「現場の生の声」の間に立ち、いかに互いが納得できる落としどころを見つけ出すかという地道な翻訳作業の中にあるのだと私は考えました。
3. システムの内側と外側、エンジニアとお客様をつなぐこれからの決意
これまでに直面したような「認識の溝」や「運用のツケ」といった問題を一発で解決してくれるような魔法のボタンは残念ながらPCの中にも、Salesforceの設定画面にも、ありませんでした。
そこで私が現時点で行きついたのはシステムの内と外、両方の視点をもって「つなぐ」アプローチでした。
3.1 現場に寄り添う「翻訳者」としてDXの土壌を耕す
これまで私は、Salesforceの仕様上こうなります、や、標準の範囲だとこうです、のようにシステムの仕様を一方的に説明することが多かったと感じています。
そうではなく、まずは現場がどうExcelや紙を使い、どこで手が止まるのかといった情報を得ることから始めました。
そういった地道な、より現場に寄り添った業務理解を進めることが第一歩だと考えたからです。
また、お客様に好意的にとらえていただけるような表現を追求しました。
例えば、
「標準だからこうしてください」
という半ば強制するような表現ではなく、
「この機能によって、将来的にこんなデータ分析ができるようになり、組織全体としてこのようなメリットがあります。そのためにこの入力に協力していただけないでしょうか？」
のようなお客様の将来的なメリットまで考えた表現に翻訳してお伝えする。
エンジニアとお客様には双方必ず仕方がない事情があると思います。
それらをなるべく好意的に感じていただく、そういった地道な翻訳作業がDX推進の第一歩だと私は結論付けました。
3.2 お客様のこだわりを「武器」に変える開発
一方で、すべての業務をFit to Standardの理念に基づいて標準機能にまとめることが正解であるとも思わなくなりました。
Fit to Standardを追求する中で、どうしても譲れないお客様独自の強みや強みの源泉が見えてくる瞬間があるからです。
こういったお客様が長年培ってきた「独自のこだわり」や「競争力の源泉」となる部分には積極的に個別開発といった力を投入すべきです。
反対に、誰がやっても同じである定型作業は徹底して標準機能で効率化することでFit to Standardのメリットもしっかり享受する。
そうした個別開発を行うか、標準機能での実装かを見極める力を磨くことで本当の意味でお客様の「武器」になるシステムを作ることができると考えます。
3.3 二年目の私が出した「つなぐ」という答え
この一年と少し、上流工程で理想を描き、下流工程で現場の切実な現実を見てきたことで、私が出した結論は、DX推進の核は「理屈」(システム)と「感情」(現場)をいかにしてつなぐかにある。ということです。
システムだけが正論を突き通しても、現場の心は離れていきます。
逆に、現場の要望にすべて応えて個別開発を繰り返せばコストに見合わない維持不能なシステムになってしまいます。
エンジニアの役割はその真ん中に立ち、「システムという用意された型」をお客様にとっての「使いやすい武器」へ翻訳し、つなぎ合わせることにあります。
3年目に向けてさらに技術力を磨き、現場との対話を重ね、誰よりも確かな現場との架け橋となれるよう頑張りたいと思います。
4. おわりに
ここまで、私の経験をもとに感じたこと、得た知見を述べさせていただきました。
もちろんベテランの方からすると当たり前のことも多くあったかもしれませんが、私の経験がより多くの若手、Salesforceエンジニアを志す人の一助となれれば良いなと思いここまで書かせていただきました。
私も、エンジニアとしてさらに成長できるように取り組んでまいります。
ここまで読んでくださった方、ありがとうございました。
※本記事は2025年12月時点の情報に基づいて作成されており、記載されているサービスの仕様や情報は変更される可能性があります。実際の利用にあたっては、最新の公式ドキュメントをご確認ください。
-
2025年より「Agentforce World Tour Tokyo」に名称が変更。 ↩