本記事はシリーズ「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%の生産性向上が報告されていますが¹、組織全体への適用時は控えめに見積もっています。

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 の導入初期は学習コストにより効果が低く、月を追って改善する想定です。
※ 工数削減率は各種事例報告¹²を基にした著者推定の目標値であり、大規模な実証データに基づくものではありません。

経営層への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: テストで囲む	変更対象の周囲に特性化テストを書く。「正しい振る舞い」ではなく「現在の振る舞い」を記録するテスト³	L2
Step 3: 島を作る	新規コードは J-SIX（TDD）で書く。Strangler Fig パターン⁴で旧実装を徐々に置き換え	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 環境の検討⁵

顧客の壁

壁	対策
「設計書を先に見せろ」という要求	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 ↩ ↩²
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 ↩