データアーキテクトのように考える
ほかに 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)
Data Architectコース第1章の学習ガイドです。まず7つのモジュールを読んでください。このページでは、何が身についたかを確認できます。
この学習ガイドについて。 このガイドは、このコース自体の内容と、Salesforceが公開している試験ガイドの出題目標の一覧だけをもとに作られています。実際の試験問題をもとにしたことは一度もなく、試験に何が出るかを知っているとも主張しません。すでに受験した方は、どうか試験の問題を私に送らないでください。認定資格の契約で共有が禁じられていますし、そもそも答えを暗記するのはアーキテクトになる方法として間違っています。
この章は試験の知識事項が少なめですが、それは意図的です。この章が扱うのはアーキテクトの考え方であり、この章だけに属する試験目標はありません。しかし試験はシナリオでできています。あるビジネス、いくつかの数字、一つの制約、そしてうまくいきそうな複数の答え。この章の習慣は、そうしたシナリオを読み解く方法です。そこで下のチェックリストでは、直接出題されると主張する代わりに、各項目がどの目標を支えるかを示しています。
進めながらチェックしていきましょう。各項目には、それを教えている箇所へのリンクがあります。
アーキテクトとしてシナリオを読む（すべての目標を支える）
- 本当の要件を、それが包まれてやって来た設計から切り分けられる（「承認者2と承認者3の項目が必要」と「すべての承認を記録する必要がある」）。（要件をそのまま受け取らない）
- 誰も口にしていない暗黙の要件を探せる：所有、鮮度、失敗、保持、アクセス。（暗黙の要件を探す）
- 数字を当てはめられる：1日あたり、1年あたり、成長込みのボリューム。そしてゼロが一つ増えると答えが変わることに気づける。（数字を知る）
- うまくいく複数の答えの中で、示された要件と制約に照らしてそれぞれが何を得て何を手放すかを比較できる。（何を手放しているのかを知る、制約が答えを変える）
- コスト、ライセンス、制限を、後回しにせず、ツールが合うかどうかの一部として扱える。（9つの問い）
データモデル（DM-1を支える）
- モデルを、ビジネスを支えるか、ともに成長するか、性能を出すかで評価できる。（支える。成長する。性能を出す。）
- フラットすぎるモデル（項目1、項目2、項目3）、正規化しすぎたモデル、間違った標準オブジェクトの上に作られたモデルを見抜ける。（フラットすぎる、複雑すぎる、あるいは単に間違っている）
- 選択リストが短く安定したリストに向き、参照関係が増え続けるリストや連携から届くリストに向く理由を知っている。（問題を解く方法はたくさんある）
- 意味を持つキー（たとえば名前の一部）は、その意味が変わると壊れることを知っている。（安く変えられる判断もある）
すでにあるものを変える（DM-1とSDM-2を支える）
- 項目のデータ型を変えたり、既存の項目を必須にしたりすると後で問題が起き得る理由と、コードやフローが項目を参照している間はプラットフォームが型の変更を止める理由を知っている。（骨格を変えるときは慎重に）
- 変えるより足す、驚かせるより廃止予定にするというパターンと、Field Usageで項目を廃止候補としてマークできることを知っている。（骨格を変えるときは慎重に）
- 可逆性テストの背後にある主従関係の事実を知っている：詳細側のアクセスと所有は主側に従い、主レコードを削除すると詳細も削除され、積み上げ集計には主従関係が必要で、参照関係を主従関係に変換できるのはすべてのレコードに値がある場合だけ。（可逆性テスト、さらに学ぶ）
ライセンスと共有（SDM-1を支える）
- 大量コミュニティユーザー（Customer Communityなど）はロールを持たず共有モデルを使わないため、アクセスは共有セットと共有グループから来て、Apex共有は届かないことを知っている。（実例：Apex共有）
失敗（MIG-1と連携の章を支える）
- 「ジョブ完了」はデータが正しいことと同じではないこと、そして照合で届かなかったレコードをどう見つけるかを知っている。（部分的な成功も、理解すべき失敗である）
試験の先へ
Section titled “試験の先へ ”試験は床であって天井ではありません。ここに挙げるのは、問題で問われるかどうかにかかわらず、アーキテクトに必要なこの章の習慣です。
- 誰かが設計図を手にしていなければならない。 アーキテクチャとは、不完全な情報のもとでよい判断を下し、その結果を知っていることです。
- データモデルは骨格である。 ほかのすべてはその上に作られます。
- 可逆性テスト： 元に戻すのはどれくらい難しいか、どれだけのものがそれに依存するか？
- アーキテクチャは重力を生む。 変化を高くつくものにするのは、変化そのものではなく依存関係です。
- 影響範囲を考える。 Salesforceの中でも、企業全体でも。アーキテクチャは双方向の通行です。
- なぜそうしたかを書き残す： 背景、選択肢、判断、結果、責任者、見直し。消さずに置き換える。
- 何において最善か？ 自分でわかっているなら、最適でない判断も最適なアーキテクチャの一部になり得ます。
- 最適の姿を持っておく。 そうすれば、そこからどの方向に、なぜ離れているのかがわかります。
- 正しく考える。速く考える。 速さは、その瞬間より前に済ませた思考から生まれます。
- 今日のために作る。明日に備える。失敗に備える。 誰も数字をくれないときは、30パーセントの成長を使いましょう。
- 答えだけでなく、9つの問いを学ぶ。
- AIはロケットブースターである。 生成は判断ではなく、元に戻せないものはやはり元に戻せず、人間によるレビューは儀式ではありません。信頼しつつ検証する。
覚えておきたい用語
Section titled “覚えておきたい用語 ”| 用語 | ひとことで |
|---|---|
| アーキテクチャ上の判断 | 元に戻しにくく、多くのものが依存する判断 |
| 可逆性テスト | 元に戻すのはどれくらい難しいか、どれだけのものがそれに依存するか？ |
| 重力 | 時間とともに判断の周りに集まってくる依存関係 |
| 影響範囲 | 判断が変わったときに一緒に動く、ほかのすべてのもの |
| 判断記録 | 背景、選択肢、判断、結果、責任者、見直しのタイミングを小さくまとめたもの |
| トレードオフ | ある選択肢が得るものと、それを得るために手放すもの |
| 暗黙の要件 | ロードが失敗したときの復旧のように、ビジネスが頼まなくても期待しているもの |
| スティーブのゼロの数 | ボリュームのゼロが一つ増えるだけで、アーキテクチャ全体が変わり得ること |
| 照合（リコンシリエーション） | 起きるはずだったことと実際に起きたことを、レコード単位で比べること |
| 廃止予定にする | その場で変えるのではなく、引退予定であることを示してから、意図的に引退させること |
| 大量ユーザー | ロールを持たず、共有モデルの外にいるコミュニティユーザー（ライセンスではCustomer Communityなど） |
| スキーマの無秩序な膨張 | 作るのが安いために積み重なり、ついには誰もモデルを設計していない状態になったオブジェクトや項目 |
理解度チェック
Section titled “理解度チェック ”コースと同じスタイルの短いシナリオです。開く前に自分の答えを決めましょう。
1. 営業チームが、商談に承認者2と承認者3の項目を、それぞれ日付付きで追加してほしいと頼んできました。何を尋ね、何を作る可能性がありますか？
なぜかを尋ね、承認がいくつになり得るかを尋ねます。2つや3つを超え得るなら、要件は項目を足すことではなく、すべての承認を記録することです。子オブジェクトにして、承認ごとに1レコードにします。要件をそのまま受け取らないを読み直しましょう。
2. ある人は項目の表示ラベルを変えたいと言い、別の人は5つのシステムがすでに保存している顧客識別子の形式を変えたいと言います。どちらにより注意を向けるべきで、それはなぜですか？
識別子です。表示ラベルは安く変えられます。識別子は可逆性テストに引っかかります。元に戻しにくく、すでに多くのものが依存しています。注意は、間違えたときのコストに見合った分だけ向けましょう。安く変えられる判断もあるを読み直しましょう。
3. あるテキスト項目が何年も使われてきました。ビジネスは今後そこに数値を入れたいと言っています。どう進めますか？
その場で変えないことです。何がそれに依存しているか（フロー、Apex、レポート、連携、エージェント）と、古いデータがどうなるかを調べます。たいていは、新しい項目を追加し、意図的に移行し、古い項目を廃止予定にします。骨格を変えるときは慎重にを読み直しましょう。
4. 1,200拠点、1拠点1日100件の予約、年間約305日、予約1件につき2レコード、5年保持、30パーセント成長。おおよそ何レコードになり、なぜそれが重要なのでしょうか？
初年度で約7,300万レコード（3,660万件の予約、各2レコード）、成長込みで5年間では6億5,000万レコードを超えます。同じ機能でも、ゼロが2つほど増えるとまったく違うアーキテクチャになります。数字を知るを読み直しましょう。
5. 夜間のロードが100万レコードで「完了」と報告しました。うまくいったとどうやってわかりますか？
照合します。受け取る側が保存したレコードごとに確認を返し、送る側が送ったものと確認されたものを比べます。確認が欠けていれば、ジョブのステータスが何と言おうとうまくいっておらず、どのレコードを再試行し、人に回し、アラートを上げればよいかがわかります。部分的な成功も、理解すべき失敗であるを読み直しましょう。
6. 1,500万人のCustomer Communityユーザーがいるコミュニティで、複雑なレコードアクセスが必要です。誰かがApex共有を提案しました。何が問題でしょうか？
彼らは大量ユーザーです。ロールを持たず、共有モデルの外にいるので、Apexが書き込む共有レコードがありません。アクセスは共有セットと共有グループから来ます。ライセンスが、どの共有ツールが存在するかを決めたのです。実例：Apex共有を読み直しましょう。
7. AIツールが新しいアプリのために20個のオブジェクトを数分で生成しました。ここでのアーキテクトの仕事は何でしょうか？
5個にすべきかどうかを決めることです。モデルを弁護できるほど理解します。なぜこのオブジェクトとリレーションなのか、キーとマスターデータはどこにあるのか、規模が大きくなったら何が起きるのか。AIが頼った事実を検証します。生成は判断ではありません。安い実装は価値の場所を移すを読み直しましょう。
さらに学ぶ
Section titled “さらに学ぶ ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)、Salesforceヘルプ（英語、2026-09-25確認）：出題目標とその配分の公式一覧。受験を予約する前に、必ず最新版を確認しましょう。