engineering-weekly-report について
エンジニアリングチームと関係者向けに、出荷状況、判断事項、リスク、指標、次の予定を定型でまとめる週次レポート作成スキルです。未提供の指標は捏造せず、データ不足として示し、具体的なブロッカーと対応を促します。
主な機能
- 01関係者向けの固定レポート構成
- 02出荷状況とブロッカーの表
- 03判断事項・リスク・エスカレーション
- 04未提供指標のデータ不足表示
- 05翌週の成果ベースの優先事項
- 06レポート品質チェックリスト
活用シーン
- 01エンジニアリングチームの週報作成
- 02関係者向けのスプリント状況整理
- 03ブロッカーと必要な判断の明確化
- 04データがない指標の適切な報告
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/engineering-weekly-reportを入力して読み込まれたか確認します。
詳細
エンジニアリング週次レポート
チームがステークホルダー、エンジニアリングマネージャー、チーム内に共有できる、週次のエンジニアリング状況レポートを作成します。読者がどこを見ればよいかすぐに分かるよう、毎週同じ形式にします。冒頭にリリースの進捗、中盤に決定事項、最後にリスクと次のステップを記載します。レポートは2分以内で読めるようにしてください。文章が長く続かないよう、箇条書き、ステータスタグ、簡潔な表を使用します。メトリクスが提供されていない場合は、数値を捏造せず、メトリクスのセクションに [data needed] マーカーを残してください。
必須入力情報
まだ提供されていない場合は、以下を確認してください。
- チーム名とレポート対象期間 — チーム名に加え、週番号または日付範囲（例：「Platform Team、Week 21、May 12–16」）
- 今週完了した作業項目 — 完了してリリースまたはマージした内容
- 進行中の作業項目 — 現在進めている作業。分かる場合はおおよその完了率も記載
- ブロックされている項目 — 何がブロックされているか、誰がブロック要因を担当しているか、解消に何が必要か
- 主な決定事項 — 今週決定したアーキテクチャ、プロセス、優先順位に関する事項
- 来週必要な決定事項 — 近いうちに決定が必要な事項と、決定を下す担当者
- リスクとエスカレーション事項 — 来週のコミットメントを脅かすもの、またはリーダー層への共有が必要なもの
- 来週の最優先事項 — チームが来週達成を目指す3～5項目
任意ですが、あると役立つ情報：
- 主なメトリクス — 信頼性（エラー率、p99 レイテンシ）、ベロシティ（完了したストーリーポイント）、その他の健全性指標
- チームの状況に関するメモ — 休暇、新規参加者、離職、注目すべき士気の兆候
- スプリントまたはイテレーション番号 — チームがスプリントを実施している場合
出力形式
エンジニアリング週次レポート — [Team Name]
週： [Week Number] | [Date Range, e.g., May 12–16, 2025] 作成者： [Name or Team Lead] 共有先： [e.g., Eng leadership, Product, Team]
リリースの進捗
今週リリースした項目
| 項目 | 説明 | 影響 |
|---|---|---|
| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
| [Feature / Fix / Infra change] | [One-line description] | [Who benefits / what it unblocks] |
進行中
| 項目 | 担当者 | ステータス | リリース目標 |
|---|---|---|---|
| [Work item] | [Name] | [~40% / On Track / At Risk] | [Date or Sprint] |
| [Work item] | [Name] | [~70% / On Track / At Risk] | [Date or Sprint] |
| [Work item] | [Name] | [~20% / On Track / At Risk] | [Date or Sprint] |
ブロック中
| 項目 | ブロック開始日 | ブロックの説明 | 担当者 | 解消に必要なこと |
|---|---|---|---|---|
| [Work item] | [Date] | [What is blocking progress] | [Name] | [Specific ask — decision, resource, dependency] |
ブロック中の項目がない場合：現在、ブロック中の項目はありません。
主なメトリクス
メトリクスの基準日：[Date]。括弧内は前週の値です。
| メトリクス | 今週 | 先週 | 推移 | 目標 |
|---|---|---|---|---|
| エラー率（5xx） | [X%] | [X%] | [↑ / ↓ / →] | < [threshold] |
| p99 レイテンシ | [Xms] | [Xms] | [↑ / ↓ / →] | < [threshold] |
| デプロイ頻度 | [X deploys] | [X deploys] | [↑ / ↓ / →] | [target] |
| 完了したストーリーポイント | [X] | [X] | [↑ / ↓ / →] | [sprint target] |
| オンコールのページ通知数 | [X pages] | [X pages] | [↑ / ↓ / →] | < [threshold] |
メトリクスに関する注記： [数値を理解するために必要な背景情報。例：「火曜日にエラー率が急増。下流依存先の障害が原因で、当日中に解消。」]
メトリクスが提供されていない場合：表の各行を [data needed — provide metric values for this section] に置き換えてください。
決定事項
今週の決定事項
| 決定事項 | 理由 | 担当者 | 関係者への共有 |
|---|---|---|---|
| [決定事項の説明] | [理由 — 1文] | [名前] | [はい／いいえ — 対象者] |
| [決定事項の説明] | [理由 — 1文] | [名前] | [はい／いいえ — 対象者] |
決定事項がない場合：今週、重要な決定事項はありません。
来週必要な決定事項
| 決定事項 | 背景 | 期限 | 決定責任者 |
|---|---|---|---|
| [決定が必要な事項] | [重要な理由、延期した場合の影響] | [日付] | [名前または役割] |
保留中の決定事項がない場合：保留中の決定事項はありません。
リスクとエスカレーション
| リスク | 発生可能性 | 影響 | 軽減策 | エスカレーション先 |
|---|---|---|---|---|
| [リスクの説明] | [高／中／低] | [高／中／低] | [対応内容] | [エスカレーションが必要な場合の名前／役割] |
今週のエスカレーション： [リーダーシップによる早急な対応が必要な項目は、表の行に埋もれさせず、ここに明記してください。該当がない場合：「なし。」]
チームの状況
| 項目 | 状況 |
|---|---|
| 今週のチーム稼働状況 | [フル稼働のメンバー数／全メンバー数] |
| PTO／不在 | [名前と日付、または「なし」] |
| 新規参加／離任 | [名前、役割、日付、または「なし」] |
| 今週のオンコール担当 | [名前] |
| 来週のオンコール担当 | [名前] |
チームに関するメモ： [共有すべき士気、業務量、チームの動向に関する兆候があれば記載してください。事実に基づき、建設的な内容にしてください。特記事項がなければ、この行は省略してください。]
来週の優先事項
来週、このチームがリリースする、または大きく前進させる項目を3～5件記載してください。
- [優先事項] — [完了の定義と担当者を1文で記載]
- [優先事項] — [完了の定義と担当者を1文で記載]
- [優先事項] — [完了の定義と担当者を1文で記載]
- [優先事項] — [完了の定義と担当者を1文で記載]
- [優先事項] — [完了の定義と担当者を1文で記載]
稼働能力のリスク： [PTO、インシデントなどにより来週のチーム稼働能力が低下する場合は、関係者が期待値を調整できるよう、ここに記載してください。]
付録：スプリント実績表（該当する場合）
| スプリント | コミット済み | 完了 | 完了率 | 持ち越し |
|---|---|---|---|---|
| スプリント [N-1] | [X pt] | [X pt] | [X%] | [X pt] |
| スプリント [N]（進行中） | [X pt] | [X pt — 途中経過] | [中間時点でX%] | TBD |
質問や修正： [Slack チャンネルまたはメール] | 次回レポート： [日付]
品質チェック
- ブロックされているすべての項目に具体的な担当者と、ブロック解除に必要な具体的事項が記載されている。「Xの対応待ち」だけでは不十分です
- 決定事項の表に期限と名前が明記された決定責任者が記載されている。「TBD」のような曖昧な記述はありません
- 指標の表には実際の数値が記載されているか、明示的に
[data needed]と記されています。指標を捏造していません - 来週の優先事項は、活動（「Xに取り組む」）ではなく成果（「Xをリリースする」「Yの移行を完了する」）として記載されています
- リーダーシップによる対応が必要なエスカレーションは、表の行に埋もれさせず、「リスク」セクションに明記されています
- レポート全体を2分以内に読めます。印刷したときに1ページを超える場合は、内容を削ってください
- レポート期間（週番号と日付範囲）がヘッダーに明記されています
アンチパターン
- 指標を捏造しないでください。データがない場合は推定せず、項目に
[data needed]と記載してください。架空の数値に基づいて関係者が意思決定することは、深刻な悪影響を及ぼします。 - 来週の優先事項を「X に取り組む」のような活動として書かないでください。「X をリリースする」「Y の移行を完了する」のような成果として示し、関係者がチームの成果を評価できるようにしてください。
- エスカレーション事項をリスク表の行に埋もれさせないでください。リーダーシップの注意が必要な事項は、「エスカレーション」セクションで明示してください。
- ブロックされている項目を、具体的な担当者と明確な解消アクションを示さずに列挙しないでください。「X の対応待ち」はブロッカーの記載ではなく、単なる仮置きです。
- 印刷時に2ページを超えるレポートを書かないでください。長さは、関係者にとって重要な点を見極める編集作業を執筆者が行っていないことを示します。
例となるトリガーフレーズ
- 「チームの近況を書いてください。」
- 「週次のエンジニアリングレポートを書いてください。」
- 「スプリントの状況を知らせるメールを書いてください。」
- 「今週のチームの状況を関係者に伝えてください。」