Introducing Team Kit
要件定義〜画面モック生成までを自動化、そこからのフィードバックも一貫してできるツールを公開しました。
Team Kit とは
AI駆動開発における周辺業務の自動化ツールという位置付けで開発しています。
エンジニアがよりプログラミングや設計などのコア業務に集中できるよう、要件定義から画面モックの生成、フィードバック管理まで、開発業務周辺のプロセスをサポートする予定です。
このツールを導入することで、開発チームの生産性が大幅に向上し、品質の高いソフトウェアを効率的に開発できるようになることを目指しています。
開発のきっかけ
元々はKiroとRDRAを組み合わせて、爆速PoCシステム開発を目指してました。
ただ、実際に試してみると様々な問題に出くわしました。
その中でも一番致命的だったのが、「設計の情報量が多いこと」でした。
要件ではなく設計で情報量が爆発してしまうと結局情報量に圧倒され、ちゃんとした判断ができず、実装も想定とズレが生じて、それを修正するにも情報量の多い設計を修正するしかなくなりました。
解決策としては、1つではなく適切なサイズの設計単位に分割してそれぞれ判断していくことだったのですが、そこまでいくならDocDDで突き詰めていけばいいのでは？となりました。
それ以外の選択肢を考えたときに、 「エンジニア以外にも伝わるモックアップなら情報量もそこまで大きくならず、要件としてざっくり重要なところだけ判断でき、合意形成も楽になるのでは？」 と思い、プログラミングの外側の合意形成プロセスを支援することを目的に作ってみました。
要件→モックアップまでは、すんなりできたのですが、モックアップをバイブコーディングで改修していくと、要件とのズレがでてくるので、それをフィードバックする仕組みを用意しました。
また、要件自体も抜け漏れをAIがチェックできる仕組みを作ったことで、ロジック的な破綻もなく、要件とモックアップの整合性を維持したまま要件を追加することができました。
仕組みが汎用的でプロジェクトを横断して使えるのが分かってたので、いっそのことツールとして公開してみんなに使ってもらうことで、色々なフィードバックがほしくなったので公開することにしました。
インストール
# カレントディレクトリにインストール
curl -fsSL https://raw.githubusercontent.com/tango238/teamkit/main/install.sh | bash -s -- .
※ Claude Code を使うことを想定しています。
基本的なワークフロー
Team Kitは、段階的な仕様書作成ワークフローを提供します。各ステップは /teamkit:* というスラッシュコマンドとして利用できます。
1. プロジェクトの初期化
まず、仕様書を管理するディレクトリを作成します:
your-project/
└── specs/
└── YourFeature/
└── README.md # 要件を記述
README.md に記載する内容に特に決まりはありませんが、次のような内容が良いかもしれません。
# <機能名>
## 背景
## 目的
## 主要アクター
## 業務概要
## 要求
2. フィーチャーの作成
README.md から要件を抽出し、フィーチャー定義を生成します:
/create-feature YourFeature
生成ファイル:
-
specs/YourFeature/feature.yml- フィーチャー定義 -
specs/YourFeature/status.json- ステータス管理ファイル
3. HTMLモックアップの生成
UI定義からインタラクティブなHTMLモックアップを生成します:
/create-mock YourFeature
生成ファイル:
-
specs/YourFeature/index.html- モックアップのインデックスページ -
specs/YourFeature/mock/*.html- 各画面のモックアップ -
specs/YourFeature/mock/screens.yml- 画面生成ステータス
チェックとフィードバック
Team Kit では作成されたモックアップに対するフィードバックや、機能要件としてロジックに矛盾や抜け漏れがないかチェックする機能があります。
例えば、チェックすると次のような check.md が作成されます。
# TODO
- [ ] 1. エラー系シナリオの追加
- [ ] 2. 参照（詳細表示）シナリオの追加
- [ ] 3. 他のアクターによる参照権限の明確化
# Summary
## 1. エラー系シナリオの追加
- Target: 全てのfeature
- Issue: 正常系（Happy Path）のみ記述されており、入力エラーや業務ルール違反時の挙動が定義されていない。
- Recommended action: 必須項目未入力、重複登録、削除時の依存データ存在エラーなどのシナリオを追加する。
- Notes: 特に削除時のチェックは重要。
## 2. 参照（詳細表示）シナリオの追加
- Target: 全てのfeature
- Issue: 検索後に直接「更新」や「削除」に進むフローとなっているが、通常は詳細確認画面を挟むことが多い。
- Recommended action: 「施設情報の詳細表示」などのシナリオを追加し、編集権限がないユーザーでも閲覧できるフローを検討する。
## 3. 他のアクターによる参照権限の明確化
- Target: actor, precondition
- Issue: 施設管理者の操作は明記されているが、フロントスタッフや予約管理担当者が施設情報を参照できるか不明確。
- Recommended action: 参照専用のシナリオを追加し、適切なprecondition（権限）を設定する。
このチェック内容を確認して、- [o] とセットすると変更予定として設定できます。
何もしなければ勝手に適用されませんし、- [~] にしておくと見送りとしてマークします。
適用内容は Recommended action の内容で修正されますが、ここを修正することで、適用内容を調整することができます。
/teamkit:update-feature <feature> を実行すると [o] にしたTODOを適用します。
適用した変更は [x] にして完了としてマークします。
フィードバックは /teamkit:feedback <feature> "コメント" でフィードバックすることができます。フィードバックはすぐ適用されるわけではなく、影響範囲やTODOが feedback.md に記載されていくので、チェックのときと同じように [o] をつけていきます。
フィードバックの反映は /teamkit:apply-feedback <feature> で行います。
このようにチェックとフィードバックの繰り返しで、ロジック的な抜け漏れをなくしつつ、要件〜モックアップまでの一貫性を持たせながら要件を詰めていきます。
次のようなイテレーティブな要件定義が行えることが特徴です。
将来の予定
いまはまだ安定した動作ができていないので、調整をしているところですが、将来の予定としては内部的にユーザーストーリーやユースケース、画面遷移図も生成しているので、システム全体の構造も把握できるようになると思っています。
既存システムへの適用はまだどうするか悩んでいますが、システムの全体構成がわかるようになれば、そこからユーザーマニュアルなどの作成も可能なのでは？と思っています。
あとは、もともとは Spec-Driven Development を試しているうちに生まれたツールなので、ここから SDD へ繋げることも考えています。
Discussion