核要内容のまとめ
この記事では、企業における「AIネイティブ開発」の実践に焦点を当て、なぜ企業がAIネイティブを目指す際に「断絶感」を感じるのか（個人レベルではAIを使って効率が上がるが、組織全体としての導入が難しい）を説明しています。その後、SDD（仕様駆動開発：Spec-Driven Development）という組織レベルでのAIネイティブなソリューションを紹介し、プロジェクトの再構築を通じてSpec-KitとBMADという2つのツールの特徴や長所・短所を実践的に比較しています。最後に、AIネイティブの本質は協力プロセスの再構築であると指摘しています。つまり、個々のメンバーがAIツールを使うだけでなく、チーム全体がAIの能力に適応することが重要です。
1. なぜ企業はAIネイティブを導入する際に「面白くない」と感じるのか？
個人がAIを使ってコードを書くときは、「効率が2倍になった！」と感じます。しかし、企業がAIネイティブを推進すると、多くの「面白くない」問題に直面します：
- 権限はどう設定すればいいのか？どのタスクをAIに自動化させるべきか？PRは誰が審査するのか？
- AIが生成したTodoが重複した場合はどう対処するのか？単体テストに失敗した場合の責任は誰が負うのか？
- 自動コードマージで問題が発生した場合は誰が責任を持つのか？AIが資料を要求する際の言葉遣いは同僚を不快にさせないだろうか？
これらの細かなルールや対応策は、企業にとってAIネイティブを「低効率」と感じさせるかもしれませんが、それは必要不可欠です。個人が求めるのは「速さ」であり、組織が求めるのは「安定した速さ」です。たまに起こる驚くべき成果よりも、プロセス内でAIが誤動作せず、コントロール可能であることが重要なのです。だからこそ、これらの「面白くない」詳細こそがAIネイティブを実現するための鍵となります。
2. AIネイティブ開発の本質：「誰もがAIを使う」ではなく、「AIが協力に参加する」
多くの企業は、「誰もがChatGPTを使ってコードを書く」ということをAIネイティブだと考えがちですが、それは間違いです。
AIネイティブの真の本質は、AIをチームのタスクフロー、協力プロセス、デリバリープロセスに組み込み、仮想メンバーとして機能させることです。例えば、以下のようなAIの活用例があります：
- チャットやログを自動的に監視し、問題を特定し、Todoを整理する。
- コードを書くことができるAIは、要件を自動的に作成したり、コードを修正したり、テストを実行したり、PRを提出したりする。
- 文脈情報が不足している場合は、責任者に資料の提供を促す。
- 低リスクなコードについては2つのモデルを使って相互にレビューする。
重要な変化は、「AIにコードを書いてもらえるかどうか」から、「AIがどのような基準でコードを書くべきか」へと移行することです。つまり、AIに明確なルールや要件の境界、ビジネスロジックを提供し、安定した出力を実現させる必要があります。
3. SDD：AIにルールを設ける「仕様駆動開発」
SDD（Spec-Driven Development）とは、AIに明確なルールを与える方法です。つまり、「要件」「プラン」「タスク」といった明確な「仕様」を使ってAIの開発を進め、AIが無秩序に動くのを防ぎます。GitHubのSpec-Kitはこの考え方を広めるのに役立ちました。
主な機能：AIに安定した環境（要件の境界、コードルール、ビジネス制約）を提供し、組織レベルでのAIの使用をより効率的にします。例えば、Spec-Kitは散在する要件やプラン、タスクを標準化し、AIが順序立てて作業できるようにします。
本質：AIを「自由に動くアシスタント」から、「ルールに従って働く従業員」へと変え、チームの協力に統一された基準を提供する。
4. Spec-Kit vs BMAD：2つのツールの実践的な比較
1. Spec-Kit：「固定されたプロセステンプレート」のようなもの
- 特徴：プロセスが明確で（specify→plan→tasks→implement）、標準化が強制される。単一の機能やチームの基盤が整っている場合に適しています（規則があり、複数のリポジトリが管理されている）。
- 問題：実際のプロジェクトが複雑な場合（複数のリポジトリや多くの役割がある場合）、多くの補完メカニズムが必要になる。例えば、作者はSpec-Kitを使用する際に、AIがフロントエンドとバックエンドのコードの位置を理解できるように自分でコマンドを封装したり、APIの衝突をチェックする必要がある。
2. BMAD：「AI仮想チーム」のようなもの
- 特徴：製品エンジニア、アーキテクト、QAなどのAIロールが内蔵されており、「円卓レビュー」を行い、能力不足を補うことができる。例えば、リファクタリング時にオンライン切り替えや古いシステムの問題を発見したり、不要な要件を13項目削減したりする。
- 問題：レビュー作業量が多く、精神的負担が大きい。すべての詳細をチェックしなければならず、得意でない分野（例えばフロントエンドがバックエンドのプランをレビューする場合）は特に苦労する。初期段階での作業時間が人間同士の協力よりも長くなる可能性がある。
5. ツールの選択方法：小規模チームはBMAD、大規模チームはSpec-Kit
- BMADの適用例：1人または小規模なチームで、アーキテクトなどの役割が不足している場合。AIによって能力のギャップを補う必要がある。完全なチーム環境をシミュレートし、欠陥を避けるのに役立つ。
- Spec-Kitの適用例：チームの能力が高く、基盤が整っている場合（規則があり、複数のリポジトリが管理されている）。AIによる出力をよりコントロールしたい場合。既存のシステム内で効率的にAIを活用することができる。
最後に、AIネイティブとは「ツールの積み重ね」ではなく、「プロセスの再構築」であるという点を強調します。チームがAIの能力に適応することで、AIの効率を組織全体の効率に変えることができます。