はじめに
こんにちは。エンジニアの鈴木（@yamotuki）です。 今回はエンジニアの生産性向上の施策として、Jiraを用いた計測手法と、やってみた施策について書こうと思います。
背景
ストーリーポイントの計測
”ストーリーポイントとは？”についての詳細は他の記事にお任せします。
弊社ではスプリントを採用しており、毎スプリントで消化しているストーリーポイントを計測しています。 エンジニアが特定の一つのタスクに詰まってしまって、なかなか終わらせることができなければストーリーポイントの合計は当然低くなってしまいます。 スプリントで消化したストーリーポイントが高いからといって、優先度の低かったり不要なタスクをやっていたら生産性というのは向上しないものですが、消化したストーリーポイントが低い場合には何らかの問題が隠れているものです。
ただ、スプリントが終わった時の消化ストーリーポイントの合計というのは、結果の値でしかなく、細かくどこでエンジニアが詰まったのか？というのは一見して分析することができません。
サイクルタイムの計測
そこで、”サイクルタイム”を計測することにしました。 サイクルタイムは Jira ですと管理チャートで確認することができます。
サイクルタイムとは何か、については以下にGoogle翻訳による翻訳を引用します。
サイクルタイムは、問題の作業に費やされた時間です。通常、問題の作業が開始されてから作業が完了するまでにかかる時間ですが、問題の作業に費やされたその他の時間も含まれます。たとえば、問題が再開され、作業が行われ、再度完了した場合、この余分な作業の時間がサイクルタイムに追加されます。
例えば、「仕様決めに時間がかかったのか？」「作業に時間がかかったのか？」「レビューで時間がかかったのか」などを細かく追っていくことができます。
施策を始める前
Github IssueからJiraに移行してから測定は勝手にされていたので、遡って各種数値を確認することができました。 測定と生産性向上施策を始める前の状態は以下の図の通りでした。 一つのタスクを着手から完了まで３日近くかかっています。赤い線が表示期間の中での平均で、青い線が前後のタスクとの移動平均です。
タスク完了まで時間がかかるのには以下のような問題点があると考えました。
- チェック待ち状態が長くなる要因
- プルリクを出した後にレビュアが二人チェック。議論が全てGithub上で行われるので、ラリーが多い
- 仕様がふわっとした状態で実装を始めて、レビューの段階で「ここPdMと相談しておいた方がいいんじゃない？」みたいな話が頻繁に行われ、手戻りが多い
- 作業中状態が長くなる要因
- 一人が複数タスクを際限なく取ることができるので、複数タスクを平行で進めることによって結果として全てのタスクに時間がかかる。3ポイントのタスクを二つ持つとどちらもなかなか終わらない。（補足: 現在は適当なタスクからの相対的な値としてストーリーポイントを見積もっていますが、過去には3ポイントは ”2日以内に終わる” という風に見積もっていました。弊社における3ポイントはこれくらいの大きさです。
- 各エンジニアがハマっても、他の人が適切に助けることができない
- 一つの大きなタスクを分割せずやろうとする。ざっくり8ポイントとかだと、いつ終わるかの見積もりも立てづらい
施策
DevOpsハンドブックには「それぞれのプロセスを短くしてフィードバックサイクルを早くすることで生産性が上がる」（と私は解釈）と書かれていました。そこで、できるだけそれぞれのプロセスを小さなバッチサイズにするような施策を試してみることにしました。
試した施策
以下のような施策を試してみました。特に改善効果があった施策は太文字にしておきます。
- チェック待ちが長くなる原因の対処
- レビューを一回やって修正項目が出たらレビュアとペアプロをやって一気にマージまで持っていく。文章でのラリーを避ける
- Jiraのステータスで、"作業中"の他に”仕様受け入れ中”を作る。PMとして仕様が固まったら”仕様策定済み”になり、エンジニアが細かい仕様を詰めているステータスとして”仕様受け入れ中”を使用。エンジニアとして明確になったと思ったら"作業中"に移動する。
- 実装者とレビュアを三人チームとして固定。タスクを取る人はレビュアになる人にもできるだけ共有しておく。実装前に不明点をできるだけ潰して手戻りを防ぐ
- 作業中状態が長くなる原因の対処
- 並列で取れるタスクの量をストーリーポイント4ポイント以内にする。3ポイントのタスクを取ったら1ポイントの小粒なタスクしか取ってはいけない。
- Slackの
#developers_chattingチャンネルに今やっていること、困っていることを投稿する。他の人は余裕があれば支援（口出しともいう）をする - 詰まったら積極的にレビュアになる人に通話を繋いでペアプロ作業をする。
- タスクを1~3ポイントのタスクに積極的に分割して、順次終わらせる
一番効果があった施策
一番効果があったのは、”タスクを一人で抱え込まず、チームで一気に終わらせる” ためのペアプロでした。ペアプロを通して、タスクは一人のものではなくてチームで解決するものなのだという意識が浸透したのも良かった点かなと個人的には考えています。
ペアプロの方法としては、Aroundというミーティングツールを使ってslack上でミーティングルームを立ち上げて、他の人が入るという形をよく使っています。
他にもPhpStormでリアルタイム共同編集できる機能なども出てきているので、活用していきたいと思っています。
施策の結果
サイクルタイムを見ながら施策を投入していくことで、以下のように一つのタスクが終わるまでの平均時間が改善しました。タスクを小さく分割する施策も入れているので平均時間が減るのは当たり前と言えば当たり前ですが、一人でずっと抱えて巨大プルリクを作って大きく手戻り、というのは減ったと思います。
👇 1ヶ月以上かかるプロジェクトをみんなでやっていたパターン。コミュニケーションコストが低く、平均として低く抑えられている。
👇 細かい改善タスクをバラバラやっていた期間のパターン。コミュニケーションコストが高いが、beforeの2.9日からafterとして2.2日くらいまでよくなっています。 期間の最後ではちょっと上がってしまっていますが、時間のかかるインフラタスクをやっていたり、他部署の人にデータ渡す系のタスクなど、完了まである程度時間がかかる原因が分かりやすいタスクが多かったです。
終わりに
もっと早く、もっと楽に、ユーザに価値を届けられる組織をこれからも目指していきます。 生産性の高いエンジニア組織作りに興味がある方などいらっしゃれば声をかけていただけるとありがたいです。
