4keysの測定でわかった、アプリチームのタスク粒度の課題
4keysのデプロイ頻度とリードタイムは、製品の製作開始からユーザーに提供するまでの指標である。障害率や復元率、未復元時間はリリース後の製品の安定性や品質を示す指標だ。短いリードタイムは、デプロイを早く、そして頻繁にできることを意味する。一方で、デプロイ頻度を増やすためには、小さなタスクを速やかに開発する必要がある。これらの指標は相関関係が存在する。
月澤氏は「助太刀の場合、リードタイムが特に長かった」と振り返る。リードタイムを短縮すると、細かいプルリクエストを作成し小規模なリリースが可能となる。結果として、サービスのバグ発生や障害が一定の範囲に収まると考えた。
しかし、改善前に実際の状態を知るため、特定のツールを使用して状況を把握した。3月の1カ月間を対象に分析したところ、コミットからマージまでの時間が非常に長かった。プルリクエストが提出されても、不要であると判断されるものや、放置されているものが多く存在した。本来、不要なタスクは削減し、ユーザーに価値を提供するタスクに時間を割くべきである。無駄なものや、放置されているものを確認し、改善の方向性を模索した。
4keysを計測すると、バックエンドチームにおいては、ユニットテストを書く文化がしっかりと醸成されているため、リードタイムは短縮され、一貫したコードの書き方がなされている一方で、iOS／Androidのアプリチームはテストが不十分であることがわかった。アプリチームにはテストを整備するためのリアーキテクチャやリファクタリングが必要だった。
アプリチームの現場の課題に、タスクの割り当てがあった。プルリクエストやタスクの粒度が大きいため、実装やレビューに時間がかかり、すべてのレビューができないため品質が低下するという状況だった。そのため、タスクの粒度を小さくする方針を採った。最も重要なのはレビューの単位や機能の最小単位の最適化である。その単位をチーム内での議論を通じて決定し、その粒度での取り組みを始めた。
アプリチームのこれまでのアプローチでは、「バックエンドAPIの呼び出し部分」「フロントのロジック」そして「UIの表現」の3要素が1つの機能として扱われていた。改善後は3つのレイヤーごとにプロジェクトを切り分ける方法を採用した。チームはGitHubを利用しているが、プルリクエストにおいて変更箇所が一定のサイズを超えた場合に警告が出る機能や、特定の期間でマージされていないプルリクエストをSlackで通知する機能を導入した。毎週金曜日に振り返りの時間が設定され、未完了タスクの原因やタスク分割の反省などが行われている。
計測によって生じたエンジニアの心理的ハードルを対話で解消
4keysの計測を行った際、エンジニアの心理的ハードルが現れた。これには、自分のプルリクエストの進行速度が他者より遅いことへの過度な意識や、自分たちが監視されていると感じることなどが挙げられる。実際、エンジニアはコミットの粒度やタイミングが異なり、すべてのアウトプットが同じ速度でないため、それが他者に比べて遅いと認識される可能性がある。この問題への対策として、チームのエンジニアメンバーに対して丁寧な説明を行った。
出社する体制のため、対面でしっかりコミュニケーションしたのだ。月澤氏は「4Keysはあくまで指標であり、健康診断的に使うもの。助太刀の最終的な目的は建設業のユーザーに価値を返すことです。背景や目的を明確に説明し、チームメンバーが納得する形で取り組むことが大切」と語る。
ストーリーポイントを小さくする取り組みにおいて、その粒度の違いによる課題が発生した。短時間で終了するタスクと長時間を要するタスクが同じストーリーポイントを持つことで、タスクの粒度にばらつきが生じたのだ。これを解決するために、チームはストーリーポイントの基準を定期的に見直し、振り返りの際に適切なタスクの調整を行っている。
一方、リファクタリングやライブラリのアップデートなど、一括で変更が必要なタスクに関しては、4Keysの指標によって細分化することが困難であることがわかった。このような場合には、そのタスクを除外した。結果として、アプリチームではタスクの処理速度の向上といった成果が得られた。
月澤氏は「このプロセスを通じて、アプリのコードやアーキテクチャについての再評価の必要性を感じるようになりました。特にコードのリファクタリングや設計の見直しを行うことで、現在の依存関係や課題をより明確に把握することができ、やって良かったと思いました」とコメントした。
