sdlc-review

SDLC レビュースキル

カンバンの実装レーンからレビューに引き渡された作業を独立して検証し、承認するか、変更を依頼するか、エスカレーションします。このスキルでは成果物とその証拠をレビューします。実装担当者の作業を引き継ぐものではありません。

使用するタイミング

以下のすべてに該当する場合に、このスキルを使用します。

• ディスパッチャーによって、review レーンから取得したタスクに割り当てられた。
• 実装担当者が review_requested の引き継ぎを提出した。
• タスクの完了前に、独立した判定が必要である。

別個の後続レビューカードには使用しないでください。後続カードは、レビューを重視した仕様を持つ通常の実装作業であり、独自のライフサイクルを通じて完了します。

前提条件

• 現在のタスクと実行識別子を含むカンバンワーカーコンテキスト。
• カンバンのネイティブツール：kanban_show、kanban_comment、kanban_complete、kanban_request_changes、kanban_block。
• 成果物がコードの場合、read_file、search_files、terminal を使ったワークスペースへのアクセス。
• タスクの元の仕様、受け入れ基準、引き継ぎの要約、以前の実行履歴を kanban_show から参照できること。

実行方法

このスキルはレビューのディスパッチャーによって自動的に読み込まれます。ファイルを調べたり判定を選んだりする前に、kanban_show を実行してください。

1. タスクの仕様と最新の review_requested の引き継ぎを読みます。
2. 実際の成果物を調べ、関連する検証を実行します。
3. 承認、変更依頼、エスカレーションのいずれか1つだけを選びます。
4. カンバンの最終遷移時に、具体的な証拠を記録します。

クイックリファレンス

判定	条件	最終アクション
承認	受け入れ基準と検証に合格している	kanban_complete
変更依頼	修正可能な実装上の不備が残っている	kanban_comment、続けて kanban_request_changes
エスカレーション	人間の判断または外部の前提条件が必要である	kanban_block

変更依頼による遷移では、タスクは元の実装担当者に戻ります。その実装担当者がレビュー担当者を指定せずに再度レビューを依頼した場合、保存されたレビュアーの来歴情報に基づき、同じレビュアープロファイルに再レビューが割り当てられます。

レビューの観点

同じ検査を繰り返すのではなく、各ラウンドで作業の見方を変えてください。相関の低い観点を使うと、異なる種類の不備を発見できます。成果物を先入観なく読むことで、実装担当者の説明によって覆い隠されていた設計や正確性の問題が明らかになり、実行することで再現できない主張が表面化し、厳密な契約監査によって気づきにくいスコープの逸脱が見つかります。ラウンド3でラウンド1と同じ観点を繰り返すと、ラウンド1で見つかった問題を再発見するだけになる可能性が高くなります。

ワーカーコンテキストにあるタスク記録の履歴から、現在のラウンドを判断します。「Prior attempts on this task」セクションにある changes_requested エントリの数を数えてください（kanban_show では以前の実行としても表示されます）。現在のレビューラウンドは、その数に1を加えたものです。そのため、ラウンド1では changes_requested の試行が0件、ラウンド2では1件となり、以降も同様です。

ラウンド	観点	適用方法
1	成果物	実装担当者の要約を読む前に、差分または成果物を先入観なく読みます。独立して判断を下し、引き継ぎの説明と比較して、食い違いがあればすべて調査します。
2	実行	作業をチェックアウトし、terminal から実際に実行します。ビルド、テストを行い、報告された挙動を自分で試します。成果物を読み直すのではなく、引き継ぎの主張を経験的に一つずつ検証します。
3以降	契約	タスクの元の本文と受け入れ基準を読み直し、それらに照らして成果物を厳密に監査します。また、以前の kanban_request_changes の各ラウンドで指摘された項目がすべて反映されていることを検証します。

「手順」セクションに記載された基本的な職務は、どのラウンドでも適用されます。観点によって、最初に行う検査と最も重視する検査が決まります。

アドホックなレビューのファンアウトにおける観点の違い

同じ原則は、カンバンのレビュー用レーン以外にも当てはまります。delegate_task で複数のレビュー担当者を並行して起動するときは、全員に同じブリーフを渡すのではなく、異なる観点を割り当ててください。たとえば、差分のみを確認するブリーフ、全コンテキストを確認するブリーフ、チェックアウトして実行するブリーフです。同じブリーフでは判定が相関し、指摘が重複しますが、ブリーフに変化をつければ、同じレビューコストでより多くの種類の不具合を見つけられます。

手順

1. 永続的なタスク記録から状況を把握する

kanban_show を呼び出し、次の情報を特定します。

• 元のタスク本文と受け入れ基準。
• 最新の実装概要と構造化メタデータ。
• 変更されたファイル、コミット識別子、テストのエビデンス。
• 以前の実行でのコメントや決定事項。
• 過去のレビューラウンドでの指摘。

引き継ぎ内容は検証すべき主張として扱い、作業が正しいことの証拠とは見なしません。

2. 要求された動作と成果物の動作を比較する

各受け入れ基準を、具体的な実装または出力のエビデンスに対応付けます。より詳しい確認を行うか判断する前に、漏れ、意味の変更、無関係な範囲への変更を記録します。

コード作業の場合：

1. read_file と search_files を使って、変更されたパスとその呼び出し元を調べます。
2. terminal を使って差分を確認し、プロジェクトに既存の対象を絞ったテスト、リンター、型チェック、ビルドコマンドを実行します。
3. 可能であれば、報告された失敗パスと、通常の制御パスを少なくとも1つ実行します。
4. 変更に関係するエラー処理、エッジケース、並行処理の境界、データの保持、セキュリティ境界、クロスプラットフォームの動作を確認します。
5. テストが単にソーステキストや定数のスナップショットを取るのではなく、動作を検証していることを確認します。

コード以外の作業の場合：

1. 概要だけでなく、成果物全体を確認します。
2. 正確性、完全性、書式、出所を確認します。
3. 判定に影響する参照先のURLや外部情報は、適切なネイティブツールで検証します。

3. 判定を1つ選ぶ

承認

受け入れ基準を満たし、エビデンスが十分な場合にのみ承認します。次を呼び出します。

kanban_complete(
    summary="Reviewed and approved. <what was verified>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

合格した確認項目を正確に記載し、承認を妨げない範囲の留保事項があれば記載します。

変更を依頼

具体的で修正可能な不具合には、この判定を使います。まず、実行可能な指摘を記録します。

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <file or artifact + defect>\n2. <required correction>",
)

次に、同じタスクを実装担当者に戻します。

kanban_request_changes(
    reason="<concise summary of the required corrections>"
)

不具合の箇所、再現方法、タスクに違反する理由、解決に必要な最低限の結果を示します。この遷移では、ブロッカーの再発回数を記録しません。

エスカレーション

レビュー担当者と実装担当者だけでは、人間による判断や外部の前提条件なしに問題を解決できない場合にのみ、エスカレーションを使います。

kanban_block(
    reason="escalation: <decision or prerequisite required>"
)

判断が止まっている理由と、作業を続けるために必要な最小限の情報を説明します。

4. 役割分担を維持する

レビュー担当者として作業している間は、実装を編集しないでください。変更を依頼し、実装担当者に次の候補を作成してもらってから、次のレビュー実行でその候補を独立して検証します。

注意点

• 安易な承認： 引き継ぎ概要が合格を示していても、それだけでは独立したエビデンスになりません。
• レビュー担当者による実装： 成果物を編集すると担当の境界が曖昧になり、再レビューの独立性が損なわれます。
• 曖昧な指摘： 「要修正」では、実装担当者が再現可能な修正対象を特定できません。
• スタイルだけを理由にブロック： 動作とリポジトリの規約に問題がない場合、好みの範囲の細かな指摘を理由に変更を依頼しないでください。
• 過去のラウンドを確認しない： 再レビューでは、依頼した修正と、以前に合格した動作が維持されていることの両方を確認する必要があります。
• 通常の手戻りにブロッカーを使う： 修正可能な不具合には kanban_request_changes を使い、kanban_block は真の外部ブロッカーや人間による判断が必要な場合に限ります。
• エビデンスなしで完了する： 承認の概要には、実際に確認したチェック項目または成果物を必ず記載します。

検証

判定を提出する前に、以下を確認してください。

• 現在のタスクについて kanban_show を読み、実行しました。
• すべての受け入れ基準を証拠に対応付けました。
• 実際の成果物を確認しました。
• 関連する重点チェックを実行しました。実行できなかった場合は、その明確な理由を記録しました。
• 再レビューでは、以前に依頼された変更を再テストしました。
• 無関係なリグレッションとスコープの変更を検討しました。
• 判定では、終端アクションをちょうど1つ使用しています。
• 要約には、具体的で機密情報を含まない証拠が記載されています。
• レビュアーは実装ファイルを編集していません。