- 毎日同じ生産性を維持するのではなく、集中力が最大化される日とそうでない日を区別して働く方法
- エンジニアの仕事への集中度は日によって異なり、それを問題と見なさず自然に受け入れることが、むしろ生産性に有利
- 集中できていない状態で高難度のプロジェクト作業を無理に進めると、重要なポイントを見落とすミスが起きやすい
- プロジェクト作業でのミスは単なるやり直しよりも調整コストの方が大きいため、待った方がよい
- 集中しているときは高優先度の作業だけに没頭し、そうでないときは簡単な作業を中心に処理する戦略が効果的
- 大規模テック企業では暇な時期と集中期が繰り返されるため、このリズムに合わせた働き方が効率的
作業リズムに関する基本的な観察
- エンジニアごとに1日の生産性は一定ではなく、ある日は極度に集中でき、別の日は限定的である
- 同じ労働時間を維持しようとする試みが、かえって過労や自己非難につながることがある
- 生産性の高い日と低い日の差を問題視せず、自然な変動として受け入れるべきである
集中作業の定義
- **「集中作業」**とは単に時間を投じることではなく、プロジェクトに実質的な前進をもたらす作業を意味し、すべての業務を指すわけではない
- 講座の受講、単純なPRレビュー、メッセージへの返信、反復的なコーディングは、集中力が低くても実行できる
- 集中力が不足している日でも完全に休むのではなく、補助的な作業をこなすことで時間を活用する
無理に押し切ることの問題点
- 高難度のプロジェクト作業では、没入している状態（Flow/集中）とそうでない状態とで成果物の品質が異なる
- 集中できないときに高リスクのプロジェクト作業（重要コードの作成、対外コミュニケーションなど）を行うと、翌日になって重要なポイントを見落としていたり、ミスしていたことに気づくことが多い
- プロジェクトのデプロイ時のミスは、単純なやり直しよりも修正コストが高い
- チームに誤った依頼をすると、本当に必要なものを説明しづらくなり、依頼の優先度が下がる可能性がある
- 集中状態ではないときに無理に働くと、頭痛がして具合が悪いように感じる
- まるで集中状態で限られた内部資源を消費し、それが精神的な休息によってゆっくり回復するかのように感じられる
- 集中しているときは12時間以上働いても平気である
- もちろん締め切りや緊急の依頼時には、状態に関係なく集中しなければならない
- ただし最終スプリント前までは、プロジェクトはおおむね外部依存の待ち時間に支配されている（特に大企業では）
- したがって、特定の作業をいつ行うかについてはある程度の裁量がある
2つの働き方
- 集中状態のとき（in the zone）:
- 問題がより単純に見え、複雑な作業もやってみる価値があるように感じられる
- あらゆる妨害要因を最小化し、最優先の業務に没頭する
- 本当に重要なメッセージ以外は返信を後回しにする（Slackの**「後で通知」**機能を活用）
- マルチタスクをできるだけ避け、一度に1つの作業に集中する
- 夕方以降まで働きたければそうし、翌日やその次の日に十分休んで時間を取り戻す
- 集中状態ではないとき（not in the zone）:
- すべての作業が複雑で、リスク要因が多く見える
- 防御的に進め、リスクを避けようとする
- 優先順位をそれほど気にせず、手早く得られる成果を出すことに集中する
- 複数のプロジェクトの間を行き来しながら、会話や軽めの業務を多く行う
- 普段より早く退勤しても構わない（あとで集中期間に取り返せると分かっているため）
ビッグテック企業での適合性
- この働き方は大規模技術企業で意外なほどよく合う
- 経験上、すべてのチームの仕事は似たようなパターンに従う
- 暇な低優先度プロジェクトの時期と、経営陣が突然強い関心を示す高優先度プロジェクトの時期が交互に現れる
- 暇な時期には余裕を持ち、集中期には没頭することが、非常に効率的なアプローチである
まだコメントはありません。