オブジェクト構成図のススメ

こー。

こんばんは、場末のSFコンサルタント、こー。です。
今回は「オブジェクト構成図を描こう」という話をしたいと思います。

私個人の心がけていることを言語化していますので、もし「私はこうしている」「もっとこうした方がいい」などがあれば教えてください。


本稿のまとめ

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

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

  1. オブジェクト構成図は、データベースの設計図

  2. 正しい状態を維持すると、いろいろなコストを減らしてくれる

  3. オブジェクトの親子関係がわかるようにすっきり描く

    1. 具体的にどう描くといいかはこんなかんじ。

オブジェクト構成図を知ろう

まず、オブジェクト構成図について知っていきましょう。

オブジェクト構成図とは？

まずは実物の例を見てみましょう。

【Sales Cloudの例】
こちら、私がSales Cloudを説明する際に話す範囲を図示したものです。
オブジェクトの親子関係がある程度まとまっていると思います。


Sales Cloudをざっくり説明する際の図

【Service Cloudの例】
もう一個行きましょう。
これは、私がService Cloudコンサルタントの学習をする際に整理したものです（21年の半ば頃の時点のものです。現在の仕様と一致しているかは定かでありません）

エンタイトルメント関連のオブジェクト構成

では、本題です。
ここでいうオブジェクト構成図とは、以下のようなものです。

  • オブジェクトの役割と関係を整理したもの

  • データベース設計におけるER図のようなもの

簡単にいうと「オブジェクトを並べて」・「参照関係や主従関係を示す」ドキュメントと思ってもらえれば幸いです。

※　オブジェクト構成図、という言葉自体は、公式で定義されている言葉ではありません。私の周辺では割と使っていた言葉なので、よくある方言なのだろうと思っています。
※　と思っていたのですが、サクセスナビでも同じ言葉を使っていました。リンク先の記事、ほぼ本稿と役割かぶっていますが、別にパクってはいないです（笑）
※　ER、という耳慣れない言葉は、adminの方は気にしなくていいです。データベース設計の世界で同じような役目のドキュメントを作るのだ、と思ってもらえればOKです。

オブジェクト構成図があるとどんな得があるのか

ぱっと見難しそうですよね？
何の得があるんだ？と思うかもしれません。
でも、実はこれはとてもお得なドキュメントなんです。

ということで、オブジェクト構成図を作るとどんな得があるのか、を紹介していきましょう。

【外注費が下がる】
端的に、社外に払うお金が減ります。
特に強力に働くのが、”社内adminだけで頑張っていたけれど一部機能を開発企業に依頼する”場合です。

そうしたケースでは大体の場合において「環境調査費用」が見積に乗ってきます。
正しさが保証されているオブジェクト構成図があると、この部分がかなり大きくショートカットされます。

※　私がこういうことをやる際、ざっと整理するのに1オブジェクト1時間くらいの時間で作図整理しています。あとは単価をかけてざっくりのコスト感を試算してみてください。

【社内向けの説明が簡単になる】
新入社員が社内の業務を把握するうえで、オンボーディングコストが下がります。

例えばレポート作成というシーンで考えてみましょう。
SFの作成は「レポート機能の操作の仕方」と「そのSF組織のどこにどんなデータがあるか」を把握している必要があると思います。
オブジェクト構成図があると、後者の理解が促進されます。

【SF組織の設計の無駄を省ける（可能性がある）】

どんなデータをどんな構造で格納しているのがはっきりしていると、
新規オブジェクトを作る際に、「すでにあるオブジェクトを使いまわす方がいいのでは？」ということを考えることができます。
結果的に不要なオブジェクトが乱立しないようにできます

スキーマビルダーじゃダメ？

ダメです。
では、なぜダメかを考えていきましょう。

スキーマビルダーでは、今のオブジェクトの実装が図示されます。
自動図示されます。
しかし、そこでは以下の情報がありません

  • 業務上の先行、後続の関係性

  • 重要な関係性とそうでない関係性について

論より証拠、ということで、先ほどのサンプルと同じものをスキーマビルダーで作っていましょう。
※　Sales Cloudの分だけでご容赦ください。

Sales Cloudをざっくり説明する際の図②

ね？わかりにくいでしょ？

オブジェクト構成図の描き方

では、私がオブジェクト構成図を描く際に注意している点を説明したいと思います。
私のノウハウを下敷きに、取捨選択してやってみてください。

描くこと描かないこと

①　描くこと

  • 業務の流れに沿って主要なオブジェクトはすべて書きましょう

  • オブジェクト間のリレーションは、主要なものを描きましょう

  • もし可能なら、オブジェクト間のデータの流れも書けるといいと思います。

②　描かないこと

  • 実業務上あまり出てこない、システム機能で使うオブジェクトなどは省略してもよいです。

    • 先ほどの絵で言うと価格表や価格表エントリは、説明がややこしくなるので省きました。
      価格機能の説明を行いたいときは書いてください。

  • 補足的に付与している参照関係などは省略してもよいです。

    • 先ほどの絵で言うと、例えば、主キャンペーンソースあたりのリレーションは省きました。

省いたものの例。ほかにもいろいろ割り切っています。

まずは概要レベルで、何のためのオブジェクトがどう関連してるか、をバクっとつかめる状態であることが大切です。

使う道具（ツール）について

何でもよいですが、おすすめはdrow.ioです。
ツールを選ぶ際は、以下の点を条件に選んでください。

  • 図形描画ができる
    図形と図形の間のコネクタ設定がある、色味の設定ができる等がポイントです。これは図形機能のあるツールなら大体なんでも大丈夫です。

  • 共有と編集が容易
    社内で利用者が多い、学習コストが低いというのも重要です。
    この点は、Microsoft Office製品やGoogleWorkSpace製品がアドバンテージがあると思います。

  • 印刷した時の印刷設定がしやすい
    地味ですがポイントです。特に大きなオブジェクト構成図は、A3で印刷してペン片手に眺める方が有効に使える場合があります。

参考までに、ですが・・・

  • 前述のサクセスナビのテンプレートはパワーポイントです。これも悪くないのですが、図形の位置決めのが難しいところがネックです。

  • Excelでセルの縦横を同じ幅にした、いわゆるExcel方眼紙も割り切れば悪くありません。例えば、前述のService Cloudの例はExcel方眼紙で作ってあります。

  • 逆におすすめしにくいのはGoogleWorkSpace系です。
    スプレッドシートも、スライドも細かいコネクタ設定を表現するだけの表現力が足りない印象です。
    ※　完全に余談ですが、パワーポイントで作図したオブジェクト構成図をGoogleスライドで開くとコネクタの配置が壊れます。お気をつけて。

  • Miroなどのオンラインホワイトボード系は慣れていれば悪くない選択肢です。ただ、総じて印刷系機能が弱いので、この点は割り切りが必要です。

使う図形について

使う図形は最低限以下の二つです。

  1. 円柱

  2. コネクタ

オブジェクトを表現するための円柱。元々はフローチャート作図時のデータベース記号


関係性を示すコネクタ。鳥足式です。

特に重要なのがコネクタです。
オブジェクトの親子の向きを決めて、どちらが子供なのかを一定のルールで対応しましょう

前述の通り、データベース設計の世界ではER図がオブジェクト構成図に相当します。そこでは、鳥の足記法という記載ルールがあります。
コネクタの子供側（１対多の多の方）に、鳥の足のような枝をつける記法で、システム開発に携わる人にとって一般的な記述になるので、おすすめです。

ご参考：カラスの足のデータベース表記を使用してダイアグラムを作成する - Microsoft サポート

図形の配置のコツ

図形を配置するうえでのコツは以下の通りです。
両立しない場合はこだわりすぎないようにしてください。

  • 業務の順番上、風上の業務を左上に、風下の業務を右下に、で配置する。

  • データの内容特性上・・・

    • お客さんに関連する情報を左に、社内の情報を右に配置する

    • 業務間でデータの流用がある場合は、同格のデータを同じ縦軸そろえる

    • ある業務で複数のオブジェクトを利用する場合は、横軸をそろえる

  • コネクタはなるべくコネクタを跨がないようにする

  • オブジェクト図形のサイズは統一する。

  • オブジェクト図形の間の隙間は、統一の幅を維持する。

これらの実現イメージを抜粋した図で見てみましょう。

先ほどの図を商談関連だけ抜粋

  • オブジェクト間は、大体10マス分の間をあけてあります。

  • 商談系や、見積系は、役割で塊となるようにしてあります。

  • 商談１件に対して見積が複数件発生しますので、

    • 商談系を上に配置しています。

    • 見積オブジェクトは商談オブジェクトより一段階右寄せにしています。

  • 商談商品と見積品目は、同期する機能があることを踏まえて、同じ横位置に指定あります。

これらを意識したうえで、後は試行錯誤です。
100点満点はありえないので、ある程度越えたら割り切りが大事です。

ただ、この横縦の配置ルールに沿って並べると、自分の組織のオブジェクトがどんな方針でデータ管理していくのか考えることになるので、結果的に理解が進みます。

具体例で比較してみましょう。
例えば、商談受注後に契約オブジェクトデータを作るとして
商談オブジェクトと契約オブジェクトは同じ横軸で配置するのか、縦軸にずらして配置するか、でだいぶ印象が変わります。

【例：商談と契約が同格っぽい描き方】

商談と契約が同格に見える描き方

例えば、SaaSビジネスなどで、

  • 取引先に対して、1個の契約がぶら下がる。

  • 初期商談で、契約を締結する

  • 以降、契約に対してアップセル商談を積み上げていく

ようなケースだとこの配置の方が素直であると思います。
続いて、別パターンを見てみましょう。

【例：商談1件に対して、契約が1件発生するように見える描き方】

「商談が契約になる」ように見える描き方

このパターンは、商談1件について、契約が都度生えてくるようなビジネスの表現になります。

例えば、受託開発案件を新規商談として獲得し、その結果をプロジェクトオブジェクトに格納するというようなケースは、このパターンの方がわかりやすいと思います。

その他関連するノウハウ

オブジェクト構成図自体については以上です。
合わせてやっておいた方がよいこと、を少しふれておきます。

【オブジェクトは、一覧化しておきましょう】

一覧表でオブジェクトの役割を管理しておくとよいです。
以下のようなことをリストにしておくのがおすすめです。

  • だれがレコード登録するのか

  • どんな時に新規レコードができるのか

  • 1件のレコードは何を意味しているのか。
    例えば、取引先オブジェクトは「法人で1件」か「営業所単位で一件か」

  • オブジェクトを作ることを決めた時の経緯
    ※　最低でも、誰に聞けばわかるかは記録しておいた方が得です

結び

描いてください、といわれても、中々具体的に気を付けるべきポイントが語られない範囲だと思います。

これを機にあなたの会社のSF組織のオブジェクト構成が可視化されると、こー。はうれしいです。

もしほかに「こういう時はどうするといい？」ですとか「俺はこうしてるよ」、「サンプルの図面ください」などがあればご連絡ください。

それでは、また。

いいなと思ったら応援しよう！