レガシー組織で2人から始めるタスク管理改善

#想定読者

• アジャイル、スクラムとは無縁の組織、チームで仕事をしている。
• チームは存在するがチーム感がない、それぞれで別のことをしている。
• このような状況をなんとかしたいと思っているが、はじめの一歩が分からない。

まとめを追記しました

#結論から話します
週に1度、チーム全体のタスクを一枚のリストにまとめ、
優先度をつけ上から順番に対応していきましょう。

そして、タスクをそれぞれのメンバーに振り分けるのではなく、
先頭のタスクを更に分解して、先頭のタスクがチームで最速で終わるように、
振り分けを考えてみましょう。

チーム全体として「シングルタスク」的な考え方で開発を進めていきましょうという提案です。

#具体的には
3人のチームで開発を進めている機能が3つあるとします。(各5人日, X, Y, Z)
一般的な方法の場合、以下のように機能単位で開発を分けると思います。

担当者	月	火	水	木	金
Aさん	X	X	X	X	X
Bさん	Y	Y	Y	Y	Y
Cさん	Z	Z	Z	Z	Z

この方法では、全ての開発が金曜日に終わることを想定しています。
しかし、個人に割り振りを行っているため、不確定要素が大きく、
チームでリカバーすることもできません。

そこで、以下のシングルタスク管理法を提案します。
優先度の高いタスクから1つずつチーム全体で最速で終わらせるように計画しましょう。
以下のようなイメージです。

担当者	月	火	水	木	金	月
Aさん	X	X	Y	Y	Z	Z
Bさん	X	X	Y	Y	Z	Z
Cさん	X	X	Y	Y	Z	Z

金曜日に3つをまとめて完了させる計画ではなく、
2日毎に1つずつ終わらせるように計画します。

鋭い方は5人日だった開発が6人日になっている!と思うかもしれません。
この指摘は正しいです。
タスクの分解には限界があり、
複数人で共同で開発することによる調整のコストが発生するためです。

しかし、そのコストを踏まえても、このような方法でタスク計画を行い実施していく利点があります。

#この方法の利点
#####利点1.タスクが着実に完了する
対応しているタスクが完成するまでチームでやりきりましょう。
(リリース、リリース準備完了、あるいは受入テスト完了の状態まで)
こうすることで、1週間経っているのに1つもタスクが終わっていないという状態は発生しません。

逆にこの方法で1週間経ってもタスクが1つも完了しなかった場合は、
業務の工程のどこかに問題があることが明確に分かります。
見積もりの際の要件定義が足りないのか、実装工程で作り込む不具合が多いのか、
原因は複数考えられますが、複数人で関わりながら開発しているので、
1人で抱え込んでいる場合よりも原因特定に至りやすいです。

#####利点2.チーム単位での成果に着目できるようになる
チームメンバー全員で同じ開発に取り組むので、
業務知識の共有が自然とできている状態になるはずです。
メンバー間の知識格差も比較的小さくなり、
最初期はブレが生じますが、時間がたつにつれ、
開発内容に対する見積もりも個人に対して振り分けたときよりも、
正確になってきます。

またチームとして優先度を設定することで、
関係部署への説明やへの協力の要請もしやすくなります。
開発リソースは有限であり、納期短縮だけを狙ったあらゆる行動は、
品質や機能、システムの長期的運用に悪影響しか及ぼさないことを理解してもらう必要があります。

#####利点3.調整のための調整をなくすことができる
進捗確認において、現物(プログラム、実動作する環境、テストケース、その他成果物)の確認以外は本質的に意味がありません。
ですが、多くの現場でそれが出来ないのは、頭と技術的な環境の切り替えコストが高くなるからです。
チームでシングルタスクになるように開発を進めていけば、
この切り替えコストが極端に下がります。

チーム全体のタスク自体もリストに優先度をつけて並べていますので、
毎日調整する必要はありません。
もし差し込みで対応が必要なものがあれば、
受ける代わりに他のタスクの納期は後ろ倒しになること、
切り替えコストの発生で元々より工数が多くなることは理解してもらいましょう。
(エンジニアとしてはこの切り替えコストを削減していく取り組みも重要です)

#####利点のまとめ
チームとしてシングルタスクで動くように意識することで、
・1つ1つのタスクを確実に完了させることができ、精度の高い計画が立てられるようになる。
・チーム全体での成果に着目できるようになり、効率のよい知識共有が可能になる。
・調整のための調整が不要になり、無駄な時間を短縮することができる。

#一般的な方法が失敗しやすい理由を話します
#####理由1.遅延リスクを個人に押し付けているから
個人に割り振ったタスクは、要件漏れ、不具合、
急な私用、個々人の能力差、パーキンソンの法則、
様々な理由で必ず遅延します。
ですが、タスク管理に問題を抱えているチームでは、
計画に際して現実を無視して机上のスケジュールを作成しがちです。

もしくはバッファを積むことで対応しますが、
多くの場合はそのバッファも超過していないでしょうか?

#####理由2.悪い属人化を止められないから
私自身は良い属人化と悪い属人化¹があると考えています。

悪い属人化により、チームメンバー全体の業務知識レベルがいびつになります。
業務知識レベルがいびつになることで、チーム全体としての業務遂行に偏りが生じ、
人数に対しての成果の量が少なくなっていきます。

また、引き継ぎや知識移転のための特別な時間が必要となってしまいます。
得てしてこのような活動は後回しにされ、
転職のための引き継ぎまで行われないことがほとんどではないでしょうか?
結局、時間が経てば立つほど、チームとしては劣化していくループに入ってしまいます。

#具体的にどうやっていけばいいかのTips
######シングルタスク管理法:基本的なやり方

• チーム全体のタスク一覧を作る
• 週に1度、タスク一覧の内容に優先順位をつける
• 優先順位に沿って、チーム全体でシングルタスクになるように対応を進めていく
• 分割して対応する規模ではない場合でも、最低2人で対応を進めるようにする

######タスク管理について

• チームとして何を行えば開発が完了するかを明確にすること
• 現物確認を重視すること
• 脳、集中力、環境等の切り替えコストが存在することを理解すること

######利害関係者への対応

• 優先順位決定に際しては、利害関係者とそれら全員を包括するマネージャーを呼ぶのがベスト
• 差し込み課題に関しては、対応してもよいが、代償をしっかりと説明し全体に共有すること
• 開発業務も物理法則で動いている事を理解し、理解してもらう努力を怠らないこと

技術的な要素

• 知識や技術の標準化や共有を重視するが、一方で人によっては理解できないレベルの高い専門性のある分野があることを理解すること
• タスク管理のレイヤーではなく、技術で解決できる問題も多くあることを理解し、改善し続けること

######チームとして

• お互いへの尊敬の気持ちが一番重要(HRT)
• ふりかえりを積極的に行うこと
• 開発業務上での問題は個人を主語にせず、チームの問題として考えるようにする(そうでない問題は会社に対して適切にアクションをとってもらいましょう)

#結論
スクラムやアジャイルなどの大きなフレームワークをいきなり導入することは、
難しいことも多いと思います。
その第一歩として、基本的なチームのタスクの進め方を変更することによる効果は、
労力に対してかなり高いと思います。

個人ではなくチームでの開発の見積もりが正確に行えるようになってくると、
日々の業務遂行が安定し、改善のためのさらなる行動を取れるようになってきます。
その先では、より高度な手法の導入が以前よりも楽にできる状態になっていると思います。

1. ※悪い属人化とは、専門性とはほど遠い部分に、一番貴重な自分の時間を割かなければいけない状態を指します。あるシステムや機能が重要かどうかの判断を抜きにして、「その人が一番詳しいから」「早く作れるから」というだけで属人化しているタスクがありませんか?それが業界的に見て高い専門性のある内容であれば別ですが、そうでないのであれば本人としても他の専門性が高いことをできる機会損失をしています。転職をするにしても、引き継ぎなどで自身のスケジュールで動きにくいでしょうし、悪い属人化が当たり前になっているチームでは、そもそも適切な引き継ぎができないでしょう。(属人化させているマネージャーが良い悪いの話ではなく、プロのエンジニアとしてそのような状況を放置するのが良いか悪いかのレイヤーの話です。) ↩