swe-method

SWE メソッド

このワークフローを使って、推測に基づく実装を避けるために十分なコンテキストと検証を確保しながら、Jira ストーリーに取り組みます。

ステップ 1：コンテキストを定義する

すでに把握しているリソースを、最初にまとめます。

仕様

• Jira チケット ID

追加コンテキストの一覧

• Slack スレッドの URL
• AI ツールとのやり取りのセッション ID
• 会議の議事録
• 個人的なメモ
• 親タスク、関連タスク、子タスク
• 既存のブランチと PR

ステップ 2：データを変更不可のレイヤーに取得する

推論の根拠となるソース資料を収集し、解釈とは分けて保管します。これにより、後続のステップを記憶ではなく事実に基づいて進められます。

ステップ 3：コードベースとシステムを調査する

仕様と追加コンテキストに基づいて、作業に関係する実際のリポジトリ、ブランチ、PR、API、スキーマ、CLI、および周辺システムを調査します。

ステップ 4：人間参加型の仕様の精緻化

ルール：

• タスクが大きいほど、すべてを事前に明確化するのは難しくなります。
• 自律実行が長くなるほど、エンジニアが意図した成果から逸脱するリスクが高まります。

規模の目安：

• ごく小さく反復的なタスク：HIL のステップは省略し、判断をスキルに組み込めることがよくあります。
• 小規模なタスク：軽量な HIL 計画ステップを実施してから、実装を自動化します。
• 大規模なタスク：作業を小さなサブタスクに分割し、それぞれ実行前に仕様を精緻化します。

エージェントの質問フローを使って、一度に 1 つずつ判断を引き出し、明確化した仕様を仕様ファイルまたは仕様フォルダーに保存します。

質問の種類には、次のようなものがあります。

• ステークホルダーやチームメイトへの確認が必要な要件
• エンジニアが決定するか、エスカレーションできる設計上の判断

ステップ 5：実行計画

仕様は何を構築するかを定めます。実行計画は、不明な事実を幻覚で補わずに、どのように構築するかを定めます。

特にデータベース、API、CLI、SDK が関係する既存システムでは、エージェントにスキーマやレスポンスの形を推測させないでください。まず検証します。

実行計画には、エージェントが以下を確認するための HIL ステップを含めることができます。

• 実際の API レスポンス
• 実際の DB スキーマ
• 実際の CLI または SDK の動作

前提を検証してから、それらの事実に基づいてテストを作成します。

クラスの変更に関する実行計画の例：

1. クラスが依存する API または DB に問い合わせます。
2. 確認した形状に基づいてテストケースを定義します。
3. テストが通るまで実装します。
4. リファクタリングして簡潔にします。
5. ドキュメントを更新します。

ステップ 6：実装

実行可能なアプローチは 2 つあります。

• 一部分を実装し、実際のシステムに対してエンドツーエンドで実行して、正しく動作するまで問題を解決してから、テストを追加してその状態を固定します。
• まず実際の外部動作を検証し、想像ではなく事実に基づくレスポンスを使って TDD を行います。

実装とクリーンアップを交互に行い、コード品質と規約が最後まで先送りされず、継続的に適用されるようにします。