ステアリング駆動開発とは：概要

🚀 要件定義が終わると、開発が終わっている

従来の開発では、要件定義→設計→実装→テストに数ヶ月かかるのが当たり前でした。

AI コーディングツール（Claude Code 等）を正しく活用すると、この常識が変わります。要件と設計をドキュメントに落とし込んだ時点で、 AI が実装の大部分を完了させる ことが現実になっています。

つまり「何を作るか」を明確にする作業 = 開発そのものになる。ステアリング駆動開発は、この「AI に何をどう伝えるか」を体系化した手法です。

🏗️ AI 駆動開発におけるステアリングの位置づけ

AI 駆動開発は、AI にコードを書かせるだけでは成立しません。以下の 3 層で成り立っています。

ステアリング駆動開発は最上位層 です。どんなに優秀な AI ツールでも、「何を作るか」が曖昧なら正しいコードは生まれません。逆に、ステアリングで要件と設計が明確になれば、AI は驚くほど正確にコードを生成します。

⚠️ バイブコーディングの限界

「AI に雰囲気で指示を出して、出てきたコードをそのまま使う」— いわゆるバイブコーディングには限界があります。

• コンテキストが揮発する（セッションをまたぐと忘れる）
• 品質が不安定（同じ指示でも結果がブレる）
• 大規模プロジェクトでスケールしない

小さな修正ならこれでも動きます。しかしプロジェクトが大きくなるほど、「何を作るか」の定義が曖昧なまま進めるリスクは大きくなります。

ステアリング駆動開発は、 作業の規模に応じてドキュメントの量を変える ことで、この問題を解決します。バグ修正に 8 ファイルの仕様書は不要ですが、新ドメイン追加には必要です。規模判定によって、過不足のない準備を行います。

🔄 ステアリング駆動開発の統一フロー

すべての作業は以下のフローに従います。

壁打ち → 規模判定 → オーナー承認 → ステアリング作成 → レビュー → 実装 → 完了

壁打ちフェーズ

実装前に背景・目的・スコープを整理します。 壁打ちのスキップは禁止 です。

• なぜこの作業が必要か？
• 何を達成したいか？成功の定義は？
• スコープ（含むもの / 含まないもの）
• リスク・懸念

壁打ちの結果は ADR（Architecture Decision Record）として永続ドキュメントに保存します。

規模判定（S / M / L）

「全タスクにステアリングを適用する」罠を避けることが重要です。 S 規模にステアリングは不要です。

L 規模のシグナル

以下のいずれかに該当すれば L 規模：

• 複数の Bounded Context にまたがる
• 新しいエンティティ・集約を導入する
• 既存アーキテクチャの変更を伴う
• 新しい用語（ユビキタス言語）を導入する

📄 2 層のドキュメント設計

ステアリング駆動開発では、ドキュメントを 2 層に分離します。

永続ドキュメント（docs/）= 北極星

プロジェクトの方向性を定義するドキュメント。ステアリング完了後も残り続けます。

• アーキテクチャ設計書
• API 仕様
• ドメインモデル
• ADR（Architecture Decision Record）

ADR とは、「なぜその技術的判断をしたのか」を記録するドキュメントです。壁打ちフェーズの議論や設計判断を ADR として残すことで、後から「なぜこうなっているのか」を誰でも追跡できます。

作業ドキュメント（.steering/）= 今回の航路

タスクごとに作成し、完了後はアーカイブに移動します。

M 規模（4 ファイル）:

L 規模（8 ファイル）:

上記 4 ファイルに加えて：

✅ 3 つの承認ゲート

ステアリング駆動開発では、 人間が 3 回承認する ことで品質を担保します。

1. 壁打ち後の規模判定承認
   ↓
2. ステアリング作成後のドキュメントレビュー承認
   ↓
3. 実装完了後の受入テスト承認

AI が自動で進めるのではなく、各段階でオーナーが判断します。これが「Humans on the Loop」です。

🗺️ 業界用語との対応

🔧 ステアリングのワークフロー

以下の図は、ステアリング駆動開発の全体フローを示しています。

📚 シリーズ記事