Salesforceの改善の計画（ロードマップ）の立て方

ロードマップは何のために作るか

Trailhead は、Salesforce を社内の「製品」として扱い、ビジネスに価値をもたらすよう管理することを、システム管理者の役目の一つに挙げています。肩書きに関係なく、管理者は自社の組織の製品管理者だという考え方です。[1][7]

ロードマップは、関係者全員が見る情報の中心です。何を、いつ届けるかを一か所にまとめ、チームの向きをそろえるために使います。[5]

作る順序は、要望を集めて一覧にする、優先度を付ける、リリースの時期に当てはめる、関係者に伝える、定期的に見直す、の流れになります。[1][5]

要望を集めて一覧にする

まず、要望を受け付ける窓口を決めます。Trailhead では、利用者は管理者が決めたチャネルで依頼し、依頼はバグ・質問・機能要求に分かれるとしています。[2]

集めた要望は、バックログと呼ばれる一覧に書きためます。今すぐやる作業の一覧ではなく、将来やるかもしれない作業の候補を残しておく場所です。[3]

• 書き方：動詞から始め、誰かが手に取れるくらい具体的に書きます。だれが言ったか、どの困りごとを解くかも添えます[3]
• 集め方：多くの利用者から声を集めるにはアンケート、背景を深く聞くには利用者の委員会での聞き取りが役立ちます[4]
• 決める人：だれが一覧に足し、だれが優先度を決めるかを、チームや上の立場の人と先にそろえておきます[3]

使用状況のデータから改善すべき点を見つけることも、製品管理の責務に含まれています。声の大きさだけで一覧を作らないためにも役立ちます。[1]

優先度の付け方

• 方法 1価値と手間要望ごとにビジネスへの影響と実装の手間を高・中・低で付け、両方を見て並べます。Trailhead の例では、この形で導入する機能の一覧を作ります[4][5]
• 方法 2確信度を加える価値と手間に、期待した効果が出るとどこまで言えるかを足して考えます。手間には時間のほか、別の案をあきらめる分も含まれます[5]
• 方法 3MoSCoW必須・望ましい・あればよい・今回はやらない、の 4 つに分けます。何が欠かせず、何を待てるかをはっきりさせます[3]
• 方法 4RICE影響する人数、効果の大きさ、確信度、手間を点数にし、前の 3 つを掛けて手間で割ります。手間が少なく価値が高いものを見つけやすくなります[3]
• 方法 5重み付けの採点戦略との合い方やリスクの減り方など、自社が大事にする基準に重みを付けて点数を出します[3]

年 3 回のリリースと合わせる

Salesforce の新機能は、Spring・Summer・Winter の年 3 回のリリースで届きます（2026年10月時点）。プレビューの対象にした Sandbox は、本番より 4〜6 週間前に新しいリリースへ上がります。そうでない Sandbox は今の版のまま残ります。[6][7]

Trailhead は、次の 2〜3 回分の Sandbox と本番のリリース日を調べてカレンダーに書き、そこから逆算して計画を立てるよう勧めています。必要な技術の担当者を押さえるためにも、早めに動き始めます。[6][4]

新しいリリースの機能にも、価値と手間の考え方を当てはめます。良い新機能の多くは初めから有効ではなく、管理者が有効にして設定する必要があります。[7]

全部を初日に入れる必要はありません。価値が高くても手間が大きい機能は、手早く出せるものを先に届けた後の 2 回目の段階に回す、という分け方も示されています。[7][4]

関係者への共有

ロードマップは、目指す姿と、そこへの進め方の両方を伝えるものです。細部を詰め込みすぎないよう注意します。[1][5]

関係者とは継続的につながり、だれが何を担当しているかを見えるようにしておきます。一覧のすべてを全員に見せる必要はありませんが、ある程度見せると、要望が放っておかれていないことが伝わります。[5][3]

リリースに合わせた伝え方も分けて考えます。本番の更新前には管理者や開発者のチームに、更新後には利用者に、変わる点を伝えます。[7]

計画の見直し

ロードマップは定期的に見直し、必要に応じて直します。古いままでは、関係者が今どこにいるかを見失います。中身は変わるものと考え、柔軟に保ちます。[5]

一覧の見直しは、毎月や四半期ごとなど、日を決めて行います。重複を消し、足りない背景を書き足し、着手できるものに印を付けます。[3]

どの要望にも同じ優先度の決まりを当てはめると、進め方が公平で分かりやすくなります。見送った要望は、その理由も書き残します。[3]