可逆性テスト
ほかに 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)
モジュール3／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：データモデルは骨格である · 次へ：アーキテクチャはトレードオフの技術である
このモジュールが答える問い： アーキテクチャ上の判断と普通の判断を、どう見分けるか？
アーキテクトはたくさんの判断を下します。
しかし、すべての判断がアーキテクチャ上の判断というわけではありません。
これは大切な区別です。すべての判断をアーキテクチャとして扱えば、比較的簡単に変えられることの議論に時間をすべて使ってしまいます。本当にアーキテクチャ上の判断を見分けられなければ、今日5分で下した判断を解きほぐすのに5年かかることになりかねません。
では、どうやって見分けるのでしょうか？
私はシンプルな問いを立てるのが好きです。
この判断を後から元に戻すのは、どれくらい難しいか？
私はこれを可逆性テストと呼んでいます。
元に戻すのが難しく、ほかのものが依存するほど、アーキテクチャ上の注意を払う価値があります。
安く変えられる判断もある
Section titled “安く変えられる判断もある ”簡単なものから始めましょう。
ある項目を**Customer Category（顧客カテゴリ）と名付けたとします。半年後、ビジネス側は、みんな実際にはCustomer Segment（顧客セグメント）**と呼んでいると判断します。表示ラベルを変えます。更新するドキュメントや少しのユーザートレーニングはあるかもしれませんが、大きなアーキテクチャ上の出来事ではありません。ただし、元のAPI参照名とは付き合い続けることになります。それを変えるとずっと大きな影響が出るからです。つまりこれは、表示ラベルの変更と、それに伴う混乱に対処するだけのことかもしれません。
判断を下し、考えを変え、先に進みました。
では、別の判断と比べてみましょう。
顧客の識別子を作るとします。それが何を意味するか、どんな形式にするか、どのシステムが作成するかを決めます。そして公開します。
Salesforceが使います。データウェアハウスが使います。連携プラットフォームが使います。顧客ポータルが使います。ほかに5つのアプリケーションがそれを保存し始めます。レポートやデータパイプラインが使います。やがて顧客の目に触れるかもしれません。
3年後、誰かが言います。
あの識別子は、あんな設計にすべきではなかったかもしれない。
これはまったく別の会話です。
違いは、一方の判断がもう一方より技術的だということではありません。
違いは可逆性です。
それがどう起きるかを見てみましょう。ビジネスが、顧客名の一部と番号を組み合わせてキーを作ってきたとします。名前を変える必要が一度もなかったので、何年もうまくいきます。ところが1年以上たってから名前が変わり、突然、キーがほかのデータが期待するパターンと合わなくなります。これが、キーに固有の意味を持たせるべきではない理由の一つです。
アーキテクチャは重力を生む
Section titled “アーキテクチャは重力を生む ”アーキテクチャ上の判断の周りには、ものが集まってくる傾向があります。私はそれを重力と考えています。
オブジェクトモデルを選べば、その周りに自動化が作られます。
キーを選べば、ほかのシステムがそれを保存し始めます。
マスターデータの置き場所を選べば、そこに向かう連携とそこから出る連携が流れ始めます。
共有モデルを選べば、誰が何を見られるかにビジネスプロセスが依存し始めます。
連携パターンを選べば、システムはそのタイミングと振る舞いに依存し始めます。
そうした判断が長く存在するほど、重力は強くなります。やがて元の判断を変えることは、その周りに集まったすべてを変えることを意味するようになります。
AIもその重力を感じます。AIツールは、すでにシステムにあるものを土台に動きます。一度重要な設計要素がそこに入ると、その後のすべてのAIとのやりとりはそれを事実として扱い、その上に積み上げ、積み上げ、さらに積み上げていきます。その判断はさらに多くの判断を通じて先へ先へと反響し、元の判断を見直しに戻る人間は誰もいません。生成のたびに、重力は増していきます。
だからこそ、データモデルが「骨格」であることが重要なのです。変化が悪いから慎重になるのではありません。依存関係が変化を高くつくものにするから慎重になるのです。
2つの問いを立てる
Section titled “2つの問いを立てる ”設計上の判断を見るとき、私は2つの問いを立てます。
元に戻すのはどれくらい難しいか？
どれだけのものがそれに依存するか？
この二つは関連していますが、同じではありません。技術的には簡単に変えられても、何百もの利用者がいるものもあります。以前は、わかりやすくするために標準オブジェクトの表示ラベルを変えることがよくありました。たとえば取引先を「顧客」に。簡単にできます。その後、別のシステムが取引先をパートナーにも使いたくなり、使えなくなりました。逆に、利用者は少なくても、変えるには膨大な移行が必要なものもあります。内部の多くの場所で参照されているオブジェクトのAPI参照名がそうです。外からは誰にも見えませんが、間違った名前はチームを混乱させ続けます。どちらも注意を払う価値があります。
よくあるデータの判断を考えてみましょう。
- このビジネス概念を表すのは、どのSalesforceオブジェクトか？
- 一意の識別子は何か？
- どのシステムが記録システムか？
- このデータはSalesforceにコピーするのか、それともどこか別の場所でアクセスするのか？
- これは一つのオブジェクトか、それとも関連する複数のオブジェクトか？
- 誰がデータを所有し、どれくらいの期間保持するのか？
- デフォルトのアクセス境界はどうするか？
- このデータはシステム間をどう移動するのか？
これらは、Lightningページのどこに項目を置くかを決めることとはまったく違います。ページのデザインも大切です。ただ、間違えたときのコストが違うのです。
影響範囲を考える
Section titled “影響範囲を考える ”可逆性を考えるもう一つの方法が影響範囲です。この判断を変えたら、ほかに何が動くか？
項目としてモデリングしたものが、実は子オブジェクトである必要があったとします。それは単なるスキーマの変更ではありません。既存のデータはどうなるでしょうか？ レポートは、その項目を前提にしている連携は、それを参照しているApexやフローは、セキュリティは、分析は、元の構造に依存して動くAIエージェントはどうなるでしょうか？
影響範囲が大きいほど、元の判断はより慎重に下すべきです。
これは、アーキテクトがシステムの自分の担当部分の外まで見なければならない理由でもあります。Salesforceの中から見れば、変更は簡単に見えるかもしれません。企業全体から見れば、ほかの12のシステムに影響するかもしれません。
企業全体の判断とSalesforceの判断
Section titled “企業全体の判断とSalesforceの判断 ”データアーキテクトは2つのレベルで考えます。
Salesforceの中では、オブジェクト、リレーション、キー、ボリューム、アクセス、自動化、そしてプラットフォーム上でデータがどう振る舞うかを決めます。
企業全体では、もっと広い問いを立てます。顧客は実際にどこにあるのか？ 製品は誰が所有しているのか？ 注文を作成するのはどのシステムか？ 権威ある識別子は何か？ どの情報をシステム間でコピーし、どの情報をその場に置いておくのか？
この2つのレベルはつながっていなければなりません。内部のモデルはそれだけ見れば完璧に筋が通っているのに、周りの企業全体には合っていないSalesforceの導入を見たことがあります。それでは不十分です。Salesforceの構造は企業レベルで表現される必要があり、企業レベルの判断はSalesforceに流れ戻ってくる必要があります。
アーキテクチャは双方向の通行です。
高くつく判断ではペースを落とす
Section titled “高くつく判断ではペースを落とす ”テクノロジーの危険の一つは、最も実装しやすい判断が、最も下しやすい判断に見えてしまうことです。この二つは同じではありません。
カスタムオブジェクトをもう一つ作るのは簡単です。項目をもう一つ作るのも簡単です。APIをもう一つつなぐのもどんどん簡単になっていて、AIはそのすべてをさらに簡単にします。
しかし、実装のしやすさは、アーキテクチャ上の判断のコストについてほとんど何も教えてくれません。
元に戻しにくい判断の前には、少なくとも次のことを問えるくらいにはペースを落としましょう。実際にはどんな問題を解いているのか？ どんな選択肢を検討したか？ 何を前提にしているか？ ボリュームが増えたら、ビジネスが変わったら何が起きるか？ ほかに何がこれに依存することになるか？ 間違っていたらどうなるか？
オブジェクトを作るたびに半年のレビューは要りません。必要なのは、間違えたときのコストに見合った思考です。一つの部門やサブシステムのためのオブジェクトなら、もっと速く進められます。参照データ、主要な顧客オブジェクト、システムをまたいで使われるものなら、時間をかけて考え抜きましょう。
なぜそうしたかを書き残す
Section titled “なぜそうしたかを書き残す ”重要な判断にはもう一つ問題があります。人は、なぜその判断が下されたのかを忘れてしまうのです。
3年後に誰かがアーキテクチャを見て、「いったい誰がこんな設計にしたんだ？」と尋ねます。悪い設計だったというのが答えのこともあります。それは起こります。しかし、とてもよい理由があったこともあります。今はもう存在しないプラットフォームの制約、規制上の要件、望ましい方法に対応できなかった別のシステム、期限に間に合わせるために承知の上で受け入れたトレードオフ。
何を決めたか（what）だけを記録して、なぜ（why）を記録しなければ、次のアーキテクトには知る手段がありません。
重要な判断は書き残しましょう。50ページの文書である必要はありません。役に立つ判断記録はごく小さくてかまいません。
背景： どんな問題を解いているのか？
選択肢： 現実的にどんな選択肢を検討したか？
判断： 何を選んだか？
結果： 何を得て、何を手放すのか？
責任者： この判断に責任を持つのは誰か？
見直し： どんな理由や日付が来たら見直すべきか？
価値は文書にあるのではありません。価値は考えた筋道を残すことにあります。
そして判断が変わったときは、元の判断を消さないでください。置き換えるのです。2027年に正しかった判断が、2030年には正しくないかもしれません。ボリュームも、ビジネスも、Salesforceも、私たちの理解も変わるからです。私が残したいのはストーリーです。こういう背景があり、こういう判断をこういう理由で下し、これが変わり、今こう決めている。いつも答えを知っていたふりをするより、ずっと価値があります。
試験の先へ：AIは判断から依存までの時間を縮める。 AIツールは数秒でデータモデルを提案し、その上にオブジェクト、自動化、連携コード、ユーザーインターフェースを作ってくれます。以前は、疑わしい判断に多くのものが依存するまでに何か月もの開発が必要でした。今では依存関係がほぼ即座にやって来ます。だから、出力だけでなく、出力の下にある判断をレビューしましょう。AIは手伝えます。選択肢を挙げ、前提に異を唱え、判断記録の下書きを作れます。しかし判断するのはやはりアーキテクトであり、元に戻しにくい判断ほど、人間の判断力が重要になります。
どの判断が重要かを知る
Section titled “どの判断が重要かを知る ”身につけてほしいスキルの一つは、どこに注意を向けるかを知ることです。
設定の選択の一つひとつを、アーキテクチャ会議にしないでください。
しかし、組織がこの先10年付き合うことになる判断を、気軽に下さないでください。
問いましょう。
元に戻すのはどれくらい難しいか？
どれだけのものがそれに依存するか？
答えがとても難しいとたくさんなら、おそらくアーキテクチャ上の判断を見つけたのです。
ペースを落とす。要件を理解する。選択肢を探る。トレードオフを見えるようにする。判断を下す。そして、なぜそうしたかを書き残す。
アーキテクチャの目的は、決して変えられない判断を下すことではありません。
目的は、考えを変えると高くつく判断を見分けることです。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- どの判断がアーキテクチャ上の判断か：元に戻しにくく、多くのものが依存するもの。
- それぞれの判断にどれだけ注意を払うか。間違えたときのコストに見合った分だけ。
- どの判断を、背景、選択肢、結果、責任者、見直しのタイミングとともに書き残すか。
- Salesforceの判断を企業全体の判断とどう整合させるか。
さらに学ぶ
Section titled “さらに学ぶ ”- Object Relationships Overview (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認、2026-10-12再確認）：主従関係では、詳細側のアクセスと所有は主側に従い、主レコードを削除すると詳細レコードも削除される。
- Considerations for Object Relationships (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認、2026-10-12再確認）：参照関係を主従関係に変換できるのは、すべてのレコードに値が入っている場合だけ。変換すると共有モデルが（「親レコードとの関連付けにより管理」に）変わり、リレーションの種類によって使える標準レポートタイプが決まる。
- Roll-Up Summary Field (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認、2026-10-12再確認）：積み上げ集計項目は主従関係にしか存在せず、主従関係を参照関係に変えるには先に削除しなければならない。