LESSON 30分

ストーリー

あなた
メッセージキューの候補がKafka、RabbitMQ、SQSの3つに絞られたんですが、どれにすべきでしょうか？
あ

佐藤CTOは微笑みました。

佐
佐藤CTO
机上の比較表は作った？
あなた
はい。スループット、レイテンシ、運用コスト…でも数値だけでは判断しきれなくて
あ
佐
佐藤CTO
当然だ。カタログスペックと実際の挙動は違う。それを確認するのがPoC（Proof of Concept）だ。ただし、PoCには”やり方”がある。闇雲に触って終わりにするのではなく、仮説を立て、検証し、判断する。科学的なアプローチだよ

PoC と技術スパイクの違い

項目技術スパイク（Spike）PoC（Proof of Concept）
目的技術的な不確実性を解消するビジネス要件を満たせるか検証する
期間1-3日1-4週間
スコープ特定の技術的問いに答えるエンドツーエンドの概念実証
成果物知見レポート動くプロトタイプ + 評価レポート
判断基準「できるか/できないか」「要件を満たすか/TCOは妥当か」
例「KafkaのExactly-onceは本当に動くか」「注文処理のイベント駆動化は可能か」

「スパイクは”学習”、PoCは”検証”。スパイクで基礎を理解してから、PoCで本格検証する。この2段階を意識するだけで、無駄な検証が激減する」 — 佐藤CTO

PoC 設計の5ステップ

Step 1: 仮説の明文化

PoCの出発点は「検証したい仮説」の明文化です。

# PoC 仮説シート
poc_id: "POC-2026-003"
title: "Kafkaによる注文イベント処理の検証"

hypotheses:
  - id: H1
    statement: "Kafkaは毎秒10,000注文イベントを処理できる"
    metric: "スループット（events/sec）"
    success_criteria: ">= 10,000 events/sec at p99 < 100ms"

  - id: H2
    statement: "Kafkaのコンシューマーグループで水平スケール可能"
    metric: "スケールファクター"
    success_criteria: "コンシューマー3台→6台でスループット1.8倍以上"

  - id: H3
    statement: "障害時のメッセージロストがゼロ"
    metric: "メッセージロスト数"
    success_criteria: "ブローカー1台停止時にロスト0"

Step 2: タイムボクシング

gantt
    title PoC タイムボクシング（2週間・延長なし）
    dateFormat  X
    axisFormat %s

    section Week 1
    環境構築           :a1, 0, 4
    基本検証（H1）      :a2, 3, 8

    section Week 2
    スケール検証（H2）  :b1, 8, 12
    障害検証（H3）      :b2, 11, 15
    レポート作成        :b3, 13, 16

    section 判定
    Go/No-Go判定        :milestone, m1, 16, 0
タイムボクシングのルール
ルール説明
延長禁止期限内に終わらない = 技術が複雑すぎるシグナル
スコープ調整期限は固定、スコープを調整する
毎日の進捗共有Slackチャンネルに毎日進捗を投稿
Kill条件致命的な問題発見時は即座に中止

Step 3: 評価基準の事前定義

PoCの結果を「感覚」ではなく「基準」で判断するために、評価基準を事前に定義します。

## PoC 評価基準

### Must Have（必須条件 - 1つでも不合格ならNo-Go）
| # | 基準 | 閾値 |
|---|------|------|
| M1 | スループット | >= 10,000 events/sec |
| M2 | データロスト | 0件 |
| M3 | 運用ドキュメントの充実度 | 日本語ドキュメントあり |

### Should Have（推奨条件 - 総合的に判断）
| # | 基準 | 閾値 | 重み |
|---|------|------|------|
| S1 | p99レイテンシ | < 100ms | 30% |
| S2 | 水平スケール効率 | > 80% | 25% |
| S3 | 運用の容易さ | マネージドサービスあり | 25% |
| S4 | チームの習熟コスト | < 2週間 | 20% |

Step 4: 検証の実施

検証の原則:
1. 本番に近い条件で検証する（ネットワーク遅延、データ量）
2. 正常系だけでなく異常系を重点的にテストする
3. 定量データを取得する（感想ではなく数値で）
4. 検証ログを残す（再現可能性の確保）

Step 5: Go/No-Go 判定

# Go/No-Go 判定テンプレート
poc_id: "POC-2026-003"
decision_date: "2026-03-14"

results:
  H1:
    status: "PASS"
    actual: "12,500 events/sec at p99 = 85ms"
    note: "期待以上のパフォーマンス"
  H2:
    status: "PASS"
    actual: "スケールファクター 1.85x"
    note: "ほぼリニアにスケール"
  H3:
    status: "PASS"
    actual: "ブローカー停止時のロスト0件"
    note: "acks=all, min.insync.replicas=2 設定"

must_have_results:
  M1: PASS
  M2: PASS
  M3: PASS

overall_decision: "GO"
conditions:
  - "本番環境ではMSK（Managed Kafka）を使用"
  - "運用チーム向けトレーニングを実施"
next_steps:
  - "ADR-015として技術選定を記録"
  - "Sprint 12で本格実装開始"

PoC レポートのテンプレート

# PoC レポート: [タイトル]

## 概要
- PoC ID: [ID]
- 期間: [開始日] 〜 [終了日]
- 参加者: [名前]
- 判定: GO / NO-GO / 追加検証

## 背景と目的
[なぜこのPoCを実施したか]

## 仮説と検証結果
| 仮説 | 期待値 | 実測値 | 判定 |
|------|--------|--------|------|
| H1   |        |        |      |
| H2   |        |        |      |

## アーキテクチャ概要
[PoC環境の構成図]

## 定量データ
[ベンチマーク結果、グラフ]

## 課題と制約
[発見された課題]

## 推奨事項
[次のアクション]

## 参考資料
[使用したドキュメント、ツール]

複数候補の比較評価

PoCが複数候補の比較である場合、加重スコアリングで評価します。

評価軸重みKafkaRabbitMQSQS
スループット30%5 (1.5)3 (0.9)4 (1.2)
運用容易性25%2 (0.5)3 (0.75)5 (1.25)
チーム習熟度20%2 (0.4)4 (0.8)4 (0.8)
コスト15%3 (0.45)4 (0.6)4 (0.6)
エコシステム10%5 (0.5)3 (0.3)4 (0.4)
合計3.353.354.25

「数値が同じでも、文脈によって答えは変わる。スコアは判断を助ける道具であって、意思決定そのものではない。最終的には”このチームで、このプロジェクトで、この時点で最善か”を考えるんだ」 — 佐藤CTO

まとめ

ポイント内容
スパイク vs PoCスパイクは学習、PoCは検証
仮説駆動「何を検証するか」を明文化してから始める
タイムボクシング期限固定、スコープ調整。延長は禁止
Go/No-Go事前定義した基準に基づき判断する

チェックリスト

  • 技術スパイクとPoCの違いを理解した
  • PoC設計の5ステップを把握した
  • タイムボクシングの重要性を理解した
  • Go/No-Go判定の方法を理解した

次のステップへ

次は演習です。これまで学んだテクノロジーレーダー、ロードマップ策定、Build/Buy/OSS判断、PoC設計を統合して、実際にテクノロジーロードマップを作成してみましょう。

推定読了時間: 30分