はじめに

2024年10月からメドピア株式会社のVPoEに就任した保立（@purunkaoru）です。弊社では、CxOとVPoEが月1回ほどの頻度で社内外向けにLetterを発信し、経営陣の考えていることをお伝えしていきます。

Letter from VPoEの第1回目では、開発量を計測する目的や、エンジニア界隈で話題になっている「開発生産性」について、私の思いをお伝えしたいと思います。10月から私がVPoEになり、特に事業部所属の方には「開発量」や「開発生産性」というキーワードについて、何度かお話ししております。アジャイル開発をされている皆さんには、まさに「開発量」を週次管理しており、常に意識する数値にさせていただいています。
本日は、エンジニアの成果を測るうえで、「開発量」を指標として位置付けている意味についてお伝えしたいと思います。（ここでは、「開発量」は開発したアウトプット量を指します。PullRequestの数や消化ストーリーポイント数のことです）

「開発量」を指標として位置付ける理由

まず「開発量を上げてほしい」と言われたら、何をするでしょうか。業務時間を増やす、技術力・設計力を上げるなど、様々な方法があります。業務時間はコードを書く時間とそれ以外の時間に分けることができるので、コードを書く時間を増やすという方法もあります。例えば、要件確認や仕様調整をするコミュニケーションが短くなる工夫をする、手動テストを減らせる仕組みを作るなどです。さらに、我々はチーム開発をしているので、個人への影響だけでなく、チームへ影響を与える工夫もできます。例えば、チーム内で技術共有や設計ルールを明文化したり、CIにかかる時間や無駄なMTGや作業を減らすことで、全体の開発量を増やすことができます。歴史のあるプロダクトや人数の多いチームほど、チーム全体の開発量を上げる余地は多くあります。まとめると、以下のような表になります。

では、なぜメドピアでは、「開発量」を指標として定義しているのでしょうか。例えば、「事業KPIにしないと意味がないのでは？」といった疑問もあると思います。「開発量」を指標として定義する理由は、大きく3つあります。

1点目は、開発量をプロダクトのアジリティを上げるための重要なファクターと捉えているためです。成功するプロダクトの方法が完全に理解できていれば作るだけでいいですが、実際はそうではありません。事業やリリース可能な頻度にもよりますが、弊社の場合は1度のリリースで目標達成できることは少なく、何度も試行錯誤を繰り返して徐々にゴールへ近づいていくのが現実的な流れです。この開発が事業KPIの達成に近づけるだろうという仮説を立てて機能を実装し、フィードバックやデータを見て修正し、再度リリースして反応を確かめる――このサイクルを高速で回せるチームほど、結果的に事業上の成功確率が高まります。逆に、実装に時間がかかり過ぎると、事業が求める改善や新たな挑戦に乗り遅れてしまい、競合やマーケットの変化に対応できなくなるリスクが上がります。ということで、中盤に来てタイトルの回収になりますが、「作って試す」というアジャイル開発の効果を最大化するためにも、開発量を指標として用いる必要があると考えています。

2点目は、開発量はエンジニアチームが主体的に向上させられる数値であり、個人でも組織としても取り組みやすいという理由です。売上や事業KPIはどうしてもビジネス要因やマーケットの動向に影響される部分がある一方、開発量はエンジニア自身の手で向上させることが可能です。また、開発量は取組みの結果がすぐに分かるというメリットもあります。もちろん、PMやCS、デザイナーやQAなど他の職種にも開発量を上げるための依頼をすることもありますが、エンジニアチームが主体的に上げる施策を考えられる数値であります。そのため、開発量を重視指標として定義しています。

3点目は、開発量を測ることで、新しいツールの導入や施策に対するROIが測れることです。現代のソフトウェア開発現場では、開発プロセスの自動化や効率化を実現するために、GitHub Copilot や devin.ai といった先進的なツールが注目されています。弊社でも、これらのツールを活用しております。（devin.ai の活用事例は近日中に弊社テックブログで掲載予定です）エンジニアがコードを迅速に生成したり、開発作業の自動化を促進したりすることで、生産性の向上に寄与すると考えて新しいツールの導入を進めますが、導入前後の投資効果を客観的に評価することは、経営判断の重要な指標となります。ツール導入前後で開発量を比較することで、どれだけの工数削減や生産性向上が実現されたかを定量的に把握することができます。
もちろん、devin.ai のようなツールは、開発量の増加以外の効果もあります。開発作業の一部を自動化・効率化することにより、エンジニアの集中できる時間を増加させます。また、新しいツールを導入することが、採用や社員のエンゲージメント増加にもつながるので、開発量以外の指標にも良い影響を与えることが予想されます。定量的に測りづらい面も加味しながら、定量的に測れる開発量でROI も計測して、ツール導入の効果を多面的に評価することを意識しています。

ここまでは、開発量を計測する理由を記載しましたが、全てのチーム・プロジェクトで計測しているわけではありません。エンジニア組織の生産性を測るための指標は、開発量だけでなく、例えば事業KPIに直結する開発割合も大事ですし、障害発生数や復旧速度、またUXや非機能要件など開発の質の部分も大事であります。「チームの組成期で、今はスピードよりもチーム力の強化や品質維持に注力したい」というケースもある」と思いますし、「すでに十分な開発速度を保てているので、事業KPIや売上をダイレクトに伸ばす取り組みにリソースを割きたい」というチームもあると思います。そうしたチームでは、必ずしも「開発量」の指標を強く意識しなくてもいいと思います。あくまでも足りない部分を補い、エンジニアリング活動の質と量の両方を高めるための一つの指標にすぎません。

それでもなお、「自分の開発量を成長させる」ことに脳のリソースを割くことは、多くのエンジニアにとって価値があると考えています。単なるPullRequestの数を増やす、コード行数を増やす、ストーリーポイント数を増やすの話ではなく、最初にお伝えした開発量を上げるための4象限の施策をもとに何をすればいいかを考え、必要に応じて周りを巻き込むことで、結果的に自分の仕事のアウトプットが増えていきます。そこでは、開発量という定量的に計測できる指標をもとに、短いサイクルで多くの仮説検証を行うことができ、エンジニアとしても学びが大きいはずです。

弊社では、現在テックサポート制度やEM研修など、開発量を伸ばすためのサポートを会社として行っております。また、毎週水曜日に全事業部のエンジニアが集まり知見を共有する会など、技術顧問の willnetさん（@netwillnet) や他事業部の有識者から学ぶ機会も用意してあります。

終わりに

VPoE Letter の第1回目、最後まで読んでいただきありがとうございました。
次回の VPoE Letter では、理想のエンジニア組織について書かせていただきます。
長文にお付き合いいただき、ありがとうございました。

メドピア採用　求人一覧はこちら▼

経営メンバーの生の声をすぐにお届け！マガジンをフォローする▼