データ・KPI

システム導入の効果測定は、稼働前の数字で決まる

用語

CRM（顧客管理システム）

公開 2026年10月24日

下半期の予算で、新しいシステムを入れる。半年後の経営会議で「で、何が変わったの」と聞かれる。

答えに詰まるのは、稼働後の数字が無いからではない。比べる相手になる、稼働前の数字が無いからだ、というのが私の見立てです。

測ること自体が後回しになりやすいのは、調査にも表れています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査2026」（2025年度調査、東証上場企業とそれに準じる企業957社が回答）では、言語系の生成AIの効果測定を聞いた設問（n=507）で、「効果測定は行っていない」が51.9%でした（前年は59.8%）。回答企業全体のうち、「削減できた労働時間の測定」をしているのは39.4%、「金額的な効果の測定」は6.5%です。

この設問が聞いているのは生成AIで、稼働前の数字を取ったかどうかまでは聞いていません。上場企業層の数字なので、中小企業にもそのまま当てはまりません。言えるのは、いま最も注目されている投資でも、半数ほどが効果を測っていないというところまでです。

稼働してから測ろうとすると、比べる相手がもう残っていない

新しいCRM（顧客管理システム）のレポートが持っているのは、稼働した日から後のデータだけです。

稼働前の業務は、Excel、メール、担当者の頭の中にありました。後から再現しようとすると、出てくるのは「前は見積に2日くらいかかっていた」という記憶です。2日だったのか4日だったのか、誰にも確かめられません。

定義も変わります。新しいシステムで「商談」や「リード」の数え方が変われば、業務が何も変わらなくても数字は動きます。前後で同じものを数えていなければ、差は効果ではなく定義の違いです。

「営業AIの時間削減は、行き先を決めないと社内に吸われやすい」では、導入前とは比べず、同じ時期のチーム同士で比べると書きました。あの指標は、稼働前の記録が後から作れないものだったからです。稼働前の記録を残せるなら、残しておくほうが話は早い。この記事は、その残し方です。

削減時間は報告しやすいが、経営会議の問いには届きにくい

JUASの調査で、測っている取り組みの中で「削減できた労働時間」が最も多かったのは自然なことです。導入した側が報告しやすいからです。

調査は、その時間をどう測ったかまでは示していません。ただ削減時間は、「1件あたり何分短くなったか × 件数」の推計でも出せてしまう指標です。稼働前の実測が無くても報告できる。しかも、浮いた時間がどこへ行ったかは教えてくれません。

だから測るのは、使った時間ではなく、業務の結果として残る日数や件数にします。

ただし、これは業務が変わったかの報告であって、受注や売上への効果ではありません。「問い合わせから初回連絡までが2日縮んだ」を、そのまま投資効果として報告しないことです。入口の変化と受注への効果を分けて報告する理由は「入口の数字で「効果が出ています」と報告すると、翌月に訂正が必要になります」に書きました。

業務を1つに絞り、1件の定義と、稼働後も残る記録を決める

導入を決めた時点で、次の3つを決めます。作業は導入プロジェクトの事務局、業務の選び方は予算を承認した役員と導入責任者の合意です。

変える業務を1つだけ選ぶ。 「問い合わせから初回連絡まで」「見積の依頼から提出まで」のように、始まりと終わりがあり、月に数十件は起きる業務にします。月次の締めのように月1回しか起きない業務は、件数が集まらないので向きません。「営業の効率化」は業務ではありません。1つに絞るのは、何が数字を動かしたのかを後から追える粒度にするためです
1件の定義と、除外するものを1行で書く。 同じ会社からの2度目の問い合わせは1件か、見積の出し直しは数えるか、営業メールや採用の問い合わせは外すか。ここが前後でずれると、比べる意味がなくなります
始点と終点を、稼働後も残る記録で決める。 稼働前は、問い合わせメールの受信日時や、見積書を送ったメールの送信日時から取ることが多いはずです。ところがCRMを入れると、問い合わせはフォームに、見積はCRMの見積機能に置き換わり、その記録自体が無くなることがあります。だから導入責任者に、稼働後の設計で同じ始点・終点がどの日時項目に残るかを先に確かめます。残らないなら、稼働前に項目を用意してもらいます。並行稼働の期間があれば、同じ案件を旧来の記録とCRMの日時の両方で取り、ずれが無いことを確かめてから切り替えます

測るのは移行作業の前、拾うのは事務局が見られる記録から

測る期間は、移行作業や研修が始まる前の4週間に置きます。稼働直前は、データ移行の確認や研修で現場がふだんと違う動きをしていて、その数字は比べる土台になりません。4週間にするのは、月末を1回含めるためです。

件数は数十件で足ります。目的は、桁と分布を知ることです。現場に新しい記録は頼まず、事務局が拾います。拾う先は、共有の受信箱や共有フォルダのように、事務局がもともと見られる記録を優先します。個人のメールボックスにしか無い場合は、本文ではなく日時の一覧だけを担当者に出してもらうか、情報システム部門と部門長に了解を取ってから見ます。

残すのは中央値だけではありません。案件ID、始点の日時、終点の日時、日数を1件ずつ並べた一覧を、測った期間と一緒に保存します。件数が少なくばらつきの大きい数字なので、比べるのは中央値にし、極端に長い案件は一覧で別に確かめます。

稼働を部署ごとに段階的に進めるなら、先に稼働した部署と、まだ稼働していない部署を同じ期間で並べる方法も使えます。季節や案件の偏りを分けやすくなります。

比べる日と見直す条件は、稼働前に決めて稟議に書く

稼働した直後は、慣れていないぶん業務が一時的に遅くなることが少なくありません。だから比べる日を先に決めます。目安は稼働から3か月後です。

そのときの数字は、稼働前と同じ記録、同じ1件の定義、同じ取り方で事務局が出し、同じ形の一覧で保存します。CRMのレポートは、後から項目が更新されると過去の値まで変わることがあります。比べた日の数字は、その日の一覧として残しておきます。理由は「先月報告した商談化率が、今月見たら変わっていた」と同じです。

見直す条件も、数字で先に書きます。「3か月後に中央値が◯日から◯日になっていなければ、設定か運用の見直しに入る」。これは効果の証明ではなく、見直しに入るかどうかの合図です。前後比較には季節も人の入れ替わりも混ざるので、合図として使うのがちょうどいい精度です。条件を後から決めると、出てきた数字に合わせて線を引いてしまう。期限と判断を先に決める考え方は「施策を止める判断は、中止ではなく「更新しない」で下す」と同じです。

置き場所は稟議書がいちばん確実です。「変える業務と1件の定義」「稼働前の数字と測った期間」「比べる日と見直す条件」の3行を足しておけば、半年後の経営会議では、その3行と一覧を開くところから話が始められます。

システム導入の効果は、稼働前の同じ数字が無いと前後を比べる土台が無い。変えたい業務を1つに絞り、稼働後も同じ記録から取れる数字を移行作業の前に測っておく。比べる日と見直す条件も、そのとき決めます。

いま稟議が回っているシステムがあれば、変える業務を1行で書けるかどうかだけ、先に確かめてみてください。書けなければ、測る前に決めることがあります。