「一応、新規構築です」「触ってみたら、もう結構いろいろ動いてました」

この7つは順番に消化する手順ではなく、着手前に並行して確認しておくべき独立した観点です。

着手前ヒアリングでそのまま使える監査シートのフォーマットです。観点ごとに1行以上使って埋めてください。

• エディション（Professional／Enterprise／Unlimited等）
• APIアクセス可否
• 追加ライセンスの増枠余地

• Sandboxの有無と種別（Developer／Partial／Full）
• 本番直接作業か、Sandbox→本番リリースフローがあるか
• 将来的な環境分離の予定（マルチorg化等）

新規構築に見えても、実際にはゼロからではなく既存orgへの追加であることが少なくありません。ここを飛ばすと、後工程で「実は使われていた機能を壊した」という事故につながります。

ここで一つ、先に反論しておきます。「新規構築の見積もりなのだから、既存orgの調査はスコープ外では」と思うかもしれません。契約上はその通りかもしれませんが、既存orgの現状把握を飛ばして着手した場合のリスクは、結局その後の手戻り工数として跳ね返ってきます。着手前の数時間の調査を惜しんで、後工程で数日分の手戻りを払うのは、多くの現場で割に合わない選択です。

• そもそも誰がどんな用途で使っていたか
• 現在稼働中のオブジェクト・レコード件数の規模感
• AppExchangeパッケージの導入有無（管理パッケージは削除・変更に制約がある）
• Apexコード（トリガー・クラス）の有無
• 入力規則・数式項目の設定状況
• 稼働中のフロー・プロセスビルダー・ワークフロールールの有無と内容
• 外部システムとの連携状況（API・CSV・middleware等）
• 既存レポート・ダッシュボードの利用者と用途

• 現状のプロファイル・権限セット構成
• 組織の共有設定（OWD）とロール階層の設計有無
• 共有ルールの有無
• IP制限・多要素認証等のセキュリティ設定
• 外部ユーザー（パートナー・顧客）アクセスの有無
• 他部門・他事業からのデータ可視範囲

• 標準オブジェクトの利用状況（取引先・取引先責任者・商談・リード・商品等）
• カスタムオブジェクトの有無と用途
• フロートリガーとなっている項目の特定
• 書き換えると困る項目・データの特定
• 重複ルールの設定状況

• レコードの重複状況
• 項目の入力率・データ欠損の状況
• 表記ゆれ・データ不整合の状況
• 過去データの退避・保全方針

データ品質の確認を後回しにすると、せっかく構築した自動化やダッシュボードが「元データが汚れているせいで数字が信用できない」という状態に陥ります。着手前の早い段階で、少なくとも主要オブジェクトの入力率だけでも確認しておく価値があります。土台が傾いた家に立派な内装を入れても意味がないのと同じで、データ品質を確認しないまま自動化やレポートを積み上げても、最終的に見る数字そのものが信用できません。

• 現在の社内システム管理者は誰か
• 変更管理のルール・承認フローの有無
• 外部パートナーへの作業権限付与の前例有無

既存orgの現状把握は、具体的に誰に何を聞けばいいですか

現行の管理者・主要な利用部門の担当者それぞれに、稼働中のフロー・外部連携・よく見るレポートを個別にヒアリングするのが実務的です。管理者だけに聞くと、現場が独自に作った運用や、管理者が把握していないシャドー利用が漏れることがあります

AppExchangeの管理パッケージがあると、何に困りますか

管理パッケージ（Managed Package）は提供元がロックした部分があり、項目の削除や一部設定変更に制約がかかります。既存orgに管理パッケージが入っている場合、それを前提に構築方針を立てる必要があり、着手前の確認を飛ばすと設計をやり直すことになりかねません

データ品質のチェックは、どのくらいの粒度でやればいいですか

着手前の時点では、主要オブジェクト（取引先・商談等）の必須級の項目について、入力率と重複レコードの概算を掴む程度で十分です。詳細な名寄せ・クレンジングは、構築方針が固まった後の別工程として扱うのが現実的です

着手前に、この7観点のうち何個を実際に確認しましたか。「新規構築だから」という理由だけで既存orgの調査を省略した項目があるとしたら、それは本当に何もない場所への構築だと確認した上での省略でしょうか。