メインコンテンツへスキップ

​
ほとんどのスプリントワークフローにあるギャップ

チームはJira、Linear、またはNotionで要件を追跡します。開発者はPRでそれらを実装します。しかし、PRが実際にすべての受け入れ基準をカバーしているかどうかを体系的に確認する人は誰もいません — QAがステージングでギャップを見つけるまでは。 このクックブックは、タスク要件に対してPRを自動的に検証することで、そのループを閉じます。

​
ワークフロー

タスク作成（Jira/Linear/Notion）
    ↓
開発者が実装 → PRを開く
    ↓
Kodusが自動的に：
  1. リンクされたツールからタスクコンテキストを取得する
  2. PR差分を受け入れ基準と比較する
  3. 欠落/部分的な実装を報告する
    ↓
開発者が結果に対処 → 再検証
    ↓
自信を持ってマージ

​
ステップ1 — タスク管理ツールに接続する

設定 → Plugins に移動してツールを接続します：
  • Jira — Atlassianを使用するチーム向け
  • Linear — Linearを使用するチーム向け
  • Notion — タスクトラッカーとしてNotionを使用するチーム向け
  • ClickUp — ClickUpを使用するチーム向け
接続すると、Kodusはレビュー中に自動的にタスクコンテキストを取得できます。

​
ステップ2 — ビジネスロジック検証を有効にする

デフォルトで有効になっていますが、確認してください： 
reviewOptions:
  business_logic: true

​
ステップ3 — 良い受け入れ基準を書く

検証の品質はタスクの説明の品質にすべて依存します。Kodusはタスクコンテキストを以下のように分類します：
品質意味対処法
完全タイトル + 説明 + 受け入れ基準最良の結果 — 基準ごとの検証
部分的タイトル + 説明、基準なし適切な結果 — 動作ベースの分析
最小限タイトルのみ不十分な結果 — 明らかなギャップのみフラグ
Jira/Linearタスクのテンプレート： 
## 説明
何を変更する必要があるか、なぜかについての簡単なコンテキスト。

## 受け入れ基準
1. 「admin」ロールを持つユーザーは任意のコメントを削除できる
2. ユーザーは24時間以内に自分のコメントのみ編集できる
3. 削除されたコメントには「[削除済み]」プレースホルダーが表示される
4. 監査ログに誰が何を削除したかと日時が記録される
5. APIは認証されていない削除試行に403を返す

​
ステップ4 — 開発中にオンデマンド検証を使用する

PRをレディとしてマークする前に、開発者は自己チェックできます： 
@kody -v business-logic https://kodustech.atlassian.net/browse/KC-1292
これによりギャップを早期に検出できます。レビュアーがPRを見る前に。

​
ステップ5 — スプリント規約をMemoriesとして教える

@kody remember: すべてのPRはJiraチケットにリンクされている必要がある。
リンクされたチケットのないPRにはフラグを立てる。

@kody remember: チケットで「スコープ外」とマークされた受け入れ基準は
欠落としてフラグを立てるべきではない。

​
ステップ6 — PR要件ルールを作成する

Name: PRはタスクを参照する必要がある
Scope: Pull Request
Severity: Medium
Instructions:
  pr_descriptionとpr_titleでタスク参照を確認する
  （例：KC-1234、TEAM-456、またはJira/Linear/NotionへのURL）。
  タスク参照が見つからない場合はフラグを立て、
  ビジネスロジック検証のために開発者に関連タスクをリンクするよう求める。

​
結果

セットアップ後、スプリントのすべてのPRで以下が得られます：
  1. コード品質レビュー — セキュリティ、パフォーマンス、スタイル（標準のKodus）
  2. ビジネスロジック検証 — すべての受け入れ基準が実装されているか？
  3. スコープミスマッチ検出 — このPRは正しいタスクに取り組んでいるか？
QAが見つけるギャップが減り、スプリントデモがスムーズに進み、「それは完了したと思っていた」というケースが少なくなります。

​
ヒント

  • 番号付きの受け入れ基準を書くようにチームを促す — 最良の検証結果が得られる
  • レビュー時だけでなく、開発中にオンデマンド検証を使用する
  • PRが意図的にすべての基準をカバーしていない場合（段階的なデリバリー）、Kodyが考慮できるようPRの説明に注記する
詳細については、ビジネスロジック検証 を参照してください。