はじめに — 「10時間働いたのに、コードは 100 行も書けてない」
ほぼすべての開発者が抱える悩み。原因:
- 週 10〜15 時間の会議
- 週 5〜10 時間の Slack・メール対応
- コンテキストスイッチ (分単位で割り込み)
- バーンアウトによる日中のフォグ
- 夜になってやっと静かになる → 健康悪化
本稿の内容:
- Deep Work — Cal Newport の実践
- GTD — David Allen を開発者向けに
- Calendar Blocking、Time-boxing、Pomodoro の比較
- 会議・Slack・メールのトリアージ
- Manager スケジュール vs Maker スケジュール
- バーンアウトの初期サインと予防
- 40〜50代でも集中力を保つ
Season 3 Episode 9。前回の「お金」で時間は複利と述べた。今回はその時間をどう使うか。
Chapter 1: Deep Work — なぜ深い集中か
1.1 定義
Cal Newport (Deep Work, 2016):
「Deep Work とは、認知的努力の限界で行われ、価値を生み、複製されにくい作業である。」
対義語は Shallow Work: 物流的雑務、メール、会議、繰り返し作業。
現代知識労働の罠: Shallow が膨張し、Deep が縮む。
1.2 開発者にとっての価値
複雑なバグ調査、アーキテクチャ設計、新技術の学習 — すべて Deep Work。
1 時間の Deep > 5 時間の Shallow。集中の質が量を凌ぐ。
1.3 4 つのモード
Monastic: 修道院モード。Shallow を全遮断。Knuth がメールを使わない理由。
Bimodal: 一定期間は Monastic、一定期間は Shallow。例: 論文執筆中の 2 週間集中。
Rhythmic: 毎日決まった時間 (例: 6〜9時)。
Journalistic: 隙間時間をすべて Deep に。熟練が必要。
1.4 環境づくり
- ブロックスケジュール: Calendar に Deep Work ブロックを固定
- 通知遮断: Do Not Disturb、Slack Snooze
- 物理的分離: 会議室、カフェ、図書館
- 開始儀式: コーヒー → 音楽 → コード
- 終了儀式: 「今日はここまで」と宣言
1.5 1 日の上限
- 初心者: 1〜2 時間
- 訓練後: 3〜4 時間
- 上限: 1 日 4 時間 (Newport、Knuth)
1 日 8 時間の Deep Work は不可能。マラソンではなくスプリント 4 本。
Chapter 2: GTD — 頭を空にする仕組み
2.1 5 ステップ
David Allen (Getting Things Done, 2001):
- Capture (収集): 頭の中をすべて外に出す
- Clarify (明確化): 各項目の意味を判定
- Organize (整理): カテゴリ別に分類
- Reflect (見直し): 定期レビュー
- Engage (実行): 今何をするか決める
2.2 Capture ツール
- 紙ノート、アプリ (Notion、Apple Notes、Obsidian)
- 単一 Inbox: すべてを 1 カ所に
- 「Inbox Zero」は非現実的、「定期排出」が現実的
2.3 2 分ルール
Clarify の段階:
「2 分以内にできるなら今やれ。」
- 短いメール返信
- 小さな PR レビュー
- コードコメント追加
理由: 保管・管理コストが実行コストを上回る。
2.4 Context
行動別のグルーピング:
@computer: PC が必要@phone: 電話が必要@office: オフィスで@waiting: 相手待ち@someday: いつか
開発者版:
@code: IDE の前@review: PR レビュー@design: ドキュメント・図@meeting: 会議準備@learn: 書籍・講義
2.5 Weekly Review
毎週 30〜60 分:
- Inbox を空に
- 進行中プロジェクトの確認
- 来週の優先 3 件
- Someday リスト更新
これがないと GTD は崩れる。
2.6 開発者への適用
Capture:
- Slack 通知 → Todoist/Notion へ移動
- バグ → Jira/Linear に登録
- アイデア → Obsidian daily note
Clarify/Organize:
- Jira バックログ = 長期保管
- Todoist = 今日/今週
- Calendar = ブロック済み作業
Engage:
- 今日の優先 3 件 (MIT — Most Important Tasks)
- Calendar ブロックに固定時間
Chapter 3: Calendar Blocking
3.1 定義
1 日のすべての時間をブロックで割り当てる。「いつ何をやる」を先に決める。
3.2 1 日の例 (開発者)
08:00 - 09:00 朝のルーチン + 運動
09:00 - 11:30 Deep Work: コア実装
11:30 - 12:00 Slack/メールのトリアージ
12:00 - 13:00 昼食 + 読書
13:00 - 14:00 会議 (週次シンク)
14:00 - 15:00 PR レビュー
15:00 - 17:00 Deep Work: 2 本目
17:00 - 18:00 1-on-1 / 締め
18:00+ 個人時間
3.3 Buffer 原則
- 会議間 15 分バッファ: 移動・休憩・準備
- ブロック間 30 分バッファ: 認知の切替
- 1.5 倍: 1 時間想定なら 1.5 時間ブロック
3.4 ブロック防衛
- 「Focus Time」ラベル
- Accept されても移動を依頼
- Slack/Zoom ステータスで邪魔禁止
Google Calendar の Focus Time 機能: 自動拒否 + Slack 通知抑制。
3.5 障害物
- 緊急対応: ブロックが侵食される → 予備時間を確保
- 上司の会議: 断りにくい → Focus ブロックを事前登録
- 自分の誘惑: Slack 見たい → アプリ遮断
Chapter 4: Time-boxing
4.1 Calendar Blocking との違い
Calendar Blocking: 各時間に何をやるかを割り当てる。 Time-boxing: 各タスクに上限時間を割り当てる (より厳格)。
4.2 例
- この PR レビュー → 30 分
- 新機能 Spike → 4 時間 (超過したらアプローチ再考)
- このバグ調査 → 2 時間 (その後エスカレーション)
4.3 Parkinson の法則
「仕事は与えられた時間いっぱいに膨張する。」
制限なし → 永遠の微調整。 制限あり → 優先度が強制される。
4.4 実践のコツ
- 2 時間解けない → 同僚に聞く
- 4 時間 Spike → アプローチを変える
- 30 分会議 → 30 分を超えない
Chapter 5: Pomodoro とウルトラディアン・リズム
5.1 Pomodoro
- 25 分集中 + 5 分休憩
- 4 回後に長休憩 (15〜30 分)
- Francesco Cirillo (1980 年代)
長所: シンプル、開始しやすい。 短所: 25 分が短すぎることも (Flow 入りかけで切れる)。
5.2 90 分ウルトラディアン
- 人間の自然周期 = 90 分集中 + 20 分休憩
- Peter Schulman、Nathan Kleitman の研究
- 開発者の Deep Work により適合
5.3 Flow State
Mihaly Csikszentmihalyi:
- 挑戦の難易度 ≈ 自分の能力
- 明確な目標
- 即時フィードバック
- 時間感覚の消失
- 自我の消失
入るのに 15〜20 分。25 分 Pomodoro では Flow に入らない。
5.4 推奨
- 複雑な実装: 90 分ブロック + 20 分休憩
- 簡単な PR レビュー: 25 分 Pomodoro
- 学習・読書: 45〜60 分
Chapter 6: Manager スケジュール vs Maker スケジュール
6.1 Paul Graham のエッセイ
Paul Graham (2009):
Manager's Schedule: 1 時間単位のスロット。会議が普通。
Maker's Schedule: 1 日を 2〜4 ブロック。会議 1 本でブロックが崩壊。
開発者は Maker。午前の会議 1 本 = 午前の Deep Work ブロック消滅。
6.2 衝突と解決
Manager:
- 「10 時に 30 分の会議どう?」
- (Manager 視点) 14 時までまだ 7 時間ある
- (Maker 視点) 午前ブロックが崩壊
解決:
- Maker は 午後に会議を集約
- 午前ノーミーティングを宣言
- 非同期に置換 (動画録画、ドキュメント)
6.3 「No Meeting Day」文化
多くの企業が導入:
- GitLab: Focus Friday
- Asana: Wednesday No Meeting
- Basecamp: 構造的に最小会議
6.4 Staff+ のスケジュール転換
Senior までは Maker。Staff+ で Manager 要素が増える。
折衷:
- 午前: Maker (Deep Work)
- 午後: Manager (1-on-1、レビュー、会議)
Chapter 7: Slack・メール・会議のトリアージ
7.1 Slack ルール
送信者:
- スレッド利用 (チャンネル汚染防止)
- 1 メッセージで完結
@here、@channel濫用禁止- DM より チャンネル (知識共有)
受信者:
- DND (Do Not Disturb) 活用
- Focus ブロック中は通知オフ
- 決まった時間のみ Slack を開く (10:00、13:00、16:00)
- 通知はモバイルのみ (デスクトップは静か)
7.2 メールトリアージ
毎日 Inbox Zero:
- 削除 (スパム、ニュースレター)
- 返信 (2 分以内)
- 委任 (その人の責任)
- 延期 (To-Do 登録)
- アーカイブ (参照)
時間制限: 朝 15 分、昼 10 分、夕 10 分。
7.3 会議トリアージ
受諾基準:
- 自分が決定者か
- 事前資料があるか
- 目的が明確か
- 他の時間がないか
断りのスクリプト:
「ありがとうございます。私なしで進められるならメモ共有をお願いします。難しければ来週はいかがでしょう?」
7.4 会議を減らす
- 同期 → 非同期: Loom 録画、ドキュメント回覧
- 定例の見直し: 四半期ごとにすべての反復会議を点検
- Standup 代替: Slack daily post
Chapter 8: バーンアウト — 初期サインと予防
8.1 WHO の 3 要素
- 情緒的消耗 (Emotional exhaustion): 枯渇感
- 脱人格化 (Depersonalization): 「何も意味がない」
- 達成感の低下 (Reduced accomplishment): 無力感
8.2 初期サイン 10 個
- 朝起きたくない
- 会議に出る気力がない
- Slack を見たくない (週末も)
- 小さなバグに過剰に苛立つ
- 同僚の発言が癪に障る
- 週末で回復しない
- 睡眠の質低下
- 食事量・飲酒量増加
- 運動をやめた
- 趣味が面白くない
8.3 予防
毎日:
- 7〜8 時間の睡眠
- 30 分以上の運動
- 昼休みは本当に休む (コードしない)
- 夜は Slack を切る
毎週:
- 週末の 1 日は完全オフ
- 家族・友人との時間
- 自然 (散歩、公園)
毎年:
- 年休を全消化
- 1 週間以上連続休暇 (脳のリセットには 10 日以上)
- 必要なら Sabbatical (長期休職)
8.4 回復
初期:
- 1 週間の休暇
- 運動・睡眠の回復
- 会議を半減
中期:
- 役割・プロジェクトの変更申請
- 治療・カウンセリング検討
- チーム編成の見直し
後期:
- 転職検討
- Sabbatical または パートタイム
- 精神医療
Chapter 9: 40代・50代でも集中力を保つ
9.1 認知加齢の現実
- 30 代後半から作業記憶 (working memory) が低下
- 新技術の習得時間が増える
- 回復が遅くなる
9.2 対応戦略
体力管理:
- 週 3 回の有酸素 (心臓 = 脳)
- 筋力トレーニング (40 代から筋減少)
- ストレッチ (腰、首)
食習慣:
- 地中海式 (オリーブオイル、魚、野菜)
- 朝の たんぱく質 (脳のエネルギー)
- 水分、電解質
睡眠:
- 7〜9 時間
- ブルーライト管理
- 睡眠トラッキングアプリ
9.3 経験の強み
加齢は悪いことばかりではない:
- 判断力: 多数の事例をパターンマッチ
- 意思決定: 速く正確
- コミュニケーション: 落ち着き、説得力
Staff+ エンジニアには 経験こそ武器。
9.4 長寿開発者の共通点
- 毎日少しずつ学ぶ: 一気呵成より継続
- 好奇心を保つ: 新言語、新ドメイン
- ネットワーク: 若手とつながる
- シンプルな生活: 派手さより持続性
- 承認欲求を手放す: 40 代以降はプライドを下げる
Chapter 10: リモートワーク時の時間管理
10.1 長所と罠
長所: 通勤ゼロ、集中、家族。 罠: 境界が曖昧、孤立、運動不足。
10.2 区切りの儀式
- 出勤儀式: 着替え、コーヒー、散歩のあと机へ
- 退勤儀式: PC を閉じる、「退勤」ルーチン
- 作業空間の分離: 寝室で仕事をしない
10.3 孤立対策
- 週 1 回は外出 (カフェ、コワーキング)
- 週 1 回はオフライン集まり (コミュニティ、友人)
- 週 1 回は家族・友人と通話
10.4 Async 文化
- Slack にすべてを流さない (ドキュメント化)
- Loom 録画 (3 分録画 = 30 分会議)
- Standup の代わりに Daily Slack Post
- Decision Log を文書化
Chapter 11: ツール推奨
11.1 タスク管理
- Todoist: シンプル、クロスプラットフォーム
- Things 3: Apple 生態系、美しい
- OmniFocus: GTD 特化
- Notion: 柔軟
- Linear/Jira: 業務用
11.2 ノート
- Obsidian: Markdown、ローカル、Zettelkasten
- Apple Notes: 基本だが強力
- Notion: DB + ノート
- Roam Research: 双方向リンク
- LogSeq: オープンソース版 Roam
11.3 集中ツール
- Freedom: サイトブロッカー
- Cold Turkey: 強制ブロッカー
- Focus To-Do: Pomodoro
- macOS Focus Mode: 標準機能が強力
11.4 Calendar
- Google Calendar: 基本
- Fantastical: 自然言語入力
- Cron/Notion Calendar: モダン UI
11.5 AI アシスタント
- ChatGPT/Claude: ブレインストーミング
- Notion AI: ノート要約
- Raycast AI: 素早い質問
- Copilot (Writer、Code): 反復作業
Chapter 12: 12 項目生産性チェックリスト
- Deep Work ブロック: 週 10 時間以上保護
- No Meeting Day: 週 1 日
- Inbox Zero: 週 1 回到達
- Slack 時間制限: 通知時間帯を設定
- Weekly Review: 30 分定期
- MIT 3 件: 朝の開始時に決定
- 会議の事前資料: 前日までに共有
- 運動 週 3 回: 50 分以上
- 睡眠 7 時間以上: 定期的に
- Sabbatical プラン: 3〜5 年毎に 2 週間以上の連続休暇
- 1-on-1 記録: 毎回ノート
- バーンアウト点検: 月 1 回の自己点検
Chapter 13: 生産性アンチパターン 10 選
1) 「忙しく見せる」演技
Slack 即返信で忙しさを演出。実価値ゼロ。可視性 ≠ 生産性。
2) マルチタスク自慢
同時に 3 件。コンテキストスイッチのコスト 40% 超。シングルタスク原則。
3) 通知オールオン
全アプリ通知 ON。1 日数百回の割り込み。デフォルトは OFF。
4) 会議 = 生産性の錯覚
1 日 8 時間会議 = 8 時間の生産性? 何も作っていない。
5) 「後で休む」の先延ばし
プロジェクト後に休む。プロジェクトは終わらない。定期的な休息が必須。
6) カフェイン乱用
4 杯以上のコーヒー。睡眠破壊、不安。午後 2 時以降は禁止。
7) 夜にまとめて
昼は会議、夜にコード。睡眠破壊。日中の Deep Work を死守。
8) 完璧なセットアップ追求
新 Notion、新 Todoist の設定に時間。実務は進まない。80% で開始。
9) 「マニュアルなし」自慢
チェックリストを軽蔑、同じミスを繰り返す。チェックリストこそプロ。
10) 休み方が分からない
休日も Slack。本当の休息ができない。Off は練習が必要。
むすびに — 時間こそ唯一の有限資源
原則 1: 生産性は健康から
睡眠、運動、食事が基盤。これなしにどんなシステムも失敗。
原則 2: 単純さが複雑さに勝つ
Notion の 30 テンプレ < ノート 1 枚 + To-Do 1 件。簡素 > 洗練。
原則 3: 1 日を事前設計
朝に MIT 3 件を決め、夜に振り返る。この 2 回が核。
原則 4: 「No」が「Yes」を可能にする
断りなしに集中なし。重要でない仕事から自分を守る。
原則 5: 完璧より一貫性
毎日少しずつ > 一気にたくさん。複利の魔法。
原則 6: 原典を読め
- Deep Work - Cal Newport
- Getting Things Done - David Allen
- Slow Productivity - Cal Newport
- Maker's Schedule, Manager's Schedule - Paul Graham
- The 4-Hour Workweek - Tim Ferriss
- Rest - Alex Soojung-Kim Pang
次回予告 — 「開発者のメンタルヘルス完全ガイド」
Season 3 Ep 10 では:
- 開発者のメンタルヘルス統計 (Stack Overflow Survey)
- インポスター症候群の発生メカニズム
- 不安・ストレス管理
- うつの初期サイン
- セラピー、CBT、瞑想
- 会社の EAP (Employee Assistance Program) 活用
- 韓国で開発者が精神科に行きづらい理由
- コミュニティと同僚の役割
- 家族の支援、または障壁
- 回復と再発予防
次回へ。
현재 단락 (1/311)
ほぼすべての開発者が抱える悩み。原因: