Salesforceの変更を頼む前に、要件をまとめる方法

1. 作りたい機能より、業務の課題から書く

Trailhead では、ビジネスアナリストが最初に行うのは、戦略的に重要なビジネスニーズを特定することだとしています。このニーズが、その後の作業全体の指針になります。依頼の文書も、作りたい画面や項目からではなく、どの業務で何に困っているかから書き始めます。[1]

課題を書き出すときは、誰が・何を・どこで・なぜ・いつ・どのようにの問いを使います。「誰がこの作業をしているか」「解決したい問題は何か」「入力した情報はどこへ行くか」「週に 1 回か、毎月 1 日か」「今はどう動いていて、本来はどう動くべきか」といった問いです。[1]

決まった手順を「この通りに作ってほしい」と頼みたくなったときも、その手順がなぜ要るのかを一度確かめます。Trailhead では、理由を問わずに指示に従うことを誤りとし、要望の裏に危険が潜んでいないかを確かめるよう勧めています。[3]

今の状態と目指す状態を並べて差を書き出す方法は、ギャップ分析と呼ばれます。差が見えると、何を変えれば課題が解けるかを話し合いやすくなります。[1][2]

2. 関係者を洗い出す

ステークホルダーは、意思決定をしたり、優先度や要件を決めるうえで大きな役割を持ったりする、社内外の人やグループです。Trailhead では、早い段階で特定することが欠かせないとし、課題に関心がある人と、影響を受ける人すべてを出発点にするよう案内しています。[1]

関係者を分析する文書では、次の 3 つを書き出します。[2]

• 業務の課題を理解するために、誰と話す必要があるか[2]
• 要件を具体的にするために、誰が協力してくれるか[2]
• 違う見方を教えてくれるのは誰か[2]

役割は RACI チャートで分けておくと、誰が何に責任を持つかが一目で分かります。実行する人、結果に最終的な責任を持つ人、意見を求める人、決まったことを知らせる人の 4 つです。[2]

ほかの部署への影響も確かめます。1 つのチームのための変更が、別のチームのできることを狭めることがあるためです。影響を受けそうなチームは、早めに話し合いに加えるよう勧められています。[3]

返事が早い人の声だけで要件を固めないことも大切です。話しやすい人が、最も大事な優先事項に関わる人とは限らないためです。[4]

3. 今の業務の流れを見える化する

要件を出す前に、今の業務がどう流れているかを図にします。ビジネスプロセスマップは、業務の手順、誰が何をするか、成功をどう測るかを表した図です。[10]

流れは、使っているアプリではなく、何が入って何が出てくるかで捉えます。たとえば「問い合わせを受けてから、ケースを閉じるまで」のように、始まりと終わりを決めます。Salesforce の画面だけで業務全体が回っているとは限らないため、手作業や別のアプリの工程も含めます。[5]

最初から会社の中心の業務を描こうとせず、範囲が狭く関係者が少ない流れから始めるよう勧められています。各手順には動詞を入れ、誰が担うかを書きます。[5]

下書きは、手元の資料や研修資料から作ります。その後、実際にその作業をしている人に見てもらい、抜けや誤りを直してもらいます。この場では、今の流れへの不満や、非効率の原因が出てきやすいとされています。[4]

社内でしか通じない言葉が出てきたら、その場で意味を確かめ、用語集にまとめます。要件も現場の言葉で書くと、現場の人が読んで確かめられます。[4][2]

4. ユーザーストーリーと受け入れ条件を書く

ユーザーストーリーは、使う人の立場から機能を短く書いたものです。型は「〈誰〉として、〈なぜ〉のために、〈何〉が必要です」です。要件のすべてを書くものではなく、全体の姿をつかむためのものです。[6]

「誰」には、Salesforce の中での役割を入れます。書き始める前に、使う人の役割の一覧を作っておくと、「誰」があいまいになりません。[6][7]

例：「サポート担当として、問い合わせに早く応えるために、新しいケースを自分の担当にして、顧客にメールを送れることが必要です。」[6]

各ストーリーには、受け入れ条件を 1 つ以上付けます。受け入れ条件は、ストーリーが満たされたかどうかを、合格か不合格かで判定できる文です。1 つずつ単独で確かめられ、はいかいいえで答えられる形にします。[7]

受け入れ条件には、作り方ではなく、できるようになることを書きます。Trailhead の例では、「[承認/却下] ボタンを押して割引を承認できる」は作り方に寄った書き方で、「地域マネージャーが割引を承認または却下できる」が適した書き方とされています。[7]

書いたストーリーは、INVEST の観点で見直せます。独立している、交渉できる、価値がある、見積もれる、小さい、テストできる、の 6 つです。どれかを満たさないときは、書き直しを考えます。[7]

5. ニーズ・ウォンツ・期待で優先度を付ける

関係者自身も、何が必要で何が欲しいのかをはっきり分かっていないことがあります。Trailhead では、要件を次の 3 つに分けて優先度を付ける方法を紹介しています。[8]

• 区分 1ニーズ必須の要件です。範囲の最初の定義になり、最も優先します。[8]
• 区分 2ウォンツあると望ましい要件です。範囲が大きくなりすぎたときは、話し合いで外したり後に回したりします。[8]
• 区分 3期待関係者が思い描く姿です。どの機能で、いつ、どう価値を出すかを含みます。聞き出すと、ニーズやウォンツが増えることがあります。[8]

範囲を確かめるには、枠を 1 つ描き、範囲に入れる要件を枠の中に、入れない要件を枠の外に書く方法があります。枠の中にないものは範囲の外です。[8]

部署の間で優先度がぶつかったときは、両方を取ることはできません。依頼する側の組織の誰かが選び、その決定を作業に入る前に済ませます。[3]

承認を得ない変更が範囲に入り込むことを、スコープクリープと呼びます。範囲を変えるとスケジュールと費用にも影響するため、途中で増えた要望は、日付と依頼者を残す変更要求ログに記録します。[8][2]

6. テストと受け入れの確かめ方を決める

受け入れ条件がはっきりしていると、テストする人が何を確かめればよいかが分かります。テスト計画、テストケース、ユーザー受け入れテスト計画も、ビジネスアナリストが作る文書として挙げられています。[7][2]

テストは本番組織ではなく Sandbox で行います。Sandbox は本番組織から切り離されているため、そこでの操作は本番に影響しません。公式ヘルプでは、2026年10月時点で、Partial Copy Sandbox をユーザー受け入れテストなどの品質保証の作業に使うよう案内しています。[9]

想定どおりの操作だけでなく、利用者がつまずきそうな例外の場面も試します。作った人は仕組みを知っているため、説明をせずに別の人に触ってもらい、その様子を見る方法も勧められています。[3]

新しい機能に加えて、変わっていないはずの既存の関連機能も確かめます。仕組みどうしがつながっているため、1 か所の変更が別の場所に影響することがあるためです。[3]

3 で描いた今の流れと、変更後の流れを並べておくと、何が良くなったかを関係者に説明しやすくなります。[4]