こんにちは。エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。
弊社では昨年度よりKPIマネジメントを導入し、さまざまな組織課題の解決や目標達成に向け活用しています。 私がマネジメントするエンジニアチームでも同様に開発生産性向上を目標とし、KPIマネジメントの手法を用いて実現への取り組みを実施してきました。 そのような中、今回はこの半期においての私のチームでの取り組みについて紹介したいと思います。
KPIマネジメントの概要や今までの取り組みについては以前こちらのブログでも投稿いたしましたので、よければ併せてご覧ください。
CSF・KPIの選定
KPIマネジメントは4MCと呼ばれる4つの主な要素（Goal, KGI, CSF, KPI）から成り立っています。 そのうち、GoalとKGIはエンジニア組織全体で目線をそろえるため、共通的な目標・指標を設定しています。
Goal
開発生産性の向上
KGI
一人当たりのPullRequestマージ数（前期比115%UP）
そのため、各チームでは今期を通して一人当たりのPRマージ数を115%増加させるために必要なCSF、KPIの選定を行います。 私のチームではこれらの選定にあたりまずはデータを元に現状を把握するところから取り掛かりました。
現状把握
「時間」に焦点を当て、総業務の内どれだけの時間を開発またはそれ以外の業務に費やしているのか、実装プロセスの内どの工程にどれだけの時間を費やしているかを整理したものが以下の表となります。
| 構成要素 | コントロール可否 | 計測可否 | 前期の状況 | |
|---|---|---|---|---|
| 総業務時間 | 全体 | × | ◯ | |
| 開発時間 | ◯ | ◯ | 54% | |
| 運用時間 | ◯ | ◯ | 3.6% | |
| MTG時間（組織系） | △ | ◯ | 前期までは測定不能 | |
| MTG時間（開発系） | ◯ | ◯ | ||
| 1タスクあたりの開発時間 | 全体 | ◯ | × | |
| 開発着手からPRマージ | ◯ | × | ||
| 1stコミットからPRマージ | ◯ | △ | 平均：254.27時間（約10.6日） | |
| 開発着手からPR作成 | ◯ | × | ||
| 1stコミットからPR作成 | ◯ | ◯ | 平均：130.94時間（約5.5日） | |
| PR作成から1stレビュー | ◯ | ◯ | 平均：54.95時間（約2.3日） | |
| PR作成からマージ | ◯ | ◯ | 平均：123.33時間（約5.1日） | |
CSFとKPIを選定する上でのポイントとして、KPIマネジメントでは以下のことが言われています。
- CSFは現場でコントロールでき、努力で変化するプロセスであること
- KPIは即座に計測・入手できる指標であること
これらから、各データに対してはコントロール可能であるか、計測可能であるかどうかも併せてまとめました。
選定
データを見える化したことで意外な事実に気付きました。 これまでは主観的に社内関係者からの質問・相談対応や定期・不定期問わずの運用業務が多く、開発時間を逼迫する要因だと思っておりました。 しかし、実際のデータを確認することで運用業務にかかる時間は4%弱しかなく、50%以上の時間は開発業務に充てられていたのです。
そこで、今改善すべきプロセスは開発に充ている時間を増やすことではなく、開発工程の中にあると想定し一つの時間に着目しました。
それが「PR作成からマージ」の時間です。 この時間は主にコードレビューにかかる時間を表していますが、平均約5.1日かかっており、実装時間（1stコミットからPR作成）とほぼ同等の時間を要していることが分かりました。 そのためコードレビューにかかる時間を短縮することが、開発生産性を高めるための最も重要なプロセスであるとしてCSFに選定しました。
CSF
コードレビュー時間の短縮
KPI
PullRequest作成からマージまでのリードタイム
PDDSサイクルを回す
4MCが決定したら日々の業務の中で実行し改善サイクルを回すことが重要です。 PDCAが普段よく耳にする言葉であるかと思いますが、最高の結果を出すKPIマネジメントの中ではPDDSサイクルが提唱されています。 PDDSサイクルはPlan（よく考え）- Decide（すばやく絞り込み）- Do（徹底的に実行し）- See（きちんと振り返る）で構成されます。 私のチームでもPDDSサイクルを意識し日々の改善活動に取り組んでいます。
具体的なアクションに落とし込んで実行する
CSFはKGIの達成のため最も重要なプロセスとなりますが、それだけ決まっていれば日々の業務の中で行動を変えられるわけではありません。 そのため私のチームでは、CSFの実現につながる具体的なアクションを一つ週次で決め、実行しています。 今まで実行したアクションの実例を少し紹介します。
長期間残っているPullRequestの整理
改善活動を実行するためには、正しくデータを計測できることが重要です。 しかし、現状長い時間コードレビューされず放置または後回しにされたPullRequestが存在し、それらがあるタイミングでマージされることで直近のリードタイムが正しく計測できない問題がありました。
そのため、まずはそのような長期間残っているPullRequestをすべて洗い出し、不要な修正はClose、必要な修正は優先的にコードレビューすることですべてのPullRequestの整理を行いました。 その結果、計測結果にノイズを発生させるようなPullRequestはすべてなくなり、正しく計測できる状態へと変化しました。
コードレビュー期限の明確化
コードレビューの時間を引き伸ばす次なる要因としては、プロジェクトチーム横断的なタスクにありました。 基本的にチームの各メンバーはプロジェクトに参画し、主にプロジェクト内で開発活動を行うことになります。
一方で突発的な開発作業やリファクタリングなどのコード修正が発生することもあり、これらの実装およびコードレビューはプロジェクトとは切り離して実施されます。 そのため、このようなタスクはついつい後回しにされがちで結果PullRequestを作成してから放置される傾向にありました。
これらの課題を解決すべく、コードレビュー依頼者はあらかじめレビュー期限を明確化し、期限内にレビュー可能なメンバーが引き受けることとしました。
レビュアーの指定
レビュー期限を明確化することで、横断的なタスクであっても長期間PullRequestが残り続けることはなくなりましたが、次なる課題も見えてきました。 コードレビューを依頼する際Slackでメンバー全体に投げかけているのですが、お見合いが発生しレビュアー決定まで無駄な時間が発生していたのです。
そのため、依頼者がレビュアーを指定し、直接調整することでほかのメンバーとのお見合いを防ぎました。
定期的に計測し振り返る
アクションを実行することで日々状況が変化するため、その変化を計測し振り返り、次なる打ち手を検討することが重要となります。 私達は毎週の定例ミーティングにて以下の枠組みで計測・振り返りを実施しています。
- KPI・KGIの計測結果確認
- 今週のアクションに対しての振り返り
- 次週のアクション決定
これらPDDSサイクルを実行することで、コードレビューにかかる時間は徐々に短縮され結果として表れてきています。（PR作成からマージ：123.33 → 36.55）
まとめ
今回はKPIマネジメントを活用した開発生産性向上への取り組みを共有させていただきました。 組織課題について同様に頭を悩ます方も多くいらっしゃるかと思います。この記事がそういった方々の一つのヒントになれば幸いです。
また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。
