ポモドーロに分ける効果

なぜ25分にわけるのか。

シングルタスクで集中している状態を継続できれば、作業効率は上がります。しかし、長時間集中を保つことは難しいので、25分だけ集中する時間を作ります。また、25分を一単位として管理するので、「この作業は２ポモドーロで終わる」などという見積りもしやすくなります。

ということで、要は集中力向上で生産性をあげる方法だな、と思っていました。最初は。

ただ実際にやって見るなかで、別の効果があることがわかってきました。

タイムボックスの意味

時間を決まった単位に区切ってそこにタスクを割り当てるという手法は、「タイムボックス」と呼ばれるアジャイル開発の技法そのものです。
アジャイルは反復開発をするため２週間などの期間をタイムボックスとして設定し、その期間内で実装できる最も優先度の高い作業を集中して実施します。

ところでアジャイルでは、このタイムボックスの長さを調整するということをしません。例えば設定した作業があと２日で終わるから２週間+２日に変更することはありません。代わりに優先度の低いタスクを減らすことで対応します。

この方法を取る場合、ウォーターフォールでの開発と大きく変わるのは、開発者の見積に対する感覚です。
ウォーターフォールでは作業遅延が発生したときにマスタープランを修正できます。そしてプロジェクトではQCDを管理します。このプロセスは開発者に「一定以上の品質で、所定のコストを使い、できるだけ早くやる」という目標を持たせます。

ただこの目標には問題があります。なぜなら「できるだけ早く」ということは、「できなければ遅くなる」ということでもあるからです。開発者は作業遅延が発生したときに、端的に「所定の期間ではできなかったからだ」と考えます。逆に顧客は開発者の能力が高ければもっと早くできたはずだと考えます。作業は「できるだけ早く」できるのだから、所定の期間に終わらなかったのは開発者が「できない」やつらだったからだという論理に帰結します。

この状況は、個人的な作業でも生まれ得ます。

できないことを肯定する

目標が達成可能か否かという視点と、実際に目標にトライするかどうかという視点から、作業への取り組みにあたっての作業者の姿勢を以下の４パターンにわけます。

上記したような開発者が作業遅延時にあきらめのような感情を抱くケースは(b)に当たります。

４つのケースにおいて作業に取り組んだ場合、それぞれ以下のような帰結をします。

(a) 「できない」という事実に直面するので無力感は感じるが、作業コストはかからないで終わる。
(b) 当初からできないと分かっている作業なので、完了できなくてもあきらめが付く。
(c) 成果は出ないものの、やればすぐに出来ることがわかっているので、気軽に作業を保留できる。
(d) できるとわかっていることので、真摯に取り組まなくては結果がでない。ただし、最終的には成果を得られる。

実は、４つのケースのうち実際の成果が出るのは(d)の場合のみです。
にも関わらず、(a)〜(c)に当たるような取り組みを行ってしまうことは多いのではないでしょうか。
(d)は成果を得られるケースですが、同時に最もコストがかかるケースでもあります。唯一価値のあるやり方であるにもかかわらず、作業者の負担が最も大きいのです。

だから、作業者は簡単に(a)〜(c)のパターンを選択してしまいます。できないことを肯定してしまうのです。

できることだけをやる。

ポモドーロ・テクニックの効果は簡単にいえば、上記した(d)のケースにあたる作業を増やせることです。

これは単純に優先度づけをするタスク管理術にはできないことですし、ただ生産性を上げることにこだわる方法論の効果とも違っています。

タイムボックス=ポモドーロに割り当てるタスクは、常にできる範囲の作業です。あまりに時間がかかるような作業は分割しなくてはいけません。このためタスクの割り当ての段階で、(a)(b)のケースに陥る可能性が排除されます。
タスクを割り当てた段階で、タイマーが回っている時間内に自分が何ができるかが確定してしています。別の作業を割りこませることは禁止されているので、タイマーが回っている間、割り当ての作業をしないことはできません。このため(c)のケースも排除されます。

作業者は、結果として最も負担の大きい(d)のケースとして作業に向かうことができます。もちろんその見返りとして成果を得ることができます。

キッチンタイマーは、もともと、変更不可能な時間を計るために使われてきました。
その意味でも、ポモドーロ・テクニックという名前は適当なものなのかもしれません。