ベテランプログラマが警告「Scrumは開発チームを無能化する」25年のキャリアから

何が起きたか

ソフトウェア開発業界で、Scrum手法への根本的な批判が改めて注目を集めている。発端は25年のソフトウェア開発経験を持つエンジニアによる告発的なブログ記事。「Scrumはシニアエンジニアを無能化する」という主張が、HackerNewsやRedditで数百件のコメントを集めた。

批判の核心はポーカープランニングにある。複数人で同時にストーリーポイントを提示し、乖離を議論するこの手法を「計画ツールではなく、単なる儀式」と断じる。見積もり数値が実装工数の精度向上に直結しない一方で、1回のプランニングセッションに1〜3時間を費やすチームは珍しくない。

より広い文脈では、アジャイルへの「疲労感」が業界全体で蓄積しつつある。2001年のアジャイル宣言から四半世紀が過ぎ、当初の思想が形骸化したプロセスに変質したという指摘は、今回の記事に限った話ではない。

Scrumの何が問題か：具体的なコスト構造

Scrumの標準的なセレモニーを週ベースで積算すると、その重さが見えてくる。2週間スプリントの場合、1スプリントあたりに消費される会議時間の目安は次のとおり。

週40時間労働を前提とすると、セレモニーだけで週4.5〜9時間、つまり実装時間の10〜25%を占める計算になる。シニアエンジニアほどコンテキストスイッチのコストが高く、断片化した作業時間のダメージが大きい。

さらに深刻なのはスプリント単位の区切りによる問題。複雑なアーキテクチャ上の判断やリファクタリングは「次のスプリントで」と先送りされ続け、技術的負債が積み上がる構造が生まれる。

開発生産性を計測する：時間比率の可視化

この問題を実務で検証するには、実装時間と会議時間の比率を計測するのが第一歩。以下のコマンドは、Gitコミットログから開発活動の時間分布を大まかに把握する手法。

# 直近30日のコミット頻度を時間帯別に集計
git log --since="30 days ago" --format="%ad" --date=format:"%H" \
  | sort | uniq -c | sort -k2 -n

# コミット間隔の統計（集中度の指標）
git log --since="30 days ago" --format="%at" \
  | awk 'NR>1{diff=$1-prev; if(diff<3600) sum+=diff; count++} {prev=$1} END{print "avg gap:", sum/count/60, "min"}'

# 特定期間のコミット数（スプリント前後比較）
git log --after="2026-03-01" --before="2026-03-15" --oneline | wc -l
git log --after="2026-03-15" --before="2026-04-01" --oneline | wc -l

会議記録と突き合わせて「スプリント計画日の翌日はコミットが減る」「レトロ週はアウトプットが下がる」といったパターンが見えれば、プロセス見直しの根拠となる。

3つのアプローチの比較：ワークフロー構造の違い

flowchart LR
    subgraph Scrum["Scrum"]
        A[バックログ] --> B[スプリント計画]
        B --> C[2週間スプリント]
        C --> D[レビュー&レトロ]
        D --> A
    end

    subgraph Kanban["Kanban"]
        E[バックログ] --> F{WIP制限}
        F -->|空きあり| G[進行中]
        F -->|上限到達| H[ブロック中]
        G --> I[完了]
    end

    subgraph Freeform["自由形式（経験則）"]
        J[優先課題] --> K[直接実装]
        K --> L{問題発生?}
        L -->|Yes| M[同期・相談]
        L -->|No| N[継続]
        M --> K
    end

3つのアプローチの根本的な違いは「同期タイミングの設計思想」にある。Scrumは定期同期を前提とし、Kanbanはフローの詰まりを可視化することで非同期を保つ。自由形式は問題発生時にのみ同期する、いわばイベント駆動型。

チームの状況別：どのアプローチが合うか

CI/CDと組み合わせた軽量プロセス設計

Scrumの批判者が共通して提案する代替案の一つが、デプロイ頻度自体を進捗指標にするアプローチ。会議でバーンダウンチャートを議論するより、継続的デリバリーの実績値が客観的な進捗証跡になるという考え方。

以下は GitHub Actions でデプロイ頻度とリードタイムを自動計測するワークフロー例。

# .github/workflows/deploy-metrics.yml
name: Deploy Metrics

on:
  push:
    branches: [main]

jobs:
  track-metrics:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Calculate lead time
        run: |
          # 最新コミットのタイムスタンプ
          COMMIT_TIME=$(git log -1 --format="%ct")
          DEPLOY_TIME=$(date +%s)
          LEAD_TIME=$(( (DEPLOY_TIME - COMMIT_TIME) / 3600 ))
          echo "Lead time: ${LEAD_TIME}h" >> $GITHUB_STEP_SUMMARY

      - name: Count deploys this month
        run: |
          DEPLOYS=$(gh run list \
            --workflow=deploy-metrics.yml \
            --status=success \
            --created=">=2026-04-01" \
            --json=createdAt \
            --jq='length')
          echo "Deploys this month: ${DEPLOYS}" >> $GITHUB_STEP_SUMMARY
        env:
          GH_TOKEN: $

このデータを蓄積することで「会議を増やしてもリードタイムは下がらない」「デプロイ頻度が上がるほどMTTR（障害復旧時間）が短い」といったDORA指標ベースの改善ループを回せる。

Jira/Linear でのアジャイルツール設定例

プロセス変更を試みる際、ツール設定から入るチームも多い。Linearを使った軽量スプリント設定の例を示す。

// linear-config.json（チームテンプレート）
{
  "team": {
    "cycleEnabled": true,
    "cycleDuration": 14,
    "cycleCooldownTime": 1,
    "cycleStartDay": 1,
    "triageEnabled": false,
    "estimationType": "notUsed"
  },
  "workflow": {
    "states": [
      { "name": "Backlog", "type": "backlog" },
      { "name": "In Progress", "type": "started", "wipLimit": 2 },
      { "name": "In Review", "type": "started", "wipLimit": 3 },
      { "name": "Done", "type": "completed" }
    ]
  },
  "integrations": {
    "github": {
      "autoCloseOnMerge": true,
      "branchNamingPattern": "{issueId}-{issueTitle}"
    }
  }
}

注目点は estimationType: "notUsed" の設定。ストーリーポイント見積もりを完全に廃止し、デプロイ済みタスク数とサイクルタイムをKPIに置き換える設計。ポーカープランニング廃止の第一歩として採用するチームが増えている。

Apache Airflowのようなワークフローオーケストレーションツールでも、同様の「プロセス計測・可視化」の考え方が応用できる。パイプラインのレイテンシを継続的に計測し、ボトルネックを特定するアプローチは、開発プロセス改善とほぼ同じ構造。

批判への反論と限界

Scrumを擁護する側の主張も根拠がある。新人比率が高いチームや、要件が頻繁に変わる環境では、スプリント区切りによる強制的な方向修正が実際に機能する。デイリースタンドアップがなければ、ブロッカーが数日間放置されるケースも現実にある。

React Scanのようなパフォーマンス計測ツールが「計測なき最適化は無意味」という前提に立つように、プロセス改善も計測が先。感覚論でScrumを否定するのではなく、実際の会議時間・デプロイ頻度・バグ率を計測した上で判断するのが合理的なアプローチ。

またClearMLのような実験管理ツールが示すように、MLOpsの世界では「実験の再現性」のためにプロセスの形式化が不可欠な場面もある。プロセスの価値はチームのコンテキストに依存する。

25年のキャリアを持つエンジニアが「Scrumは有害」と断言できるのは、プロセスなしで機能する信頼関係とスキルセットが揃っているから。その前提が崩れる状況では、形式的なプロセスが「最低限の品質保証」として機能する現実も無視できない。

参照ソース

• Agile Manifesto（アジャイル宣言）
• The Scrum Guide（2020年版）
• DORA - Accelerate State of DevOps Report

この記事はAI業界の最新動向を速報でお届けする「AI Heartland ニュース」です。