集中作業と応答時間を分ける
設計やデバッグのように長時間コンテキストを維持する必要がある作業は、カレンダーにまとめて確保しましょう。午前中が誰にとっても最適とは限りません。自分が実際に集中できる時間帯を選び、緊急連絡を受ける方法はチームと事前に決めておくと現実的です。
作業を次の行動単位まで小さくする
「決済機能の開発」のように大きな名前だけを書いても、始めるべき地点が見えません。要件確認、失敗条件の作成、テストの追加、実装、レビュー依頼のように、次の行動へ分けましょう。1 日の優先順位も、数字を無理に固定するのではなく、締め切り、ユーザーへの影響、他の人が待っているかどうかで決めるとよいでしょう。
タイマーは選択肢として使う
ポモドーロは、一定時間集中した後に休憩する方法です。25 分が合わなければ、もっと短い、または長い区切りを使ってもかまいません。タイマーがかえって流れを断つなら、使わなくても大丈夫です。大切なのは、始める前に 1 つの成果を決め、終わった後に次の行動を残すことです。
会議は時間より目的を先に確認する
決める内容、必要な参加者、準備資料がなければ、まず文書やメッセージで代替できないか考えましょう。複雑な設計議論のように、会話のテンポが重要なことは会議を開き、終了時に決定事項、担当者、次回確認日を記録します。すべての会議を午後や 30 分以内に固定する必要はありません。
レビュー待ちの時間をスケジュールに含める
コードを書いた後にも、レビュー、修正、テスト、デプロイの時間が残ります。作業計画には自分の作業だけでなく、他の人が確認する時間も含めましょう。大きな変更はレビューしやすい単位に分け、変更理由と確認方法も一緒に書くと、やり取りの時間を短縮できます。
自動化は繰り返し回数と失敗コストで選ぶ
1 回に 5 分かかるからといって、すべてを自動化する必要はありません。頻繁に繰り返す作業や、人が見落としやすいテスト、形式チェック、デプロイ前の確認から、小さな自動化を試しましょう。維持管理にかかる時間が節約できる時間を上回るなら、シンプルなチェックリストのほうが適している場合もあります。