Twitterに投稿したことを忘れないうちに補足。
他のかたのソリューションをジャッジ目線で採点すると、自分にも至らぬところが見えてくるな。勉強になる。
— Hiroki Iida (@hiroki_iida_) 2023年1月14日
「もっと、こう、こんなふうに書いてくれたらいいのに」的な。
具体的にどういうことかというと、私を含め「受験者側がやりがちな振る舞い」と、「採点者側の目線・期待値」とは、ずれることがあるだろうな、というもの。もちろん私の想像なのですが。
受験者側がやりがちなふるまい
以前の投稿でも紹介したとおり、レビューボード試験では、限られた時間のなかでシナリオを読み込んで、自分が提案するソリューションを書き上げます。
提案ソリューションの全体像を示すために、「ランドスケープ図」を描きます。例えばこの図では、こんなことを意識するようにしています。
- ランドスケープ図で気を付けていること
- 現行システム、提案する新システムを記載
- 現行システムには廃止や改修するシステムを明示
- Salesforce Platform で実現できることと、外部システム（AppExchange、ミドルウェア、認証プロバイダ、HerokuとかAWSとか）で実現することを明示
- 連携するルートは線で表明
- 凡例も忘れずに
もちろん、他にも書き示したいことはたくさんたくさんあるのですが、時間との闘いになります。
こういった要領で、データモデルやロール階層、そのほか必要と考えたダイアグラムを描き示していきます。
並行して、シナリオ（10ページほどのテキスト）にはソリューションを書き込んでいきます。 文章の形で要件が詰まっているので、それを読み解いて、おおよそどんなソリューションを提案するかを考えてメモしていきます。ここでも時間との闘いで、書き込めるのはメモ程度。プレゼンのときにメモを頼りに前後を埋めてソリューションを説明します。
要件が、「注文が確定したら、ERPで請求する必要があります」だったら、新システム（Salesforce側）の注文の情報をERPに連携することを提案します。要件はなにか。制約はなにか。処理の契機はなにか。インテグレーションのどのパターンを採用するか。などなど。システム連携の内容をメモしておきます。
ひとつひとつは普段のシステム構築のときにも常々考えていることなので、業務の全体像や、ひとつひとつの連携の重要性が把握できれば、そんなに難しいものではないです。 難しいものではない、はずなのですが、シナリオへの書き込みは「その個所に示されたひとつの要件の実現方法」になりがちです。
ただ、これだけでは採点者側の目線・期待値はみたせないのではないか、というのが気づきでした。
採点者側の目線・期待値（妄想）
たとえば、インテグレーションの範囲の採点トピックはこの4つの観点です。
- インテグレーション概観を推奨し、関連リスク、トレードオフ、その他考慮事項が述べられているか
- 適切な技術の機能を説明し、全体的なインテグレーションアーキテクチャの一部として使用することの妥当性の根拠が示されているか。
- 適切なインテグレーション戦略とインテグレーションパターンを推奨し、妥当性の根拠を示せているか。
- プラットフォーム固有のインテグレーション技術を推奨しているか。
採点者となった場合には、これらの観点で受験者のソリューション（図、テキストの書き込み、プレゼン）を評価することになります。
「インテグレーション概観を推奨」は、受験者のソリューションに示されていたでしょうか。それは、正当性（Justification）のあるものでしたでしょうか。
「関連リスク、トレードオフ」は、受験者のソリューションに示されていたでしょうか。
「全体的なインテグレーションアーキテクチャの一部として使用することの妥当性の根拠」は、示せていたでしょうか。
『「木を見て森を見ず」ではなく「木を見て森も見る」』は、2022/6/30 Salesforce Live の 模擬レビューボード会のときにいただいたアドバイスのひとつです。システム思考でも言われる言葉かと。受験者として、もちろん森（全体最適）も考えてソリューション選択しているつもりですが、それをソリューションとしてダイアグラムやソリューションテキストに表明できていたか。振り返ると十分ではなかったかと思います。
おすすめ。ほかのかたのソリューションを採点してみること。
こうして、採点トピックに照らしてソリューションを眺めてみると、改善の余地はありそうです。なのですが、自分が作成したソリューションを眺めていてもなかなか気づかないように思います。自分のなかでは、全体も部分も繋がっていますので違和感を感じることが難しい。
そこでおすすめなのが、ほかのかたのソリューションを採点してみることです。スコアカードを手元において、「この項目を加点するには、ソリューションのどこをどう解釈したらよかろうか」「ソリューションとしては妥当なものが記載はされているけど、選択した根拠が知りたい（プレゼン聞こう、QAしよう）」など。 と、やってみると、前の節で書いたような、「ダイアグラムやソリューションテキストだけでは表明されづらい採点項目」があることが見えてきました。私の場合、その一つが「全体像・概観」でした。ソリューションを検討したときに検討しているはずですよね。これをきちんと表明できていると、採点する側も採点しやすいはず（※個人の考えです）
やりかたは、プレゼンに盛り込むのか、テキストに書くのか、図を描くのか、いろいろあると思います。
ここまで、インテグレーションのトピックを取り上げて言及しましたが、ほかの分野にも似たようなことが言えそうです。
普段の提案・システム構築でも同じことがいえますが、提供者目線だけではよくないですね。がんばっていきましょうー
補足
レビューボード試験に求められることは受験ガイドに記載されています。
レビューボードのサンプルシナリオ、練習用スコアシートは、Trailblazers Communityに公開されています。