タスク（ストーリー）の最小化をしたら、みえてきたこと

　僕の所属しているチームが、会社に貢献することは、「１日でも早くコンバージョンをするものを届ける」と考えています。そのために、2018年、「フロー効率性の追求」を、目標としていました。そのために、やったことの一つがタスク（ストーリー）の最小化です。今回は、この最小化でみえてきた事を書きます。

POからのストーリーは大きい

POから依頼がくるタスク（ストーリー）は、〇〇できるようにしてくださいという内容で、大きなくくり（１ヶ月かかる）ものもあれば、小さいもの（１日で終わる）もあります。チームでは、タスク管理にPivotal Trackerを使っています。POには、pivotalに大きなくくりのまま、まず入力してもらいます。

タスクというと、作業一つ一つのニュアンスになるで、ここからはストーリーという言葉を使います。

担当をきめたら作業を分解・見積もり

僕たちのチームでは、朝会があるので、入力されいる新規のストーリに対し、①担当を決め、②担当はその詳細を確認し、３時間ぐらい毎を目安に、ストーリーを分解し、③翌朝、そのストーリー分解と、見積り時間が正しいかチーム複数人で確認し、④いつぐらいにまでにできるかPO報告します。

※チームでは、１日を６時間とし、ストーリの１単位を３時間程度としています

作業分解してよかったこと

1）1日でも早くリリースできる
2）リーダーして管理が楽
3）問題点をコントロールできるようになる
4）エンジニアの開発作業がみなおせそう

一日でも早くリリースできる

POからの依頼は、１ヶ月のストーリーでも、細かく分解し、分解した各ストーリー完了したら、リリースして行きます。ので、「１日でも早くコンバージョンをするものを届ける」ことができるようになってきました。

リーダーとし管理が楽

スートーリーが細いので、今それがどうなっているのか、リスクは何か？考える範囲が狭くなります。リーダーとしては、管理楽になりました。

問題点をコントロールできるようになる

ストーリーは、3時間位毎にきっています。問題が発生すれば、それ毎にメンバーから、アラートがあがります。問題点が、すぐに対処でき、コントロールがしやすくなりました。

エンジニアの開発作業がみなおせそう

作業を分解していって、なぜその作業が遅れたかを、毎週メンバーの前に話すことにより、わかったことがあります。

それは、一つの一つのストーリーに何をしていて、何を最適化すればよいのかです。

一つのストーリー（３時間の単位）で、エンジニアの開発作業には、

1)環境準備

2)考える

2-1)集中するまでの時間

2-2)仕様を確認する・設計する

3)コーディングする

に分解されます。エンジニアは、コーディングすることが仕事です。ですので、１ストーリーで、いかに、３）の最大化をし、1,2を最小化するかがポイントになります。そして、3は計測できるので、最大化しやすそうです。
1は、dockerやci により短縮化でき、僕たちのチームでも導入し、大分最適化されています。
2はどうでしょうか？2には、2-1）集中するまでの時間と、2-2）設計する時間にわかれます。2-1は、最小化するべきですが、2-2は怠ると、「死ね」というコードができあがります。2を削減すれば良いとはいえません。しかも、2は計測できず、2-1と2-2は区別できません。

まとめると、3が計測できるからといって、最大化すればいいとはいきません。計測できない2の内、2-2は重要で、2-1は削減すべきものなのです。

どうしていくべきか？

今のところ、答えはでていません。ただ、2-1を削減できれば、稼働率が100%に近づき、リソース効率もあがります

この対策、色々考えて答えがでずです。そこで、今やれる事として、とりあえず、朝会で、ストーリー毎に、「あなたは、このストーリーに集中できましたか？ファイブフィンガーで答えて」を聞くことにします。都度聞くことで、集中できたかに意識を向ける事により、カイゼンのアイディアが浮かぶはずと考えています。2019年は、「集中できたか？」を唱え続けて、チームの成長を促して行きたいと思います。集中するまでの時間、削減できたら、また報告します。