こんにちは。エンジニアの加藤です。 普段はLIFULL HOME'Sの注文住宅領域にてエンジニアグループのマネジメントを担当しております。
マネジメントに携わり3年目となりますが、エンジニア組織の成果を定量的に測る難しさを常に感じておりました。 そのような中、今期より全社的にKPIマネジメントが導入され、その考え方を元に自身の担当するエンジニアグループとして目指すべき指標が明確化されたため、今回はその内容を紹介したいと思います。
KPIマネジメントについて
弊社では中尾隆一郎さんが提唱するKPIマネジメント（最高の結果を出すKPIマネジメント）を取り入れており、そちらには以下の4つのメインキャラクタ（4MC）が定義されています。
Goal
最終的に目指すべき状態。
KGI
Key Goal Indicator = 重要目標達成指標
最終的に期末に到達したい最も重要な目標数値。
CSF
Critical Success Factor = 重要成功要因
最重要プロセス = 事業成功の鍵。
KGIを達成するためにいくつかあるプロセスの中から、最も重要なプロセス。
KPI
Key Performance Indicator = 重要業績評価指標
KGIの先行指標であり、CSFの数値目標。
最も重要なプロセスであるCSFをどの程度実施すれば、期末にKGIを達成できるかを表した数値。
KPIマネジメントでは上記4MCの関係性を理解したうえで適切に設定し、運用・計測・改善することが重要となります。
グループ目標としての4MC
KPIマネジメントを構成する4MCに対し、私たちのグループでは以下のように設定致しました。
Goal
開発生産性の向上
KGI
開発生産力 = 価値創出数(= Pull Requestマージ数) / 開発に関わるコスト(= 人件費 + 業務委託費 + システム利用料)
CSF
1タスクにかかる開発速度の向上
KPI
Pull Requestマージ数
これらの4MCを選定したプロセスを紹介していきたいと思います。
Goal・KGIの選定
まずGoalとKGIについてですが、弊社では各組織単位においてそれぞれ4MCを設定し、KPIマネジメントの運用を行っております。 そのため、私がマネジメントするグループの上記組織であるユニット・部においても同様に4MCの設定がなされております。
そこで、ユニット・部を含めた組織全体として同じ方向性を持ち意識を揃える意図として、最終的な目標であるGoalとKGIは上位組織を踏襲することと致しました。
ただし、目標を達成する上での課題や状況、最適なプロセスは組織ごとに異なると考えられるため、Goalに対しての手段（CSF、KPI）はグループとして検討を行います。
CSFの選定
中尾さんの提唱するKPIマネジメントではCSFを選定する上でのポイントは以下のように言われております。
現場でコントロールでき、努力で変化するプロセス（季節要因、外的要因などは排除）
実行していればGoalに繋がるプロセス
複数候補の中から一番弱いプロセス
これらを踏まえCSFを選定するにあたり、まずはKGIを構成する要素を分解し以下の2つをCSFの候補として比較致しました。
価値創出数
開発に関わるコスト
開発に関わるコストは人件費やシステム利用料などであり、ある程度固定費としてかかるため、価値創出数に対し現場の努力により変動する幅の狭い要素であると判断しました。 そのため、この時点で開発に関わるコストはCSFの候補から除外し、価値創出数を増加させるプロセスを深堀りすることと致しました。
KGIの要素である価値創出数はPull Requestマージ数に置き換えているため、Pull Requestマージ数の増減に影響する要素を以下のように分解しました。
実開発時間(= 総業務時間 - 運用時間 - ミーティング時間 - 社内行事時間) / 1タスクあたりの開発時間 * 1タスクあたりのPull Request数
これらの要素に対し分析を行い、最終的なCSFの決定を行います。
総業務時間
総業務時間を増加することで価値創出数が増加
各メンバーの業務時間を単純に増やすことで総業務時間を増加できる
ただし業務時間の増加 = 残業時間の増加となるため、本質的でなくCSFには適さない
運用時間
運用時間を削減することで価値創出数が増加
運用業務の削減、効率化、自動化することで運用時間の短縮を図ることができる
体感として運用業務が発生することで意識が分散し、実時間以上に生産性の妨げになっている可能性がある
しかし、日次採算システム上、全体に占める割合は約5%
改善すべきポイントではあるが、最重要プロセスとはいい難い
ミーティング時間
ミーティング時間（以降MTG）を削減することで価値創出数が増加
不要なMTGの廃止、必要なMTGのみへの参加、MTGの効率化などにより削減可能
ただし日次採算システム上、全体に占めるMTGの割合は13%ほど
在宅勤務により必要なコミュニケーションも存在するとの考え方もあるため、一番弱いプロセスとしては考えづらい
社内行事時間
社内行事時間を削減することで価値創出数が増加
社内行事時間は全社的に設けられているイベントに対しての時間のためグループとしてコントロールしづらい
そのため極めて定数に近い要素となるため、CSFには適さない
1タスクあたりの開発時間
1タスクあたりの開発時間を削減することで価値創出数が増加
開発タスクに着手してから完了となるまでのリードタイムを削減する
実行するためには開発プロセスの改善やシステム基盤の整備（リファクタ、リプレイス、仕組み化、標準化など）など様々なアプローチが考えられる
エンジニアに裁量があり、主体となって実行する部分であるためコントロールがしやすい
現状システムの複雑性や技術的負債が開発生産性を妨げている大きな要因となっている
これらにより考えられるアプローチを実行したうえで開発時間を短縮することが、最も重要なプロセスであると考える
1タスクあたりのPull Request数
1タスクあたりのPull Request数を増加することで価値創出数が増加
レビュアーの1回のレビューにかかる負担を減らすなど開発生産性の向上に対しての一定の効果が表れる可能性がある
ただ1タスクあたりのPull Request数を上げることだけを最重要プロセスとして捉えると、小手先での調整でも可能となり、本質的な取り組みから離れてしまう懸念がある
そのため、ここではCSFの対象としては除外する
上記より、最終的に私たちのグループでは「1タスクにかかる開発速度の向上」が最重要プロセスであると捉え、CSFとして選定しました。
また、弊社では以前より日次採算システムを全社的に導入しており、一人ひとりが各業務ごとにどれだけ時間を費やしているかを計測しております。 体感では運用業務に多くの時間を費やしている印象もありましたが、実際に計測数値を確認してみると割合としては少ないと分かったことから、事実を元に分析をする上でKPIマネジメントと日次採算システムの組み合わせの有効性の高さを感じました。
KPIの選定
CSF同様、KPIにも選定する上でのポイントがあり、以下のように言われております。
- シンプルで分かりやすい指標
- CSFとの整合性が取れている指標
- 現場でコントロール可能な指標
- 即座に計測・入手できる指標
CSFは1タスクにかかる開発速度の向上であるため、それを計測する指標としては1タスクあたりの開発時間がKPIとして考えられます。 しかし、現状では各開発タスク毎にどれだけの時間がかかっているかを正確に計測する仕組みがなく、「即座に計測・入手できる指標」であるという部分にマッチしません。 また、計測に際しての運用も複雑になる懸念があるため、現状KPIとしては適さないと判断し、別の指標を検討致しました。
そこで、1タスクにかかる開発速度の向上を計測する指標を選定するため、改めて価値創出数を算出する要素を確認します。
価値創出数(Pull Requestマージ数) = 総業務時間 / 1タスクあたりの開発時間 * 1タスクあたりのPull Request数
ここで各要素に着目し、それぞれ定数と変数に分類しました。（青：定数、赤：変数）
定数と変数に分類したことにより、1タスクあたりの開発時間の変化に比例して、Pull Requestマージ数が増加すると捉えることができると思います。 そのため、Pull Requestマージ数がKPI候補となり得るのではないかと考え、KPI選定のポイントと照らし合わせても以下の理由で最適であると考えました。
- シンプルな値で分かりやすい
- 上記の式によりCSFとの整合性が取れている
- （開発時間の短縮を）現場の努力で改善可能
- ダッシュボードより既に容易に計測可能
上記より、最終的に私たちのグループでは「Pull Requestマージ数」をKPIとして選定しました。
ただし、このKPIには注意点も存在します。 総業務時間と1タスクあたりのPull Request数が定数であることが前提であるため、この2つの要素が現状から大きく変化する場合、正しく成果が計測できないこととなります。 そのため、定期的に上記2つの数値は確認をし、変化が大きい場合はKPIを見直すことをルールとして定め運用します。
KGIとKPIの目標値について
KPIマネジメント導入の初年度ということもあり、今期に関しては現状からの105%成長で設定しました。 2020/10〜2020/12をサンプリング期間として定め、こちらの期間の3ヵ月の平均値をベースに105%成長した数値を目標値として設定し、2021/1〜2021/9までの9ヵ月間の平均値にて計測します。
目標値を平均値としている理由には、繁忙期やプロジェクトのフェーズにより数値のばらつきも発生すると考えられるため、平均して一定のパフォーマンスが発揮されているかを測る意図があります。
まとめ
以上が私の担当するエンジニアグループがKPIマネジメントの考え方を元に目標指標と定量的な目標値を導いた内容となりますが、まだスタートラインに立った状態であると思います。 今後、設定した目標に対し実行・計測・改善を繰り返し、より生産性の高いエンジニア組織へと成長していきたいと思います。
今回の記事を通じ、私と同じようにエンジニア組織の定量的な成果計測に悩む方の一つのヒントになれば幸いです。
