名詞に耳を傾ける
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール1／6：Data Architectコース第2章「意味のあるデータモデリング」。各モジュールは単独でも読めます。 前へ：章の概要 · 次へ：関係を描く
このモジュールが答える問い： ビジネスの会話の中から、データモデルの出発点をどう見つけるか？
お客様との最初の打ち合わせで私が必ずすることの一つは、名詞に耳を傾けることです。
最初の設計セッションの話ではありません。まだビジネスや、お客様が何を実現しようとしているのかを理解しようとしている、最初の会話のことです。
お客様が話し、私は聞いています。
そして、次のような言葉に耳を澄ませています。
小売パートナー。受取人。物流センター。積荷目録。配送。ルート。クルー。トラック。
こうした名詞はすぐに私の注意を引きます。その会話のどこかに、データモデルの出発点があるからです。
問題を完全に理解できたと思えるまで待つことはしません。聞いている最中からデータが見え始めます。名詞を聞き、それらがどう関係するかをスケッチし始め、そのスケッチが次の会話の枠組みを作ってくれます。お客様との最初のミーティングが終わる頃には、自分用のデータモデルがすでに描けていることもあります。
私の場合、すべては名詞から始まります。
Salesforceのことは少し忘れましょう
Section titled “Salesforceのことは少し忘れましょう ”ここで、ある本能に抵抗してほしいのです。Salesforceの管理者を長く経験している人ほど、この本能は強いものです。
お客様が顧客と言うと、あなたはこう考えます。
取引先。
人と言えば、こう考えます。
取引先責任者。
物流センターと言えば、もうカスタムオブジェクトが必要かどうかを考え始めています。
まだそれはしないでください。
この段階では、顧客が最終的に取引先になるのか、個人取引先になるのか、カスタムオブジェクトになるのか、それ以外になるのかは気にしません。まずビジネスを理解したいのです。
それが、ビジネスをモデリングすることとSalesforceを設定することの違いです。Salesforceのオブジェクトから始めると、その時点で考え方を一つの実装に縛ってしまいます。結局は予想どおりの場所にたどり着くかもしれませんが、そこにたどり着く理由は、取引先と取引先責任者が最初に知っていた2つのオブジェクトだったからではなく、ビジネスがそこへ導いたからであってほしいのです。
ですから、しばらくの間Salesforceのことは忘れてください。実際にビジネスを動かしている人たちが、自分たちの世界をどう表現するかに耳を傾けましょう。
おすわり、まて、モデル
Section titled “おすわり、まて、モデル ”ビジネスに耳を傾ける前に、誰もがすでに知っているものに耳を傾けてみましょう。ライブで教えるとき、私は犬から始めます。
ここに1匹の犬がいます。マーカスがベラを飼っています。ベラを繁殖したのはMaple Ridge Kennelsです。ラブラドールで、おすわり、まて、お手ができます。
名詞に耳を傾けてください。マーカス、ベラ、Maple Ridge Kennels、ラブラドール、おすわり。ただし、これらは名前、つまり特定のものです。私が知りたいのは、それぞれの名前がどんな種類のものに属するかです。ベラは犬。マーカスは飼い主。Maple Ridge Kennelsはブリーダー。ラブラドールは犬種。おすわりは芸。5つの名詞、5つの候補の箱です。
次に、どの名詞にも投げかける問いです。それは仕事をしている人なのか、それともデータなのか？ マーカスは人です。でも、ベラを飼うことは仕事ではありません。ベラについての事実であり、遅かれ早かれ誰かが「この犬の飼い主は誰？」と尋ねます。だから飼い主はモデルに入ります。ベラにお手を教えたトレーナーは仕事をしている人なので、箱は必要ないかもしれません。ビジネスが、誰がどの芸を教えたのかを尋ね始めない限りは。
そして、候補という言葉に注目してください。犬種は本当にそれ自体の箱なのでしょうか、それとも犬に書かれた単なる言葉なのでしょうか？ その問いは覚えておいてください。モジュール4で正規化するときに答えを出します。
これが、小さなものに当てはめた手法のすべてです。では、本物のビジネスに耳を傾けてみましょう。
名詞から候補エンティティが見えてくる
Section titled “名詞から候補エンティティが見えてくる ”Steve Truckingの話を聞いてみましょう。このコースを通じて使う家族経営の会社です。大型量販店の物流センターから大型の商品（冷蔵庫、洗濯機、テレビ）を各家庭へ配送し、その一部の設置も行います。
最初の会話で、次のような言葉が聞こえてきます。
- 小売パートナー（Retail Partner）
- 受取人（Recipient）
- 物流センター（Distribution Center）
- 積荷目録（Manifest）
- 配送（Delivery）
- ルート（Route）
- クルー（Crew）
- トラック（Truck）
これだけでも役に立ちます。ホワイトボードに箱を描き始められます。
では、名詞を四角形の中に入れましょう。この時点では、それらはただの箱です。線も色もなく、Salesforceを示すものも何もありません。コースが進むと、形や色が意味を持つようになります。今のところ、四角形はビジネスが話題にする「もの」にすぎません。
次に、それらを配置していきます。箱を置くたびに、2つのことを考えます。互いにどう関係しているか、そしてそれがどんな種類のデータか、です。一部は顧客データです。私たちが一緒に仕事をする企業や人々です。一部は注文や注文明細のようなトランザクションデータです。何度も繰り返し起こる出来事です。そして一部は、企業が提供する製品やサービスのような参照データです。仕事の拠りどころとなるものです。
Steve Truckingでは、小売パートナーと受取人が顧客データです。積荷目録、配送、ルートはトランザクションです。物流センター、クルー、トラックは、仕事の拠りどころとなるものです。
ただし、ここで大切な言葉があります。候補です。
名詞は手がかりです。自動的にエンティティになるわけではなく、ましてや自動的にSalesforceのオブジェクトになるわけでもありません。
ディスカバリーセッションでは、名詞をすべて書き留めます。相手が口にする名詞の一つひとつについて、自分に問いかけます。それは仕事をしている人なのか、それともデータなのか？ 事業開発マネージャーは、仕事をしている人です。それはユーザーであり、ロールであり、権限セットかもしれません。注文、請求書、明細行はデータです。どちらも重要ですが、設計の中ではまったく違う場所に収まります。早い段階で仕分けておけば、組織図の役職ごとに箱を描かずに済みます。
さて、こうした名詞の中には人も含まれます。Steve Truckingでいえば、冷蔵庫を待っている受取人、積荷目録を送ってくる小売パートナーの担当者、そしてトラックに乗る運転手と助手からなるクルーです。これらは役割であり、役割はデータに見えないかもしれません。しかし、人がデータに対して何かを行ったり、データに関係したりする場合、その人自身もデータとして表現される必要があります。誰が配送したのか？誰が受領のサインをしたのか？誰が積荷目録を送ったのか？ですから、多くの役割、ときにはすべての役割が、モデルにも入ってきます。
Steve Truckingの話し方に耳を傾けると、あることに気づきます。彼らは単に「顧客」とは言いません。顧客には2種類あるのです。小売パートナーは、Steve Truckingが配送を請け負う大型量販店です。積荷目録を送り、配送ごとに料金を支払います。受取人は、冷蔵庫が届けられる相手です。受取人は店で商品を買っただけで、Steve Truckingのことは聞いたこともないかもしれません。
もし「顧客」という箱を1つだけ描いていたら、まったく異なる2つのものを混ぜてしまっていたでしょう。
物流センターは、独自のレコード、履歴、関係、属性を持つほど重要かもしれません。
別の名詞は、結局は何か別のものの属性にすぎないとわかるかもしれません。
それを見つけ出そうとしているのです。まだオブジェクトを作ってはいません。ビジネスへの理解を組み立てているところです。
次に、関係に耳を傾ける
Section titled “次に、関係に耳を傾ける ”名詞が出発点を与えてくれます。次に、ビジネスがそれらをどう結びつけているかに耳を傾けます。
小売パートナーは物流センターを運営しています。
小売パートナーは、物流センターと配送日ごとに積荷目録を送ります。
積荷目録には配送が並んでいます。
配送は受取人に届けられます。
ルートは、約10か所の停車地を回る1日の行程です。
2人組のクルーがトラックを運行します。
何かが動き始めました。もう名詞のリストを見ているのではありません。モデルが見え始めています。
ここで、疑問も湧き始めます。
小売パートナーは複数の物流センターを持てるのか？
配送と停車地は同じものなのか？
1つの停車地で2人の受取人に配送できるのか？
クルーはいつも同じ2人なのか？
先月どのクルーがどのトラックを使ったかが重要なのか、それとも今日どのトラックに乗っているかだけが重要なのか？
私たちが何をしているかに注目してください。まだSalesforceについての質問はしていません。ビジネスについての質問をしています。そして、その答えが最終的にSalesforceの設計を方向づけます。
最初のモデルは完璧でなくていい
Section titled “最初のモデルは完璧でなくていい ”最初に描いた箱がそのまま残るとは思っていません。むしろ、そのまま残ったら怪しいと思うでしょう。
最初のモデルの目的は、正しくあることではありません。どこが間違っているかを見つけられるだけの具体的なものを手にすることです。
ホワイトボードに配送、ルート、クルー、トラックを描けば、人はそれに反応できます。
「実は、配送は1つの商品とは限りません。洗濯機と乾燥機、それに古い製品の引き取りかもしれません。」
いいですね。もっと教えてください。
「クルーは配送ごとに割り当てるのではありません。ルートに割り当てます。」
なるほど。ルートには何が含まれていますか？
「それから、設置がある場合、チェックリストと写真がそろうまで、クルーはその停車地を完了にできません。」
ここで大切なことがわかってきました。
図があることで、あいまいな会話が、疑問をぶつけられる具体的なものに変わりました。私が早い段階でモデリングするのが好きな理由の一つです。美しい図で場を感心させたいわけではありません。より早く学びたいのです。
モデルは会話の一部です。
これが概念モデルです
Section titled “これが概念モデルです ”私たちが作り始めたものには正式な名前があります。概念データモデルです。
このレベルで関心があるのは、ビジネスが大切にしている重要なものと、それらがどう関係しているかです。標準オブジェクトかカスタムオブジェクトか、項目のAPI参照名、参照関係か主従関係か、必須項目、インデックス、自動化、Apexやフローについては、まだ気にしません。それらも重要で、いずれ扱います。しかし、何をモデリングしているのかを理解する前にそれらを決めてしまうと、間違った問題を先に解くことになります。
概念モデルは、その場にいるSalesforceを知らない人たちにとっても意味が通じるものであるべきです。これは便利なテストです。業務マネージャーが私の図を読めるようになる前に、Delivery__cの意味を説明しなければならないのなら、私は実装に早く進みすぎています。
私は、彼らがモデルを見てこう言ってくれることを望んでいます。
「はい、私たちのビジネスはそのとおりに動いています。」
あるいは、もっと良いのは：
「いいえ、そうは動いていません。」
そうすれば、直すべきものが見つかるからです。
誰も話していないときにも同じ手法が使える
Section titled “誰も話していないときにも同じ手法が使える ”これはお客様とのディスカバリーだけで使う手法ではありません。「お客様」が文書の場合にも使えます。
要件定義書を読み込むときも、ほぼ同じことをしています。重要なビジネス概念は何か？どんな関係が書かれているか？繰り返し出てくるものは何か？独自のライフサイクルを持つもの、単独で識別する必要があるもの、履歴が必要なものは何か？作成、変更、割り当て、移管、予定、廃止されるものは何か？
これらは、最初のミーティングで耳を傾けているのと同じことです。文書の上では、こうした手がかりが要件の段落を、筋道立てて考えられるモデルに変え、次の会話のためのより良い質問に変えてくれます。
モデルは、問題を解決した後に作るだけのものではありません。問題を解決するために使う道具の一つなのです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”この最初の段階を終えるまでに、私は次のことを決めようとしています。
- どの名詞が意味のある候補エンティティなのか。
- どの異なる言葉が同じビジネス概念を表し、どの1つの言葉が2つの概念を隠しているのか（「顧客」のように）。
- どの概念が、独自のレコードとライフサイクルを必要とするのか。
- 主要な概念が互いにどう関係しているか。
- 自信を持ってモデリングする前に、ビジネスが答えるべき質問は何か。
Salesforceでの実装は、まだ決めていません。まず、ビジネスを図に描けるほど十分に理解する必要があります。そして名詞がホワイトボードに並んだら、次に理解したいのはそれらの間の線です。
試験の先へ：AIが変えること。 AIツールに要件定義書を渡せば、数秒で名詞を見つけ、エンティティを提案し、関係を描いてくれます。ディスカバリーを加速するために使いましょう。ただし、理解まで任せてはいけません。Steve Truckingで「顧客」が2つの異なる意味を持つことは、ビジネス側が教えてくれない限りAIにはわかりません。AIが作った最初のモデルを、実際にビジネスを動かしている人たちに見せて、こう尋ねてください。「本当に、御社のビジネスはこのとおりに動いていますか？」