どうも、産休に飽きてきました。



夫から借りた本。サブタイトルの「仕事が速くなる」という点に惹かれて読み進めました。チームでのプロジェクト管理に関する本ですが、個人のタスク管理にも当てはまる要素がたくさんありました。個人のタスク管理手法としては、私が以前からタスク管理に用いているGTDに近い、という印象です。

要約すると、このような手法のようです。まずタスクとその完了条件をすべて書き出して優先順位を決め(バックログの作成)、ホワイトボードを使ってチーム全員のタスクを可視化して管理する。計画は初めからFIXしているのではなく、タスクの進捗状況を見ながら、徐々に作りこんでいく。極限まで無駄を減らすため、会議は1日1回、15分まで。マルチタスクを排除する。

以下は特に印象に残った部分です。

1.計画は初めからかためない
p.26
完成する時期がいえるのは、チームがどの程度伸びるかが見えてきたときです。つまり、どのくらいのスピードで仕事ができるか、どの程度スピードが上がってくるかがつかめてからです。
まずは始める。
そして、何をするのにどれくらいの時間がかかるのかをきちんと把握して行くことが大切。
p.28
スプリントの最後にはチームが集まり、期間中に完成した仕事を共有する。そして付箋に書き出した項目が実際にいくつ完成したかを確認する。1つのスプリントに多く詰め込み過ぎて全部が終わらなかったり、逆に少なすぎてもう少しやれたりといった進捗を把握する。ここで大事なのは、自分たちがどの程度のスピードでこなせるかという基準、すなわち自分たちのベロシティ(速さ)を知ることにある。できた仕事を共有したらーここからが大野の考え方の出番なのだがー、何ができたかではなく、どう仕事を進めたかをチームで話し合う。次のスプリントではどうすればもっとうまく皆で仕事を進められるだろう?今回のスプリントで進捗の妨げになったのは何だろう?チームのベロシティを下げた障害物は何だろう?

2.ホワイトボードで進捗管理する、スプリントの最後には実物を見せる
スプリント内のタスクの管理方法についてはホワイトボードをつかって、全員が見れる状態で管理する。
p.97
ホワイトボードは「バックログ」「作業中」「完了」の3列に区切られている。スプリントの初めに、メンバーはその週にできそうだと思うタスクを選び、「作業中」の列にその付箋を貼っていく。タスクが完了すると「完了」の列に移す。これを見れば、メンバーがそれぞれ今何に取り組んでいるのか、チーム全員で常に共有できるわけだ。大事な点は、実際にユーザーが使える状態でなければ「完了」にはできないことだ。

3.マルチタスクは無駄をうむ
p.119
全部を同時進行していく、従来一般的だった進め方をした場合、3件のプロジェクトが完了するのは7月末になる。だがスクラムを取り入れ、各プロジェクトを1件ずつ「完了」に持っていく進め方にすると、コンテクストを切り替える、つまりタスクを切り替えるときに生じるロスは最小限に抑えられる。結果、3件のプロジェクトは5月初旬には完了する。
しかもマルチタスクで進めてどれも完了しない(半分はできてるが)場合、それはなにもできていないのと同等、とのこと。
p.123
ここで犯しがちな最大のミスが、リストにある5つの仕事すべてに同時に手をつけることだ。つまりマルチタスキングであり、それをするとおそらくどれも完了せず、「やりかけの仕事」が生じてしまう。5つの仕事がどれも途中になっている状態を想像してみてほしい。(中略)労力はかけたが、何一つ価値を生み出していないのだ。(中略)やるべき仕事の途中までやった状態というのは、本質的には何もしていないのと同じだ。
最近タスクの進捗状況が思わしくなくてなんとなくブルーだったのですが、この観点が抜け落ちてたからだったのか…!と気づきました。至極当然のことなのに忘れていた…あほ…。

コンサルタントとして仕事をしていると、つい「いかにマルチタスクをうまく回すか?」ということに躍起になってしまいがちですが、そもそも「マルチタスクをいかになくすか?」を考えることのほうが有意義なのだなあ、と認識を改めました。