まえがき
この記事は株式会社ビットキー 情シス Advent Calendar 2023 の24日目の投稿です。
こんにちは。株式会社ビットキーの中瀬です。
19日目に、以下の記事も執筆しました。
【 非エンジニアが、複数モデルの事業と組織と業務の立ち上げをSalesforceをテコに目指した話 】
今回は、Salesforce活用に関して、また別の観点からより具体的なお話を書いていきます。
Salesforceを導入する目的は具体的には導入企業ごとに異なるでしょうが、抽象化すれば殆どの場合、タイトルに書いたとおり 「ビジネスを前進させるため」 と言ってまとめても齟齬は無いのではと思います。
あらゆる設計はその目的のための手段となるわけですが、良い設計のためにはユーザーと管理者間での優れたコミュニケーション・協議が大切になってきます。
今回は、そんな社内のSalesforceユーザー（相談者）と、システム管理者（今回の文脈では、開発者を含む）とが 「優れたコミュニケーション」を行うためのポイント・それを組織的に実践するための標準化方法を考えてみます。
1. 現場から、新規管理項目の相談が発生する
「取引先に関する情報として、"●●●数" を管理できるように項目増やしたいんだよね」
現場のSalesforceユーザーと、システム管理者との間で日常的に発生する会話だと思います。
業務要件定義と、システム（上記の例で言えば、項目）設計を進めるために、相談の入り口時点でコミュニケーション（すなわち、"相談のもらい方"）を型化しているケースも多いと思いますが（当社においても同様で、後ほど紹介します）、
システム管理者として、上記の相談に対して一言目にどのように返しますか？
取引先に関する"●●●数"とは、典型的には「従業員数」などの情報です。
SFA、CRMシステムに営業先、顧客の情報を蓄え、それを業務に活用したいというニーズが根源的にあり、そこから相談が発生します。
とても基礎的な話にはなりますが、
「従業員数」を管理することで、営業先、顧客の「規模感」を判別している企業は世に非常に多く存在していることと思います。
表現をひっくり返すと、
「顧客の『規模感』を判別したいがために、『従業員数』を管理したい」という目的整理になります。
こうした"●●●数"といった管理項目1つ取ってみても、SFA、CRMシステムで管理したい情報はそれを利用する企業において非常に多様なはずで、そして一企業内においても時と共に増減し、変容するはずです。
例えば当社においては、そのビジネスの性質上、業界としてはデベロッパーや不動産会社がお取引先になることが非常に多くあります。
「従業員数」も然りですが、お取引先を捉え、識別するために管理したい"●●●数"はその他にも色々とあります。
代表的なものは、「不動産管理戸数」で、当該お取引先が不動産管理会社である場合、
「何件の物件を管理しているのか」を示すこの数値が分かることで、
「ビットキー製品/サービスをどれくらいの数でご導入いただき得るのか」を語る1つの手立てとなります。
cf. Salesforce Trailhead【カスタム項目の作成】
遠回りしましたが、以降の章で、
「
取引先に関する情報として、"●●●数" を管理できるように項目増やしたいんだよね」
システム管理者として、上記の相談に対して一言目にどのように返しますか？
に対する答えに繋がるポイントを、考えていきます。
２． 「なぜ」管理したいのか
＜ 相談者 ＞
「取引先に関する情報として、"●●●数" を管理できるように項目増やしたいんだよね」
＜ システム管理者 ＞
「分かりました！"●●●数"ということは、数値型の項目にして、0以下は入力できないような入力規則を設けておきますね！画面上の表示箇所は~~~~」
＜ 相談者 ＞
「ありがとうございます！これで管理する場所が決まりました！うちの管理者は対応が早くて嬉しいな〜！」
..........
はやいはやい。
悪い意味で、早すぎます。
上記のような検討で実現された管理項目の運用は、大体の場合、3ヶ月くらい経つと（下手したら1ヶ月でも)、以下のような感じになっていることでしょう。
＜ システム管理者 ＞
「あれ？久しぶりにデータ見てみたけど、"●●●数"全然入力されてないじゃん？あと、なんかテキトーな情報が入力されているものもある....？」
斯く言う私も、何度かこのような失敗を経験してきました。
特に、スタートアップにおいて一気に事業を立ち上げるに際してSalesforceを構築するとなれば、設けなければならない新規項目も多く、1つ1つの議論が蔑ろになりがちです。
何が問題なのでしょうか？
「取引先に関する情報として、"●●●数" を管理できるように項目増やしたい」
という要望は、
手段のことにしか言及していないということに無自覚なまま、項目設計に着手してしまったことが問題です。
何よりもはじめに捉える必要があるのは、
「管理したい」という業務上の目的がどこにあるのかということ。
業務上の目的を掴むために、具体的な問いとして以下のようなコミュニケーションを相談者に取ることを大切にします。
- 誰が、なぜ ●●●数を管理したいと考えはじめたのか
-
なぜいま、●●●数を管理したいと考えるようになったのか
└ 背景に、ビジネス上 / オペレーション上の変化が何かあるのか（それはいつから起こった変化なのか） - 管理できていない今を、できている状態に変えることで、業務 / 組織運営上で具体的にどのような変化を生み出したい（生み出せると期待している）のか
システム管理者が肝に銘じておかなければいけないポイントは、相談者自身が、この「目的」に対して無自覚であり、言語化できていないまま相談が開始されることは非常によくあることだ、ということです。
ゆえにシステム管理者は、ただ受け身で項目を用意してあげるというスタンスではなく、踏み込んで、正しい設計にするための議論を提起しなければなりません。
3. 業務理解に裏付けされた運用実行性の検討
項目を設ける目的が分かってきたとき、
（システム検証などの手続きは当然行うとして）それだけで項目設計を済ませ、リリースをして良いでしょうか？
「項目」を、"ビジネスデータを蓄える箱" として捉えたとき、
"どのような箱を設けるか（四角？丸型？大きい？小さい？）" が、項目設計を意味し、
"どのように箱にデータを入れていく運用にするか" を、運用設計として捉えられるでしょう。
この運用設計は、項目設計に跳ねて返ってくる論点です。
引き続き、以下を具体例に考えてみます。
「
取引先に関する情報として、"●●●数" を管理できるように項目増やしたいんだよね」
さて、この"●●●数"というビジネス情報は、
【A】誰が、どのように、取得できるものでしょうか？
- 帝国データバンクを代表としたデータ提供会社から取得するものですか？
- 業界新聞などのメディアが開示しているデータを利用するものですか？
- それとも、ビジネスメンバー（特にセールスメンバー）が、お客様からヒアリングしてくるものですか？
そのうえで、
自社において取得されてきた情報をどのようにして"正しい"情報として認めますか(認めることにしますか)？
ヒアリング能力が高くないメンバーが的確ではない聞き方でお客様から聞いてきた情報を、そのままデータ登録してしまって問題ないでしょうか？
次に、【B】その情報は、どのような形式(精度)で取得できそうですか？
"●●●数"といった数値系の情報だと議論が分かりやすいのですが、
例えば従業員数を想像してください。
「一の位まで正確に把握できる情報ですか？把握したい情報ですか？」
この問い対する絶対的な答えは、ありません。
お分かりの通り、"目的に依存するから" です。
目的から考えると、
一の位まで正確に把握したいのだが、実際はそのような形式(精度)での取得は難しいかもしれません。
あるいは、一の位まで正確に把握する必要など無いかもしれません。
（ビジネスや情報によっては小数点以下までの管理、負の値の管理が必要になるものも大いにありえます）
最後に、【C】その情報の"賞味期限"はいつですか？
取引先に関する"●●●数"は、どれくらいの頻度で変動する情報でしょうか？
どれくらいの頻度でその変動をフォローして情報を更新取得できるでしょうか？すべきでしょうか？
年に一度でいいですか？ダメでしょうか？
もし、"賞味期限"が切れたデータが混ざっている状態で、その項目を用いた分析と意思決定が行われた場合、どのような判断ミスに至るリスクがあるでしょうか？
上記のような問いに答えるために必要なのが、"業務理解"になります。
自社のセールスメンバーは、普段どのようなコミュニケーションをお客様と行っているのか。
自社の取引先には、どのような方々がいて、どのような情報交換が可能なのか。
こういった業務実態に対する理解が無いと、上記の【A】~【C】のような問いへ回答することは難しいと思います。
正確な回答が行えなかったとき、データ運用の実効性を伴わない設計となり、目的を継続的に満たし続ける項目を生み出すことはできません。
これもまた、実は相談者自身が解像度高く説明できるとは限りません。自分自身の業務に対して客観的に認知できていて、説明できるとは限らないからです。
そのため、"業務理解"を深めるために、業務の主体者である相談者にヒアリングするという手は有効な方法の一つですが、ヒアリングだけで正しい"業務理解"に至れるかどうかは別問題と思っておく必要があります。
「ヒアリング→回答」という情報の得方には、それ相応のバイアスが介在するからです。
当然、誰に聞くかも重要でありながら、システム管理者自身が当該業務に対しての解像度を上げるアクションを考えて実行する必要があるでしょう（例えば、お取引先との打合せの場に同席させてもらう、とかも有効かもしれません）。
再度並べると、
【A】誰が、どのように、取得できるものでしょうか？
【B】その情報は、どのような形式(精度)で取得できそうですか？
【C】その情報の"賞味期限"はいつですか？
これで確認すべき点として完璧かはさておき、このような運用検討は、より良い項目設計に繋がり、かつ項目リリース後の的確な運用設計・運用浸透に繋がるでしょう。
なお、割愛しましたが、
「項目に蓄える情報をどのように集計し、分析にするのか」といった「溜まったデータの活用イメージ」の検討も項目設計に影響するポイントで、この点の検討方法も非常に議論のしがいがあるものです。
4. 改めて、項目設計
改めて、具体的に冒頭の相談について理解を深め、項目設計をしてみます。
「
取引先に関する情報として、"●●●数" を管理できるように項目増やしたいんだよね」
目的
誰が、なぜ、●●●数を管理したいと考えはじめたのか
▶ セールスマネージャーが、営業先の取引先から見込むことができる売上額を計算し、営業活動の優先順位を設定するため（例えば、当社では「不動産管理戸数」）
運用実行性検討
【A】誰が、どのように、取得できるものでしょうか？
▶ 各セールスメンバーが、取引先への訪問時にヒアリングすることで把握できる。また、その情報をそのまま登録する情報とする。
【B】その情報は、どのような形式(精度)で取得できそうですか？
▶ 基本的には一の位の粒度で正確に把握されるべきで、かつ把握することができる。
【C】その情報の"賞味期限"はいつですか？
▶ 1年に1度はほとんどの取引先で大きく変動しうる。かつ、変動した場合は把握しないと「営業活動の優先順位設定」における判断ミスに繋がるリスクがある
項目設計・運用設計の例
- データ型｜数値型
一の位まで入力を求める。 - また、●●●数の"鮮度"をユーザーに分かるようにするため、「●●●数 最終更新日」項目を併置し、内容更新時のタイムスタンプを保持する。
- レポートで●●●数を活用する際は「●●●数 最終更新日」項目でフィルタすべきという注意点をセールスマネージャーと握る。
- セールス部門の運営として、「●●●数 最終更新日」が１年以上過去になっている取引先については、訪問時にヒアリングしなおすよう、セールスメンバーへ運用を浸透させる。
項目を設けるためにビジネスや業務に対して理解を深め、
例えばこのような内容まで検討し、システム管理者として提案をすることで、ビジネスを前進させることにこだわることができると良いでしょう。
5. 当社で設けているリクエスト受付フォーマット
現在当社では、相談者とシステム管理者間でのコミュニケーションの質について、水準を担保するために、相談のフォーマットを型化しています。
Slackの特定のチャンネルを活用して相談を出せるようにしてあり、
相談をしたい場合にはチャンネル内のワークフローを利用することをルールにすることで、
誰が相談者になって、誰がシステム管理者側での対応者になっても、できるだけ正確に必要な検討が行われることを目指しています。
相談者自身が手段論（(例)新規項目を設ける）に飛びつくことなく、
解決したい課題そのものや、実現目的をきちんと言語化できるよう、考えてもらうことを大切にしています。
6. まとめ
Salesforceユーザーからの項目設計に関する相談は、往々にして項目を設けること自体に目が向きがちです。
しかし大切なのはその項目を設けたいと考え始めた動機であり、業務上実現したいことが何なのか、という目的にあります。
システム管理者として、踏み込んでそのような本質の理解に努めた上、ユーザーと協働してデータ管理の運用実行性についての見解も深めたうえで、項目設計に昇華させられると良いのだろうと考えています。