はじめに

こんにちは！グロービスで「ナノ単科」の開発を担当しています、GDPの堀尾です。
今回は業務委託の多いチームでの開発生産性向上の取り組みについて紹介していこうと思います。

ナノ単科とは？

ナノ単科はグロービス経営大学院が2021年10月から提供している教育プログラムです。動画学習はもちろん、AIを使った学習コンテンツや大学院講師によるライブ授業、受講生同士で学習理解を深めるグループワークなどを通じて、6週間で仕事に活かせる基礎スキルを身につけることができます。

ある日のこと

上長から「開発生産性を向上させて欲しい！」と言われました。
体感として若干開発スピードが落ちてそう、という声がちらほら上がっていたので、本腰を入れて生産性向上に向けて取り組むことに。

ナノ単科開発チームの状況

メンバー10人のうち、社員は2名（1名育休中）
業務委託の方がほとんど
稼働が不安定&定量的な分析にも難しさがある

という状況でした。
まずはどんなステップで進めるかを考えてみることにしました。

どんなステップで進めたか？

生産性向上に向けて、上記のステップを踏むことに決めました。
ナノ単科開発チームではFindyTeamsという定量的に開発生産性をモニタリングできるツールを導入していたのですが、定量的な課題抽出だけでは不足していると考え、メンバーの感じている課題感を定性的に捉えることで、両面からの課題抽出を行うことにしました。

続いて、計測指標となるKPIを3つに絞ろうと考えました。
1つだけだと、余程クリティカルな指標でないと効果がないと考え、3つを超えると認知的負荷が高くなると思ったので3つのKPIに絞っています。

策定したKPIに対して、有効そうな施策をブレストし、投票によって施策を策定するというステップで進めました。

以降の各ステップは開発定例MTGの時間を使って進めました。zoomのブレイクアウトルームで何名かのチームに別れてブレストしてみたり、全員で投票してみたりといった方式で進めています。
資料はnotionとmiroを使いました。ブレストに適していると思いmiroを導入してみたのですが、ブレスト・投票のフェーズではかなり役立ってくれました。キャプチャを貼っておくので参考にしてみてください。

定性的な課題抽出

どう進めたか

そもそも開発とは何かを構造解析してみる
どこに時間がかかっていそうかを投票してみる

まず、「開発」とは何を指すのかを構造解析してみました。
これは、今回の開発生産性向上の取り組みのスコープがどこになるのか？をメンバー全員で認識合わせする意図も含んでいます。

開発フェーズを洗い出したところで、我々の開発において時間がかかってそうなフェーズを投票してみました。

得られた示唆

PRのレビューに時間がかかっていそう
Clientの実装に時間がかかっていそう
テストに時間がかかっていそう

この中で、何を対象に改善していくかを決める必要があるのですが、ここを間違えてしまうと効果の出ない施策を続けることになり、メンバーの士気も下がってしまいます。
KPI策定における注意点を後の章でまとめるので、もう少し読み進めてみてくださいmm

定量的な課題抽出

どう進めたか

Findy teamsを使って定量的に分析してみる
問題がありそうな指標を洗い出して原因分析

FindyTeamsではレビューリードタイムやPRあたりの平均変更行数などをモニタリングできます。
これらの指標を時系列で確認し、どこに問題がありそうか？を定量的に分析してみました。

結果的に以下の示唆を得ることができました。

得られた示唆

PRがすぐにApproveされなくなってきている？
変更リードタイムが前年比+30hになっている
PR作成数は減っているのに、レビューからマージまでの時間は伸びている
approveからマージまで3日かかっているがこれは妥当なのかな？
変更行数は大きいPRが多い、何千から1万は流石に辛い

定性的な分析を行ったときに多くの表が入っていた「PRレビューのリードタイム」について、定量的な分析を行うことで色々な示唆を得ることができました。

これらの分析結果から「大きめの機能開発が多いためレビューしづらくなっている？」「稼働が不安定な中でのレビューのしづらさが問題？」などの仮説立てを行うことができました。

定量的・定性的な分析を行い、課題抽出と仮説立てを行ったうえで、生産性向上にインパクトがありそうなKPIを策定していきます。

KPI策定にあたっての注意点

KPI策定にあたっては上記2つの点を意識しました。
現場によって価値観が異なりますし、プロダクトのフェーズによっても重要度が変わるので、一律この注意点が適用できるわけではないのですが、我々のチームでは「品質を犠牲にしない」「意識を変えることが重要」という価値観で進めることにしました。

KPI候補の洗い出し

上記画像のようにKPIになりそうな指標を候補として6つほど挙げました。
その上で、「我々のチームにフィットする」かつ「生産性向上に影響しそう」なKPIを投票により3つに絞りました。

KPIの策定

最終的に残ったKPIが上記の3つです。

デプロイ数/稼働時間

もともとグロービスではd/d/dという指標を取り入れていたのですが、この指標は「デプロイ数/開発者数/稼働日数」でデプロイ頻度のヘルスチェックを行う指標です。
ただ、業務委託の多いチームではd/d/dだと正確な数値が取れないため、デプロイ数をメンバーの月の総稼働時間で割った時間を指標としました。

PRオープンからアプルーブまでの時間

定性・定量分析の両方で課題として挙げられていたレビューリードタイムを指標としてみました。

PR数/稼働時間

PRを分割することでレビューのしやすさにも繋がると考え、PR数/総稼働時間を指標としてみました。
こちらも総稼働時間で割ったものを指標としておいています。

施策の洗い出し

KPIを決めたので、次は各KPIに対して実施する施策を洗い出していきます。
これは全員でブレストを行った結果のキャプチャです。
この中から、KPIの目標達成に効きそうな施策を投票していきます。

ここまでのワークでmiroとnotionを使ったブレストや投票を行ってきましたが、全員で納得感を持って課題感を自分ごとに意識できる効果があったと思っています。
もちろんリーダーがすべてを決めてメンバーに伝えるのも良いと思いますが、我々のチームは業務委託メンバーのスキルがかなり高いこともあり、集合知で解決しようという試みで進めました。

各KPIに対する施策（一部）

投票により策定された施策の一部を載せておきます。
施策自体は毎日意識的に取り組めるものを中心に、各KPIに対して3~4つほど策定しました。

さて、最後に生産性は向上できたのかを見ていきたいと思います。

生産性は向上できたのか？

上の表が目標対比での実績です。2024.05~06での実績を掲載しておきます。
割とストレッチな目標設定だったのですが、着実に生産性を向上させることができたと思います。
欲を言えばすべて目標達成したかったのですが、ある程度数値を向上させることができたので、まずまずの結果だったと思っています。

得られた示唆と改善したいこと

目標がストレッチすぎたので、実現可能性が高い目標設定が必要
PRのアプルーブまでの時間は指標として不適切だったかもしれない
平均変更行数を指標に加えたい → PRレビューのしやすさなどにつながる
持続可能性のある施策を実行するのが大事

上でも書きましたが、若干目標がストレッチだったなと思っています。
あまりにも高すぎる目標は逆に士気が下がることに繋がりかねないので、チームにフィットした目標設計が重要です。
また、この取り組みは1回で終わらず継続的にウォッチすることが大事なので、何回かイテレーションを回す中で目標を調整していくのも良いと思います。

また、KPI自体も調整の必要性を感じました。
PRのアプルーブまでを計測対象としていましたが、レビュー後の修正時間を含むため、品質を考えると不適切な指標だったかもしれません。

実施する施策は実現可能性が高く持続的に実施できるものでないと意味がないです。
メンバーが意識でき、着実に効果が得られる施策を策定することも重要だと感じています。実際施策選びが結構難しかったです。他社事例なども参考にして施策の洗い出しを行うのも効果的かと思います。

一緒に働く仲間を募集しています！

グロービスでは一緒に働いてくれる仲間を募集しています！
興味がある方は以下の募集ページから、是非応募してみてください！！