田島でございます。
今日は「エンジニアと言いたい私」が、日頃どのように作業管理をしているかをご紹介できればと思います。
「こんな風にやっているんだな」と、何かの参考になれば幸いです。
「タスク管理、やってます」
ざっくりとしたこの一言、だいたい罠です。
なぜなら “タスク管理” という言葉の中には、TODO、計画、優先順位、見積もり、進捗、そして心の安寧まで全部詰め込まれていて、だいたいそのどれかが破綻しているからです。
昔の私も例外ではなく、気づいたらこうなっていました。
- やることは書いてある（偉い）
- でも終わらない（普通）
- 予定は崩れる（いつも）
- 罪悪感だけが増える（最悪）
そこで、根性論から脱却するために、ポモドーロ＋WBS＋週間キャパ設計を組み合わせた運用に落ち着きました。
コーディング以外の業務にも“アジャイルっぽい”ことを取り入れてよい感じになっています。
ポモドーロは「集中法」だけではなく「見積もりの単位」として使う
ポモドーロというと、
「あの25分集中して5分休憩するやつでしょ？」「古いって聞くよ」
というイメージが強いかもしれません。基本は同じですが、私の使い方は少し違います。
私はポモドーロ（今後はポモと呼びます）を “作業の見積もり単位” として扱っています。
ここで重要なのは、見積もりが当たるかどうかよりも、見積もりの粒度が揃うことです。
そもそも作業の見積もりをするときって、人日や時間だったり、大中小、SML、松竹梅だったり単位がバラバラで、その時のTPOで切り替えたりして、気づくと脳がぐるぐるしています。
なので自分の中の見積もり粒度をポモに固定して考えると、
「これは2ポモかな」
「いや、不確実性があるから5ポモにしておこう」
みたいな、“迷い” がそのまま見積もりに乗せられるので、ここで（間違えたらどうしよう）というグジグジする時間が減ります。
もちろん、あくまで自己の作業タスク見積に限りますが。
プロジェクトを作業レベルに分解
プロジェクトやタスクが発生したら「成果物」や「完了条件」ベースで分解します。
いわゆるWBSですね。
このとき「やった気になるだけの行動」が混ざると無駄が多くなるため、タスクを作成する際には必ず成果物ベースで作業を設定します。
たとえば
- 調査する → 比較表を作る（A4一枚）
- 検討する → 選定理由を3行で書く
- 相談する → 論点を2つに絞って投げる
ここを曖昧にすると未来の自分が戸惑います。逆に、作業単位で成果物がカチッと決まっていると、ポモの見積もり精度も上がります。
各タスクのポモ見積もりは「フィボナッチ数列」で
細かく見積もろうとして脳が疲れては本末転倒なので、私はだいたいフィボナッチ数列（1,2,3,5,8,13…）で丸めています。
あくまで一つの目安ですが、私はこう当てはめています。
- 1ポモ：ミーティングや軽い準備など
- 2–3ポモ：すぐ終わる（脳内で道筋が見えている）
- 5ポモ：普通の作業
- 8ポモ：負荷あり。連続で時間をとると生産性がアップ
- 13ポモ：不確実性があるかも。途中で詰まらないように注意
- 21ポモ：でかい。分割した方がいいサイン
ここでは、”正確な見積もり”より“運用可能性”を優先して、ポンポン割り当てていきます。
最初から正確性を求めて考え込むほど、手が止まってしまいます。
では精度はどう担保するかというと、必ず「消化したポモ」を記録し、週末に振り返ります。
そうすることで自分のリアルな生産性が見えてきて、おのずと見積もりの正確性も追いついてきます。
1週間をあえて「70ポモ」で設計する
理論上、1日8時間労働なら「16ポモ×5日＝80ポモ」が1週間の最大キャパシティです。
しかし、私はあえて 週5日で70ポモ（1日あたり14ポモ） で作業を割り当てていきます。
会議・調整・突発タスクなどが必ず発生するため、バッファ込みで「週70ポモ」にするのが圧倒的に運用しやすいからです。
ここで大事なのは、数字の正しさではなく「上限を決めると詰め込みが止まる」ということ。
上限がないと、まず無限にその週に作業予定を入れて、最後は根性論で乗り切ろうとしてしまいます。
そして破綻が見えてきたときにこう私は言っていました。
「予定通りいかなかったので、リスケします」
それはリスケじゃなくて、最初から無理だっただけなのに！
新しいタスクが発生したら追加せず「入れ替える」
現場で一番よく起きるイベント、それは「急にタスクが増える」ことです。
ここでありがちなのが、
- 既存の計画はそのまま
- 新しいタスクを上乗せ
- 結果：全部遅れる
- でも“頑張ればいける”と言い張る
という負のループ。まず、これをやめます。
やることはシンプルで、新しいタスクが入ったら、基本は何かを落とす（または後ろへずらす）。
つまり、差し替え運用にします。
この時、残す／ずらすの優先順位は下記で判断しています。
- マイルストーンに直結するもの（期限が硬い）
- クリティカルパスに乗っているもの（止まると全体が止まる）
- 関係者待ちが発生するもの（先に投げた方が得）
この運用で何が良くなるのか（たぶん一番大事）
この運用の良さは、タスクが着実に進むこともそうですが、個人的には「今週は絶対これだけやれば勝ち」が明確になることが一番大きいです。
- 予定が崩れても、“差し替え”で再設計できる
- 見積もりが外れても、ポモ単位なのでダメージが小さい
- 進捗が “気分” ではなく “消化ポモ” で可視化される
- 罪悪感が減る（自分の生産性だけが悪いわけではないことが見える化される）
仕事はだいたい、タスクを増やすより減らした方がうまくいきます。
そして減らすには、先に上限が必要なんです。「やらないこと」をしっかり決めるのが大切かなと感じています。
まとめ：大切なのは非コーディングでも「設計」と「差し替え」
まとめると、私がやっていることはこの5つです。
- タスクを「成果物・完了条件」ベースに分解する
- 作業のボリューム見積もりはフィボナッチ数列で丸める（精度より運用）
- 週のキャパ（上限）に作業予定をあてはめていく
- 新規タスクは追加ではなく「入れ替え」で扱う（差し替え運用）
- 定期的に「見積もったポモ」と「消化したポモ」を振り返る
ここまで読んで、「え、これ自体を管理したり振り返ったりするのが大変じゃん」と思った方は大正解です。
昔はうっかりすると、このタスク管理自体が目的になってしまう罠に落ちたりしていました。
が、実はいま、ここに時間はあまりかかっていません。
面倒だなと思うところは、全部AIエージェントさんにやってもらっているからです。
私は新しいタスクが発生したら、AIに概要とマイルストーンを伝えるだけ。
あとは、作成されたWBSの確認とポモの微調整、必要に応じて作業の入れ替えと毎週の振り返りを行うだけで済んでいます。
最後に
この記事はあくまで個人の工夫であり、私の脳内を整えるためのものです。業務の正しさや絶対的な進捗を保証するものではありません。ご了承ください。