組織・運用定着

CRMの見直しは、要件定義書の前提を読み直す

用語

CRM（顧客管理システム）
SFA（営業支援システム）
MA（マーケティング自動化ツール）

公開 2026年11月6日

導入から1年。要件定義書を、最後に開いたのはいつでしょうか。

私が導入を支援する仕事では、離れるときに設計書と項目の定義を残します。そのあともCRM（顧客管理システム）が使われ続けている会社はあります。

ただ、使われ続けていることと、いまの事業に合っていることは別の話です。

事業は導入のあとも変わります。売る相手が変わり、売り方が変わり、担当者が変わる。前提が動いても、記録の仕組みは導入した日のまま、ということが起きます。

CRMの見直しは、項目の棚卸しからではなく、要件定義書に書いた前提を読み直すところから始める。 動いた前提が分かれば、直す場所は思ったより少なく済みます。

この記事が対象にするのは、導入から1年以上たち、入力は続いているのに「最近このCRM、使いにくいね」と言われ始めた会社です。入力そのものが続いていないなら、先に「SFAが定着しない理由は、入力の手間ではなく使い道」を見てください。

入力が続いていても、設計は古くなる

古くなった設計は、止まらずに回り続けます。だから気づきにくい。

症状が出るのは、CRMの外です。

会議の前に、CRMから書き出して手で直す表が増えている
選択肢の「その他」が増え、メモ欄に同じ種類の情報が書かれている
新しい担当者が、どの項目を入れるのかを先輩に聞いている

どれも個別に直せそうに見えます。項目を足す。研修をやり直す。

ただ、原因が前提の変化なら、足した項目もいずれ同じように古くなります。

数字を1つだけ置きます。キーウォーカーの調査（2025年10月実施、n=1,034、SFA・CRM・BIツールの導入済み企業の営業部門の現場担当者と管理職、複数回答）では、入力の動機付けになる要素の最多は「入力の目的やデータの使い道が明確」54.8%でした。

BIツールの導入支援をしている会社の自社調査で、導入時に決めた使い道がいまも生きているかまでは聞いていません。

調査で言えるのは入力の動機までです。見直しの入口を前提に置くのは、私の判断です。

読むのは機能の一覧ではなく、その裏にある4つの前提

要件定義書には、機能と項目が並んでいます。ここを1行ずつ確かめても、「実装した」「していない」の確認にしかなりません。

読むのは、その要件を成り立たせていた前提です。多くは次の4つに分けられます。

前提	導入時に置きがちなこと（例）	動くきっかけ（例）	直す場所の候補
売る相手	中小企業の部門長が決める	大企業へ広げた、業種を絞った	会社の区分、レポートの切り口、MA（マーケティング自動化ツール）のスコアと配信リスト
売り方	自社の営業が直接売る	販売代理店が増えた、年間契約を始めた	パイプライン、ステージの定義、更新の扱い
担当	営業が全件を入力する	分業を始めた、CRM管理者が替わった	入力する人、通知と自動化の宛先、権限
数字を使う会議	週次の営業会議で受注見込みを見る	会議が変わった、経営の見る数字が変わった	レポート、必須項目

要件定義書が見つからない会社もあるはずです。その場合は、いまの設定から逆に書きます。

ステージ、必須項目、主なレポートを開いて、「これはどんな売り方を前提にしているか」を4行にする。完璧でなくて構いません。読み直す相手がある状態を作るのが目的です。

4行は記憶ではなく、直近の受注10件と並べる

進め方は3段です。下書きはCRM管理者、判定の合意は営業の責任者が持ちます。直す場所がマーケ、カスタマーサクセス、経理の使う項目や連携に及ぶなら、その持ち主も判定に入れます。

導入時の4行を書く。 要件定義書か、いまの設定から書き起こします。1行は短く、例の表くらいの粒度で十分です
直近の受注を10件開き、いまの4行を書く。 誰が決めたか、どの経路で来たか、契約の形はどうか、誰が入力したか。会議で聞く前に、記録から書きます。「うちは変わっていない」という記憶は、前提の変化をいちばん見落としやすいからです。売る相手と売り方の行は、失注と進行中の商談も数件見ます。広げようとして負けている相手は、受注には出てこないからです。数字を使う会議の行だけは取引の記録に載らないので、直近の会議資料と、実際に開かれたレポートから書きます。10件は傾向を掴むための数で、統計ではありません。1年で10件に満たなければ全件で構いません
営業の責任者と並べて、1行ずつ判定する。 「同じ」「変わった」「不明」の3つです。次へ進めるのは「変わった」の行だけ。「不明」は記録が足りないという発見なので、担当の営業に1件ずつ短く聞いて決めます

変わった前提1つにつき、直す場所を1つだけ決める

4行のうち3行が変わっていても、一度に全部は直しません。何が効いたのか分からなくなり、現場も同時に多くは変えられないからです。直すのは1四半期に1行。残りの行は決定の記録に載せ、次の四半期の切り替わりで直します。

どの行から直すかは、会議で決めます。変わった行のうち、いま会議の判断がいちばん止まっている行からです。どの行でも、最初に聞くのは「その数字を、どの会議で何に使うのか」です。使う場が決まれば、要る項目が決まります。

たとえば、販売代理店経由の受注が増えていたとします。ここで代理店用のパイプラインを足したくなりますが、先に「経営会議で何を見たいのか」を確かめます。

見たいのが直販と代理店の受注見込みの内訳なら、取引に「販売経路」の項目を1つ置けば足りるかもしれません。項目を足した場合、過去は空欄です。進行中の取引だけ埋め、内訳は切り替え日以降を読みます。パイプラインを分ける判断には別の代償があることは、「パイプラインを部署ごとに分けた結果、全社の予測が作れなくなった」に書きました。

大企業へ広げて承認の段が増えた場合も、ステージは増やしません。承認の段は、取引の項目「決裁の進捗」1つで持ちます。

直す前に、次の3つを押さえます。

その項目やステージを読んでいるものを洗い出す。 レポート、リスト、自動化、外部連携です。手順は「CRMの項目を半分に削るとき、消す前に確かめること」と同じです
切り替えは四半期の切り替わりに置き、日付を記録する。 受注・失注済みの取引は書き換えず、切り替え日より前は旧定義として読みます。進行中の取引は、切り替え日に新しい定義で振り直します。ステージを減らすのはこのときだけにします。設定を変えると確度や滞留日数の集計にも響くので、自動化と合わせて前日に確かめます
新旧の数字を並べる。 受注見込みのように毎週比べる数字は、切り替えの直前に旧定義の数字を表に保存し、前後1四半期を並べます。考え方は「リード数の定義が部署ごとに合わないときの揃え方」と同じです

読み直す持ち主は検収の日に、過ぎていれば今回決める

要件定義書が読み直されない理由は、怠慢ではないと思っています。持ち主がいなくなるからです。

要件定義書の持ち主は、導入プロジェクトです。プロジェクトは検収で解散し、支援会社も約束の範囲で終わります。私もそうです。設計書は残せても、読み直す人までは残せません。

だから検収の日に、次の3つを決めます。決めるのは導入責任者と、予算を承認した役員です。検収が済んでいる会社は、今回の判定の最後に、営業の責任者といま予算を持つ役員で決めます。

持ち主を、人ではなく役職で決める。 営業企画の責任者、のように。個人名にすると異動で消えます
読み直す時期を、来期の予算を組む前に置く。 年1回で足ります。直す費用を来期の予算に載せられる時期だからです
臨時で読み直す出来事を決めておく。 新しい製品や料金、販売経路の追加、組織の変更、CRM管理者の交代です

定義の調整は、これまでの記事で「見るのは毎週、変えるのは四半期の切り替わり」と書いてきました。それは前提が同じ間の調整です。年1回の読み直しは、その前提自体を疑う作業なので、別に置きます。

推進役が替わるときに何を渡すかは、「「上が決めたから」で入れたツールは、推進役の異動で止まった」に書きました。読み直しの予定も、渡すものの1つに入れてください。

採らなかった案

全項目の棚卸しから始める案。 入力されていない項目は見つかります。ただ、棚卸しで見えるのは今ある項目だけで、前提が動いたせいで足りなくなったものは出てきません。減らす作業は、4行を読み直したあとに回します。

CRMを入れ替える案。 使いにくさの原因が前提の変化なら、新しいCRMにも古い前提を移すことになります。乗り換えを検討するとしても、この4行は最初に要る材料です。

CRMの見直しは、項目の棚卸しではなく導入時の前提を読み直すことから始める。売る相手・売り方・担当・数字を使う会議の4行をいまの事実と並べ、変わった前提ごとに直す場所を1つだけ決める。読み直す持ち主は検収の日に、過ぎていれば今回の読み直しで決めます。

導入から1年以上たっているなら、今週、直近の受注を10件開いて「売り方」の1行だけ書いてみてください。要件定義書と同じなら、それはそれで安心できます。