オブジェクトが分かれるとき:業務分割の観点から

こんばんは、場末のSFコンサルタント、こー。です。
今回は、「オブジェクトを新しく作る際の視点」を一つお目にかけます。
何かの参考になれば幸いです。


まとめ:オブジェクトは業務の切れ目で分けろ

本稿のまとめです。これでわかった人は本稿が不要な人なので読み飛ばしていただいて構いません。ご一緒に頑張りましょう。

これから細かく説明していきますが、本稿で言いたいことは以下の通りです。

  1. オブジェクトは業務の切れ目で分けろ

    1. なぜならば:Salesforceは、データベースを作ると画面が付いてくる仕掛けである。

    2. 言い換えると:データベース一個に対して、1画面を提供する仕組みになっている

    3. だから:1個の画面で複数のデータベースを扱うのが苦手

    4. まとめ:業務のわかれめで、オブジェクトをわけると、業務がすっきりしやすい。

では、内容に入っていきましょう

Salesforceは、データベースを作ると画面が付いてくる仕掛けである

Salesforceでオブジェクトを作ると、自動的に一覧画面と詳細画面が付いてきます。
この点は、データベース屋さんからすると結構すごいことです。なにしろ「データベース一つ作ったら画面を個別に作らなきゃいけないのだるいな」と思っていたところが、丸ごとバイパスされているのですから。

ちなみに、Salesforceのある種の競合であるKintoneの場合は、
「画面に項目を配置するとデータベース化される」
という順番です。
Salesforceと順番が逆ですね。

この違い新しく何かを作るときの分け方・考え方に、影響が出てくるだろうな、と感じています(が、ここでKintoneを深堀するのは本稿の眼目でないので割愛します。)

データベース一個に対して、1画面を提供する仕組みになっている

前述の仕掛けであるため、データベース1に対して1画面の構造になっていきます。
この点は、製品の特性としてまず受けて止めていきたいところです。

1個の画面で複数のデータベースを扱うのが苦手

裏を返すと、「1個の画面で複数のデータべ―スを扱うのが難しい」という特徴があります。
※ 厳密には、「プログラムを書けばできます」です。普通のシステム開発をSalesforce上でやればできますが、逆に言うと、Salesforceのノーコードのスピード感はちょっと損なわれてしまいます。

例をあげましょう。
例えば、商談管理システムを普通のシステム開発で作ると、以下のような画面を作りたくなるんじゃないか?と思います。

  1. 案件概要が記録できるようにしたいよね

  2. 当然、キーマンの登録と編集も一気にやりたいよ

  3. 見積書も明細まで案件画面上で編集保存したいね

  4. というのを、一気に編集して保存できるようになってるといいな。

はい、Opportunityでもできますよ、という感じはします。
でも、”一気に編集して保存”の部分、Salesforceだと意外にむつかしいですよね。
例えば、商談画面を編集モードにして、編集モード上で商談履歴も書くし、顧客担当者の登録も書いて、見積書を複数世代編集・表示・編集して、【保存】ボタンを押したら一気に登録される、みたいな動きは、Salesforceでは難しいこと、共感してもらえると思います。

業務のわかれめでオブジェクトをわけると、すっきりしやすい。

こうした特性を踏まえて、是非考えていただきたいのが、
「業務の切れ目は何か」です。ここで言う業務の切れ目、とは、「業務のオーナーの切れ目」と読み替えていただいて構いません。

例えば、商談オブジェクトを発注内諾までの管理とするのか、
契約書の回収までとするのか、
はたまた請求までの管理とするのか、というシーンを考えてみましょう。

「営業の責任範囲は契約書事務手続きの手前まで。内諾でひっくり返された場合は営業の責任を問わない」というような役割分担しそうなら、そこで業務が切れて、業務の主体者が営業担当から営業事務にバトンタッチすることでしょう。
そうであるならば、「契約書の回収プロセスはタスク管理系のシステムを使って管理するのだ」、も十分ありうる選択肢だと思います。

これは、SF語で言うなら「所有者が変わったらオブジェクトを割る」と言い換えてもよいかと思います。
そう聞くと当たりまえのことに聞こえてきませんか?

結びに

当然のことですが、そういう業務切れ目でオブジェクトを分けるのが絶対ではありません。

例えば、商談商品のようにあるオブジェクトの明細データは、別オブジェクトに分けた方がシンプルで拡張性が高いです。
ただ、それに対して、「一度に全データ編集できないのは嫌だ」という理由で、商談内部に「A商品の価格・数量」というようなカスタム項目を作る場合もあります。

一つの判断軸として、「業務のきれめ」というのを頭の道具箱に忍ばせていただけたら、と思います。

次回はこれに類する話で、オブジェクトの役割と登録するデータの基本方針を決めておこう、という話をしたいと思います。

それでは、また。

この記事が気に入ったらサポートをしてみませんか?