チームでのタスク管理に関する考察

Published at: 2023/8/19

チームで仕事をする場合に、やることをどのように管理していくか。

対象のタスクが複雑になっていくと、 stagger chart が本質となる。プロジェクトないしチームのオペレーションも、時間発展と共に実績と予測が積み上がっていく複雑系である。その見積りは、タスクを細かく分解して管理することで自動的に計算されるようなものではない。むしろ、あるべき時間発展のアウトプットを予測し、実行し、振り返りと修正(Action・予測改善)の PDCA を回すことによってのみ、精度が上がっていく。 Stagger Chart については、 Andrew S. Grove による High Output Management を参考。

High Output Management

出典: amazon.co.jp

Buy on Amazon.co.jp

タスクの日々の管理という面を見ていると、作業者のリソースを管理しているのか、が大きな問題となる。ソフトウェアエンジニアリング界隈では、エンジニアが実際にプロダクトを作る時間が事業上のボトルネックとなる。結果、作業時間というリソースをどのように活用していくかが問題となり、それを上手く手法として考えられたのがスクラムである。スクラム的なことをやらない場合、マネージャーがやりたいと思ったことを伝えていっても、それが実現されるまでに必然、タイムラグが発生する構造があり、やりたいことリストは無限に積み上がる。そのタスクの消化に着目し、スプリントという単位時間あたりでの生産量を見極めて、コミュニケーションを円滑化する試みがスクラムであり、そのタスク管理はスプリントごとのカンバンになる。

以上のような背景知識がある前提で、実際に仕事を回していく中で、ワークするなと思ったチームにおけるタスク管理の方法論を列挙する。

議事録 with 前回のコピペ
Trello with Backlog, Doing, Done, Archive
Jira 等、いわゆるスクラム機能があるカンバン

1. 議事録 with 前回のコピペ

タスクを実行する際の作業時間リソースに余裕がある場合や、そこが重要ではない場合に、タスクの洗い出しと実行(進捗管理)が重要になる。それぞれのタスクの見込みと、今週(今月)やっていたこと、これまでの経緯がまとまったエントリーが列挙されているような議事録を作成し、それを定例毎にコピペして報告事項とする。

これは、行っていることは本質的には stagger chart を、タスク管理に適用したもの、という構造になり、必要に応じて振り返りなども行える。問題点としては、ただの文章であるため、エクセルのような管理はあんまり向いておらず、チームで今着手中のタスク一覧、ぐらいの量までがこの方法で管理する際の適正なボリュームとなる。

2. Trello with Backlog, Doing, Done, Archive

バックログの管理と進捗確認が必要なタスクのトラッキングが向いている。作業タスクは、 doing に何かしら進捗があり、 done になっていく。進捗確認系タスクは、問題ないか、ある場合には、どのような対応を取るのか、などの確認を行う。

3. Jira 等、いわゆるスクラム機能があるカンバン

sprint の概念に上手くのるのは、実際に着手するタスクが作業タスクにまで落とすようなプロセスが正常に回っている場合である。スクラム的には、それは backlog grooming と、 product owner の存在によって担保される、ことになっている。

逆にそれが担保されている場合に、開発のスループットを上げたいのであれば、この方式を採用するのが良い、というのがソフトウェアエンジニアリング業界の経験則となる。

補足として、(昔ながらの) SI 業界は開発プロセスを事務作業にまで分解し、各々の資料作成者は交換可能であるとする。その在り方ゆえ、ボトルネックは PM 能力の方に寄っていき、結果、スクラムはあんまり適さない、ということになりがち。

いつ、どれを利用するか

1 議事録コピペで問題ないならば、それを利用する。バックログ管理を入れたくなったり、管理中のタスク数が増えてくるような場合に、 stagger 性を犠牲にして、 2. Trello が採用される。

作業量が本質的なチーム上のボトルネックの場合にスクラムを導入し、作業スピードの向上を行っていく。作業タスクが、実際の価値に繋るインクリメントになっていることの担保を、何かしら行えていることが前提条件となる。

感想

こうしてみると、何故ソフトウェアエンジニアリング以外の分野においては、スクラムがそもそも採用されないのか、が分かる気がする。実際の仕事において、作業さえすればよい、という構造はあまりない。どちらかというと、マネージャーを用意し、その人にアソシエイトをアサインし、いわゆるマネジメントを行わせる方が、事業的には生産性を出しやすい。

エンジニアが価値あるプロダクトを開発するスピードを最適化すること、普遍化して、希少性の高い作業者の作業のスループットが事業上で最も大事である、という性質の領域において、スクラムはワークしうる。

それ以外の場面においては、議事録をちゃんと残す事業定例か、バックログ的なものの管理を一緒にしたくなった場合においては、 trello が妥当になっていく。

おまけ: Notion

まだこれまで、チームでのタスク管理において利用したことはないが、 Notion をその目的で使う場合、 2. Trello の代替となりうる。おそらく、 Trello の上位互換として扱える感じだが、デメリットとして、 Trello と比較すれば、学習コストがそれなりにあること、と考えられる。例えば、ブルーワーカーのタスク管理として Notion が採用されているイメージがあまり分かない。