マイペースなRailsおじさん

Ruby、Ruby on Rails、オブジェクト指向設計を主なテーマとして扱います。だんだん大きくなっていくRuby on Rails製プロダクトのメンテナンス性を損なわない方法を考えたり考えなかったりしている人のブログです。

大きなタスクを細分化して立ち向かう

大きなタスクをもらいました。 そしてその大きなタスクは、さらにどんどん大きくなっていきます。

タスクをちぎるといいよ、という話をツイッターで見かけたので実践してみた。

計画

〇〇機能を実装する

という、大きなタスクを30~60分程度でこなせる大きさにの小さなタスクに分割していく。

大まかにわける

まずは時間のことは気にせず、この作業が完了しているということはつまり、これが終わっているはずだというざっくりとした工程に分ける。この時点では、かかる時間はは気にしない。

細かく分ける

60分以上掛かりそうなものは、複数に分割する。 ここまでできていれば半分くらいいっているはずだ、という感じの大体の目安は見えるはずなので、その目安を基準に分割する。 それぞれの目安が、60分以内になるように分割する。

もし、そのような目安さえも見えないと言うなら、そのタスクは自分の手には負えないものだということだ。 60分でたどり着く場所の想像さえもつかないと言うなら、そのタスクがどれだけの時間があれば終わるか想像もつかないということだ。 この時点で、周りに助けを求めよう。

小さすぎて30分以内に終わってしまうものについては、他のタスクに混ぜて大きさが揃うようにしよう。 この段階では、大きさを揃えることが目的なので、全く性質の違うタスクが一緒になっていても構わない。 ただし、無理に一つのことばで表したりするのはやめよう。

さあ、ここまでくると、あなたがやらなければならないことの全体像と、その量が見えてくる。 かかる時間を揃えたおかげて、全部で何時間かかるかは明確だ。

取り組む

あとは、作ったタスクリストにしたがって作業しよう。 それぞれのタスクにどれくらいの時間がかかったのか記録してあると、あとで振り返りがやりやすくなる。

たいていは予想どおりには進まない。一つのタスクに5時間かかってしまう、なんてこともざらにあるだろう。 それはそれで構わない。あなたは、どうして1時間で終わるはずの仕事が5時間もかかってしまったのか、自然と考えるだろう。その分析は必ず次の計画に役立つはずだ。もしかしたら、上司への言い訳にも使えるかもしれない。

振り返る

仕事を終えたら、計画通りに行ったのか振り返ってみよう。

時間が大幅に遅れたタスクの原因は何だったのだろう?

  • やることが予想以上に多かったから?
  • やることが予想難しかったから?
  • 邪魔が入ったから?
  • 全然やる気が出なくて、実際の作業時間が短かったから?
  • 社内ツールの使い勝手が予想よりも残念だったから?

これらを解決する方法はないか考えてみよう。

所感

タスクの粒度を時間で分けてみると、自分の進捗がとてもわかりやすい。 そうなると、チームのメンバーへの報告もしやすい。 自分がただ頭を抱えているだけではなく、確実に歩を進めているという実感を得やすい。

しばらくはこれを続けたいと思う。