はじめに
こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（TENTEN11055）です。
普段はチームで Findy Context というプロダクトの開発に取り組んでいます。
2025年11月、AWS主催のAI-DLC Unicorn Gymに参加し、AI駆動開発の手法であるAI-DLCを実践しました。
学びはとても大きかった一方で、自分たちのチームにそのまま持ち込むには壁もあり、現場の実態に合わせて作り変える必要がありました。
Unicorn Gym参加時の様子はこちら。
AI-DLCはAIが作業を実行し、人間が監視と判断に集中する開発手法です。
要件・ストーリー・作業単位を整理するInception、設計・実装・テストを進めるConstruction、IaCやデプロイを担うOperationの3フェーズで構成され、AIが提案する成果物をチーム全員で検証しながら進めます。
チームではそのうち実装に関わるInceptionとConstructionの2フェーズを採用しました。
詳細は次の記事を参照ください。
この記事ではAI-DLCをClaude Skill化し、Epic制開発フローの中で要件整理からテストまでを一人のメンバーが一貫して担えるようにした取り組みを紹介します。
チームが抱える課題
これまではPMやデザイナー、QAエンジニアといった専任者と分業する形で開発してきましたが、チーム構成の変化により、エンジニア自身が担当領域を越境していく必要が出てきました。
担当領域越境の必要性
チームのフロントエンド専任者が一人のため、フロントの設計・実装を全て頼るわけにもいきません。
また4月末でQAエンジニアが別プロダクトへ異動となり、実装者のみでのテスト設計、ケース実装を担うことになりました。
さらに専任のPMも他プロダクトを兼務しており割ける時間が限られるため、要件整理など本来PMの領域だった部分にも開発者が踏み込んでいく必要があります。
これらを加味し、エンジニア一人一人が担当領域を広げる必要が出てきました。
AI-DLCをそのまま取り入れる難しさ
そこで越境を支援する手段として、これまで個々人で自由に行なっていたAI-DLCをチームの開発フローとして取り入れることを検討しました。
しかしInceptionフェーズは関係者が集まって仕様を決めていくスタイルであり、その実施には一定の同期コストが発生します。
作りたい機能の具体が曖昧であればあるほど全員参加は効果的になりますが、Epicイシューが作成された段階で既に一定の解像度がある場合は、PMも含め全員で擦り合わせをすると、得られる解像度向上に対して投入する時間（チーム全体の同期コスト）の方が目立ってしまいます。
Epic制開発フローの導入
これらの課題を解決する一環としてチームではEpic制を導入しました。
こちらはVPoEのhamさんがFindy Team+開発で実施した個人アサインへのシフトに影響を受けています。
各Epicにメンバーをアサインすることで要件整理から開発まで一貫して責任を持つようになり、ボトルネックも発生しづらくなります。
実際の運用としては、大まかに次の流れで開発を進めています。
- Epic担当者はAI-DLCスキルを用いてInceptionドキュメントを作成する
- ワイヤーフレーム作成スキルに1のドキュメントを読み込ませ、HTMLでワイヤーを作成する
- 1と2を元にデザイナーとPMに確認をとる
- AI-DLCスキルでConstructionドキュメント、テスト設計、テストケースを実装する
- デザイン、実装、テスト
- 受け入れ確認、リリース
チーム内ではこれらを用いたフローをAI-E-DLC (AI - Epic - Driven Development Life Cycle)と名付けており、今後も運用と改善を重ねていこうとしています。
ここからはこのフローの1と4で利用するAI-DLCスキルについて掘り下げていきます。
AI-DLCの2フェーズと付随する作業をClaude Skill化する
同じプロンプトを用いてドキュメントを作成しても、AIの成果物にはばらつきが生じる可能性があります。
そのためAI-DLCにおけるInceptionとConstructionのドキュメント生成をそれぞれスキル化し、潜在的な課題をいくつか改善することができました。
1. フォーマットのばらつきが改善
同じAI-DLCのプロンプトを使っても、書き手によって構成・粒度にばらつきが生じたり、必要な情報が抜けたりすることで、実装・テスト設計・レビューなどの工程でAIが読み取りにくいドキュメントが生まれていました。
この課題に対し、スキルで手順と出力フォーマットを固定し、誰が実行しても同じ骨格のドキュメントを出力できるようにしています。
ちなみにこのフォーマットの固定化が多くの改善の起点になっており、これなしでは後述の内容も実現しえませんでした。
2. 横展開を容易にする
AI-DLCの手法を各メンバーが再現するには、フェーズ理解・プロンプト設計・観点整理の習熟が必要であり属人化しやすいものですが、スキル化により手順がガイドされるため、未経験者でも気軽に実践できる「型」として提供できます。
またFindy Contextが複数リポジトリで構成されるため、リポジトリ非依存で動くスキルにしています。
今まで各リポジトリに合わせたプロンプトを用意する必要がありましたが、どれにおいても同じスキルを呼べばOKな状態にしています。
汎用性の高いスキルにすることでどこでも誰でもAI-DLCに則ったドキュメントを作成できるようになりました。
3. ツールを利用してよりシームレスな設計ができる
AIからの質問事項にはClaude CodeのAskUserQuestionツールを必ず利用させています。
InceptionではAIから人間への質問フェーズが存在し、ドキュメントに記載された質問に対し人間が回答を書き込むのが基本でした。
これに対し選択 or 自由回答という形式をとり回答候補を提示してもらうことで一から考えることがなくなるため、回答作業だけでなく脳の負担も軽減されました。
他にも一部の難易度の高い作業をAgentに任せるなど、場面に適した設定を共有できるのもスキル化の利点の一つです。
4. 付随するスキルの精度が上がり、人間の負担を下げる
フォーマットのばらつきが改善されたことにより、専用のテスト設計・ケース実装スキルとドキュメントレビュースキルも作成することができました。
テストをAIで用意する際、何を材料とするかが重要です。
もしコードを材料とした場合、そのコードが仕様に沿っていなければ誤ったテストとなってしまいます。
このテスト設計・作成スキルはInception・Constructionドキュメントを材料とし、エンジニア・PM・デザイナー間で認識が揃った仕様を前提とするため高い精度を出すことができます。
またドキュメントレビューに関してはAI-DLCの中で最も人間の負荷が高い作業です。
AI-DLCスキルで生成されるドキュメントは10ファイルを超え、全部均等にレビューしようとすると破綻します。
そこでレビュースキル側で、生成されたドキュメントを「核となるドキュメント（仕様の中核を担うもの）」と「補助となるドキュメント（核を支える補足）」に分類し、Epicイシューとも照らし合わせて齟齬や抜けがないかをチェックさせています。
これにより人間が熟読すべきドキュメントを明確にし、レビュー負荷を下げることができました。
スキル運用後の効果とまとめ
運用を始めて数日が経ちましたが、想像以上に強力なスキルとフローであると感じています。
チームの課題でもあった「役割の越境」に対して有効なアプローチとなり、これまで専任者（PM・デザイナー・QAエンジニアなど）に頼っていた作業の下地を実装者が担い、専任者はレビュー・判断に集中できるようになりました。
習熟度の壁を下げられたことも大きな成果で、スキル作成後に説明する場を設けなくても気づいた時には他メンバーが使っており、数日後にはスキルの改善PRも上げてくれていました。
レビューにおいてもAI-DLCを始めた頃によくあった「ドキュメントレビューしんどい...」という声は幸いまだ聞こえてきていません。
今回の取り組みはAI-DLCをそのまま導入するのではなく、チームの開発体制や課題に合わせて適応させる試みでした。
まだ運用を始めて間もないため改善の余地はありますが、その部分に誰もが参加できる間口を用意できるのもスキル化の利点かもしれません。
ファインディでは一緒に働くメンバーを募集中です！
よかったら覗いてみてください。
