ツールを知る：9つの問い
ほかに 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)
モジュール6／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：今日のために作る。明日に備える。失敗に備える。 · 次へ：AI時代のデータアーキテクト
このモジュールが答える問い： 見たことのないツールも含めて、どんなツールでも評価するにはどうすればよいか？
アーキテクトには判断力が必要です。しかし知識のない判断力はあまり役に立ちません。やはりツールを知っておく必要があります。
私は何年もアーキテクトを教えてきました。そこで使っているフレームワークの一つが、アーキテクチャの中の重要なツールや機能のすべてについて答えられるべき問いのセットです。もともとは8つの問いを教えていましたが、9つ目を加えました。テクノロジーは変わり、Salesforceも変わり、新しい製品が登場し、古い機能は進化し、AIがそのすべてを加速させています。それでも、この問いは役に立ち続けます。
9つの問い
Section titled “9つの問い ”テクノロジーを学ぶとき、評価するときは、いつも次のことを問いましょう。
- それは何か？
- どこで使われるか？
- どう使うか？
- ほかにどんな選択肢があるか？
- 強みは何か？
- 弱みは何か？
- 開発者、ビジネス、経営層にどう説明するか？
- 長期的にどう保守するか？
- コストはいくらで、どんなライセンスが必要で、どんな制限があるか？
9つすべてに答えられるなら、アーキテクトとしてそのツールを理解し始めています。リストにないものに注目してください。「設定できるか？」です。それも大切ですが、ツールを知ることの一部にすぎません。
1. それは何か？
Section titled “1. それは何か？ ”当たり前の問いから始めましょう。驚くほど頻繁に飛ばされるからです。製品名や機能名を聞くと、すぐにそれを使うかどうかの議論を始めてしまいます。ペースを落としましょう。それは実際に何をするのか？ どんな問題を解くために設計されたのか？ アーキテクチャのどこに位置し、何ではないのか？ アーキテクトは、マーケティングの説明を繰り返さずにテクノロジーを説明できるべきです。数文で説明できないなら、おそらくまだ十分に理解していません。
2. どこで使われるか？
Section titled “2. どこで使われるか？ ”何をするのかを知ることは、それがいつアーキテクチャに属するのかを知ることと同じではありません。どんな種類の問題が得意なのか？ どんな条件なら適切で、どんな条件なら疑ってかかるべきか？ これは「この機能を知っている」から「この機能が解く問題を見抜ける」への一歩であり、大きな一歩です。お気に入りのテクノロジーを使える場所を探して歩き回りたいのではありません。問題を見抜き、どのツールが合うかを知りたいのです。
3. どう使うか？
Section titled “3. どう使うか？ ”はい、アーキテクトは実装を理解しているべきです。すべての部品を自分で作る必要はありませんが、ほかの人に何を作るよう頼んでいるのかがわかる程度には理解しているべきです。どう設定するのか、開発者はどう扱うのか、データはどう出入りするのか、どうデプロイしてセキュリティを確保するのか、運用ではどう見えるのかを知りましょう。製品紹介のスライドでしか見たことのないテクノロジーを前提に設計するアーキテクトは困ります。手を動かしましょう。何かを作り、何かを壊し、実際にどう振る舞うかを見るのです。アーキテクチャは現実に根ざしているほどよくなります。
4. ほかにどんな選択肢があるか？
Section titled “4. ほかにどんな選択肢があるか？ ”これはリストの中で最も重要な問いかもしれません。問題を解く方法を一つしか知らないなら、それはアーキテクチャ上の判断ではなく、ただのデフォルトです。誰かがテクノロジーを提案するたびに、私はほかに何ができるかを知りたいのです。別のSalesforceの機能？ 宣言的なものか、コードか？ その機能をSalesforceの外に置けるか？ データをコピーせずにその場に置いておけるか、API呼び出しの代わりにイベントを使えるか、あるいは何も作らずに済むか？ 選択肢がトレードオフを生み、トレードオフこそがアーキテクチャの核心です。
5. 強みは何か？
Section titled “5. 強みは何か？ ”どのツールにも存在する理由があります。それが本当に得意なことを理解しましょう。何を簡単にするのか、どこでうまくスケールするのか、どんな複雑さを取り除くのか、どんな問題をエレガントに解くのか。テクノロジーは、その強みが問題と一致するところで使いましょう。当たり前に聞こえますが、すでに持っているから、チームが知っているから、新しいから、誰かがデモを見たから、という理由でツールを選んでしまうのはとても簡単です。それらも要素にはなり得ます。しかし、アーキテクチャとして合っていることと同じではありません。
6. 弱みは何か？
Section titled “6. 弱みは何か？ ”これも同じくらい重要です。どのテクノロジーにも弱みがあります。一つ残らずです。テクノロジーの強みしか語れない人がいるなら、まだアーキテクチャの議論は始まっていません。何が苦手なのか？ どこで複雑さが現れ、規模が大きくなると何が起きるのか？ どんな運用負荷と依存関係をもたらすのか？ どんな要件がそれを得意分野から押し出すのか？ 弱みがあるからといって、そのテクノロジーを使うべきでないとは限りません。何を受け入れているのかを知る必要がある、という意味です。理解しているトレードオフは、アーキテクチャ上の判断になり得ます。理解していないトレードオフは、思わぬ事態になり得ます。
7. 相手に合わせてどう説明するか？
Section titled “7. 相手に合わせてどう説明するか？ ”これは、技術的な知識とアーキテクトとしてのスキルを分ける問いの一つです。同じテクノロジーを、開発者に、ビジネスに、経営層に説明できるでしょうか？ それぞれ同じ説明であるべきではありません。開発者にはAPI、トランザクションの振る舞い、セキュリティ、失敗時の処理、実装パターンが必要です。ビジネスが気にするのは、それで何ができるようになり、自分たちのプロセスがどう変わるかです。経営層が気にするのは、コスト、リスク、時間、組織への影響、そしてその判断がどの選択肢を残し、どれを閉ざすかです。真実を変えているのではありません。抽象度を変えているのです。ドキュメントの用語でしかテクノロジーを説明できないなら、理解をもう少し深めましょう。
8. 長期的にどう保守するか？
Section titled “8. 長期的にどう保守するか？ ”プロジェクトは終わります。システムは終わりません。少なくとも、終わらないことを願っています。プロジェクトチームが去った後、作ったものを誰かが所有しなければなりません。つまり、どう監視し、アップグレードし、トラブルシューティングするのか、それを支えるスキルを誰が持つ必要があるのか、変更をどうデプロイしてテストするのか、そしてテクノロジーが進化したり、Salesforceが足元で何かを変えたりしたら何が起きるのかを知っておくということです。3年後を思い浮かべてください。リリース当日はとても巧妙だったのに、その後の運用が悲惨なアーキテクチャを見てきました。それは成功ではありません。保守しやすさもアーキテクチャの一部です。
9. コストはいくらで、どんなライセンスが必要で、どんな制限があるか？
Section titled “9. コストはいくらで、どんなライセンスが必要で、どんな制限があるか？ ”これが元の8つに加えた問いで、今では外すことなど考えられません。技術的には完璧な解決策でも、経済的に成り立たなければ、アーキテクチャとしては間違った解決策になり得ます。手持ちのライセンスに含まれているのか、それともアドオンか？ ユーザー単位、使用量単位、消費量単位、ストレージ単位、トランザクション単位のどれでライセンスされるのか？ 規模が大きくなるとコストはどうなるのか？
そして制限があります。どのプラットフォームにもあります。API、ストレージ、クエリ、トランザクション、同時実行、スループット、ライセンスの制限。ハードなものもソフトなものもあり、引き上げられるものもそうでないものもあり、ゼロがもう一つ増えるまでは私たちの規模では問題にならないものもあります。Salesforceのすべての制限を暗記する必要はありませんし、そうするのは時間のひどい無駄遣いです。必要なのは、制限が存在すること、どの制限が自分のアーキテクチャにとって重要か、そしていつ現在の数値を確かめに行くべきかを知ることです。数値は変わります。アーキテクチャ上の問いは残ります。
実例：Apex共有
Section titled “実例：Apex共有 ”この問いが実際に働く、私がよく使う例を一つ紹介します。複雑な共有の要件を受け取ったとします。所有者に基づく共有ルールでも条件に基づく共有ルールでも満たせない共有です。そこでApex共有、つまり共有レコードをコード自身が書き込む方法にたどり着きます。すると、Apex共有とは何か、どこで使われるか、どう使うかなどを知る必要が出てきます。これはエスカレーションです。Apex共有は、必要なルールが所有者ベースや条件ベースの共有で表現できる範囲を超えたときの選択肢（問い4）なのです。
次はその弱み（問い6）です。会員が1,000万人や2,000万人のカスタマーコミュニティがあり、Customer Community Plusではなく、Customer Communityライセンスを使っているとします。彼らは大量ユーザーです。ロールを持たず、共有モデルをまったく使いません。アクセスは共有セットと共有グループから来ていて、ユーザーの取引先と取引先責任者を通じて照合されます。Apexが彼らのために書き込む共有レコードがないので、Apex共有は彼らには使えません。そして、私たちをそこに追い込んだのはコストとライセンスの問い（問い9）でした。ライセンスの選択が、そもそもどの共有ツールが存在するかを決めたのです。
ですから、Apex共有が所有者ベースや条件ベースのルールの代わりだったのと同じように、Apex共有の代わりが必要になる場面に出くわすかもしれません。そしてその時点では、複雑な共有ルールのための設定ベースの選択肢は事実上ありません。結局、オブジェクトを参照のみにして、Apexでアクセスを制御することになります。だから9つの問いは、選んだ後ではなく、選ぶ前にすべて問うのです。
プラットフォームを暗記しない
Section titled “プラットフォームを暗記しない ”これは、Salesforceのアーキテクチャを学んでいるときに最も大切なことです。Salesforceを暗記しようとしないでください。できません。プラットフォームは大きすぎますし、変化が速すぎます。私は長くSalesforceに携わってきましたが、今でも学び続けています。それが普通です。
身につけてほしいのは、学ぶためのフレームワークです。明日Salesforceが新しい機能をリリースしても、私がそれを前に見たことがある必要はありません。何を問えばよいかを知っています。それは何か、どこに合うのか、どう使うのか、ほかに何が使えるのか、何が得意か、どこで苦労するか、どう説明するか、どう運用するか、コストはいくらで制限はどこにあるか。これで評価を始められます。機能比較表をもう一つ暗記するより、ずっと価値があります。
試験の先へ：AIは9つの問いへの答えを速くし、そして間違いやすくもする。 知らないテクノロジーに出会ったら、AIに説明させたり、3つの方法を比較させたり、制限やよくある失敗パターンを挙げさせたり、使うべきでない理由を論じさせたりできます。すばらしいリサーチアシスタントです。しかし、間違っていることも、古いことも、似た名前の2つの製品やエディションを自信満々に取り違えることもあります。判断に影響することは、何であれ検証しましょう。情報源をたどり、現在のドキュメント、制限、ライセンスを確認するのです。信頼しつつ検証する（モジュール7）。
答えだけでなく問いを学ぶ
Section titled “答えだけでなく問いを学ぶ ”このコースでは多くのテクノロジーに出会います。答えを集めてほしいのではありません。問いを練習してほしいのです。Big Object、外部データ、Data 360、連携パターン、あるいはこの章が書かれた半年後にSalesforceがリリースするAI機能について話すときも、同じ9つの問いを立ててください。
答えは変わります。問いは長持ちします。 それが、これを学習ガイドではなくアーキテクチャのフレームワークにしているのです。
ツールを知りましょう。何が得意で、何が苦手か、ほかに何が使えるか、コストはいくらで、どこで壊れるか。そして、その判断と付き合っていく人たちに説明できるだけのことを知っておきましょう。それが、アーキテクトがテクノロジーを学ぶ方法です。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- ツールが問題に合っているかどうか。設定できるかどうかだけでなく、9つの問いすべてで判断する。
- ほかの選択肢は何か、そしてツールのコスト、ライセンス、制限が自分たちの規模で何を意味するか。
- 3年後、誰がどうやってそれを保守するか。
- ツールについてのどの事実を、頼る前に検証するか。
さらに学ぶ
Section titled “さらに学ぶ ”- About High-Volume Community or Site Users (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認、2026-10-12再確認）：大量ユーザー（External Apps、Customer Community、High Volume Customer Portal、Authenticated Websiteの各ライセンス）はロールを持たず、アクセスは共有セットと共有グループから来る。所有者ベースの共有ルールに含めることはできず、彼らが所有するレコードは手動で共有できない。
- Platform Sharing Architecture (opens in a new tab)、Salesforce Architects（英語、2026-10-09確認、2026-10-12再確認）：大量ユーザー（Customer Community、High Volume Customer Portal、Authenticated Website）は、ライセンスがロールをサポートしないため共有モデルを使わない。アクセスは、共有セットまたは共有グループを通じて、ユーザーを取引先と取引先責任者の参照項目に照合することで機能する。同じページには、Apex管理共有が適したツールである場合も挙げられている。
- Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab)、Trailblazer Communityの質問、2024年11月（英語、2026-10-09確認、2026-10-12再確認）：大量ユーザー向けの共有レコードを挿入しようとしたらエラーで失敗した、という実務者の報告。公式ドキュメントではなく、現場からの報告です。（オンラインのTrailblazer Communityは2026年10月30日に読み取り専用になるため、リンクが変わる可能性があります。）
- Create a Sharing Set for Experience Cloud Site Users (opens in a new tab)、Salesforceヘルプ（英語、2026-10-09確認）：共有セットは、ユーザーの取引先または取引先責任者に関連するレコードへのアクセスを付与する。