タスクの進捗は視えるところに貼っておけ

「今時間をもらっていい？。朝一でお願いしたタスクってどう？」
「検証と手順書化ですね。AさんとBさんが担当しています。」
「それってそれぞれのタスクの完了の定義はどう設定したの？」
「検証はとりまとめまで。手順書はこのメンバのレビューまでです。」
「アウトプットのボリュームは？検証で確認する課題はいくつ？」
「あの1件だけです。」
「検証作業で必要な見込み時間は？」
「夕方までには。」
「それ、そんなにかからないでしょ。確かGUIの操作の遷移の話でしょ？」
「そうです。」
「あと、手順書を作成する作業は何時間必要なの？」
「これも夕方までにメンバでレビューします。」
「？ねぇ、この手順をザックリ聞いたらどう作っても数ページにしかならないんとおもんだけど。」
「そうですね。」
「あのね。作業時間の見積もりは理想時間で見積もって欲しいんだ。途中で割り込みが入ったら予定完了日をスライドさせていいから。」
「あとね、チケット切ってからタスクに着手したのかな。」
「抱えているタスクはね、視えるようにしておかないと後から割り込みのお化けがくるよ。」

この会話で、ワタシが問題だと思う点は2つあると思っています。
1つ目は、タスクを定義して、チケットを書かずに始めていることです。カンバンやチケットシステムを取り入れていないプロジェクトなら、MS projectやEXCELのWBSにタスクを追加せずに始めるようなものです。

これは、そのチームでアサイン状況を知らない人から見たら、その人はタスクに携わっているにもかからわず、空いているように見えるんです。これで何が拙いかと言えば、“急な割り込みがねじ込まれやすい状況を自ら作っている”ということなんですよ。

すべてのタスクが自分たちのプロジェクトチームでコントロールできているならそんな心配はないと思うんですが、関連するシステムがいくつもあるとそれはもう、いろいろとあるのですよ。それは自分たちのチームのタスクのコントロールを失うことになるので拙いんです。自分たちのチームのタスクはそれが関連システムなどの対外チームであったとしても依頼されてやるとしたら自分たちでタスクをコントロールしないといけないんです。そうでなければ自分のチームのコントロールの主導権を失うんです。そうなっていいんですか？ってことです。

そこまで話せば少なくとも表面上は(＝つまりこちらが心配している本質まで理解は届かなくても)同意してくれるんですがその理解の程度がそれはそれで問題なんですが。

もう1つ。作業時間を理想時間で見積もらないのも拙いです。

それ、自分で見積もったのにいつ完成できるかわからないと言っているのと同じなんですから。タスクごとの中の段取り、検討して、作って、セルフレビューして、内部レビューして、と段取りが決まっているならその段取りでメンバや他人とかかわるところをいつ都合付けようか手配しないといけないわけで、自分の作業の見積もりが適当ならその手筈もできない。多少の前後はあるにしても、不明瞭なところは着手前にオープンにしておいて、「これ不確定だからこれで終わりがぶれるかも。」って言っておけばいいんですよ。そうすれば誰もが気になるものですし、知っていれば教えてくれますから。チームですからね。

実際は、先の手順書は完了基準があっていなくて、内部レビューまで終わらないといけないんですね。ということはタスクの定義自体が独りよがり、独断で決めていたということでそのタスクが急ぎだったとしたら間に合わないわけです。そうした段取りが勘違いだったとしても理想時間で見積もっていれば、そのタスクがなる早なのであれば万難を排して優先的に後続のスケジュールを調整することもできるわけです。

タスクを定義していない、理想時間で見積もっていない、はカンバンやチケットで視えるかできていればもっと早く、自ら気づくこともできたかもしれません。それができないのは自分で自分の進捗を視えるようにしていないからです。

タスクの進捗は視えるようにしておかなければならないんです。