会社情報
採用情報
お問い合わせ
Article

1ヶ月で効果測定できる業務改善PDCA

高田晃太郎
1ヶ月で効果測定できる業務改善PDCA

統計によると、ソフトウェア開発の大型変革は高い確率で失速します。Standish GroupのCHAOSレポートは、ITプロジェクトの「完全成功」が約3割に留まる傾向を長年指摘してきました¹。一方でDORA研究は、デプロイ頻度や変更の失敗率などの技術的指標が、ビジネス成果と相関を持つことを示しています²³。ここで言うDORAとは、DevOps Research and Assessmentが提唱する4つのパフォーマンス指標（デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間）を指し、開発と運用の生産性や信頼性を数値化するための業界標準です。長期計画だけに頼るのではなく、1ヶ月という短いタイムボックスでPDCA（Plan-Do-Check-Act：計画・実行・評価・改善の反復）を回し、数値で検証しながら改善を積み重ねるアプローチが、失速を回避する現実的な打ち手になります⁴。ここでは、CTOやエンジニアリングリーダーが現場でそのまま使える、期間明示・成果数値にこだわるPDCAの設計と実装を提示します。指標の選び方、計測の自動化、4週間の運用モデル、そして意思決定に耐える統計の扱いまでを、実コードとともに解説します。DevOpsやCI/CD（継続的インテグレーション/継続的デリバリー）に馴染みの薄い方でも読み進められるよう、用語は適宜かみ砕いて説明します。

1ヶ月で測るための設計原則：指標・閾値・データ品質

1ヶ月で効果を測るには、成果の定義をあいまいにしないところから始めます。DORAの4指標（デプロイ頻度、変更のリードタイム、変更失敗率、復旧時間）のうち、短期で感度よく動くのは多くのチームでリードタイム（変更のアイデアから本番反映までの経過時間）とデプロイ頻度です。変更失敗率（本番変更のうち障害につながった割合）と復旧時間（障害から回復するまでの時間）は守りの指標として同時に監視します⁵。現状のベースラインを過去4〜8週で算出し、改善の最小検出効果を事前に定めます。たとえば平均リードタイムを20%短縮、デプロイ頻度を30%増、変更失敗率は+0.5pt以内の増加に抑制、といった具体的な目標を閾値として明文化します。これらはKPI（重要業績評価指標）として、ビジネス価値とのつながりを常に意識します。

短期PDCAで信頼できる結論に近づくには、データ品質がすべてです。課題チケットのライフサイクル、GitのコミットやPR、CI/CDのジョブ、本番リリースのイベントを一気通貫で紐付け、タイムスタンプの整合性を担保します。ツールが分断されている場合はID連携のポリシーを決め、PRタイトルにチケットIDを強制するなど、追跡性を高めるガードレールを敷きます。観測の自動化（データ収集・集計・可視化の自動パイプライン化）は初週に集中投資し、以降の3週間は改善施策の実験にリソースを寄せます。データが自動で集まる状態を先に作ることが、1ヶ月で判断する唯一の近道です⁶。

計測の単位は週次が扱いやすく、外乱の影響を平滑化できます。平均だけでなく中央値や95パーセンタイルも併記し、尾の重い分布に備えます。統計的な有意差検定に固執するより、実用上意味のある最小効果量（例えば1日短縮）と信頼区間（推定値の不確実性の幅）の重なりを見ます。併せて季節要因やリリースの凹凸をメモし、解釈の文脈を残します。対照群の用意が難しい小規模チームでは、ロールアウトを段階化して擬似対照を作る方法が現実的です⁷。

4週間PDCA：ベースライン、実装、実験、判定

PDCAは短いサイクルで回すほど学習速度が上がります⁴。第1週はベースラインの採取に徹します（Plan）。課題作成から本番までの経路を可視化し、欠損データを洗い出します。JiraやGitHub、CI/CD、デプロイの事実をイベントストアに集約し、同一のチケットIDで連結します。第2週は観測の自動化を完成させ、改善施策を1〜2件だけに絞って投入します（Do）。例えばWIP制限の導入やレビュー時刻の固定化など、リードタイムに効きやすい打ち手を選びます。第3週は施策の継続運用と中間レビューを行い、意図せぬ副作用（失敗率の悪化など）を見ます（Check）。第4週は判定の週です（Act）。初週のベースラインと比較し、事前に定めた閾値を満たしたかを淡々と評価します。満たせば拡大、満たさなければ廃止または設計の手直しを選びます。判断のためのダッシュボードは最初に作り、毎週同じ見方でレビューします。

計測基盤：イベント連結とベースラインSQL

現場で最短距離なのは、すべての出来事を時系列に落とし込むことです。DORAが公開している「Four Keys」の考え方（課題→PR→パイプライン→デプロイを一貫追跡してDORAメトリクスを自動集計する方法）を参考に、課題→PR→パイプライン→デプロイをイベントとして連結し、エンドツーエンドのメトリクスを自動集計できるようにします⁶。以下はBigQueryを例に、課題→PR→パイプライン→デプロイのイベントを連結し、週次のリードタイムと変更失敗率を算出するSQLです。

-- BigQuery: weekly engineering metrics (baseline)
WITH events AS (
  SELECT issue_id, MIN(created_at) AS issue_created FROM `proj.raw.jira_issues` GROUP BY issue_id
), prs AS (
  SELECT issue_id, MIN(merged_at) AS pr_merged FROM `proj.raw.github_prs` 
  WHERE merged_at IS NOT NULL GROUP BY issue_id
), deploys AS (
  SELECT issue_id, MIN(deployed_at) AS first_deploy, 
         LOGICAL_OR(status = 'FAILED') AS any_failed
  FROM `proj.raw.deploy_events` GROUP BY issue_id
), joined AS (
  SELECT e.issue_id, e.issue_created, p.pr_merged, d.first_deploy, d.any_failed
  FROM events e
  LEFT JOIN prs p USING(issue_id)
  LEFT JOIN deploys d USING(issue_id)
  WHERE first_deploy IS NOT NULL
)
SELECT 
  FORMAT_DATE('%G-%V', DATE(first_deploy)) AS iso_week,
  COUNT(*) AS deployments,
  AVG(TIMESTAMP_DIFF(first_deploy, issue_created, HOUR)) AS lead_time_hours_avg,
  APPROX_QUANTILES(TIMESTAMP_DIFF(first_deploy, issue_created, HOUR), 101)[SAFE_ORDINAL(51)] AS lead_time_hours_p50,
  SUM(CASE WHEN any_failed THEN 1 ELSE 0 END)/COUNT(*) AS change_failure_rate
FROM joined
GROUP BY iso_week
ORDER BY iso_week;

Pythonによるメトリクス集計と通知

週次の自動集計とSlack通知をPythonで行う例です。例外時は安全側に倒すメッセージを送ります。

import os
import json
import datetime as dt
from typing import Dict, Any
from google.cloud import bigquery
import requests

BQ_TABLE = os.getenv("BQ_TABLE", "proj.analytics.weekly_metrics")
SLACK_WEBHOOK = os.getenv("SLACK_WEBHOOK")


def fetch_latest_week() -> Dict[str, Any]:
    client = bigquery.Client()
    query = f"""
        SELECT iso_week, deployments, lead_time_hours_avg, lead_time_hours_p50, change_failure_rate
        FROM `{BQ_TABLE}`
        ORDER BY iso_week DESC
        LIMIT 1
    """
    job = client.query(query)
    rows = list(job)
    if not rows:
        raise RuntimeError("No weekly metrics found")
    r = rows[0]
    return {
        "week": r[0],
        "deployments": int(r[1]),
        "lt_avg_h": float(r[2]),
        "lt_p50_h": float(r[3]),
        "cfr": float(r[4])
    }


def notify(payload: Dict[str, Any]) -> None:
    if not SLACK_WEBHOOK:
        return
    text = (
        f":bar_chart: Weekly Metrics {payload['week']}\n"
        f"Deployments: {payload['deployments']}\n"
        f"LeadTime Avg/P50: {payload['lt_avg_h']:.1f}h / {payload['lt_p50_h']:.1f}h\n"
        f"Change Failure Rate: {payload['cfr']:.2%}"
    )
    try:
        resp = requests.post(SLACK_WEBHOOK, data=json.dumps({"text": text}), timeout=5)
        resp.raise_for_status()
    except Exception as e:
        print(f"Slack notify failed: {e}")


if __name__ == "__main__":
    try:
        latest = fetch_latest_week()
        notify(latest)
    except Exception as e:
        # fail-safe: still inform the channel about missing data
        fallback = {
            "week": dt.date.today().isocalendar(),
            "deployments": 0,
            "lt_avg_h": float("nan"),
            "lt_p50_h": float("nan"),
            "cfr": float("nan")
        }
        notify(fallback)
        raise

GitHub ActionsでPR計測をパイプライン化

PRの作成からマージまでの時間を計測し、BigQueryに積み上げる例です。CIに組み込めば、リードタイムの構成要素を日次で可視化できます。

name: pr-metrics
on:
  schedule:
    - cron: '0 2 * * *'
  workflow_dispatch: {}
jobs:
  export:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - name: Install deps
        run: pip install ghapi google-cloud-bigquery
      - name: Export PRs and load to BQ
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
          GOOGLE_APPLICATION_CREDENTIALS: ${{ secrets.GCP_SA_JSON_PATH }}
        run: |
          python scripts/export_pr_metrics.py || echo "export failed but continuing"

Prometheusルールでガードレールを可視化

改善で攻めに振るときこそ守りを数値化します。変更失敗率が事前閾値を超えたら即座に可視化・通知します。Goodhartの法則（ある指標を目標にすると指標自体が歪む）を避けるためにも、品質側のシグナルを常に併置します。

# prometheus recording & alerting rules
 groups:
 - name: engineering
   interval: 1m
   rules:
   - record: team:change_failure_rate:30d
     expr: sum(increase(deploy_failed_total[30d])) / sum(increase(deploy_total[30d]))
   - alert: ChangeFailureRateTooHigh
     expr: team:change_failure_rate:30d > 0.15
     for: 2h
     labels:
       severity: warning
     annotations:
       summary: "Change failure rate high"
       description: "CFR > 15% over 30d. Consider rollback of experiment."

dbtで週次アグリゲーションを標準化

集計ロジックをアプリ外に出してテスト可能にします。dbtモデルで指標の定義を一元化すると、チームが同じ数字を見る習慣が根付きます。

-- models/weekly_metrics.sql (dbt)
{{ config(materialized='table') }}
SELECT iso_week,
       COUNT(*) AS deployments,
       AVG(lead_time_hours) AS lead_time_hours_avg,
       PERCENTILE_CONT(lead_time_hours, 0.5) OVER() AS lead_time_hours_p50,
       SUM(CASE WHEN failed THEN 1 ELSE 0 END)/COUNT(*) AS change_failure_rate
FROM {{ ref('deploy_events_enriched') }}
GROUP BY iso_week

ケーススタディ：WIP制限とレビュー時刻固定の1ヶ月

注記：以下は実務で一般的な状況を想定した社内計測の例であり、外部公開された平均値や統計ではありません（数値はチームAの例示データ）。DORA指標の定義と解釈は公開資料に準拠しています⁵。

10名規模のWeb開発チームを想定します。ベースラインの4週間では、平均リードタイムが98時間、中央値が64時間、週あたりのデプロイが9回、変更失敗率が12%でした。第2週にカンバンのWIPを「開発中3・コードレビュー2」に設定し、レビューの締切時刻を毎日16時に固定、主要機能のPRは1,000行未満に分割するポリシーを導入しました。モブレビューは重要箇所のみとし、PRの滞留を最小化しました。

結果の3週間は、平均リードタイムが98→74時間（-24%）、中央値が64→44時間（-31%）、デプロイ頻度が9→13回/週（+44%）といった改善が観測された、という想定です。変更失敗率は12→13.5%（+1.5pt）で、事前に設定した増加上限+2ptの範囲内に収まっています。ベンチマークとして、施策を導入しなかったバックオフィス向け小規模プロジェクトの同期間のデータは、リードタイム変化-4%、デプロイ頻度変化+6%であり、外部要因だけでは説明しにくい差分が生じるケースを示しています。

ROIの概算も事前に決めた式で算出します。平均リードタイム短縮が24時間で、そのうち待ち時間短縮が7割とすると、1件あたり17時間のカレンダー短縮です。週あたり13件のデプロイなら、チーム全体で221時間/週の市場投入前倒し効果という試算になります。人件費換算ではなく、売上・CVへの寄与で評価するため、関連施策のA/Bテストの開始・終了時刻が1日早まった割合を追跡します。たとえば広告キャンペーンの入札最適化と連動する場合、改善のタイミングが早まることでコンバージョン率（CVR）が数ポイント程度改善する、といった可能性を評価できます。ここまで数値で語れると、拡大か撤退かの意思決定はブレません。

補助的な実装として、GitHubのコメントBotでPRのサイズ超過をその場で指摘する仕組みを用意しました。これは改善の運用コストを下げ、ポリシーが自然に守られる環境を作る効果があります。

# scripts/pr_guard.py
import os
from ghapi.all import GhApi

MAX_LINES = int(os.getenv("MAX_LINES", "1000"))
OWNER = os.getenv("OWNER")
REPO = os.getenv("REPO")
TOKEN = os.getenv("GH_TOKEN")

api = GhApi(owner=OWNER, repo=REPO, token=TOKEN)

for pr in api.pulls.list(state='open'):
    files = api.pulls.list_files(pr.number)
    added = sum(f.additions for f in files)
    if added > MAX_LINES:
        api.issues.create_comment(pr.number, f"PR too large: {added} lines > {MAX_LINES}. Please split.")

落とし穴と回避策：Goodhartの法則、データ欠損、過剰結論

指標は達成目標になると歪みます。Goodhartの法則を避けるには、複数指標を同時に見ることが有効です⁸。ここでは流量（デプロイ頻度）と時間（リードタイム）に加えて、品質の代理指標として変更失敗率をガードに据えました。どれか1つだけが良くても、他が悪化すれば施策は見直します。もうひとつの落とし穴はデータ欠損です。PRにチケットIDが紐付いていないだけで、リードタイムの起点がズレ、改善効果が過大にも過小にも見えます。観測の自動化を進めるほど、このリスクは下がります⁶。ダッシュボードに「不明データ比率」を常設し、5%を超えたら黄色信号という運用にします。

短期の小改善は外乱に流されやすいため、過剰な結論を避ける工夫も必要です。段階的ロールアウトで擬似対照群を作る、曜日や月末などの季節要因をコメントとして残す、PRサイズや担当者の偏りを補正する、といった素朴な工夫が効きます⁷。統計検定に頼りすぎず、信頼区間の幅とビジネス上の最小効果量で語ります。改善のレビュー会では、数字の解釈だけでなく「運用コスト」にも触れます。たとえばレビュー時刻の固定でメンバーの集中時間が削られていないか、カレンダー・リクエストの増加や会議の再配置といった副作用も事実として扱い、次のサイクルで是正します。

意思決定の材料は最小限で十分です。1枚のビューに、リードタイムの平均・中央値、デプロイ頻度、変更失敗率、欠損率、そして施策開始時刻の垂直線を重ねるだけで、1ヶ月サイクルの成否は読み取れます。可視化は用途に応じて、GrafanaやLooker、Google Data Studioなど既存のツールを使います。運用手引きや実装の詳細も参考になります。

まとめ：1ヶ月だから動ける、数値だから説得できる

改善は意思と根性では続きません。1ヶ月という短いサイクルで始め、ベースラインを採り、観測を自動化し、施策を絞って実験し、閾値で判定する。この地味で反復的な作業こそが、組織を確実に前進させます。重要なのは、着手の早さと、数字で語る習慣です。次のスプリントから、PRとチケットの連結を義務化し、週次のメトリクス通知を流し、ひとつだけ改善を選んで回してみてください。1ヶ月後、あなたは「何が効いたか」を言語化でき、拡大か撤退かを迷いなく決められるはずです。チームの時間を取り戻す最初の一歩は、今日の一本のメトリクスSQLから始まります。

参考文献

  1. The Standish Group International. CHAOS Report 2015. Standish Group; 2015.
  2. Nicole Forsgren, Jez Humble, Gene Kim. Accelerate: The Science of DevOps – Building and Scaling High Performing Technology Organizations. IT Revolution; 2018.
  3. Dina Graves Portman. Are you an Elite DevOps performer? Google Cloud Blog; 2020. https://cloud.google.com/blog/products/devops-sre/are-you-an-elite-devops-performer
  4. Peter Arbright. Using the Plan-Do-Check-Act Framework to Produce Performant and Highly Available Systems. InfoQ; 2021. https://www.infoq.com/articles/pdca-framework/
  5. Atlassian. DORA metrics: How to measure Open DevOps success. https://www.atlassian.com/devops/frameworks/dora-metrics
  6. Reyna Boyle, Chloe Condon, Chris Nesbitt-Smith, et al. Using the Four Keys to measure your DevOps performance. Google Cloud Blog; 2021. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
  7. Ron Kohavi, Diane Tang, Ya Xu. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press; 2020.
  8. Leanne Mitton. What is Goodhart’s Law? Splunk Blog; 2021. https://www.splunk.com/en_us/blog/learn/goodharts-law.html