本記事はシリーズ「J-SIX：Japanese SI Transformation」の #5（最終回）です。#0 概要編で全体像を把握してからお読みください。
はじめに — 「ビッグバン移行」はしない
「面白い話だけど、うちの現場では無理だよ」
J-SIX のコンセプトを紹介すると、多くの PM・PL からこう返されます。理由は明白です。進行中のプロジェクトがある。V字モデルで走っている案件を止められない。チームに TDD の経験がない。顧客に説明できない。
その通りです。だからこそ J-SIX は 段階的移行 を前提に設計しました。
本記事では、既存の V字モデル案件を止めずに J-SIX へ移行するための 3ステージ移行マップ を解説します。各ステージの完了基準、投資対効果の試算、レガシーコードへの適用戦略、そして移行を阻む壁と対策を具体的に示します。
「うちでもやれそうだ」と感じていただけたら、本シリーズの目標達成です。
J-SIX の全ドキュメント・テンプレートは GitHub で公開しています。
https://github.com/SeckeyJP/j-six
3ステージ移行マップ
移行の基本戦略は 「既存プロセスの内側から CC を浸透させ、結果として J-SIX に到達する」 ことです。V字モデルを「廃止」するのではなく、各工程で Claude Code（以下CC）活用を深めていくうちに、プロセスが自然に J-SIX に「進化」します。
各ステージで 効果を定量的に確認してから 次に進みます。効果が出なければ無理に進まない。この「段階的な信頼構築」が移行成功の鍵です。
移行マップ全体像
| 要素 | Stage 0（現状） | Stage 1（3ヶ月） | Stage 2（3-6ヶ月） | Stage 3（6ヶ月〜） |
|---|---|---|---|---|
| プロセス | V字 | V字+CC補助 | SDD+V字互換 | J-SIX |
| 自律度 | L0 | L1-L2 | L2-L3 | L3-L4 |
| CLAUDE.md | なし | 基本版 | 拡充版 | 完全版 |
| Spec | なし | なし | 並行導入 | 唯一の上流成果物 |
| ADR | なし | なし | 運用開始 | 全判断を記録 |
| TDD | なし | なし | 新規モジュールのみ | 全面適用 |
| 設計書 | 事前作成 | 事前作成+CC支援 | 二重作成 | 逆生成のみ（3層戦略） |
| 工数削減 | 0% | 20-30% | 40-50% | 60-70% |
※ 工数削減率は著者推定の目標値です。個別事例では40-80%の生産性向上が報告されていますが1、組織全体への適用時は控えめに見積もっています。
Stage 1: V字 + CC 補助（3ヶ月）
何が変わり、何が変わらないか
変わらないもの: V字モデルのプロセスそのもの。要件定義、基本設計、詳細設計、実装、テストの流れは従来通りです。
変わるもの: 各工程で CC を補助的に活用します。
| 工程 | CC の活用方法 | 自律度 |
|---|---|---|
| 要件定義 | 要件の曖昧性チェック、業務フロー図の下書き生成 | L1 |
| 基本設計 | 設計書ドラフトの生成支援 | L1 |
| 詳細設計 | 詳細設計書のドラフト生成 | L1 |
| 実装 | コード生成 + 人間レビュー | L2 |
| UT | テストコード自動生成 | L2 |
| IT/ST | テストケース生成支援 | L1 |
最もインパクトが大きいのは 実装とUT です。CC がコードを生成し、人間が全てレビュー・承認する（L2）運用から始めます。
この段階で導入するもの
- CLAUDE.md（基本版） — コーディング規約、ディレクトリ構成、ビルド/テストコマンドを記述。CC へのプロジェクトルール伝達が目的です
- 効果計測の仕組み — CC 活用/非活用の工数比較、CC 生成コードの品質メトリクス、開発者の満足度調査
この段階で導入しないもの
TDD、設計書逆生成、ADR、サブエージェント、Hooks はまだ導入しません。既存プロセスを維持しながら CC 活用スキルを蓄積することに集中します。
Stage 1 完了基準
| 基準 | 閾値 |
|---|---|
| CC 活用による実装工数削減率 | 20%以上 |
| CC 生成コードのバグ密度 | 人間コードの2倍以内 |
| CC 生成テストのカバレッジ | 60%以上 |
| 開発者の CC 操作習熟度 | チーム全員が日常的に使用 |
| CLAUDE.md の充実度 | コーディング規約・ビルドコマンドが網羅 |
※ 閾値は著者推奨の目安です。組織の品質基準に応じて調整してください。
ポイント: Stage 1 は「リスクが最も低いステージ」です。既存プロセスを一切変えないため、仮にうまくいかなくてもダウンサイドはCCのサブスクリプション費用のみ。これが経営層への説得材料になります。
Stage 2: CC 駆動ハイブリッド（3-6ヶ月）
何が変わるか
V字モデルの骨格は維持しつつ、内部のプロセスをCC駆動に置き換えていきます。
| 工程 | 変化のポイント | 自律度 |
|---|---|---|
| 要件定義 | Spec 作成の開始（従来の要件定義書と並行） | L2 |
| 基本設計 | Design Spec + プロトタイプ駆動（従来設計書も並行） | L2 |
| 詳細設計 | タスク分解（CC提案→人間承認） | L2 |
| 実装 | 新規モジュールで TDD 導入 | L3 |
| UT | CC 自律実行（新規モジュール） | L3 |
| IT/ST | Spec からテストケース自動生成 | L2 |
| （新規） | ADR の運用開始 | L2 |
この段階で導入するもの
- CLAUDE.md（拡充版） — 設計方針・品質基準・ADRルール・禁止事項を追加
- Spec テンプレート — 要求 Spec・Design Spec のテンプレート
- ADR テンプレート + 運用ルール — 設計判断の記録を習慣化
- Hooks（基本セット） — pre-commit での lint + カバレッジチェック
- サブエージェント（TDD用） — Red Agent / Green Agent / Refactor Agent の分離
- 設計書逆生成の試行 — 一部モジュールで逆生成を試行し、従来設計書と品質を比較
「二重作成」の意義
Stage 2 の要は 設計書の二重作成 です。一部のモジュールについて、従来方式の設計書と逆生成設計書の両方を作成します。
目的は3つあります。
- 逆生成設計書の品質を 定量的に評価 する
- 顧客・QA部門に逆生成設計書の 実物を見せ、受容性を確認 する
- 「従来設計書と同等以上」の エビデンスを蓄積 する
二重作成はコストがかかりますが、このエビデンスなしに Stage 3（逆生成のみ）への移行は困難です。投資と考えてください。
Stage 2 完了基準
| 基準 | 閾値 |
|---|---|
| TDD 導入モジュールの品質 | 非TDDモジュールと同等以上 |
| CC 自律実行（L3）の安定性 | エスカレーション率 20%以下 |
| 逆生成設計書の品質 | 従来設計書と同等（レビューア評価） |
| ADR の運用定着 | 主要な設計判断の80%以上が ADR 化 |
| Spec → タスク → 実装 のフロー | 新規モジュールで安定稼働 |
| 開発工数削減率 | 40%以上（Stage 0 比） |
Stage 3: J-SIX 全面適用（6ヶ月〜）
Stage 2 からの変化
| 観点 | Stage 2 | Stage 3（J-SIX） |
|---|---|---|
| 設計書 | 従来方式 + 逆生成の二重作成 | 逆生成のみ（3層戦略） |
| TDD | 新規モジュールのみ | 全モジュール |
| 自律度 | L2-L3（部分自律） | L3-L4（全面自律） |
| 並列実行 | 単一セッション中心 | Agent Teams + git worktree |
| Spec | 従来設計書と並行 | Spec が唯一の上流成果物 |
この段階で導入するもの
- Agent Teams — 並列タスク実行の本格化
- git worktree 運用 — 並列作業空間の確保
- Writer/Reviewer パターン — CC 相互レビューの本格運用
- 品質ダッシュボード — リアルタイム品質監視
- 設計書逆生成の全面移行 — 従来方式の事前作成を廃止
顧客への合意形成
Stage 3 への移行には顧客の合意が必要です。以下のエビデンスを提示します。
| 提示するエビデンス | 説得力のポイント |
|---|---|
| Stage 1-2 の工数削減実績 | 「40%以上の工数削減」という実績 |
| 逆生成設計書の品質比較結果 | 「従来設計書と同等以上」のエビデンス |
| 品質メトリクスの推移 | バグ密度・カバレッジの改善トレンド |
| ADR による設計判断の可視化 | 「従来より設計根拠が明確」の実証 |
ROI 試算 — 投資対効果を試算する
以下は仮定条件に基づく 試算 です。実際の効果はプロジェクト特性により異なります。
前提条件
| 項目 | 値 |
|---|---|
| プロジェクト規模 | 中規模（10人月相当） |
| 開発者数 | 5名 |
| CC サブスクリプション | Max 5x（$100/月/人）※2026年3月時点 |
| 開発者月額人件費 | 80万円/人（著者仮定） |
ステージ別 ROI
| ステージ | CC費用（月額） | 工数削減率 | 削減額（月額） | 月次ROI |
|---|---|---|---|---|
| Stage 1 | 約7.5万円 | 25%（著者推定） | 約100万円 | +92.5万円 |
| Stage 2 | 約7.5万円 | 45%（著者推定） | 約180万円 | +172.5万円 |
| Stage 3 | 約7.5万円 | 65%（著者推定） | 約260万円 | +252.5万円 |
※ API 利用料が別途発生する場合は追加コストとなります。ただし工数削減効果に比べれば少額です。
※ Stage 1 の導入初期は学習コストにより効果が低く、月を追って改善する想定です。
※ 工数削減率は各種事例報告12を基にした著者推定の目標値であり、大規模な実証データに基づくものではありません。
経営層への3つのポイント
- Stage 1 の投資回収は即月 — CC費用7.5万円に対し、25%の工数削減で約100万円相当の効果
- リスクは限定的 — Stage 1 は既存プロセスを変えないため、失敗してもダウンサイドが小さい
- 段階的投資 — 効果を確認しながら次ステージに進むため、大型投資リスクなし
レガシーコードへの適用 — 「島を作る」戦略
「新規開発なら分かるが、既存システムの保守案件ではどうすればいい？」
この疑問に対する回答が 「島を作る」戦略 です。
基本方針
レガシーコードベース全体を一度に J-SIX 化するのは非現実的です。代わりに、レガシーの海の中に J-SIX の島 を作り、島を徐々に拡大します。
レガシーコードベース（テストなし、密結合）
┌─────────────────────────────────────────────┐
│ │
│ ┌───────────┐ │
│ │ J-SIX 島 │← 新規モジュールはここに作る │
│ │(TDD, Spec)│ │
│ └─────┬─────┘ │
│ │ Anti-Corruption Layer（腐敗防止層）│
│ │ │
│ レガシーコード │
│ │
└─────────────────────────────────────────────┘
Anti-Corruption Layer（腐敗防止層） を J-SIX 島とレガシーコードの間に置き、レガシーの設計が島に侵食するのを防ぎます。これは Eric Evans のドメイン駆動設計で提唱された概念を応用したものです。
4ステップの適用手順
| ステップ | 内容 | 自律度 |
|---|---|---|
| Step 1: 理解 | CC でレガシーコードを読み解く。アーキテクチャ概要・技術スタック・暗黙のビジネスルールを分析 | L1 |
| Step 2: テストで囲む | 変更対象の周囲に特性化テストを書く。「正しい振る舞い」ではなく「現在の振る舞い」を記録するテスト3 | L2 |
| Step 3: 島を作る | 新規コードは J-SIX（TDD）で書く。Strangler Fig パターン4で旧実装を徐々に置き換え | L3 |
| Step 4: 島を広げる | リファクタリング時にレガシーを段階的に J-SIX 品質に引き上げ | L2-L3 |
重要な注意点: レガシーコードでは CC の自律度をいきなり L3 に上げないでください。CC の理解が不十分な領域では、まず L1-L2 で信頼を構築してから段階的に引き上げます。
CC がレガシーコードで特に有効な場面
- コードの読解・ドキュメント生成 — 人間が数日かかる分析を数時間で完了
- 特性化テストの生成 — 既存の振る舞いを網羅的にテスト化
- 定型的なリファクタリング — 命名統一、型追加、エラーハンドリング統一
- ADR の遡及作成 — 過去の設計判断をコードから推測して記録
移行を阻む壁と対策
移行を成功させるには、技術だけでなく 組織・顧客 の壁にも向き合う必要があります。3つの軸で整理します。
組織の壁
| 壁 | 対策 |
|---|---|
| 「V字モデルで問題ない」という保守意識 | Stage 1 の効果を定量的に示す。「問題ない」ではなく「もっと良くなる」の訴求 |
| CC に仕事を奪われる不安 | SE/PG の役割が「AI開発オーケストレーター」に進化することを明示。スキルアップの機会として位置づけ |
| 経営層の ROI 懸念 | Stage 1 の投資対効果を早期に算出。月額7.5万円 vs 工数削減効果の比較 |
| QA 部門の抵抗 | QA の役割を「テスト戦略策定 + サンプリング検証」に再定義。探索的テストの重要性を強調 |
技術の壁
| 壁 | 対策 |
|---|---|
| TDD の経験がない | Stage 2 で新規モジュールから段階的に導入。CC が TDD サイクルを主導するため、学習コストは従来のTDD導入より低い |
| レガシーコードへの適用 | 前述の「島を作る」戦略で段階的に対応 |
| CLAUDE.md の書き方がわからない | テンプレートとガイドを GitHub で公開中。シリーズ #4 で詳述 |
| セキュリティ懸念（コードの外部送信） | Anthropic API の利用規約を確認。Enterprise プラン + VPC 環境の検討5 |
顧客の壁
| 壁 | 対策 |
|---|---|
| 「設計書を先に見せろ」という要求 | Stage 2 で Spec + プロトタイプの有効性を実証。「動くもの」でレビューする文化を段階的に提案 |
| 「AI生成コードは信頼できない」 | 品質メトリクスの継続的提示。「人間が全てレビュー」の保証（Stage 1-2） |
| 契約上の成果物要件 | 逆生成設計書が契約要件を満たすことを Stage 2 で実証。必要に応じて契約内容の更新を交渉 |
「顧客が事前設計書を求める場合」は、段階的に対応します。短期では Design Spec + プロトタイプを「基本設計書相当」として提出し、中期で Spec + プロトタイプ + ADR を設計書の代替として合意を目指します。
明日からの3ステップ
ここまで読んで「やってみよう」と思った方へ。明日からできる具体的な3ステップです。
Step 1: CLAUDE.md を書く（所要: 1-2時間）
プロジェクトのコーディング規約、ディレクトリ構成、ビルド/テストコマンドを記述します。テンプレートを公開しています。
Step 2: 小さなタスクで CC を使ってみる（所要: 半日）
新規コードの生成やテストコードの作成で CC を試してください。人間がレビュー・承認する前提（L2）で運用します。いきなり大きなタスクを任せるのではなく、小さく始めることが重要です。
Step 3: 効果を計測する（所要: 継続的に）
CC 活用/非活用の工数比較を記録します。CC 生成コードのバグ密度も追跡してください。このデータが Stage 2 への移行判断、そして経営層・顧客への説得材料になります。
まとめ — 「進化」は段階的にしか起こらない
J-SIX への移行は、V字モデルを「捨てる」ことではありません。各工程で CC 活用を深めていくうちに、プロセスが自然に進化していく道筋です。
- Stage 1 はリスクが極小。既存プロセスを変えず、CC を補助的に使うだけ
- 効果を確認してから次に進む。定量データが次ステージへの根拠になる
- レガシーコードにも適用できる。「島を作る」戦略で段階的に対応
- 壁は技術だけではない。組織・顧客の壁にも計画的に対処する
J-SIX は著者のオリジナル設計であり、提示した工数削減率や ROI は推定目標値です。大規模な実証データはまだありません。しかし、Stage 1 のリスクの小ささを考えれば、「まず試してみる」のハードルは低いはずです。
本シリーズが、日本の SI 開発の進化を考えるきっかけになれば幸いです。
シリーズ記事
| # | タイトル | 状態 |
|---|---|---|
| #0 | J-SIX 概論 — なぜ今、日本のSI開発プロセスを再設計するのか | 公開済 |
| #1 | V字モデルの前提崩壊と SDD の台頭 | 公開済 |
| #2 | 3層ドキュメント戦略 — 設計書は「逆生成」の時代へ | 公開済 |
| #3 | TDD × Claude Code — 自律実行で生産性を最大化する | 公開済 |
| #4 | CLAUDE.md 実践ガイド — AI開発の「プロジェクト憲法」を書く | 公開済 |
| #5 | 本記事（段階的移行） | ✅ |
参考文献・リンク
J-SIX プロジェクト
引用・参考
-
Anthropic. "How Anthropic teams use Claude Code" (2025.07). https://claude.com/blog/how-anthropic-teams-use-claude-code ↩ ↩2
-
DataCamp. "Claude Code Best Practices" (2026.03). https://www.datacamp.com/tutorial/claude-code-best-practices ↩
-
Michael Feathers. "Working Effectively with Legacy Code" (2004). 特性化テスト、レガシーコード改善手法の原典 ↩
-
Martin Fowler. "StranglerFigApplication". https://martinfowler.com/bliki/StranglerFigApplication.html ↩
-
Anthropic. "Claude Code and new admin controls for business plans". https://www.anthropic.com/news/claude-code-on-team-and-enterprise ↩