属人化解消中に陥りやすい罠
とりさんの仕事をうさぎくんが一部引き継いだことをきっかけに、簡単なタスクはそのときに取れる人がとることで属人化を少しずつ解消するルールをチームで決めました。
さらに、難易度がわかりやすいように、タスクの難しさを星5つで表現するというルールも追加しました。
それによって、星1つの難易度低めタスクは比較的属人化解消がすすみました。
しかし、星3つ以上の少し踏み込んだ内容のタスクはまだ属人化しています。
属人化解消の実績もでてきたので、うさぎくんは上司に「もっと属人化解消ができれば最終的に開発効率があがるので、少し時間をとらせてほしい」と宣言し、チームが正式に属人化解消に取り組める状態にもっていきました。
属人化解消状態を見えるようにする
属人化解消をはじめると、いままでそのタスクを進めていた人は教える時間が必要となり、教わる側は慣れない仕事をやることになるので、仕事のスピードは必ず落ちます。
ねこさんは、引き継ぎがうまくいかなくてなかなかDONEにならないタスクを見つめながら、この開発速度がだんだん心配になってきました。
「属人化が解消したら私たちは安心できるけど、チームメンバーが増えたわけでもないのに仕事のスピードって本当に上がるのかな？」
それを聞いて、うさぎくんは「属人化がなくなれば、チームのリソースがタスクに対して均等にふられるようになるので、必ず仕事のスピードはあがります。ひとりだけが残業みたいなこともなくなりますよ」とねこさんを励ましました。
開発スピードがいったん落ちることはチームもわかっていましたが、最初は楽しかった属人化解消も、実際開発スピードが落ちていることを体感し始めるとモチベーション維持が困難になってしまうケースがあります。
そんな中、上司も「そろそろ属人化解消から2週間たつけど、生産効率どう？」と聞いてきます。
ここでうさぎくんはひらめきます。自分達がどのくらい属人化を解消できてきたかが見えるようになれば、チームメンバーはモチベーションがたもてるし、チーム外へのアピールもできるはずです。
そこでうさぎくんは、過去のタスクをあつめて、属人化解消前から解消後にかけて、1週間ごとに、DONEにしたタスクを測るようにしてみました。
タスクそれぞれで難易度が異なるので、難易度を表す星の数を数えてグラフにするのがよさそうです。
属人化解消が始まるとぐっと数はさがりますが、それからだんだんグラフは回復していく姿がみえました。
「すごい、右肩あがり！ちゃんと成長できてたんだ」
ねこさんに久々に笑顔が戻ってきました。
上司に対しても、どのくらい引き継ぎが進んで、効率がアップしたかというアピールがしやすくなりました。
達成した仕事の量を増やし続ける必要はない
そして6週間後、属人化解消前より150%ほど上のところで、グラフが安定するようになりました。
今までどんどんできることが増えていたので、グラフが安定してしまうと成長が止まってしまったのかと不安になります。
こういうときに、無理をしてでもグラフを伸ばし続けようとしてしまうことがありますが、うさぎくんはこの開発スピードが安定した状態の利点に気づきました。
今までのグラフをみると、すごく仕事がすすむ週とそうでない週のむらがあります。
それがある程度安定するようになってきたことで、来週はどのくらいまで仕事ができそうという見通しが立てやすくなり、納期やリリース日の連絡や調整がかなりスムーズにいくようになったのです。
タスクの大きさを示すことについて補足
ここではわかりやすいよう星5つの難易度で表現しましたが、難易度はチームが成長してくれば変わるので、長期的な指標としては機能しにくいです。
また、1から5の間で数字を振ってしまうと、タスクの大きさに差異をつけたくてもあまりつきにくいという問題があります。
おすすめなのは、フィボナッチ数列でタスクの大きさを見積もることです。
フィボナッチ数列は、1,2,3,5,8…… と大きな数字になるほど数の間が空きます。これは、大きなタスク（細かくできない、具体的になにをするかわからないタスク）の曖昧な大きさを表現するのに適しています。
フィボナッチ数列をつかってタスクの大きさを測るときは、「慣れている人であればこのタスクはどの程度の大きさか」ということを前提に見積もります。
仮にURLを貼るだけのタスクを「1」と置いたときに、このタスクはその3倍かかりそう、その5倍かかりそう…… という観点でみつもりをします。
この「1」のタスクは、普段している仕事のなかで、チームメンバーの誰もがイメージしやすい、一番小さいものを選ぶようにしてください。
