ストーリー

ポモドーロ・テクニック

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

基本サイクル

graph LR
    A["25分 集中<br/>1回目"] --> B["5分 休憩"]
    B --> C["25分 集中<br/>2回目"]
    C --> D["5分 休憩"]
    D --> E["25分 集中<br/>3回目"]
    E --> F["5分 休憩"]
    F --> G["25分 集中<br/>4回目"]
    G --> H["15分 長い休憩"]

    classDef focus fill:#cce5ff,stroke:#004085,color:#000
    classDef rest fill:#d4edda,stroke:#28a745,color:#000
    classDef longrest fill:#fff3cd,stroke:#856404,color:#000
    class A,C,E,G focus
    class B,D,F rest
    class H longrest

4回で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分で解決

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

重要な注意点

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

2分ルール

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

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

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

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

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

graph TD
    A["依頼が来た"] --> B{"2分以内で終わる？"}
    B -->|"Yes"| C["今すぐやる"]
    B -->|"No"| D["タスクリストに追加"]
    D --> E{"優先度は？"}
    E -->|"緊急かつ重要"| F["今のタスクを中断して対応"]
    E -->|"今日中"| G["次のポモドーロ間で対応"]
    E -->|"急がない"| H["計画に組み込む"]

    classDef now fill:#d4edda,stroke:#28a745,color:#000
    classDef urgent fill:#f8d7da,stroke:#dc3545,color:#000
    classDef later fill:#fff3cd,stroke:#856404,color:#000
    class C now
    class F urgent
    class G,H later

バッチ処理

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

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

graph LR
    A1["タスクA"] --> B["タスクB"]
    B --> A2["タスクA"]
    A2 --> C["タスクC"]
    C --> A3["タスクA"]

    B -.- L1["切替ロス<br/>15~30分"]
    A2 -.- L2["切替ロス<br/>15~30分"]
    C -.- L3["切替ロス<br/>15~30分"]

    classDef task fill:#cce5ff,stroke:#004085,color:#000
    classDef loss fill:#f8d7da,stroke:#dc3545,color:#000
    class A1,A2,A3,B,C task
    class L1,L2,L3 loss

1日に10回切り替えると、2.5~5時間のロス!

バッチ処理の例

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時以降に対応します」

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

エネルギーマネジメント

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

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

quadrantChart
    title エネルギーレベルとタスク配置
    x-axis 朝 --> 夕方
    y-axis 低エネルギー --> 高エネルギー
    設計・実装: [0.15, 0.9]
    難しいバグ修正: [0.45, 0.85]
    PRレビュー: [0.3, 0.55]
    ドキュメント作成: [0.6, 0.5]
    メール返信: [0.5, 0.2]
    タスク整理: [0.8, 0.15]

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

まとめ

チェックリスト

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

次のステップへ

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

推定読了時間: 25分