Salesforceの環境構築で現場からの要望を要件定義していく心得

はじめに

この記事は、現場の声を元にシステム改修をするのか、業務フロー自体を改善してもらうのかを判断し、改修する場合は要件に落とし込んでいく序盤の手順をまとめています。

現場の声は「宝」であるのは間違いないですが、原石ばかりではなく、鉱山ぐらいの粒度で相談を受けることがあるので、"ストレスなく"要件を定義しシステム設計に向かう工程に役立てていただけたら幸いです。

背景

私は非エンジニアであり、元々フィールド営業です。
新サービスの立ち上げからジョインし、営業組織を少数精鋭で立ち上げるために、MAを導入し、顧客管理のためにSalesforceを使い始めました。
Salesforceは既存サービスの営業管理のために導入していたものの、社内で使いたがる人も管理したがる人もいなかったため、「だったら自分がやるか」でSalesforceに手を染めました。

はじめのうちはフィールドセールスとして担当を持ちつつ、既存サービスで使われていた？かどうかも怪しい環境を修正しながら、新サービス用の環境構築を行っていく二足の草鞋状態でしたが、
この経験がやりたいことを要件定義していくのに役立ちました。
自分に無茶ぶりをしながら、形にしていく
という、成功も失敗も自ら回収してきた体験を体系化した記事であることを前置きしておきます。

手段ではなく、目的を聞き取る

現場からの要望は往々にして、具体的な手段の追加/変更であることが多いのですが「何を叶えたいのか」「それはどれぐらいの価値が有るのか」を検討した上で、最適な手段を選択することが大事。

「〇〇を見たいから、○○を入れれるようにして欲しい」
の場合は、「なぜ○○を見たいのか」「〇〇を見て、どうなったらどんなアクションを起こすのか」を聞き出さなければ「用意すべき項目の形」と「項目を使ったアウトプットの形」が想像できないということです。

ロジックツリーで解像度を上げていく

①目的とアウトプットの明確化

• どの指標の改善が狙いか？改善のためにどんなアクションを起こすのか（=運用方法）を明確にする

  • 判断を仰ぐためのダッシュボードにするのか、次のアクションを促すToDoを立てるのかを判断するために必要です

②システム改善 or 業務改善

• システム改善をすべきなのか、業務自体を改善すべきなのかを判断する

  • 判断材料は「業務の持続性」と「ボリューム（使用頻度）」です。

③新規追加 or 改修

• 新たに機能追加する必要があるのか、既存の改修をするかの判断

• 今ある機能で導き出せないか。同じ用途の機能は既に無いかを熟考

  • これはスキーマを見ただけじゃ分からないので、頭に入れておく必要があります。

  • 用途が被ると情報がバラけて質が落ちるので要注意。

    • ここの工程をサボると後で大惨事です。。。

用途別の対応方法について

• 既存のフローと異なる業務フローを導入したい

  • ⇒レコードタイプ追加

    • 「パスの追加/変更」「選択リストの値を制御」ができる

• 見せ方だけ変えたい

  • ⇒レイアウト変更

    • Lightningページ編集でコンポーネント単位で条件毎に出し分けも

• 情報粒度を揃えたいだけ

  • ⇒データ型変更

    • ロジックで算出できるなら"数式""積み上げ集計"使用

• 詳細に情報粒度を揃えたい

  • ⇒入力規則の追加

    • 「10刻みで入力させたいけど、数値で集計したい」時に重宝

• 粒度も揃えつつ、入力を促したい

  • ⇒画面フロー

    • 万能だけど管理側の運用コストが増大

まとめ

上記をマインドマップにまとめると以下の通り

特に既存の仕様で賄えるかどうかを思考することをサボると、後々とんでもなく膨大な工数を掛けてリファクタリング祭りをする必要あるので要注意です。

「見ること」「作ること」を目的にしがちなSFA/CRMなので、
事業KPIに対してどれぐらいの影響があるのか。
それは暫定的なものなのか、恒久的なものなのか。
を開発者側も一緒になって深く考え、コストに見合った開発をしていった先で、生き生きとした営業組織になっていったらいいな。