経営者のためのWebシステムKPI 16選 — 売上に効く数字は、技術指標の中にある

こんにちは、大平です。

経営会議で売上・CVR・広告費は毎月見ているのに、自社のWebシステムの表示速度やエラー率を答えられる経営者はほとんどいません。技術顧問として入った先で聞いても、「それは開発チームが見ているはず」という答えが返ってくることが大半です。そして開発チームに聞くと、「経営には報告していない。聞かれないので」と返ってくる。数字はあるのに、経営に届いていないんです。

先に結論を言うと、これは大きな機会損失です。モバイルサイトの4つの速度指標が0.1秒改善したとき、小売サイトのコンバージョン率が相対値で8.4%向上したという調査があるように、技術指標は「エンジニアの管理項目」にとどまらず、売上に影響する経営指標です。

この記事では、Webシステムを事業の武器にするために計測候補となる指標を、事業側8個・技術側8個の計16個に整理しました。厳密には、計測する指標のすべてがKPIになるわけではありません。事業目標に合わせて絞り、目標値や評価期間を定めて継続管理する指標がKPIです。この記事では便宜上、16個を「KPI候補」として扱います。単なるリストではなく、「事業と技術を1本のツリーでつなぐ」ことをゴールにしています。自社のダッシュボードの棚卸しに使ってください。

なぜ「事業のKPI」と「システムのKPI」を別々に見てはいけないのか

多くの会社で、数字は2つの世界に分断されています。マーケティングと経営が見るのは売上・CVR・広告効率。開発チームが見るのはサーバーの負荷やエラーログ。この2つは別々の会議で、別々のダッシュボードで報告されます。

問題は、この2つの数字のあいだに、無視できない影響経路があることです。表示が遅ければ買う前の離脱が増える可能性があります。決済でシステムエラーが出れば、購入機会を失います。リリースの頻度が低ければ、改善施策を本番へ反映できる機会も減ります。

技術指標の悪化は、エラーによる購入失敗のように即座に事業指標へ現れることもあれば、体験の悪化を経て継続率へ遅れて現れることもあります。そのため、技術KPIの一部は事業KPIの「先行指標」になり、別の一部は事業指標が動いた理由を説明する診断指標になります。売上だけを見て原因を探すより、技術指標も併せて見た方が早く手を打てます。

技術顧問先でよく見るのは、経営会議で「CVRの低下」が何ヶ月も議論されている一方で、開発の定例ではその前から「モバイルの表示遅延」が報告されている、という状態です。同じ問題が別の名前を付けられて、2つの会議を別々に漂流している。両方の数字を1つのテーブルに載せるだけで、この空転は止まります。

KPIを選ぶ前に：ダッシュボードは1本のツリーにする

16個のKPIを紹介する前に、大事な原則を1つ。KPIは並べるのではなく、売上を頂点にした1本のツリーとしてつなげてください。

たとえばECの売上は、おおむね「セッション数 × 転換率 × 平均注文額」に分解できます。SaaSの月次売上なら「有料顧客数 × 顧客あたり月次売上」が基本で、継続率は将来の有料顧客数を左右します。継続率を同じ時点の売上へそのまま掛けるわけではありません。事業KPIはこのツリーの幹です。そして技術KPIは、幹のそれぞれに影響を与える根として配置します。

訪問数の下に：流入チャネル別内訳、CAC
転換率の下に：カゴ落ち率、そして表示速度（LCP）・エラー率
継続率の下に：DAU/MAU比、そして稼働率・復旧時間
ツリー全体の改善速度の下に：デプロイ頻度・変更リードタイム

こうしておくと、「LCPが悪化した」という技術の報告が、「転換率が落ちるリスクがある」という経営の言葉に自動的に翻訳されます。逆に、どの技術投資がどの売上レバーに効くのかも説明できるようになります。翻訳できない数字は、経営会議では動かせません。 ツリーはその翻訳表です。

事業KPI 8選（獲得・転換・継続・収益）

まず幹になる事業側の8個です。すでに見ている数字も多いと思いますが、「経営者としてどう見るか」の観点を添えます。

1. セッション数とチャネル別内訳（獲得）

訪問の総量よりも内訳が重要です。広告・検索・SNS・直接流入の構成比を見て、特定チャネルへの依存度を把握します。広告を一時停止したら売上がほぼ消えた、という相談は実際に珍しくありません。オーガニック流入の比率は、集客の「資産性」を示す数字だと捉えてください。

2. CAC：顧客獲得コスト（獲得）

新規顧客を獲得するために使った営業・マーケティング費用を、新規顧客数で割った値です。広告で定義した購入や登録など、1件のアクションを得るための費用であるCPA（Cost Per Action）とは区別します。後述するLTV/CAC比には、費用の範囲をそろえたCACを使います。チャネル別の広告効率を見るときはCPAも併用し、「このチャネルの獲得費用はLTVに見合っているか」で判断します。

3. CVR：コンバージョン率（転換）

訪問のうち、購入や申込みに至った割合です。サイト全体の平均値だけでなく、チャネル別・デバイス別・ページ別に分解して見ます。平均値は改善ポイントを隠します。 全体では2%でも、PCは3%・モバイルは1%かもしれない。モバイル流入が7割ならば、打ち手は「モバイルの何かがおかしい」に絞られます。この分解が、後述する技術KPI（表示速度）とつながる入口になります。

4. カゴ落ち率・フォーム離脱率（転換）

商品をカートに入れた、あるいはフォーム入力を始めた人のうち、購入や送信を完了せず離脱した割合です。Baymard Instituteの調査集計では、ECのカゴ落ち率は平均70%前後です。ただし、そのすべてが「買う気があったのに離脱した人」ではありません。同調査では、カゴ落ち経験者の42%が「見ていただけ・購入準備ができていなかった」と回答しています。回避できる離脱に絞ると、追加費用の高さ、会員登録の強制、長く複雑な決済手続き、サイトのエラーなどが改善候補になります。新規の広告費を積む前に確認したい数字です。

5. チャーンレート：解約率（継続）

SaaSや会員制サービスの生命線です。月次3%の解約は一見小さく見えますが、年間に換算すると顧客の約3割を失う計算になります。穴の空いたバケツに水を注ぎ続ける状態かどうかを判定する数字なので、数値と合わせて「なぜ辞めたか」を追う仕組み（解約時アンケートやヒアリング）を必ずセットにしてください。

6. DAU/MAU比：利用の粘着度（継続）

ある日のアクティブユーザー数を、その日までの一定期間における月間アクティブユーザー数で割った値です。日ごとの変動をならすため、平均DAUをMAUで割ることもあります。適正値は毎日使うサービスと月に数回使うサービスで異なりますが、同じサービス内で比率が下がり続ける場合、利用頻度の低下がチャーンの先行指標になることがあります。利用が落ちたユーザーへ早期に声をかける起点としても使えます。

7. LTV：顧客生涯価値（収益）

1顧客が取引期間全体でもたらす粗利益です。「顧客単価 × 粗利率 × 平均継続期間」で概算するだけでも、獲得・継続の投資判断の質が変わります。月次解約率が長期にわたって一定とみなせるサブスクリプション事業では、平均継続期間を月次解約率の逆数で近似できます。チャーンが改善するとLTVが伸び、許容できるCACの上限も上がります。

8. LTV/CAC比（収益）

LTVを顧客獲得コストで割った値で、ユニットエコノミクスの健全性を示します。SaaS業界では3倍が目安としてよく使われますが、粗利率、回収期間、成長段階によって適正値は変わります。粗利益ベースのLTVと、営業・マーケティング費用を含むCACを使った場合に1倍を切るなら、顧客単位で獲得費用を回収できません。逆に5倍を大きく超えているなら、獲得投資が保守的すぎる可能性も検討します。

技術KPI 8選（性能・可用性・開発速度・安定性・復旧速度）

次に、根になる技術側の8個です。経営者が自分で計測する必要はありませんが、月次で報告させ、意味を理解しておくべき数字です。

9. LCP：表示速度（性能）

Core Web Vitalsを構成する3指標の1つで、ページを開いてから、ビューポート内で最も大きな画像・テキストブロック・動画が描画されるまでの時間です。モバイルとデスクトップを分け、実ユーザーによるページ読み込みの75パーセンタイルで2.5秒以下が「良好」の基準です。PageSpeed Insightsでは両方を確認し、顧客の利用比率が高いデバイスを優先します。オフィスのPCと高速回線で見ている「速いサイト」と、顧客がスマートフォンで体験しているサイトは、別物であることが多いです。

10. 応答時間（p95）（性能）

サーバーやAPIがリクエストを受けてから応答を返すまでの時間です。ブラウザで計る画面全体の待ち時間とは異なるため、計測区間を先に決めます。ポイントは平均値だけでなく、95%のリクエストがその値以下に収まるp95を見ることです。平均値では隠れる遅い側の体験を継続的に追えます。

11. 稼働率：アップタイム（可用性）

システムが正常に動いていた時間の割合です。99.9%と聞くと十分に見えますが、年間に換算すると約8.8時間止まっている計算です。99.99%なら約53分。この差を埋めるコストは安くないので、大事なのは数字を上げること自体ではなく、「自社の商売にとって何時間の停止までなら許容できるか」を経営として決めておくことです。セール初日にその8時間が来たら、と考えると解像度が変わります。

12. エラー率（可用性）

リクエストや業務処理のうち、システム側の理由で失敗した割合です。特に決済・申込みなど売上に直結する導線のエラーは、売上を失う可能性のある失敗です。ただし、カード会社による決済拒否や入力不備までシステム障害として数えないよう、エラーの定義と分母を決めます。全体のエラー率とクリティカル導線のエラー率を分け、後者には即時通知のアラートを設定します。

13. デプロイ頻度（開発速度）

本番環境へのデプロイ頻度です。Google Cloudの研究プログラムであるDORA（DevOps Research and Assessment）が定義する、ソフトウェアデリバリー性能の指標の1つです。かつてはFour Keysと呼ばれる4指標でしたが、現在は「変更リードタイム」「デプロイ頻度」「デプロイ失敗時の復旧までの時間（Failed deployment recovery time）」「変更障害率」「デプロイ手戻り率（Deployment rework rate）」の5指標です。DORAのQuick Checkでは「オンデマンド（1日に複数回）」も評価帯の1つですが、すべてのサービスが一律に目指す目標ではありません。同じサービスの推移を見て、頻度と安定性を併せて改善します。月1回しかデプロイできないなら、本番へ改善を届ける機会は年間12回に制約されます。頻度が低い背景に手作業や承認待ちがあるなら、それ自体が改善のシグナルです。

14. 変更リードタイム（開発速度）

コードをバージョン管理へコミットしてから、本番環境へのデプロイに成功するまでの時間です。ここが数週間かかる組織は、実装済みの変更を顧客へ届けるまでにも同じだけ待ち時間が生じます。企画から着手までの時間や開発そのものの期間とは分けて測ることで、デリバリープロセスのどこを改善すべきか判断できます。

15. 変更障害率（安定性）

本番へのデプロイのうち、サービス低下を起こし、ロールバックやホットフィックスなどの即時対応が必要になった割合です。DORAの調査では、上位の組織は速度と安定性の両方で良い結果を出し、5指標は多くのチームで相関しています。ただし、デプロイ回数だけを増やせば変更障害率が下がるわけではありません。変更を小さく保ち、自動テストやデプロイ手順、アーキテクチャも改善することで、速さと安定性を両立させます。

16. デプロイ失敗時の復旧までの時間（復旧速度）

本番への変更によってサービスが低下し、即時対応が必要になってから復旧するまでの時間です。旧来のFour KeysではMTTR（Mean Time to Recovery）や「サービス復旧時間」と呼ばれていましたが、現在のDORAは対象をデプロイ起因の失敗に絞り、「デプロイ失敗時の復旧までの時間（Failed deployment recovery time）」と定義しています。データセンター障害なども含む全インシデントの復旧時間を追う場合は、運用指標として別に管理します。経営として問うべきは、変更に失敗したとき何分で戻せる体制かです。障害訓練や自動ロールバックへの投資は、この時間を短縮する投資です。

→ 自社のダッシュボード設計を個別に相談したい方は、記事末尾の相談窓口からどうぞ。

16個の一覧（ダッシュボード設計の保存版）

ここまでの16個を1枚にまとめます。右列の「経営者が問うこと」だけ拾えば、開発チームとの月次の会話がそのまま始められます。

#	KPI	分類	経営者が問うこと
1	セッション数と流入内訳	獲得	特定チャネルに依存していないか
2	CAC	獲得	費用範囲をそろえ、LTVに見合っているか
3	CVR	転換	どのセグメントが平均を下げているか
4	カゴ落ち率・フォーム離脱率	転換	回避できる離脱はどこで起きているか
5	チャーンレート	継続	年間換算で顧客の何割を失っているか
6	DAU/MAU比	継続	解約の予兆を早期に掴めているか
7	LTV	収益	継続率の改善が粗利益にどう効いているか
8	LTV/CAC比	収益	回収期間も含め、獲得投資を増やせるか
9	LCP	性能	実ユーザーの75パーセンタイルで2.5秒以下か
10	応答時間（p95）	性能	遅い側の5%はどこまで待っているか
11	稼働率	可用性	何時間の停止まで許容すると「決めて」あるか
12	エラー率	可用性	決済導線のエラーに即時アラートはあるか
13	デプロイ頻度	開発速度	年に何回、改善の打席に立てているか
14	変更リードタイム	開発速度	変更が本番に届くまで何日かかっているか
15	変更障害率	安定性	速さと安定性を両立できているか
16	デプロイ失敗時の復旧時間	復旧速度	変更の失敗から何分で戻せる体制か

技術KPIが売上に効く「接続」の実例3つ

16個を紹介しましたが、この記事の本題はここからです。技術KPIと事業KPIがどうつながるか、代表的な接続を3つ示します。

接続1：表示速度 → 転換率。 GoogleがDeloitteらに委託した調査「Milliseconds Make Millions」（2020年）では、37ブランドの実データを分析した結果、モバイルサイトの4つの速度指標が各ページで0.1秒改善したとき、小売サイトのコンバージョン率が相対値で8.4%、平均注文額が9.2%向上しました。この調査はLCP単独の改善効果を測ったものではありませんが、読み込み性能を事業指標と結びつけて見る根拠になります。現在はLCPを含むCore Web Vitalsを使い、自社の数値と転換率を継続的に照合します。

接続2：エラー率・稼働率 → 転換率と継続率。 決済や申込みのシステムエラーは、その場の購入機会を失わせ、再訪意向にも影響し得ます。Baymardの調査では、「見ていただけ・購入準備ができていなかった」人を除くカゴ落ち経験者の17%が、サイトのエラーやクラッシュを理由に挙げています。すべてのカゴ落ちが技術品質の問題ではないため、入力不備、決済拒否、システムエラーを分けて計測します。

接続3：デプロイ頻度 → 事業の学習速度。 施策の成否は事前には分かりません。月1回デプロイする組織と週3回デプロイする組織では、同じ1年で本番へ変更を届けられる機会が約13倍違います。デプロイ数と検証した事業仮説の数は同じではありませんが、デプロイ頻度が低ければ検証サイクルの上限も低くなります。デプロイ頻度は、事業仮説を本番で検証できる速度を制約する指標です。

なお、この「仮説を立てて検証する」ループの回し方、特に顧客の声（定性データ）をKPIにつなげる設計は、姉妹編で詳しくまとめています。

顧客の声を聞く方法大全 — 既存・見込み別 14 の施策と、売上に効かせる 6 ステップ

顧客の声を聞く施策を既存顧客・見込み顧客別に14個整理し、集めた声を売上・KPIに効かせる6ステップにまとめました。SlackやDropbox、Superhumanの実例と、深く学ぶためのおすすめ書籍6冊も紹介。「要望対応の積み上げ」で終わらせず、顧客の声を事業成長のエンジンに変える設計を解説します。

2026年7月6日

「うちはECでもSaaSでもない」という方へ

ここまでの例はECとSaaS寄りでしたが、16個の枠組みはWebシステム全般に読み替えられます。

リード獲得型のコーポレートサイトなら、CVRは「問い合わせ率」、カゴ落ち率は「問い合わせフォームの離脱率」に読み替えます。完遂率を使う場合は、離脱率と数値の良し悪しが逆になる点に注意してください。BtoBの問い合わせは1件の価値が数十万〜数百万円になることも珍しくないので、フォームの表示や応答が遅いことで失う金額は、ECより大きい場合もあります。メディアサイトなら継続系の指標を「再訪率・回遊数」に読み替えます。

社内向けの業務システムでも同じです。応答時間とエラー率は従業員の生産性に直結しますし、デプロイ頻度の低さは「現場の改善要望が何ヶ月も放置される」ことを意味します。売上の代わりに「人件費×待ち時間」で換算すれば、業務システムの技術KPIも金額の言葉に翻訳できます。

自社はどこから始めるか：事業フェーズ別の絞り方

16個すべてを最初から見る必要はありません。むしろ絞るべきです。目安として、事業フェーズ別の優先順位を示します。

立ち上げ期（PMF前）：見るべきは転換系（CVR・カゴ落ち率）とLCP、それに顧客の生の声です。継続率やLTVも計測しますが、母数が少ないうちは変動が大きく、推定の幅も広くなります。数字を断定材料にせず、定性データと組み合わせるフェーズです。

成長期：継続系（チャーン・DAU/MAU比）とDORAの指標群を追加します。ユーザーが増えて技術的負債が顕在化し、「開発が遅くなってきた」と感じ始めるのがこの時期です。デプロイ頻度と変更リードタイムの悪化は、成長の天井が近いサインとして扱ってください。

成熟期：収益系（LTV・LTV/CAC比）と可用性（稼働率・エラー率）の比重を上げます。トラフィックが大きくなるほど、1回の障害・1%の転換率低下の絶対額が大きくなるからです。このフェーズの技術投資は「守りのコスト」ではなく、失われていた売上を取り戻す「回収」として計算できます。

開発を外部に委託している場合

自社に開発チームがなく、Webシステムの構築・保守を外部に委託している会社も多いと思います。その場合、技術KPIはベンダーへの報告要求項目として使ってください。月次報告に「LCP・稼働率・エラー率・当月のリリース回数」の4つを入れてもらうだけで十分です。

これはベンダー選定の質問としても機能します。「稼働率と障害復旧時間の実績を、計測条件と併せて教えてください」と聞けば、品質をどのように計測しているか確認できます。数字をすぐに出せないことだけで未計測とは断定できませんが、定義、対象期間、データソースまで説明できるかどうかは、開発会社の運用成熟度を見分ける材料になります。

何で測るか：まず既存ツールから始める

計測基盤に最初から大きな投資は要りません。事業KPIは、GA4でセッションとチャネル別内訳を確認できます。CVRに相当する「セッションのキーイベント率」を出すには、購入や問い合わせなどのイベントを実装し、キーイベントとして設定します。LCPはPageSpeed InsightsとSearch ConsoleのCore Web Vitalsレポートで確認でき、後者は実ユーザーのデータです。エラー監視にはSentryなどの無料枠も使えます。

DORA指標のデータは、バージョン管理、CI/CD、デプロイ、インシデント管理など複数の場所に分かれます。Gitのコミット履歴だけでは、変更障害率や復旧時間まで集計できません。GitLabのValue Streams Dashboard自体は現行ではPremiumまたはUltimate向けで、DORA指標の比較パネルはUltimate向けです。Findy Team+やDatadogなどのSaaSを使う方法もあります。なお、DORAのオープンソース実装「Four Keys」は2024年1月23日にアーカイブされ、メンテナンスが止まっています。今から新規に採用するものではありません。

追加コストなしで始められる指標と、データ連携や有料プランが必要な指標を分けて考えます。ツール選定より先に、数字を見る場と、各指標の定義・データソースを決めます。場が回り始めてから、計測の自動化と精度に投資すれば十分です。

よくある失敗パターン

最後に、KPI運用で繰り返し見てきた失敗を3つ挙げます。

1. 測りすぎてダッシュボードが墓場になる。 50個の指標が並んだダッシュボードは、誰も見なくなります。16個はあくまでカタログで、常時見るのは事業・技術それぞれ3〜4個に絞るべきです。指標は「今期何を動かしたいか」で入れ替えるものです。全部を常に見ようとするのは、何も見ていないのと同じです。

2. バニティメトリクスに酔う。 累計登録者数、累計PVのような「右肩上がりにしかならない数字」は気分は良いですが、意思決定には使えません。率・単価・期間あたりの数字（CVR、チャーン、LTV）に言い換えられないKPIは、ダッシュボードから外してください。

3. 数字を見る「場」がない。 計測ツールを入れても、それを見て議論する定例がなければ何も起きません。おすすめは月次の経営会議に**「技術KPIの5分報告」を組み込む**ことです。アジェンダは「3つの数字（LCP・稼働率・デプロイ頻度）の当月値と前月比」「悪化があればその理由と対処」「来月の技術投資で経営に判断してほしいこと」の3点だけ。5分で終わりますが、技術と経営の会話がここから始まりますし、開発チームに「自分たちの数字は経営に見られている」という良い緊張感が生まれます。

経営者が今日から動ける3つのアクション

記事を閉じる前に、5分〜1通のメールでできることを3つ置いておきます。

PageSpeed Insightsで自社サイトのLCPを測る（5分）。モバイルのLCP値が2.5秒を超えていたら、まず改善候補として扱います。実ユーザーデータが表示される場合は、75パーセンタイルの値を確認します
次回の経営会議に「技術KPIの5分報告」を入れる（アジェンダ1行の追加）。報告者は開発責任者、数字はLCP・稼働率・デプロイ頻度の3つだけ
開発を委託しているなら、月次報告に技術KPIを追加依頼する（メール1通）。出てくるかどうか自体が、委託先の実力の答え合わせになります

まとめ

技術KPIは経営指標：モバイルサイトの4つの速度指標が0.1秒改善したとき、小売サイトの転換率が相対値で8.4%向上した調査がある。エンジニアだけの管理項目にすると機会損失を見逃す
KPIは1本のツリーでつなぐ：売上を頂点に、事業KPIを幹、技術KPIを根として配置する。翻訳できない数字は動かせない
16個から絞って使う：常時見るのは事業3〜4個＋技術3〜4個。事業フェーズと今期のボトルネックで入れ替える
デプロイ頻度は検証速度：速さと安定性はトレードオフではない、がDORA調査の一貫した結論

自社のダッシュボードに技術KPIが1つもなかったら、まずはPageSpeed InsightsでLCPを測るところから始めてみてください。5分で終わりますし、経営会議の議題が1つ増えるはずです。