LESSON 25分

タイムマネジメントの技術

ストーリー

「優先度はわかった。でも時間が足りない気がして......」

渡辺マネージャーが頷いた。

「時間は全員に平等に1日8時間だ。 でも、同じ8時間でも成果に大きな差が出る。 それがタイムマネジメントの技術だ。 いくつかの実践的なテクニックを教えよう」

ポモドーロ・テクニック

25分の集中作業と5分の休憩を繰り返すテクニックです。エンジニアの集中力維持に効果的です。

基本サイクル

[25分 集中]→[5分 休憩]→[25分 集中]→[5分 休憩]→[25分 集中]→[5分 休憩]→[25分 集中]→[15分 長い休憩]
   1回目          2回目          3回目          4回目        → 4回で1セット

エンジニア向けの運用ルール

ルール詳細
25分間はSlack通知をオフ「集中中」ステータスを設定
割り込みは記録して後回しメモに書いてポモドーロ終了後に対応
タスク切り替えはポモドーロ間で25分の途中でタスクを変えない
4ポモドーロで1セット1セット完了後に長い休憩を取る

実際の1日の運用例

 9:00 -  9:15  朝の計画立て（タスク確認、今日のゴール設定）
 9:15 -  9:40  ポモドーロ1: 本番バグの調査
 9:40 -  9:45  休憩
 9:45 - 10:10  ポモドーロ2: バグ修正の実装
10:10 - 10:15  休憩
10:15 - 10:40  ポモドーロ3: テスト作成・PR作成
10:40 - 10:45  休憩
10:45 - 11:10  ポモドーロ4: PRレビュー対応
11:10 - 11:25  長い休憩（コーヒー、ストレッチ）
11:25 - 12:00  Slackの未読対応、メール返信
12:00 - 13:00  昼休み
13:00 - 14:30  ポモドーロ5〜7: API設計のドラフト
14:30 - 15:00  ミーティング
15:00 - 16:30  ポモドーロ8〜10: 新機能の実装
16:30 - 17:00  日報・明日の準備

タイムボクシング

タスクに予め時間の上限を設定する手法です。「完璧を目指して時間をかけすぎる」問題を防ぎます。

基本の考え方

タイムボクシングなし:
  「バグ調査が終わるまでやろう」
  → 3時間経っても終わらず、他のタスクが全滅

タイムボクシングあり:
  「バグ調査は1時間まで。それで解決しなければ相談する」
  → 1時間で得た情報を元に先輩と相談 → 30分で解決

エンジニアの作業別タイムボクシング目安

作業推奨タイムボックス時間超過時のアクション
バグ調査1時間先輩やチームに相談する
コードレビュー（1PR）30分主要な指摘だけ記載し、残りは別途
技術調査・PoC2時間調査結果をまとめて判断を仰ぐ
設計ドキュメント作成2時間ドラフト段階でレビューを依頼
ミーティングアジェンダ通りファシリテーターが時間管理

重要な注意点

タイムボクシングは「時間が来たら諦める」ではなく、「時間が来たら状況を報告し、次のアクションを決める」ための仕組みです。

2分ルール

2分以内で完了するタスクは、その場ですぐやります。タスクリストに追加して管理するコストの方が高いためです。

2分以内で終わるタスクの例

  • Slackの簡単な質問に回答する
  • PRにApproveを出す（軽微な修正の場合）
  • Jiraのステータスを更新する
  • 短いメールの返信

2分を超えるタスクの場合

タスクリストに追加し、適切な時間に取り組みます。

依頼が来た
  │
  ├─ 2分以内で終わる？
  │    ├─ Yes → 今すぐやる
  │    └─ No → タスクリストに追加
  │              │
  │              ├─ 緊急かつ重要？ → 今のタスクを中断して対応
  │              ├─ 今日中？ → 次のポモドーロ間で対応
  │              └─ 急がない？ → 計画に組み込む

バッチ処理

類似のタスクをまとめて処理することで、コンテキストスイッチのコストを減らします。

コンテキストスイッチの代償

タスクA → タスクB → タスクA → タスクC → タスクA

  各切り替えで15〜30分のロスが発生
  1日に10回切り替えると → 2.5〜5時間のロス!

バッチ処理の例

バッチタスク推奨時間帯
コミュニケーションSlack確認、メール返信、質問回答朝一、昼後、夕方
レビューPRレビュー、設計レビュー午前中の1ブロック
実装コーディング、テスト作成午後の集中時間帯
管理タスク更新、進捗記録、日報夕方の30分

1日のバッチ構成例

午前（集中系）
  9:00 -  9:15  [管理] タスク確認・計画
  9:15 - 10:15  [実装] 集中コーディング
 10:15 - 10:45  [コミュニケーション] Slack・メール
 10:45 - 11:30  [レビュー] PRレビュー
 11:30 - 12:00  [実装] 集中コーディング

午後（ミーティング+実装）
 13:00 - 14:00  ミーティング
 14:00 - 16:00  [実装] 集中コーディング
 16:00 - 16:30  [コミュニケーション] Slack・メール
 16:30 - 17:00  [管理] タスク更新・日報・明日の準備

割り込み対応の戦略

エンジニアにとって最大の生産性キラーは「割り込み」です。完全に排除はできませんが、コントロールは可能です。

割り込みの分類と対応

種類例対応
緊急の割り込み本番障害、セキュリティインシデント即座に対応。現在の作業状態をメモしてから切り替え
重要な割り込みブロッカーの解消依頼現在のポモドーロ終了後に対応
低優先の割り込み「これ知ってますか？」系の質問バッチ処理の時間に対応

Slackステータスの活用

集中時:   「集中中 - 緊急時以外は後で対応します」
レビュー可: 「レビュー受付中 - PRどうぞ」
ミーティング: 「会議中 - 14時以降に対応します」

「ちょっといいですか？」への対応テンプレート

状況回答例
集中作業中「今作業中なので、11時以降でいいですか？緊急ならSlackに書いてください」
すぐ対応できる「2分で終わるなら今やりましょう。長くなりそうなら時間を決めましょう」
自分の担当外「それは佐藤さんが詳しいです。紹介しましょうか？」

エネルギーマネジメント

時間だけでなく、自分のエネルギーレベルに合わせてタスクを配置することも重要です。

エネルギーレベルとタスクの対応

エネルギー
  高 │  ★ 設計・実装     ★ 難しいバグ修正
     │
  中 │     ★ PRレビュー     ★ ドキュメント作成
     │
  低 │        ★ メール返信    ★ タスク整理
     │
     └──────────────────────────→ 時間
       朝       午前     午後      夕方

多くの人は午前中にエネルギーが高いため、創造的で難しいタスクは午前に、定型的なタスクは午後に配置すると効果的です。

まとめ

テクニック効果使いどころ
ポモドーロ集中力維持、疲労防止日常的な作業全般
タイムボクシング完璧主義の防止、時間超過の防止調査、設計など終わりが見えにくい作業
2分ルール小タスクの滞留防止日常的な依頼対応
バッチ処理コンテキストスイッチ削減類似タスクのまとめ処理
割り込み対応集中時間の確保チーム作業中
エネルギーマネジメント生産性の最大化1日のスケジュール設計

チェックリスト

  • ポモドーロ・テクニックのサイクルを理解した
  • タイムボクシングの考え方と目安を説明できる
  • 2分ルールを適用する判断ができる
  • バッチ処理で効率化できるタスクを特定できる
  • 割り込みへの対処戦略を持っている

次のステップへ

次のセクションでは、タスク管理を効率的に行うための「ツール」を紹介します。Jira、GitHub Issues、Notionなど、チームで使われるツールの活用方法を学びましょう。

推定読了時間: 25分