🏉
品質を落とさずBlazor化を加速する秘訣〜SDD（仕様駆動開発）で変わる開発フロー〜

kossssss
2025/10/02に公開
 導入部：前回記事からの続きこんにちは。39歳の中国人エンジニアです。前回は「レガシーC#開発者がDevinと向き合った現実」というテーマで、AI駆動開発の幻想と現実についてお話しさせていただきました。ありがたいことに、この記事は6,250PVを超える多くの皆様に読んでいただき、たくさんの共感の声をいただきました。本当にありがとうございます。
前回の記事では、Devinという強力なAIエージェントをレガシーなWindowsアプリケーション開発に導入しようと奮闘し、最終的に「戦場を変える」という決断に至るまでをお話ししました。つまり、Devinが活躍できるモダンな環境、具体的にはBlazorへのコンバートを進めるという戦略です。
しかし、僕たちの戦いはまだ始まったばかりです。Blazor化という新しい戦場に足を踏み入れた僕たちを待ち受けているのは、また別の、しかし根深い問題です。それは、「品質をどう担保するか」という、ソフトウェア開発の根源的な課題です。
レガシーシステムには、長年の運用で培われた暗黙知が大量に存在します。仕様書は古く、メンテナンスもされていない。そんな中で、見た目だけを真似てBlazorにコンバートしても、本当に正しいものができる保証はありません。実際に、Blazor化プロジェクトが始まってすぐに、僕たちはこの問題に直面しています。
仕様の曖昧さ: 既存の機能がどのような仕様で動いているのか、誰も正確に把握していない。
チーム間の認識齟齬: 同じ機能について、開発者、テスター、ステークホルダーの間で認識がバラバラ。
品質の低下: 見た目は同じでも、細かい挙動が違う。エッジケースが考慮されていない。
「戦場を変える」だけでは不十分だということが分かってきました。新しい戦場で戦うための、新しい戦術が必要です。品質を落とさずに、むしろ向上させながら、Blazor化を加速させる。そんな夢のような方法はないものか。
そんな悩みを抱えている僕が最近出会ったのが、「SDD（仕様駆動開発）」という考え方と、それを強力にサポートする「cc-sdd」というツールです。この記事では、僕たちがどのようにしてSDDを導入しようとしているのか、そして現在進行中の取り組みの中で見えてきた可能性と課題について、リアルな奮闘の記録をお届けします。

 第1章：Blazor化で見えてきた「基本設計書の壁」

僕たちのプロダクト開発は「スクラム & V字モデル開発」という手法(詳しくは弊社畠山のC#開発におけるAIを使った基本設計書作成と効果の検証をご確認ください)を採用しています。アジャイルの柔軟性とウォーターフォールの品質管理を組み合わせたアプローチです。しかし、Blazor化プロジェクトが本格的に始動すると、ある重要な問題が浮き彫りになってきました。
それは、「基本設計書がない」という問題です。
僕たちは既にDevinやCursorといったAIツールを導入していますが、その精度に課題を感じていました。なぜAIの精度が上がらないのか。その答えは、開発プロセスの中にありました。V字モデルの基本設計フェーズで、AIを効果的に活用するための土台が不足していたのです。
基本設計書の不足は、特に以下の場面で深刻な問題となっています：
AS-IS分析: 既存システムの現状分析を行う際、仕様が明文化されていないため、分析に膨大な時間がかかる
リグレッションテスト: 既存機能への影響を検証する際、何をテストすべきかが不明確
プロダクト知識の属人化: 基本設計はプロダクト知識が必要で属人性が強く、特定の人に依存してしまう
社内からも「設計書がない」という声が多く上がっており、これがBlazor化の大きな障壁となっています。AIツールを使ってコードを生成しても、そのコードが本当に正しいのか、既存システムとの整合性は取れているのか、判断する基準がないのです。
「Cursor×ソースコード」という組み合わせで開発を進めようとしても、ソースコードだけでは情報の抽象度が低すぎて、AIが適切な判断を下すのが困難です。また、トークン消費量も多くなり、コスト面でも課題があります。
このままでは、Blazor化プロジェクトの品質を担保することができません。僕たちは、根本的なアプローチの見直しを迫られています。

 第2章：SDD（仕様駆動開発）との出会い
そんな八方塞がりの状況で、僕が最近出会ったのが「cc-sdd」というツールと、その背景にある「SDD（仕様駆動開発）」という考え方です。
cc-sddは、GitHubで公開されているオープンソースのツールで、AI駆動開発のライフサイクル（AI-DLC）をサポートします。その最大の特徴は、開発プロセスを「要件 → 設計 → タスク → 実装」という明確なステップに分け、各段階で品質を確保するための仕組み（品質ゲート）を提供することです。
SDD（Spec-Driven Development）とは、その名の通り「仕様書を駆動する開発」です。つまり、まず最初にしっかりとした仕様書を作成し、その仕様書に基づいて開発を進める。当たり前のことのように聞こえるかもしれませんが、AI駆動開発の文脈では、これが非常に重要な意味を持つと考えています。
従来の開発フローでは、曖昧な指示からAIがコードを生成し、それを人間が修正するという、いわば「行き当たりばったり」の開発になりがちです。しかし、SDDでは、まず人間がAIと協力して仕様を明確にし、その仕様に基づいてAIがコードを生成する。これにより、AIの能力を最大限に引き出しつつ、品質を確保することができるのではないかと期待しています。
僕たちは、このSDDという考え方に、Blazor化プロジェクトが抱える問題を解決するヒントを見出そうとしています。仕様書がないなら、作ればいい。それも、AIの力を借りて、効率的に。cc-sddツールは、まさにそのための武器になりそうです。

 第3章：cc-sddツールの実践導入
cc-sddツールの導入は、驚くほど簡単でした。npxコマンド一発で、プロジェクトに必要な設定ファイルと、10個の強力なスラッシュコマンドがインストールされます。
npx cc-sdd@latest --lang ja
インストールが完了すると、プロジェクトのルートディレクトリに.claude（または.geminiなど）というディレクトリが作成され、その中にコマンドの定義ファイルが格納されます。これにより、IDEのチャット機能などから、/kiro:spec-initといったスラッシュコマンドを使って、SDDのワークフローを開始できるようになります。
cc-sddが提供する10個のスラッシュコマンドは、SDDの各フェーズに対応しています：
/kiro:spec-init: 新しい仕様の作成を開始
/kiro:spec-requirements: 要件定義を生成
/kiro:spec-design: 設計書を生成
/kiro:spec-tasks: 実装タスクを生成
/kiro:spec-impl: 実装コードを生成
/kiro:steering: プロジェクトの全体像をAIに学習させる（プロジェクトメモリ）
/kiro:validate-gap: 既存コードと要件のギャップを分析
/kiro:validate-design: 設計の妥当性を検証
/kiro:validate-impl: 実装コードの妥当性を検証
/kiro:spec-all: 全てのフェーズを一括で実行
特に注目しているのが、/kiro:steeringコマンドです。これは、プロジェクトのソースコード全体をAIに読み込ませ、アーキテクチャやコーディング規約、ドメイン知識などを学習させる機能です。これにより、AIはプロジェクトの文脈を理解した上で、より精度の高いコードを生成できるようになると期待しています。
僕たちは、まずこの/kiro:steeringコマンドを使って、既存のレガシーシステムのソースコードをAIに学習させることから始めています。そして、Blazor化対象の機能について、/kiro:spec-initから順にコマンドを実行し、仕様書を作成していこうと計画しています。

 第4章：実際のBlazor化プロジェクトでの適用理論は分かりました。次は実践です。僕たちは、ある比較的独立した機能を選び、cc-sddを使ったBlazor化を試みています。そのプロセスは、以下のように進めようと考えています。
1. 既存機能の仕様抽出
まず、/kiro:steeringでレガシーシステムのコードを学習させたAIに対して、対象機能のソースコードを提示し、/kiro:spec-requirementsコマンドを実行する予定です。AIがソースコードを解析し、要件定義を生成してくれることを期待しています。これまで人間が何時間もかけて解読していた暗黙知が、数分でドキュメント化されるかもしれません。
2. Blazor版の要件定義
次に、生成された要件定義をベースに、Blazor版で変更・追加したい要件を追記する計画です。ここでのポイントは、AIが生成したドキュメントを鵜呑みにせず、必ず人間の目でレビューし、修正を加えることです。
3. 設計フェーズでの品質チェック
修正した要件定義を基に、/kiro:spec-designコマンドを実行し、設計書を生成しようと考えています。設計書には、コンポーネントの構成やデータの流れ、APIのインターフェースなどが詳細に記述されることを期待しています。僕たちは、この設計書をチーム全員でレビューし、設計の妥当性を検証する予定です。/kiro:validate-designコマンドを使えば、設計書と要件定義の整合性をAIがチェックしてくれるので、レビューの効率も向上するのではないかと期待しています。
4. タスク分割と実装
設計書が固まったら、/kiro:spec-tasksで実装タスクを生成します。タスクは、1つ1つが具体的な実装内容になっており、開発者は迷うことなくコーディングに集中できるはずです。そして、各タスクについて/kiro:spec-implコマンドを実行すると、AIが実装コードを生成してくれると期待しています。
このワークフローを実践することで、これまで曖昧だった仕様が明確になり、チーム間の認識のズレがなくなることを期待しています。手戻りが減り、開発スピードが向上し、そして何より、生成されるコードの品質が向上することを願っています。

 第5章：チーム全体への展開計画と期待される効果
一部の機能でSDDの効果を検証した後は、この取り組みをチーム全体に展開していく予定です。最初は、新しいツールの導入に戸惑うメンバーもいるかもしれませんが、実際にその効果を目の当たりにすれば、積極的にSDDを使いこなすようになってくれることを期待しています。
SDDの導入は、開発チーム内だけでなく、ステークホルダーとのコミュニケーションにも良い影響を与えるのではないかと考えています。これまで、開発者とステークホルダーの間では、専門用語の壁や認識のズレから、しばしばコミュニケーションの齟齬が生じていました。しかし、cc-sddが生成する仕様書や設計書は、自然言語で書かれており、非エンジニアにも理解しやすいはずです。これにより、ステークホルダーも開発の初期段階からレビューに参加できるようになり、認識のズレを早期に発見・修正できるようになることを期待しています。
仕様が可視化されることで、チーム全体の生産性は向上するはずです。無駄な手戻りがなくなり、開発者はより創造的な作業に集中できるようになる。そして、前回の記事で触れたDevinとの組み合わせも、SDDの導入によって、ついにその真価を発揮し始めるのではないかと期待しています。明確な仕様とタスクがあれば、Devinは驚くべきスピードで高品質なコードを生成してくれるはずです。SDDは、Devinという強力なエンジンを動かすための、最高の燃料になりそうです。

 第6章：SDD導入の課題と対策もちろん、SDDの導入は順風満帆に進むとは限りません。いくつかの課題が予想されます。
導入時の抵抗: 新しいツールやプロセスに対する、一部のメンバーからの心理的な抵抗があるかもしれません。これに対しては、まず小さな成功事例を作り、その効果を具体的に示すことで、徐々に理解を得ていこうと考えています。
仕様作成の工数増加: 最初に仕様書を作成する分、初期の工数は増加するでしょう。しかし、これは後工程での手戻りを防ぐための「前払いコスト」です。長期的には、全体の工数を削減できることを、データを示して説明していく予定です。
ツール習得のコスト: cc-sddは強力なツールですが、その機能を最大限に引き出すには、ある程度の学習が必要です。僕たちは、チーム内で勉強会を開いたり、ペアプログラミングでノウハウを共有したりすることで、学習コストを最小限に抑えようと計画しています。
重要なのは、SDDを「銀の弾丸」と捉えず、チームの状況に合わせて、継続的にプロセスを改善していくことです。僕たちも、まだ手探りの状態です。しかし、SDDという共通の言語と羅針盤を手に入れることで、チームは確実に正しい方向に進んでいけるのではないかと期待しています。

 結び：品質とスピードの両立への挑戦現在、僕たちのBlazor化プロジェクトは、品質とスピードのジレンマに直面しています。スピードを求めれば品質が犠牲になり、品質を求めればスピードが犠牲になる。しかし、SDDとcc-sddツールは、その両立を可能にしてくれるのではないかと期待しています。
仕様という名の土台を固めることで、僕たちは自信を持って開発を進めることができるようになるはずです。AIという強力なパートナーを得て、これまで不可能だと思っていたスピードで、高品質なアプリケーションを構築できるようになるかもしれません。
レガシーシステムの現代化は、決して平坦な道のりではありません。しかし、正しいアプローチとツールがあれば、必ず乗り越えることができると信じています。もし、あなたが僕たちと同じように、レガシーシステムとの戦いに疲弊しているのなら、一度「仕様」という原点に立ち返ってみてはいかがでしょうか。そこに、あなたのチームを救うヒントが隠されているかもしれません。
この記事が、日本中のレガシーシステムと戦う開発者の皆様にとって、少しでも参考になれば幸いです。僕たちの挑戦は、まだ始まったばかりです。