@numa08 猫耳帽子の女の子

明日目が覚めたら俺達の業界が夢のような世界になっているとイイナ。

残業や休日出勤をしないために僕達がやってること

f:id:numanuma08:20151109204654j:plain

僕がコベリンへ転職をしてそろそろ半年。

numa08.hateblo.jp

この半年間で色々とあって、業務フロー改善とかをやりまくった。

具体的に何をやって、どうなったのかはそのうち開発ブログのほうでまとめようかと思うので、ここでは「どんな業務フローだとしても、これだけはやっておけ」な事を書いてみようと思う。

まだ最適化をするな

これだけはやっておけって言いたいこと、それは「見積もりと計測」。

たぶんみんな見積もりはやってると思う。タスクを並べて「これはこれくらい時間がかかるな」とか言って、達成にかかる時間を見積もっていく。

そして、計測もまぁまぁやってるんじゃないだろうか。適当なタイミングで振り返って期日までに終わるのかどうかを見直す。そして、やばそうだなぁってなったときに残業とか休日出勤が発動する。

で、どうにかプロジェクトが終わって反省会とかやって、飲み会とか軽くやってそしてまた次のプロジェクトへ移っていく。その先に待っているのはまた残業と休日出勤・・・。体持たないね。

ただ、意識の高い人がPMだったりメンバーの一人だったりするとやれ「アジャイルだ!」とか言って張り切ったりする。

Redmine か何かを使ってチケットを作り、カンバンみたいなのを貼りだしてタスクを可視化したり、バーンダウンチャートを作って作業の進捗度合い(ベロシティー)を出したり・・・。

最初は導入するツールが沢山あって覚えるのが好きな人は楽しいしそうでない人は苦行でしかない。で、どうにか慣れて来たんだけどバーンダウンチャートのベロシティーは思ったほど良くないしカンバンがあっても現状がイマイチわからない。結局、全てをなんとかしたのは残業と休日出勤だった。

アジャイルサムライを読んで勉強したはずなのになんで?チームに最高の最適化をしたはずだったのに・・・。

まあ、これは半分僕の話なんだけどね。

コベリンに入ってしばらくしてから、「よーし、ストーリーポイントを割り振ってバーンダウンチャートを作ってプロジェクトを管理するぞー!」って意気込んだ。

f:id:numanuma08:20151109204706j:plain

ベロシティーがいい感じに下がっていくときもあったけど、そうじゃない時もあった。バーンダウンチャートを見てもそこには最後まで到達しなかったグラフがあるだけで、一体何を表しているのか、何が問題だったのかわからないのだ。

ただしく計測をしましょう

ただ、僕は toggl というWebサービスを使ってどのタスクに何時間かけたのかをすべて記録していた。

Toggl - Free Time Tracking Software

f:id:numanuma08:20151109204911p:plain

toggl は Chrome の Extentions を入れておくと、 GitHub の Issue に紐付いてタイマーをスタートできる。

f:id:numanuma08:20151109204930p:plain

そしてタスクが中断したり終わったらタイマーを止める。これだけどどのタスクにどれだけ時間がかかったのかが秒単位で記録される。

見積もりと toggl による計測の組み合わせが最強だった。2週間に1度振り返り会をやって、見積もりと実際にかかった時間の差分を取る。大きく外れていた場合は何が問題だったのかをコミットログとかを見て思い出す。

これを繰り返すことで見積もりの精度を上げることができた。

結局、かつての自分が残業や休日出勤をやっていたのは見積もりに対して計測が行われておらず、ずっと正しくない見積もりを続けていたのが原因の1つだったようだ。

弱点

見積もりをして計測をして見なおしてまた見積もりをして・・・。この仕組には弱点がある。それはメンバーの入れ替えで計測結果が大きく変わってしまうことだ。

実際、 コベリンの開発でも最初は僕1人だったが1ヶ月ほど前に@をメンバーにアサインしたときに開発速度が一気に落ちた。これは彼の能力が低いせいではない(当たり前のことだ)。今まで全く触ったことのないコードに初めて触れるので、当然開発環境つくりを始めコードの理解とかの事前準備が必要になってくる。

人を増やしても開発速度は落ちるし入れ替えても落ちる、減らせばまた落ちるだろう。ただ、速度が落ちるのは初めだけで、これも計測によって分かるのだがある段階から安定してくる。どこで安定があるのかはチーム次第だとは思うけど、コベリンでは3週間くらいかかった。

という訳で頻繁にチームメンバーが入れ替わるプロジェクトではこの方式は使えない。

あと、寿命の短いプロジェクトの場合もあんまり役に立たないと思う。メンバーが固定した状態で開発スピードが安定するのに数週間かかるとして、3ヶ月とかで終わるようなプロジェクトを年間でいくうか回すみたいなことをやる場合、計測結果を活かす場面がないような気がする。

まとめ

帰り道に思ったことをまとめてみた。大事なのは「見積もりと計測」だってこと。計測、ちゃんとやりましょう。

そして多分、こういうことは「人月の神話」とか「アジャイルサムライ」とかに書いてある。

残業や休日出勤をしたくない思ったなら、ちゃんと自分で勉強して試して反省して組織を変えなきゃならないんだよね。しんどいけど。どうにもならないときもあるけど。

とりあえず、しんどい仕事をしたくない人と一緒に仕事ができる環境を探すのが先決かもね?