GTDについては、このブログでツールの使い方を中心に紹介しているのだけど、個人的なGTDではなくて"チームでGTD"ができないかなと考えていました。
生業で関わっているプロジェクトで"scrum"という手法を使っているのですが、それが"チームでGTD"に一番近いのかなと思ったので紹介しておきます。
scrum自体はかなり日本語の文献が少ないなーという印象です。"トヨタ方式"と言われている手法に近いらしいのですが、よく分かりません。
scrumとは?
まず、scrumは、プロジェクトをいくつかのsprintに分けて管理します。たとえば、2週間で1 sprint にしたり、4週間で1 sprintにしたり。このあたりのモデルは、プロトタイプに近いところがあると思います。
scrumの特徴は、sprint内でやるタスクをsprint backlogというリストで管理します。そして、プロジェクト全体で行うべきタスクをproduct backlogというリストで管理します。product backlogは、どのsprintでどの機能が実現されているべきかというのを管理しているのに対して、sprint backlogはproduct backlogで示されたそのsprintで実現すべき機能をどうやって実現するかというのを管理しています。
sprintの始めにはsprint planningを行い、そのsprintで行うタスクについて、時間見積もりと優先度(重要度)の決定を行います。予め計算されたsprint内のチームの稼働時間をオーバーしてしまうことがあれば、次回のsprintに回してしまうことも検討します。
その他詳細はwikipediaにものっているので参照してみてください。ちなみに、米Microsoftとかで使われている管理手法だそうです。(なので英語書籍だとMicrosoftからでていたりします)
GTDとscrum
ここまで読んでいてピンと来た方もいらっしゃるかもしれません。1 sprintを1 weekとすると、sprint backlog = Next Action、product backlog = Someday / Maybe とみなせば、ほんとんどGTDに近いことが分かります。ちなみに、sprint backlogもNext Actionもまったく一緒で、タスクが完了したことを明示的に分かるタスクにしなければなりません。
BTSならたいてい存在するマイルストーンなどの管理手法にも繋がる部分は多分にあると思います。BTSならば、GTDでいうinboxも完備できることになるので、よりいいかもしれません。
アジャイル手法のなかでは、ずいぶん管理手法に重きをおいている珍しいケースだとは思います。XPとかでは顧客もチームメンバーのひとりとして、常にチームに帯同することすら求められますが、scrumは特にそのようなことはありません。ずいぶん日本にあった管理手法だなと思っていたりします。
scrumの弱点は突発的なイベントに弱いというところですね。GTDだと、たとえば割込タスクが多くてNext Actionがこなせないということを経験したことがある方もいると思います。GTDではそれは別に大きな問題にはなりませんが、scrumはbacklogを完了することが目的なので、かなり大きな問題になります。そこはたとえば「backlogのこのタスクを次のsprintまでずらしていいかな?この機能は実現できなくなるけど」といった交渉をすることで回避できるとは思います。(それすら言えない環境はぜったい変えなければいけません)
p.s.
いつもにも増して若干かたい感じのポストですが、scrum はぜひ広めたいと思っているので
最近のコメント