継続的改善は「計画」よりも「変化」を前提にタスク管理しよう
開発チームでマネジメントをしていると、「計画通りにいかない日」がよくあります。
特に、プロダクトが一度リリースされ、改善を繰り返すフェーズに入ると、その傾向はさらに強くなります。
私自身、継続的改善フェーズでマネジメントをするときも、
「チームのタスク計画をきちんと立てなきゃ」と思いながら進めていました。
しかし、ある段階で気づきました。
このフェーズは、プロジェクト型のように「計画ありき」で進めるのではなく、
「変化を前提に進める」ほうが圧倒的にうまく回る。
この記事では、
「なぜ計画による管理がうまくいかないのか」
「どうすれば改善フェーズに合うタスク管理になるのか」
をまとめてみます。
継続的改善フェーズで「計画が壊れる」理由
改善フェーズの大きな特徴のひとつに、
エンジニアが主体となるプロジェクト型とは違い、PdM、CS、営業などのビジネスサイドのメンバーと一体となって進むことがあります。
プロジェクト型は、要件が固まり、エンジニアが中心になって「計画 → 実装 → リリース」と進みます。
一方で改善フェーズは、ビジネスサイドがユーザーとの接点を持ち、日々の変化を判断しながら進めていくため、仕事の流れ方がまったく違います。
この構造が、計画の立て方に大きく影響します。
ここでは「期日の厳守」よりも、“今どのタスクがもっとも価値を生むか” をその都度判断することのほうが重要になります。
そして、ビジネスサイドからの判断やユーザーの反応、運用中の出来事によって、
緊急の調査・障害対応・仕様の微調整 といった “差し込み” が多く発生します。
すると…
- いま進めているタスクを一時停止し
- 優先度をつけ直し
- ビジネスサイドの確認を経て再度判断し
- 時には要件そのものが変わる
という流れが自然に繰り返されます。
これは誰が悪いわけでもなく、改善フェーズの仕事の流れ方そのものです。
- プロジェクト型：途中で変化が起きることはあっても、基本は "計画を軸に進められる" フェーズであるのに対し
- 改善フェーズ：ビジネスサイドやユーザーの声がその場その場で優先度を動かすため、計画よりも日々の判断が主役になります。
つまり改善フェーズは、
計画の精度より、変化に対する適応力のほうが重要になるフェーズなのです。
多くのタスク管理ツールが改善フェーズに合わない理由
世の中のタスク管理ツールの多くは、プロジェクト型を前提につくられています。
プロジェクト型とは…
- スケジュールがある
- 要件がある程度固まっている
- 依存関係が整理されている
- タスク粒度を揃えやすい
こうした環境では、計画中心で動かしやすい。
プロジェクトでガントチャートが非常に強いのも、この構造があるからです。
しかし改善フェーズでは「変化に合わせて動く」ことが求められます。
プロジェクト型も改善型も同じ「タスク管理」ですが、その性質は大きく異なります。
これこそが、私が感じた改善フェーズでのタスク管理のミスマッチによる違和感の正体でした。
Backlog、Jira、Asana など優秀なツールでも、改善フェーズではこんな現象が起きます。
- スケジュール調整が増える
- 優先順位の入れ替えが重い
- ガントチャートがすぐ現実と乖離
- 粒度の違いでタスクが並べにくい
- 日付前提の管理がストレスになる
これはツールの問題ではありません。
改善フェーズの性質と “計画前提のツール” の構造が合わないだけです。
どうすれば改善フェーズにフィットする管理になるのか？
改善フェーズは、ビジネスサイドとエンジニアが一緒にプロダクトを育てていくフェーズです。
計画を固定するよりも、変化を受け止めながら最適解を更新していくほうが重要です。
では、どうすれば改善フェーズにフィットした管理になるのか。
私の結論は、次の3つです。
① タスクに日付を定義しすぎない
改善フェーズでは、日付を細かく設定すると計画が硬直化し、変更に弱くなります。
- 優先度が変わる
- 差し込みが入る
- 要件が変わる
こうした変化があるたび、日付を直し、連鎖的に計画を調整する必要が出てくる。
これが管理コストを押し上げる最大の原因です。
期日がマストなタスク以外は、日付を設定しないほうが、結果として強い計画になります。
※ ガントチャートが改善フェーズに向かないのは、日付が前提になるからです。
② タスクのサイズ（想定工数）と優先順位で管理する
日付に頼らない代わりに、「サイズ」と「優先順位」で管理します。
特にサイズの扱いにコツがあります。
■ サイズが大きいタスクは分割する
タスクが大きくなると、進捗が見えづらく、作業者も「どこまで進んでいるか」を言語化しづらくなります。
私は “5日以上のタスクは分割する” というルールにしています。
区切りを作ることで、状態が見えやすくなり、判断が早くなります。
■ ざっくり把握する
改善フェーズでは、工数を正確に見積もることに価値はありません。
ざっくりで十分です。
例えばこんな粒度です：
- 1時間以内
- 半日
- 1 〜 5日のいずれか
迷ったら「小さいほう」を採用するくらいがちょうどいい。
また、最初からバッファを含めて大きく見積もるのは避けましょう。
「パーキンソンの法則」（仕事は与えられた時間をすべて使う）で、作業のテンポが失われます。
サイズと優先順位さえあれば、日付がなくてもタスク管理は驚くほど整理できます。
③ カンバンでタスクの流れを可視化する
改善フェーズでは、タスクの「流れ」を見える化することがとても重要です。
その点で Trelloのようなカンバン方式は、最もこのフェーズにフィットする管理手法 だと思っています。
カンバンを使うと、
- 今、誰が、何を進めているのか
- 完了したタスクがどれくらいあるのか
- 次に着手すべきタスクはどれで、誰が担当できそうか
- チーム内の仕事量のバランス
といった 改善フェーズで必要な情報が一目で掴めます。
計画が変わりやすいフェーズでは、
ガントチャートのように“日付に結びつく管理”よりも、
こうした「流れと状態の可視化」のほうが、ずっと運用しやすくなります。
一方で、一般的なカンバンツールの中には、
個人のToDoの整理には最適だけど、チーム全体の流れを把握するには少し弱い
と感じるものもあります。
改善フェーズでは、
「チーム全体のタスクの流れがどのように動いているか」を見える化できるカンバンがあると、更に運用しやすくなります。
この思想を実践するために、私は自分でタスク管理ツールを作った
ここまで述べてきた 「継続的改善フェーズにフィットするタスク管理」 を実現できるツールが、なかなか見つかりませんでした。
特にどうしても実現したかったのは、次の2つです。
- タスクを "期日" ではなく "サイズと優先順位" で扱えること
- 個人ではなく チームに最適化されたカンバン方式 であること
このマネジメント哲学を、実際に自分のチームで試してみたい──。
そう思うようになり、自分でツールを作ることにしました。
それが pitboard （ピットボード）です。
実際に半年以上チームで運用してみて
開発をしてから、pitboard をこれまで半年以上、自分のチームで使い続けてきました。
その中で一番強く感じたのは、
“変化前提の構造は、改善フェーズに本当にフィットする” ということです。
pitboard では、
- タスクのサイズ
- 優先順位
- カンバン上でのチーム内の流れ
が「変化を吸収する前提」で整理されています。
そのため、変化が起きても、
日付や計画の引き直しといった調整をすることなく、
“いまの状況を正しく映すボード” を保てるようになりました。
変化が日常的に起きる改善フェーズにおいて、
この “状況が揺れたときにも壊れない構造” は、
マネジメントの負荷を大きく減らしてくれました。
そして私は、このアプローチこそが
継続的改善フェーズにおけるタスク管理の本質だと感じています。
補足：pitboard について
この記事で触れた “変化前提のタスク管理” を実現するために、
私は pitboard（ピットボード） というタスク管理ツールを自作し、
自分のチームで運用しています。
プロマネ・ビジネスサイドのメンバー・エンジニアが同じ視点で改善を進められる
「継続的改善フェーズのためのタスク管理ツール」 です。
もしあなたのチームでも「計画より変化が多い」と感じる場面があるなら、
きっと役に立てると思います。
Discussion