worklog-reflection

name	worklog-reflection
description	作成手順「worklog-reflection」（self-evolving-agent から自動同期）: Procedure: worklog-reflection

Procedure: worklog-reflection

日次ワークログ作成手順（Andy の EM 版）

用途: 毎日の業務終了時または翌朝に当日活動を記録し、workspace/worklog-YYYYMMDD.md または Notion 日次ページとして出力するとき。所要時間: 10〜15 分。

---

Step 0: 前日クロージング — 翌朝 5 分で実施（必須）

実施タイミング: 今日のワークログを書き始める直前（翌朝冒頭）。
当日夜に書く場合は「記入予定: 翌朝」と書いて省略可。

前日のワークログファイルを開き、「つぎやること」セクションを確認する。

## 前日クロージング — [前日の日付（曜日）]

| # | アクション | 期限 | 状態 | 備考 |
|---|---|---|---|---|
| 1 | [前日のアイテム 1] | [YYYY-MM-DD] | ✅完了 | — |
| 2 | [前日のアイテム 2] | [YYYY-MM-DD] | ❌未完了 | [理由 1 行] |
| 3 | [前日のアイテム 3] | [YYYY-MM-DD] | 🔄持ち越し | [まだ期限内] |

ルール（3 つだけ）:

1. ❌ 未完了アイテム → 今日の「つぎやること」の先頭に転記。前日ファイルは変更しない。
2. 🔄 持ち越し（期限内） → 今日の「つぎやること」に再掲（期限はそのまま）。
3. 同じアイテムが 2 日連続 ❌ → 「本当に必要なタスクか？」を問い、不要なら今日のログにその判断を書いて削除してよい。

ショートカット: 前日の全件 ✅ 完了だった場合は「前日全件完了 ✅」の 1 行だけ残して省略可。

---

Step 1: 4 セクション構成を使う

ワークログは必ず以下の 4 セクションで構成する。 3 番目まで既存のフォーマットと同じ。4 番目（昇格候補）が今回追加した核心。

---

Step 2: やったこと — 事実ベースの行動記録

書くもの: 完了した行動・決定・委譲を具体的に書く。

✅ 良い例:
- PR #214 をレビューし Approve した（招待フローの認証ロジック）
- タイムゾーン P1 の原因を特定し Mei に修正委譲した
- 電通 MTG でログ仕様の宿題 1 件を持ち越した

❌ 避ける例:
- P1 対応を頑張った          ← 「状態記述」で完了物がない
- 色々レビューした           ← 何を・どう判断したか不明
- 電通とミーティングした     ← 何が決まったか / 残ったかが消える

目安: 1 日 3〜7 項目。多すぎる（8 以上）なら焦点が散漫。

---

Step 3: わかったこと — 転用可能なルール（3 要素フォーマット）

構造:

[転用ルール] 〇〇するときは△△から始めると□□ができる
[裏付け]    今日: 具体的な観察事実（何が起きたか・何分かかったか）
[適用条件]  このルールが有効な状況（不明 / 汎用の場合は省略可）

具体例（変換イメージ）:

❌ 90 点レベル（観察のみ）:
「タイムゾーン系バグはサーバ側から当たると速い。今回午後中に解決できた。」

✅ 93+ 点レベル（3 要素フォーマット）:
[転用ルール] タイムゾーン系バグは「クライアント側変換」より「サーバ側変換」
             から先に確認する。
[裏付け]    今日: サーバ側 UTC 変換漏れを昼に特定 → 午後に修正委譲完了。
             逆順で当たっていたら半日以上ロスしていた。
[適用条件]  バグ報告が「日付が 1 日ずれる / 時刻がおかしい」の場合に適用。

ポイント: 「転用ルール」は命題として書く（「〇〇するときは〜」「〜のとき先に〜」）。 読み返したとき、即座に「次どうするか」が分かる密度が目標。

目安: 1 日 2〜4 項目。少ない方が質が高い（絞ることで一般化が深まる）。

---

Step 4: つぎやること — 期限・オーナー付きアクション

• 期限（YYYY-MM-DD）とオーナーを全件明記
• 期限不明は [未定] プレースホルダー（空欄禁止）
• Lesson C 規則: 締切日は必ず python3 で平日か確認してから記載する:

  python3 -c "from datetime import date; d=date(YYYY,M,D); print(d, d.strftime('%A'))"
  

  土日に当たる場合は直前金曜か翌週月曜に移動し、インライン注記を添える。

✅ 良い例:
- [ ] 電通チームとのログ仕様宿題を Slack に流す（月 2026-06-22 中）
- [ ] Mei の P1 修正 PR を優先レビュー（上がり次第即日）
- [ ] 新メンバーと 15 分フォローアップ（月 2026-06-22 中）

---

Step 5: 🌱 Lesson / Procedure 昇格候補（新規追加セクション）

このセクションの目的: 「わかったこと」の中から、Lesson または Procedure に 格上げする価値があるものを明示的に記録し、次の kaizen セッションへ橋渡しする。

昇格判断の 3 基準（いずれか 1 つを満たせばフラグを立てる）:

基準	問い
汎用性	特定案件でなく、繰り返すタスクで再利用できるルールか？
再発防止	明示しないと同じミスや非効率が繰り返されるか？
他者価値	チームメンバーや将来の自分に共有する価値があるか？

記録フォーマット:

🌱 [Lesson / Procedure] [仮タイトル]
   → 昇格理由 1 文（3 基準のどれに該当するか）
   → 関連する既存 Lesson 番号または Procedure 名（あれば）

例:

🌱 Lesson「外部 MTG の宿題は当日中に責任者・期限を明文化する」
   → 再発防止: 今日の電通 MTG で宿題が持ち越され、責任者未確定のまま埋もれかけた
   → 既存: Lesson A（プレースホルダー規律）と類似だが外部パートナー文脈で独立価値あり

🌱 Procedure「オンボーディング認識ズレの早期発見 → 資料反映の手順」
   → 汎用性: 新メンバーが入るたびに繰り返す。手順化すれば毎回ゼロから考えなくなる
   → 既存: 該当なし

候補がない日は必ず「なし」と書く。（書かないことと確認した上で「なし」は異なる）

---

Step 6: 出力フォーマット

# ワークログ — YYYY-MM-DD（曜日）

---

## 前日クロージング（Step 0）
> 翌朝に記入。当日夜に書く場合は「記入予定: 翌朝」と書いて省略可。

| # | アクション | 状態 | 備考 |
|---|---|---|---|
| 1 | … | ✅ / ❌ / 🔄 | … |

---

## やったこと

- [完了した行動・決定・委譲]
- ...

---

## わかったこと

- [転用ルール] …
  [裏付け]    今日: …
  [適用条件]  …（省略可）
- ...

---

## つぎやること

- [ ] [アクション]（[オーナー] / [YYYY-MM-DD] 中）
- ...

---

## 🌱 Lesson / Procedure 昇格候補

🌱 [Lesson / Procedure] [仮タイトル]
   → [昇格理由 1 文]
   → [関連する既存項目]

（候補なし → 「なし」と明記）

---

Step 7: 出力前の品質チェック（30 秒）

• Step 0（前日クロージング）を実施したか（翌朝ルール。当日夜書きは免除）
• ❌ 未完了アイテムを今日の「つぎやること」先頭に転記したか
• やったことが「完了した行動」で書かれているか（状態記述になっていないか）
• わかったことに「転用ルール」が含まれているか（今日の案件専用の観察で終わっていないか）
• つぎやることに期限・オーナーが全件入っているか（[未定] でも可）
• 期限日が平日か python3 で確認したか
• 昇格候補を確認し「なし」か具体的に記録したか
• 翌朝読み直して当日の判断と学びが再現できる密度か

---

取り込み経緯:

• 2026-06-21 初版: 「毎日使うワークログに手順書がゼロ、かつ「わかったこと」が転用可能なルールとして書かれず、Lesson/Procedure へのパイプラインが断絶している」と自己診断。「わかったこと 3 要素フォーマット」と「🌱 昇格候補セクション」を追加。
• 2026-06-29 Step 0 追加: 「前日確認（Check）がゼロ = PDCA のループが断絶している」と自己診断。1on1-prep・kaizen-report は全て「前回確認」を先頭に持つが worklog だけが例外だった点を修正。Step 0（前日クロージング）を追加し、毎日の日次サイクルを完全な PDCA ループにした。