🍅【タスク管理】中年エンジニアが「俺史上最強のメソッド」を見つけたら、ただのポモドーロ・テクニックだった話

🍅【タスク管理】中年エンジニアが「俺史上最強のメソッド」を見つけたら、ただのポモドーロ・テクニックだった話

---

🚀 はじめに

こんにちは！とある中年エンジニアです。

この記事では、ここ2ヶ月間取り組んできた「タスク管理改善」の変遷と、そこでたどり着いた（というか再発見した）ポモドーロ・テクニック、そしてそこから得られたエンジニアリングに通じる気づきについて共有したいと思います。

最近、デブサミ（Developers Summit）への参加や書籍からの刺激を受け、「日報こそが能力を高めるための手法である」と再認識しました。その熱量でタスク管理の見直しを始めたのがきっかけです。みなさんと学びを共有できたら嬉しいです！

---

🛠️ 本題：タスク管理の変遷とポモドーロ・テクニック

1. 最初に取り組んだ「日報サイクル」

まずはシンプルに、以下のサイクルを回すことから始めました。

1. Todoを作る（見積もり）
2. タスク管理（実行）
3. ふりかえり
4. ネクストアクション設定

これを2週間ほど続けてみたところ、自身の働き方についていくつかの「残酷な現実」と「改善のヒント」が見えてきました。

2. 日報を書いて見えてきた「気づき」

やってみて分かったのは、**「人間はそんなに集中できないし、すぐサボる」**ということです。

• タスクの粒度は30分以内が限界: それ以上長いと集中力が持ちません。
• 学生症候群: 締め切りギリギリまで着手しない、あるいは隙間時間に動けない自分がいました。
• 「理解」には時間がかかる: 計画や意思決定のための調査など、抽象度の高いタスクほど時間が溶けます。
• 段取りが命: 各タスクの前半5分はアプローチを考える時間（段取りタイム）に充てるべきだと痛感しました。

そこで、日々の運用をテキストエディタベースのシンプルなものに変更しました。「今日の気づき」や「追加タスク（差し込み）」をその場で書き留め、今日やるべきことと来週のゴールを明確にするようにしました。

これを1ヶ月続けると、不思議なことに長期スパンの見通しが立ちやすくなりました。1日のタスクをコントロールできるようになると、自然と翌週、翌月の動き（QCD調整や先手の打ち手）が見えてくるようになったのです。

3. 「俺史上最強のメソッド」発見！？

テキストエディタだけで完結し、省エネかつ応用が効く。「これは俺史上最強の方法を見つけたかもしれない！念能力で言えばヒソカやカストロレベルの応用力だ！」と自画自賛していました。

しかし、ふと「これに近いプラクティスやフレームワークが世の中にあるのではないか？」と思い、AIに聞いてみることにしました。

私: 「（自分のやり方を説明）...これって何か名前ある？」
AI: 「たぶん Pomodoro Technique やで」

...はい。私の発明のほとんどは、すでに解明されていました。

4. たどり着いた「ポモドーロ・テクニック」

AIに言われて改めて勉強し直しました（Amazonで専門書をポチりました）。
ご存知の方も多いと思いますが、概要は以下のとおりです。

• 25分の作業 + 5分の休憩 を1セット（1ポモドーロ）とする。
• 4ポモドーロごとに長めの休憩（15〜30分）を取る。
• 時間を「分」ではなく「枠（ポモドーロ数）」で管理する。

なぜこれが効くのか

実際にやってみて、以下の効果を実感しました。

1. 集中力の維持: 短いスパンで区切ることで、集中力が続きやすくなります。
2. 時間枠への意識: 「時間がない」と焦るのではなく、「あと何ポモドーロ使えるか」という枠で考えるようになり、時間に追われる感覚が緩和されました。
3. 生産性の可視化: 何ポモドーロ消化できたかで、その日の作業量を客観的に把握できます。

5. And More な気づき：1日を制する者は長期も制す

ポモドーロ・テクニック自体も有用ですが、この取り組みを通じて得られた、より本質的なエンジニアリングの気づきがありました。

1. 1日のコントロールはプロジェクト管理の縮図

「1日をコントロールできると、長期レンジもコントロールできるようになる」 という感覚は重要です。
プロジェクトの遅延は、結局のところ「1日の遅れ」の積み重ねです。逆に言えば、1日のタスクを計画通り遂行（コントロール）できなければ、週単位、月単位のプロジェクトをコントロールすることは難しいでしょう。

2. 「仕事」と「タスク」を分ける

タスクの粒度を細かくしていく中で、「仕事（Work）」 と 「タスク（Task）」 の違いを意識するようになりました。

• 仕事: 決まった要件・仕様（What & Why）
• タスク: それを作業に落とし込んだもの（How）

生産性（スループット）を上げる鍵は、タスクを速くこなすこと以上に、タスクに取り掛かる前の「仕事の定義」 にあります。

3. グレードによる問題解決の変化

エンジニアとしてのグレード（ジュニア、シニア、プリンシパルなど）が上がるにつれ、扱う問題の抽象度は上がります。

• 正解が自明な問題: やるだけ。
• 正解らしきものがある問題: 正確性のために調査する。
• 正解があるかわからない/ない問題: 方向性を決めるために調査する。

抽象度が高い問題ほど、「要件定義」すなわち「問題の理解」そのものに時間を割く必要があります。「仕様は調整の余地がある」という前提で、変えられるもの・変えられないものを見極め、楽に要求を満たせる方法を探る。達人は脳内で常にこれをやっています。

4. システム1とシステム2

『ファスト＆スロー』にあるように、人間の思考には直観的な「システム1」と、熟慮的な「システム2」があります。
普段の業務は大体システム1で処理していますが、予実管理やふりかえりで意識的に「システム2」を使うことで、システム1の精度（直観）が鍛えられていくのだと感じます。

6. 失敗談：若かりし頃の過ち

ふと思い出したのですが、昔、海外駐在時にやってしまった失敗があります。
リリース直前のコードに設計不備を見つけ、不安になって独断でこっそり徹夜して修正・リリースしてしまったのです。
結果的にバグは防げましたが、コミット履歴からバレて、めちゃくちゃ怒られました（当然です）。

当時は「責任感」のつもりでしたが、組織としてはプロセスを無視した危険な行為です。
あの頃も、上司に毎日15分くらい課題とスケジュールを壁打ちさせられていました。「めんどくせぇ」と思っていましたが、あれが今の自分の血肉になっているんだなとしみじみ思います。

---

🎁 まとめ

2ヶ月間の取り組みをまとめると、以下の3点に集約されます。

1. 今日より明日をよくする
   日々の記録とふりかえりで、少しずつ改善していくことが大事です。

2. 巨人の肩に乗る
   我流で「最強のメソッド」を発明した気にならず、ポモドーロ・テクニックのような確立された手法や、先人の知恵を素直に学びましょう。

3. 習慣になるまでやる
   理解しただけでは変わりません。実践し続けることでしか、時間は味方につきません。

ポモドーロでも他の手法でも構いません。
「1日をコントロールする」という感覚、ぜひ味わってみてください。