以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。
良くない進め方の一例
たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1
このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。
このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分は少しでも進んでますよ」と報告できるからだ。
価値が出るところまで一気に進める
価値が出るところまで一気に進めることで、結果を早めに出すことができる。分かりやすい価値が出るポイントはプロジェクトの完了である。プロジェクトの完了とは、ユーザーに機能をリリースした、社内にシステムを導入したなどがあるだろう。
先ほどの図を更新すると以下のようになる。プロジェクトBの完了は30日後で変わっていないが、プロジェクトAの結果は10日後に出ている。
価値が出るポイントを分割し進める
上記のやり方はプロジェクトA、プロジェクトBにそれぞれ集中する形だが、現実的にはそうはいかないことも多い。関係者が別で同時に進めなければならないかもしれないし、他の人と一緒に進めていると待ち時間があるかもしれないからだ。
そこでプロジェクトの中で価値が出るポイントを分割することがおすすめだ。僕は別の人に作業が移るポイントを価値が出るポイントと定義し、分割している。たとえば
- サーバー/クライアントで分業していて自分がサーバー側を担当していた時、API定義を行なってダミーレスポンスを返すところまで行えば、クライアント側は作業を進められるようになる
- 社内システム導入のための複数システムの比較レポートを出せば、上司が検討を進められる
先ほどの図をさらに更新すると以下のようになる。プロジェクトAやプロジェクトBを別の人に作業が移るポイントを元にタスク分割し実行することで、自分が他プロジェクトを進めている間に別の人が作業を進められるようになっている。
このように僕はいくつかのタスクを持っている時、別の人に作業が移るポイントを価値が出るポイントと定義し、価値が出るポイントを見極めた上で、そこまで一気に進めてから次のタスクに取り組むようにしている。
まとめ
同僚に複数のプロジェクトを持っているときにどう進めるかという質問を受けたことをきっかけに、自分は価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると気づけた。今回の記事ではその考え方について言語化してみた。
もちろん自分が進めやすいように、さらにタスクを細分化して進めて良い。しかし価値が出るのはどこかを必ず意識しておき、価値が出ていないのにタスクをやった気分になるというのは避けて仕事をしたい。
- Work In Progressなタスクは1つにすべきという話があるが、今回は話を簡単にするためいったん置いておく。またコンテキストスイッチによる工数増加にも触れない。↩
