Salesforceの「認定 Data Architecture and Management デザイナー（Spring '19）」という認定試験に合格しましたので、これから資格の取得を目指されている方のために、どういう勉強をしたかなど、雑感、メモを共有させていただきます。
対象読者
Salesforce「認定 Data Architecture and Management デザイナー」の資格取得を検討している方。
学習方法
できるだけ短期間で合格することを重視したため、Focusonforce.comというサイトで問題集を購入して勉強しました。例題を解きながら、分からないところはヘルプや Trailhead や Google で調べる。この勉強方法で、2週間ほどの準備期間で合格できました。
公式の受験ガイドには Trailmix での勉強が勧められています。ですが、普段からこの分野に精通しているわけでない場合、Trailmixだけで合格するのはハードルが高いと思います。なぜなら、試験で出題されるのは Salesforceの製品知識だけでなく、こういった問題にもしっかり答えられるようにする必要があるからです。
- 「マスタデータ管理」「メタデータ管理」「データガバナンス」など、データ管理に関するドメイン知識
- 「Data.com」や「Einstein Analytics」など、無料の開発者エディションが提供されていないSalesforce製品
問題集を購入することで、ポイントを絞って効率的に勉強することができました。多少のお金はかかりますが、それに見合う以上の時間が買えたと思います。
サードパーティが提供する問題集は上に紹介したもの以外にもいくつか存在するようですが、執筆時点では残念ながら日本語のものはなさそうです。
押さえておいたポイント
出題分野ごとに、事前勉強したポイントなどを共有します。
データモデリング
データモデリングについては、「標準オブジェクト」「リレーション項目」「選択リスト」「監査項目」などのキーワードを押さえました。
標準オブジェクトについては、どういう種類のオブジェクトがあるか、ざっと頭に入れておきました。たとえば「BtoCのビジネスなら『個人取引先』が使える」くらいのレベルで理解しておきました。実際に試験でもそれ以上に細かい内容は出題されませんでした。
リレーション項目については、主従関係と参照関係の違い、ユースケースによってどちらを選択するか答えられるようにしておきました。たとえば、親レコードが必須でない場合は「参照関係」が回答になり、親レコードに対するのと同じレコード権限を子レコードにも与えたい場合は「主従関係」が回答になる、などです。
リレーション項目の子レコードが大量にあると、パフォーマンス的に問題が出る場合があります。親レコードが頻繁に追加されない場合（たとえば、店舗など）、「選択リスト」に置き換えるとパフォーマンス改善になることを把握しておきました。
レガシーシステムからデータ移行する場合に、元のシステムでのレコード作成日などを引き継ぎたい場合があります。「作成日」や「最終更新日」などの監査項目は、データローダで値を設定することが可能です。その際に、「レコード作成時に監査項目を設定」権限が必要なことなどを覚えておきました。
概念設計
Data Governance & Stewardship を読んで、データガバナンスやスチュワードシップの概念を頭に入れました。特に、データ品質の6つの評価ディメンション（「完全性」「正確性」「重複」など）は暗記しました。
そのうえで、「重複ルール／一致ルール」「入力規則」「Data.com クリーン」「Lightning Dataパッケージ」などのツールについて、ヘルプページなどを読んで押さえておきました。
「取引先の電話番号が入力されていない」「取引先の電話番号が間違っていてつながらない」など、データの「完全性」や「正確性」に関する問題は、信頼できるサードパーティのデータを使ってクレンジング／強化することで解決できます。ツールとしては、Data.com クリーンやLightning Data パッケージを活用できることを覚えておきました。（※Summer'19 リリースノートによると、Data.comはサービス終了予定となっているため、今後出題範囲から削除される可能性があります。）
ダッシュボードは自分で構築しなくても、既存のものをAppExchangeからインストールして活用できることを覚えておきました。AppExchangeには、「データ品質ダッシュボード」や「営業KPIダッシュボード」などがあることを押さえました。
ユーザの入力など、エントリポイントでデータ品質を維持するために、どのようなツールが活用できるか押さえておきました。Salesforceは、「入力規則」「必須項目」「選択リスト」「連動選択リスト」「ページレイアウト」「重複ルール」「ワークフロー」など、多くのツールを提供しています。
試験で出題されたのは、各ツールのコンセプトやユースケースに関する問題、たとえば「重複した取引先が登録されるのを未然に防ぐにはどのツールを使用すればよいか。」というような問題が中心であり、機能の詳細（たとえば、一致ルールの一致条件など）に関する問題はありませんでした。
マスタデータ管理（MDM）
MDMにおける、「システムオブレコード」や「Source of Truth（唯一の真のソース）」などの概念を勉強しました。MDMはひとつの分野として広くて深い世界なのだということを知りました。MDMに関してSalesforceから直接提供されているドキュメントはほとんど見当たらず、Trailmixで紹介されているブログなどは広範すぎるため、右も左も分からない状態でした。私にとっては、サードパーティの問題集がなければ十分な試験対策ができなかったと思います。
問題集で理解したのは、以下のような内容です。
複数のシステムが同じ種類のデータを共有している場合、整合性を取るためにMDMツールが活用できる。連携システムが2つであればP2Pで足りるため、MDMツールが必要なのは3つ以上のシステムがある場合。MDMが適しているかどうかの判断は、システムがクラウドにあるかオンプレにあるかに関わらない。
「システムオブレコード」とは、あるデータに関して「このシステムが正ですよ」という取り決めのこと。どのシステムをシステムオブレコードにするかは、関係者を集めてデータフローを確認し、話し合いで合意する。
システムオブレコードは、オブジェクト、項目ごとに、1つのみ決めるべき。「取引先の『電話番号』はシステムAが正で、『メールアドレス』はシステムBが正ですよ。」という具合に。システムオブレコードでデータが更新されたら、ほかの全システムに変更が波及できるようにするのが良いアーキテクチャ。MDMは更新を伝えるためのハブとして機能する。
MDMツールは、色々なシステムオブレコードからデータを集めてきて「Source of Truth（唯一の真のソース）」を構築する。同じような意味で「顧客の360度ビュー」という言葉も使われる。MDMは他のシステムの下流にあるので、システムオブレコードではない。
おそらく、厳密には間違っている点や、ほかに理解するべき点がたくさんあるのだと思いますが、試験対策としてはこのくらいの理解で十分でした。
メタデータ管理
メタデータ管理についても、概念として理解するためによいマテリアルをTrailheadなどで見つけることができませんでした。問題集が役立ちました。
事前学習で押さえておいたキーワードは、「メタデータAPI」「イベントモニタリング」「設定変更履歴」「カスタムメタデータ型」などです。
データアーキテクチャに関するドキュメント作成において、メタデータAPIで取得できるXML形式のメタデータが活用できることを頭に入れました。データアーキテクチャに関するメタデータには、「カスタムオブジェクト」「カスタム項目」「レコードタイプ」「ビジネスプロセス」「ページレイアウト」があることを覚えました。
ユーザのログインやページ読み込みなどを監視するには「イベントモニタリング」を使うことを覚えました。また、カスタムオブジェクトの設定変更などを監視するには「設定変更履歴」を使うことを覚えました。
カスタム設定と比較した、カスタムメタデータの利点として、「パッケージにデータを含めて、アプリケーションと一緒に別の組織へ配布できる」という点を押さえました。
データアーカイブ
データアーカイブについては、「エクスポートウィザード」「データローダ」「項目履歴管理」「レポート作成スナップショット」などのキーワードを押さえました。
Salesforceでは組織ごとに10GB + ユーザ数に応じた追加分のデータストレージが割り当てられています。レコードデータがこの上限容量を超える可能性がある場合に、物理アーカイブが必要になります。
項目履歴管理で追跡できる項目数は、オブジェクトごとに20個が上限であり、これより多くの項目を追跡するには、Apexトリガなどでの開発が必要になることを押さえました。
古いデータを保存する場所の選択肢として、元データと同じ形式のまま保存するにはデータウェアハウスが必要になりますが、「集計値だけでよい」「レポートで見たい」という要件の場合は、レポート作成スナップショットで集計値をカスタムオブジェクトに保存すればよいことを理解しました。
バッチ処理ではなく、特定のイベント（商談が成立したとき、など）をトリガにして外部システムへのデータ保存したい場合もあります。このような要件では、ワークフローでのアウトバウンドメッセージアクション、もしくはApexトリガでのコールアウトのどちらかが選択肢になることを押さえました。
データガバナンス
Trailmixで紹介されている Data Governance & Stewardship を読んで、データガバナンスやスチュワードシップに関する概念を理解しました。
データガバナンスプログラムの流れ（たとえば、初期フェーズでは、「スポンサーに戦略やゴールを確認する」「エンドユーザにデータの使用状況を確認する」「データの品質を評価する」など）を大まかに頭に入れました。
ここでも問題集でなければ得られなかった知識がありました。たとえば、「データガバナンスチームには、データスチュワードとデータ分析責任者を含める必要がある」「データアーキテクトは、冗長なメタデータ、共有モデル、必須項目と入力規則、を確認する必要がある」などです。
ビジネスインテリジェンス、レポート & 分析
レポートやダッシュボードの基本的な機能は理解していたため、事前学習はあまりしませんでした。
ユーザにアドホックなフィルタ条件を指定させる必要があるなど、標準のレポートやダッシュボードで対応できない要件がある場合は、Einstein Analyticsが候補になることを押さえました。
データ移行
組織の規模に応じたレコードアクセス権の作成 と、Trailhead の大量データ モジュールの内容を頭に入れました。
試験でもこれらの内容が役に立ちました。
パフォーマンス調整
大量のデータを使用するリリースのベストプラクティスと、Trailhead の大量データ モジュールを読んで頭に入れました。
また、標準インデックスはどの項目についているか、カスタムインデックスはどういう項目につけられるかを把握しておきました。
SOQLクエリがセレクティブになる条件については、Query & Search Optimization Cheat Sheet などを読み、「最初の100万レコードの30%」などいくつかのポイントとなる閾値を頭に入れておきましたが、試験では具体的な条件に関する問題はありませんでした。
まとめ
今回 Data Architecture and Management デザイナー試験を受験した主な動機は、アプリケーションアーキテクト資格取得に必須だから、という理由でしたが、事前学習を通して、様々な重要な概念を学ぶことができました。
「データ品質や管理方法に問題があって、せっかく収集したデータをうまく活用できない」というのは、個人的にも日常的によく直面する課題でしたが、それに対してどのようなアプローチやツールを適用できるのか、体系的に学ぶことができました。
もう一つの大きなテーマである、大量データのパフォーマンスに関する問題は、私にとっては日常業務であまり直面することはありませんでしたが、Salesforceのマルチテナントアーキテクチャがどのようになっているか知るための、良い機会となりました。
アプリケーションアーキテクト取得を目指している方だけでなく、データの管理や品質について課題意識を持っている方、大量データを扱う方にとっては、お薦めできる資格だと思います。