KPI管理は「集める」のをやめる｜3か所に散らばった数字を1つにまとめ、月末を待たずに見えるようにした話

KPI管理でいちばん困るのは、指標の選び方ではありません。数字が、あちこちに散らばっていることです。

売上の見込みはスプレッドシートにある。商談は顧客管理システムに入っている。案件が誰の手に渡ったかはタスク管理ツールを見ないと分からない。目標は、期初に決めたきり別のファイルの中で眠っている。どれも「ある」のに、一枚の画面になっていない。だから、月末に誰かが手で集めてくるまで、いまどうなっているのかが誰にも分かりません。

GrowGroup株式会社は、Webサイト制作を主軸にしている会社です。私たちは自社の業務のために複数のツールを内製してきましたが、そのうちの1本が「GrowGroup Webプロデューサー向けKPI管理システム」——社内で呼んでいるKPI Managerです。売り物ではありません。自分たちのために作り、いまも動いています。

この記事は、そのツールがなぜ生まれ、何を目指し、何をあえてやらなかったかを書いたものです。KPI管理の仕組みを作ろうとしている方にいちばん役に立つのは、成功譚ではなく「どこでつまずくか」の地図だと考えています。だから、同じ場所で5回転んだ話も、隠さずそのまま書きます。

この記事に出てくる数字は、すべて自社で10ヶ月動かし続けたツールの記録（開発履歴230コミット、年度計算のバグ5回）から取っています。一般論ではなく、実際に運用している会社の記録です。

KPI管理とは何か、そして実際の手順

先に、言葉の整理をしておきます。KPI管理とは、目標に到達しつつあるかどうかを、途中で分かる数字にして追いかけることです。KGI（最終的に達成したい成果）が「今期の売上」だとすれば、KPIはそこに至る途中経過——商談の数、案件の進み具合、部門ごとの積み上がり——を指します。KGIは終わってから分かる数字、KPIは途中で分かる数字、と考えると区別しやすいはずです。

手順としては、たいてい次の5つです。

1. KGIを決める — 最終的に何を達成したいのかを1つに絞る
2. KPIに分解する — KGIに効く途中経過の数字を選ぶ
3. 目標値を置く — 部門ごと・担当ごとに、どこまで積むかを決める
4. 実績を集める — 数字が実際にいくつなのかを、継続的に取れる状態にする
5. 差分を見て、打ち手を変える — 目標と実績の差を見て、月の途中で動き方を変える

この記事が扱うのは、主に4と5です。1〜3は会議で決められます。決まらないのは、その数字がどこから来て、誰が入れて、いつ更新されるのか——つまり4であり、4が滞れば5は永遠に来ません。私たちが自社で詰まったのも、そこでした。

きっかけは3つ、同時にあった

KPI管理のツール化は、ひとつの大きな不満から始まったわけではありません。性質の違う3つの不便が、同じ場所で重なっていました。

1. スプレッドシートの「月報」を、手で回していた

社内では、売上高をまとめたスプレッドシートのことを「月報」と呼んでいました。表計算ソフトでのKPI管理には、よく知られた良さがあります。誰でも触れる。すぐ作れる。列を足すのも一瞬です。

問題は、その良さの裏側にあります。誰でも触れるということは、誰かが触ったあとの状態が正しいという保証がないということです。そして、毎月同じ手順で数字を集めて貼り込む作業が、毎月必ず発生します。この「毎月必ず」が、ツール化の第一の動機でした。

2. 目標と実績の差を、月末を待たずに見たかった

2つ目が、この記事の芯です。部門ごと・担当ごとに目標があり、実績があります。知りたいのはその差分ですが、月報のリズムで集計している限り、差分が見えるのは月が終わってからになります。

月が終わってから見える数字は、報告にはなりますが、打ち手にはなりません。「今月は届かなかった」と分かった時点で、その月に対してできることは何も残っていないからです。欲しかったのは、進行中に見える数字でした。

3. 商談データはあるのに、KPIとして見られる形になっていなかった

3つ目は、多くの会社に当てはまるはずです。顧客管理システムには、自社の商談データ（誰が担当し、いまどのフェーズか、といった自社側の営業情報）が入っていました。入力されていなかったわけではありません。

ただ、私たちの使い方では、顧客管理システムは「1件の商談を管理する」ための道具になっていました。集計の機能がないという意味ではなく、部門ごとの目標と並べて到達度を見る、という形にはしていなかった、ということです。データはあるのに、KPIとして見られる形になっていない。足りなかったのはデータではなく、見方でした。

こうして並べると、やろうとしたことは一言で言えます。3か所に散らばっていた数字を1つにまとめて、月末を待たずに見えるようにする。それだけです。新しい指標を発明したわけでも、経営の理論を持ち込んだわけでもありません。

KPI管理が続かなくなる本当の理由は「入力」

KPI管理の仕組みは、たいてい同じ壊れ方をします。入力されなくなって、数字が古くなり、古い数字は見られなくなり、見られない画面は誰も直さなくなる。この順番です。

だから私たちは、入力の量を設計の一番はじめに潰しました。ここを最初に潰さない限り、どんなに立派なダッシュボードを作っても、いずれ誰も開かなくなります。

私たちの場合、幸運なことに、実績のデータはすでに他のシステムに入っていました。商談は顧客管理システムに、案件の挙手はタスク管理ツールに。人が新たに入力する必要は、本来ないはずのデータです。だから設計の出発点は最初から決まっていました。すでにどこかに入っている数字を、二度入力させない。

目的から決めた3つの方針（うち1つは「やらない」こと）

方針1：実績は、人が入力しない

商談は顧客管理システムから、案件の挙手はタスク管理ツールから、それぞれ自動で同期します。担当者がKPI管理ツールを開いて数字を打ち込む作業は、最初から存在しません。入力の手間は、便利な入力機能を作ることで解決したのではなく、入力機能を作らないことで解決しました。

この方針が実際にどう効いているか、数字で出します。これまでに自動で取り込んだ商談は9,068件、案件の挙手は1,146件。同期そのものは1日6回まわす設計で、直近30日の実測は191回＝1日あたり6.4回。成功率は98.0%です。

この9,068件を、もし人が入力していたら——という話です。1件1分でも151時間かかります。そして入力する人は、その151時間ぶんの価値を1円も生んでいません。数字はもう別のシステムに入っているのですから。

方針2：変わったら、すぐ反映する

「月末を待たずに見たい」が目的だったので、更新のタイミングも目的に従いました。元のシステム側でデータが変更されると、その通知を受けて即座に反映されます（いわゆるWebhookです）。夜間にまとめて処理して翌朝に反映、という作りにはしていません。翌朝に見える数字は、進行中の数字とは呼べないからです。

方針3：全自動にはしない（意図的に手動同期を残した）

ここが、この設計でいちばん語る価値のある判断です。リアルタイム同期を作ったのだから、手動の同期ボタンは要らないように見えます。しかし手動同期は残してあります。記録に残っているのは、役割分担の事実だけです。自動は1件ずつ、変わった瞬間に。手動はまとめて、差分だけ。なぜそう分けたかを明文化した文書はありません。ただ、運用してみると分かります——自動だけにすると、届かなかった通知に気づく手段がないのです。

自動同期は、通知が届いている限りうまく機能します。しかし届かなかった通知に気づく手段は、自動同期の中にはありません。連携先の一時的な不調、設定の変更、こちら側の作業——理由はいくらでもあります。そのとき、人が「おかしい」と思った瞬間に押せるボタンがなければ、ズレた数字を直す方法が消えます。

自動化の設計で怖いのは、自動化できないことではありません。自動化が失敗したときに、人が介入する隙間まで一緒に消してしまうことです。手動同期は、その隙間として残しました。

では、人が入力するものは何か

結果として、手で入れるものは2つだけになりました。

• 年に1回の目標設定 — 部門・担当ごとの目標。これは人が決めることなので、自動化できませんし、するべきでもありません
• 週次の1on1メモ — 数字の背景にある事情。これも人が書くしかありません

この2つに共通しているのは、どちらも「人が判断したこと」であって、どこかのシステムに既にあるデータではないという点です。逆に言えば、それ以外はすべてどこかにありました。だから、それ以外は入力させませんでした。

KPI管理の仕組みを検討している方に、この線引きはそのまま使えます。入力欄を1つ増やすたびに、その仕組みは続きにくくなる——私たちはそう考えています。増やしていいのは、人の判断が入るものだけです。

開発が止まって見える社内ツールは、失敗したツールなのか

開発の実測値を出します。このツールの変更履歴は、2025年8月から2026年6月までで計230コミット。そのうち200コミット（全体の87%）が、2ヶ月目の1ヶ月間に集中しています。

グラフにすると、こうなります。

この形のグラフを見ると、多くの人が同じ読み方をします。「立ち上がって、そのあと失速している」——ですが、それは違います。

このツールは止まっていません。2026年7月現在も、日々の業務の中で使われ続けています。コミットが減ったのは、放置されたからではなく、作り切って、触る必要がなくなったからです。

これは、社内ツールを評価するときに繰り返し起きる誤読だと思います。市場に出ているプロダクトなら、更新が止まることは黄信号です。競合がいて、市場が動いていて、作り続けなければ置いていかれるからです。しかし社内ツールに競合はいません。自社の業務という、変化の遅い相手がいるだけです。

業務が変わらないなら、ツールも変わる必要がありません。手が入っていない社内ツールは、失敗した社内ツールではなく、要件を満たし切った社内ツールであることのほうが多いのです。むしろ、毎月のように改修が入り続ける社内ツールがあるとしたら、そちらのほうを疑うべきかもしれません。最初に描いた要件が、業務と噛み合っていない可能性があるからです。

教訓として書いておきます。開発量のグラフを「衰退」の物語に使ってはいけません。コミット数は開発量の目安であって、稼働状況でも利用状況でもありません。この誤読は、外から見ているときほど起きます。開発量の推移だけを見れば「失速している」と読めてしまう。自社のツールですら、履歴だけを見ればそう読めるのです。だから、稼働の判断に履歴を使ってはいけません。使っている人に聞くのが唯一の正解です。

言葉で言っても説得力がないので、実際の利用記録を出します。

開発の手が止まった2025年10月以降も、2026年は毎月、一度も欠けることなく使われています。累計のログインは2,182件。この記事を書いた2026年7月17日にも、ログインと自動同期が動いていました（同期は100件を処理してエラー0件）。

2つのグラフを並べると、言いたいことが伝わると思います。片方は2025年9月で谷に落ち、もう片方は平らなまま続いている。この2つは矛盾していません。作り終えたものは、それ以上作る必要がないだけです。

5回つまずいた場所：会計年度が6月に始まること

ここからが、この記事でいちばん実務的な部分です。安定して動いているツールにも、同じところで何度も転んだ履歴が残っています。むしろ、5回のうち4回は立ち上げ期から半年以内に集中していました。原因は、技術的にはあまりに他愛のないことでした。

私たちの会計年度は、6月に始まります。

これだけです。これだけのことで、立ち上げ直後から最後の1回まで、約9ヶ月にわたって5回、年度計算のバグを直し続けました。

原因1：同じ計算が、7つのファイル・18か所にコピーされていた

「今日の日付から、いまが何年度かを求める」という計算があります。6月始まりなら、6月以降ならその年、5月以前なら前年。1行で書けます。

1行で書けるからこそ、共通の関数になりませんでした。ダッシュボード、分析、月次明細、チーム目標、メンバー目標……と、必要になった場所でその都度書かれ、7ファイル・18か所に同じ計算が散らばりました。

この状態で何が起きるかは、想像がつくと思います。バグを見つけて直しても、直るのは18か所のうち1か所だけです。画面Aの数字が合ったので直ったと思う。しばらくして画面Bの数字が合わないと分かる。直す。また別の画面で出る。5回直したのは、5種類のバグがあったからではありません。同じ1つのバグが、18か所に複製されていたからです。

原因2：同じ「6」なのに、向きが2種類ある

ここが、この問題のいやらしいところです。6月始まりの会計年度には、向きの違う2つの変換が登場します。

• 日付から年度を求める：2026年3月は「2025年度」。つまり1つ前に戻す
• 年度から暦年を求める：2025年度の3月は「2026年3月」。つまり1つ先に進める

どちらも境目は同じ「6月」で、どちらも1年ずらします。違うのは、ずらす向きだけです。コードの見た目もほとんど同じになります。だから取り違えます。そして実際に、私たちは取り違えました。最後に直した年度バグが、まさにこの向きの取り違えでした。

しかも、取り違えてもほとんどの月は正しく動いてしまいます。ズレが表面化するのは、年度をまたぐ1月から5月だけ。6月に作って、6月に確認して、正しく見えたものが、翌年の1月に壊れる。これが、約9ヶ月にわたって出続けた理由です。

実際に数えると、こうでした。日付から年度を求める向き（1つ戻す）が6ファイル・8か所。年度から暦年を求める向き（1つ進める）が4ファイル・10か所。同じ「6」という数字が、真逆の2方向で18か所に散らばっていたことになります。

書いている本人は、そのとき必要な向きしか考えていません。だから1行で書けてしまう。そして次に別の画面を作るとき、隣の画面からコピーしてくる——向きが逆だとは気づかずに。

原因3：設定を持っていたのに、集計側がそれを見ていなかった

いちばん反省すべき点を書きます。このツールには、会計年度の期間を設定として持つ仕組みが実装されていました。始まりの月を設定から読めば、どこにも「6」を書かずに済むはずでした。

ところが、集計する側のコードは、その設定を参照していませんでした。それぞれの場所に、直接「6」と書かれていた。設定機構を持ちながら、それを使っていない——設計としては破綻しています。

さらに正直に書けば、2026年1月の修正は、汎用的に書こうとしたロジックをあきらめて、6月を直書きし直したものでした。汎用のつもりの実装が正しく動かないので、動くと分かっている定数に戻した。その場では正しい判断です。ただ、それは散らばった「6」を、さらに1つ増やす方向の判断でもありました。急いで直すと、たいていこうなります。

持ち帰れる教訓

この話は、6月始まりの会社だけの話ではありません。「自社だけのルール」を持っている会社すべての話です。

• 会計年度が4月始まり／6月始まり／10月始まり
• 売上の計上タイミングが、検収時なのか請求時なのか
• 「翌月末締め」の翌月が、暦月なのか営業月なのか
• 部門の区分が、期の途中で変わることがある
• 特定の区分だけ、集計の扱いが違う

こういうルールは、一般的なツールやテンプレートが標準で想定しているとは限りません。だから内製するときも、既製品をカスタマイズするときも、自分たちで書き足すことになりがちです。そして1行で書けるがゆえに、その場で書かれ、散らばります。

KPI管理ツールが信用を失う瞬間は、たいてい派手な障害ではありません。「この画面の数字、あっちと合ってなくないですか」という一言です。一度これが起きると、次からは誰も画面を信じず、結局スプレッドシートで検算するようになります。そうなれば、ツール化した意味は消えます。

だから、教訓はひとつだけです。自社固有のルールは、必ず1か所に置く。設定にするか、共通の関数にするか、方法は何でも構いません。大事なのは「そのルールを変えたいとき、直す場所が1つである」という状態を作ることです。私たちはそれをしなかっただけで、約9ヶ月バグを生み続けました。

できていること、できていないこと

成果について、盛らずに書きます。

できていることは、当初の目的そのものです。3か所に散らばっていた数字が1つの画面にまとまり、実績は人手を介さず自動で入り、月末を待たずに目標との差分が見られる状態が、安定して続いています。手で入力するのは、年1回の目標と週次の1on1メモだけ。この構造が、そのまま運用の軽さになっています。

一方で、正直に書いておくべきこともあります。削減できた工数を、私たちは測っていません。月報を手で回していた時間が何時間減ったのか、数字で言える記録がありません。測っていないものを「これだけ減りました」と書くことはできないので、測っていない、と書きます。

連携先への呼び出し回数の制御や、監視サービスとの連携は、当初「将来やる」と書いたまま入っていません。

テストコードもありません。年度計算のように、間違えたら数字が狂う部分にも、1本もない。立ち上げのスピードを優先して、意図的に置いていきました。お客さまの案件では当然この判断はしませんが、社内ツールでは、それを選びました。年度計算のバグが約9ヶ月出続けた背景には、間違いなくこれもあります。年度をまたぐ月の計算にテストが1本でもあれば、5回のうち何回かは最初の1回で終わっていたはずです。

ただ、この2つを「反省」として並べたうえで言えば、それでもツールは目的を果たして稼働し続けています。社内ツールの内製は、完璧に作ることが目的ではありません。目的を果たす最短距離を通ることが目的です。どこを削るかは、その都度の判断になります。私たちはテストを削り、その代金を年度バグで支払いました。次に作るときは、そこだけ払い方を変えます。

御社のKPI管理に、そのまま移せること

ここまでの話を、道具に依存しない形で整理します。KPI管理の仕組みを内製するにせよ、既製品を入れるにせよ、この5つは共通して効きます。

そして、いちばん大事なのは順番です。KPI管理は「何を指標にするか」から始めると、たいてい失敗します。指標は決められるからです。会議で30分もあれば決まります。決まらないのは、その指標の数字がどこから来て、誰が入れて、いつ更新されるのか、という部分です。

私たちがこのツールで最初に解いたのも、指標の設計ではなくデータの流れでした。商談は顧客管理システムから流れてくる。案件はタスク管理ツールから流れてくる。目標だけは人が入れる。この流れが決まった時点で、ツールはほぼ完成しています。画面は、その後です。

よくあるご質問

Q. KPIとKGIの違いは何ですか

A. KGIは最終的に達成したい成果、KPIはそこに至る途中経過の数字です。「今期の売上」がKGIなら、その手前にある商談の数や案件の進み具合がKPIにあたります。実務上いちばん大きな違いは、見えるタイミングです。KGIは終わってからでないと分かりませんが、KPIは途中で分かるからこそ、途中で打ち手を変えられます。逆に言えば、月末にしか集計できないKPIは、KGIとほとんど同じ働きしかしません。私たちが月末を待たずに見られる形にこだわったのは、そこが理由です。

Q. KPI管理表はエクセル・スプレッドシートのままではダメですか

A. ダメではありません。むしろ最初はスプレッドシートで始めるべきだと考えています。何を見たいのかが固まっていない段階でツールを作ると、作ったあとで見たいものが変わります。ツール化を検討すべきなのは、「毎月、同じ手順で、同じ場所から数字を集めている」と気づいたときです。手順が固定化したということは、要件が固まったということだからです。

Q. リアルタイムに見られると、何が変わりますか

A. 見る目的が変わります。月末に見る数字は「報告」で、進行中に見る数字は「打ち手」です。同じ数字でも、見えるタイミングが違うだけで用途がまったく変わります。私たちがリアルタイム反映にこだわったのは、技術的に面白いからではなく、月末に見える数字ではその月に対して何もできないからです。

Q. 自動同期があるのに、手動の同期ボタンも要るのですか

A. 要ります。役割が違うからです。自動同期は「変わった1件」を即座に反映するもの、手動同期は「まとめて差分を取り直す」ものです。自動同期は、届かなかった通知に自力で気づくことができません。人が「数字がおかしい」と思ったときに押せるボタンがないと、ズレを直す手段が残りません。全自動は、しばしば「壊れたときに何もできない」と同義です。

Q. 会計年度が4月始まりなら、この問題は起きませんか

A. 起きます。境目が6月か4月かは関係ありません。問題は「暦年と会計年度がズレていること」と「そのズレの計算が散らばっていること」の組み合わせで起きます。4月始まりでも、1月〜3月の扱いでまったく同じ形のバグが出ます。むしろ4月始まりは一般的なぶん、ツールやライブラリがそれを前提にしていることがあるという程度の差です。ズレの計算を1か所に置く、という対策は変わりません。

Q. 社内ツールが使われているかどうかは、どう確かめればいいですか

A. 開発履歴やアクセスログでは分かりません。開発が止まって見えるツールが、完成して安定稼働しているだけ、ということは普通にあります。確かめる方法は1つで、使っている人に聞くことです。ただし聞き方が肝心で、「開いていますか」ではなく「この数字を見て、何か決めましたか」と聞いてください。前者はYesと言われて終わりますが、後者に答えが出てこないなら、そのツールは見られていても使われていません。

Q. KPI管理ツールは内製と既製品のどちらを選ぶべきですか

A. 私たちの判断軸は「自社固有のルールがどれだけあるか」です。ルールが一般的なら、既製品のほうが速く、安く、確実です。私たちも、そうであれば既製品を選びます。一方で、会計年度・計上タイミング・部門区分といった自社固有の決まりごとが多い場合は、既製品を自社に合わせる作業のほうが重くなることがあります。私たちの場合、実績データはすでに他システムにあり、それを自社のルールで束ねたかった——つまり「束ね方」だけが独自だったので、内製を選びました。

この切り分けは、自社の中だけだと「固有だと思っていたルールが実は一般的だった」（逆も然り）が起きやすいところです。切り分けだけでもご相談いただければ、作らずに済む範囲が見えます。

Q. KPI管理の仕組みは、どれくらいの期間で作れますか

A. 私たちの実測では、開発量の87%が2ヶ月目の1ヶ月に集中しています。ただし、これは「1ヶ月で作れる」という意味ではありません。前提として、実績データがすでに他システムに正確に入っていました。データが揃っていない状態から始めるなら、いちばん時間がかかるのはツール作りではなく、データを整えるほうです。ここを飛ばして画面から作ると、きれいな画面に古い数字が出るだけの仕組みになります。

御社のデータがいまどの状態にあるかは、洗い出してみないと分かりません。ここは1回の打ち合わせでかなりはっきりします。

まとめ：数字を集めるのをやめて、集まるようにする

この記事で書いたことを、3つにまとめます。

• KPI管理の課題は指標の設計ではなく、数字が散らばっていることだった。3か所を1つにまとめ、月末を待たずに見えるようにした
• 続く仕組みにするために、実績は自動で入るようにし、人が入力するのは「判断」だけに絞った。それでも全自動にはせず、人が介入する隙間を残した
• 約9ヶ月バグを生み続けた原因は、自社固有のルール（6月始まりの会計年度）を1か所に置かなかったこと。この1点だけは、どんな会社でもそのまま教訓になる

そして、このツールはいまも安定して動いています。2ヶ月で作り切って、あとは静かに動き続けている。社内ツールとしては、それがいちばん良い状態だと思っています。

同じ発想は、御社の業務にも使えます

ここまで読んでいただいて、「うちも数字が散らばっている」と思われたなら、それはツールの問題ではなく、データの流れの問題です。そして多くの場合、必要なデータはすでに社内のどこかに入っています。足りないのは、それを束ねる場所だけです。

GrowGroupは、Webサイト制作で培った設計と実装を、自社の業務のDXにも使ってきました。この記事のKPI管理ツールは、その1本です。同じ発想で、御社の業務を効率化するお手伝いができます。「何を作るか」が決まっていない段階からで構いません。むしろその段階からご相談いただくほうが、作らずに済む部分も含めて整理できます。

まずは、御社の数字がいまどこに、いくつあるか。それを一緒に数えるところからで構いません。

無料ダウンロード資料

GrowGroup株式会社の制作事例・料金がわかる資料を配布中

会社概要・制作実績・料金の目安をまとめた資料です ／ PDF

資料をダウンロード