TL;DR
- 休み明けからの復帰に時間がかかる
- 根本的な仕組みを整えるほうが本質的に効く
対象読者
- 連休明けの立ち上がりが毎回つらいエンジニア
- 休暇との付き合い方を仕組み側から見直したい方
はじめに
復帰後の大変さを仕組みから変更するイメージ。
連休明けの月曜、エディタを開いて固まったことがあるエンジニアは多いと思います。
「あれ、自分は先週何をしていたんだっけ？」
「このブランチ、なんで切ってたんだっけ？」
この本質的な解決方針を検討します。
"コンテキスト保持コスト"
エンジニアの仕事は、ほぼ全てが「直前まで頭に積み上げていた前提」の上に成り立っています。
- どのブランチで何をやっていたか
- どのSlackスレッドが残っているか
- なぜこの設計に決まったか
これらは作業中の脳の中にだけ存在する一時メモリです。休暇中、この一時メモリは確実に揮発します。
つまり問題は揮発したコンテキストを再構築するコストが高すぎるということです。
ここを直視せずに「気持ちの問題にしても」それは「対症療法」にすぎません。
本質解：休暇の前後を"仕組み"で設計する
筆者が辿り着いた結論はシンプルです。
休暇中の過ごし方ではなく、休暇に入る直前と出る直後を設計する
以下、エンジニアであれば今日から試せる3つの仕組みを紹介します。
① 休み前に"未来の自分への引き継ぎ"を書く
休み前に「自分への引き継ぎ」に時間を充てます。書く内容は具体的にこれだけで十分です。
## いま取り組んでいるタスク
- ブランチ: feature/holiday-handover
- 概要: 申請API の戻り値型を Result<T> に統一する
- 進捗: service.ts:42 まで実装済み。テストは未着手
## 次の最初の1手
- src/api/holiday/service.ts の validate() を Result<T> 返却に書き換え
- そのあと controller.ts:88 の呼び出し側を修正
## 待ち
- @taro さんに DTO のレビュー依頼中 (Slack: #team-api スレッド)
- CI の flaky test 調査チケット (HOL-142) は再現待ち
ポイントは「次の最初の1手」を関数名・行番号レベルで書くことです。
「機能Aの設計を続ける」ではなく「feature/xxx の service.ts:42 から書く」と書く。これがあるだけで立ち上がりコストが目に見えて下がります。
これは過去記事 リモートワーク時代、PMの仕事は「察する」から「設計する」に変わった と同じ構造です。気合に頼らず仕組みで未来の自分を助けます。
② 戻ってきた朝は"作業せず眺める"時間を取る
月曜朝、いきなりコードを書き始めるのは悪手です。
最初の30分は「読むだけ」に使います。
- 引き継ぎメモを読む
- 該当ブランチの
git logを眺める - 自分宛のメンション・PRを眺める
ここで コーディングを始めない のがコツです。脳に前提が戻る前に手を動かすと的外れな修正をする可能性が高いです。
③ AIに"先週の自分"を要約させる
AI時代ならではの仕組みです。休暇前に書いたメモ・コミットログ・PRのdiffをまとめてAIに渡し、「先週の自分が何をしていたか」を要約させます。
たとえば、休暇明けに次のワンライナーで自分の直近の動きを集めます。
git log --author="$(git config user.email)" --since="2 weeks ago" \
--pretty=format:"%h %ad %s" --date=short
これをAIに渡し、次のようなプロンプトで要約させます。
以下は私が休暇前にコミットしたログです。
休暇明けの私が作業を再開するために、次の3点を整理してください。
1. 取り組んでいたテーマ（複数あればテーマ別に）
2. 各テーマで「どこまで終わって、次は何から手を付けるべきか」
3. 未解決のまま残っている疑問・依頼待ち
<コミットログを貼り付け>
PRのdiffや休み前メモを一緒に渡すとさらに精度が上がります。休んでいる間に揮発した記憶を外部メモリから復元する（「思い出す」という人間の苦手作業をAIに肩代わりさせる発想）
おわりに
「休み明けの仕事が大変」は気合の問題ではなく、エンジニアリングの問題です。
- つらさの正体は「コンテキスト保持コスト」
- 解くべきは「休み方」ではなく「休暇の前後の仕組み」
- 引き継ぎメモ・読むだけの時間・AIによる要約、やることはこの3つだけ
連休明けに「先週何してたっけ」と固まりかけたら自分にこう言い聞かせるようしています。
→ 気合じゃなくて、仕組みで解こう。
あわせて読みたい