【要約】チーム開発の認識ズレを入口で潰す。OpenSpec に「AI が先に質問する」工程を足して比べてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
チーム開発において、開発者とAIの間で「何を作るか」という認識がズレる問題に直面している。個人の頭の中にある前提が共有されないことで、後工程での修正コストが増大する。
- ・AIが不足している前提を勝手に推測し、意図しない仕様を生成してしまう。
- ・ドメイン用語の定義が曖昧なまま進み、実装段階で認識の食い違いが発生する。
- ・仕様の変更や決定事項の根拠が不明確になり、レビューや修正の手戻りが頻発する。
// Approach
OpenSpecのワークフローを拡張し、提案書生成の前にAIによる質問工程を強制的に挟む手法を採用した。AIに能動的な問いかけを行わせることで、仕様の精度を入口で高める。
- ・OpenSpecの
spec-drivenスキーマをフォークし、schema.yamlを編集する。 - ・
proposalステップの指示に、grill-with-docsスキルを呼び出す命令を挿入する。 - ・
grill-with-docsを用いて、CONTEXT.mdやコードベースに基づき要件を対話で確定させる。 - ・決定事項をADR（設計判断の記録）として自動的に残す仕組みを構築する。
// Result
仕様の精度が劇的に向上し、開発工程における手戻りコストの削減に成功した。同一の抽象的なお題から生成した仕様を比較することで、その効果が実証されている。
- ・スコープの明確化: 「Web Pushは採用しない」等の境界線が明記される。
- ・判断根拠の保持: 設計の理由がADRに記録され、後からの追跡が可能になる。
- ・機能の粒度向上: 責務が細分化され、後続の設計・実装工程へ繋げやすくなる。
- ・一貫性の確保: エッジケースまで考慮された、整合性の高い仕様が生成される。
Senior Engineer Insight
> AIを「コード生成器」から「要件定義のパートナー」へ昇華させた実戦的な手法だ。チーム開発の最大のコストである「認識の不一致」に焦点を当てている点が極めて鋭い。OpenSpecのスキーマをフォークし、ワークフローを制御する設計は、組織の規律をコードで強制できるためスケーラビリティが高い。ただし、AIの質問が過剰になると開発者の認知負荷を上げるため、プロジェクトの成熟度に応じたチューニングが運用の鍵となる。