最も難しい「エンジニアのマネジメント」　開発生産性をどう測ればいいのか?

ビジネス書を中心に1冊10分で読める本の要約をお届けしているサービス「flier（フライヤー）」（https://www.flierinc.com/）。こちらで紹介している本の中から、特にワンランク上のビジネスパーソンを目指す方に読んでほしい一冊を、CEOの大賀康史がチョイスします。

今回、紹介するのは『エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～』（佐藤 将高著、技術評論社）。この本がビジネスパーソンにとってどう重要なのか。何を学ぶべきなのか。詳細に解説する。

エンジニア組織のマネジメント

経営の課題は主に事業、人、資金に関わることだと言われています。そして、日々仕事をする中でよく直面するのは人に関する課題です。人のマネジメントで楽な職種はありませんが、それでもなお、最も難しい領域の1つはエンジニアのマネジメントではないでしょうか。そして、エンジニアがまったく関与していないスタートアップはほとんどない時代となり、ますます多くの会社が悩んでいるテーマになっています。

私自身は学生の頃からプログラミングを始めて、働き始めてからも数年間はプログラミングやプロダクト企画の仕事をしていました。

エンジニアをしていた頃、数十万円の仕様変更がわずか一行の修正で完了したこともありましたし、その逆に1人日と見積もられた仕様に1週間かかったこともありました。エンジニアによる仕事は、その業務量すらも見積もることが難しく、そのため本書のタイトルにある開発生産性の測り方は頭を悩ますものだと言えます。

そのような背景から開発生産性というテーマは重要なものです。定量的に確認し続けることは、課題のありかや改善策を示す貴重な示唆を導き出すための鍵となります。そもそも開発生産性とは何かというところから、本書の内容を紹介していきます。

開発生産性とは

本書では開発生産性を3段階のレベルで表現しています。まずわかりやすいのはレベル1の仕事量に関わる生産性です。レベル1では、個々のタスクの完了数や作業スピードなどの純粋な作業に注目して考えていきます。具体的な指標としては、1日あたりのコミット数（作業の保存数）、プルリクエスト数（更新内容の反映依頼数）、バグ修正に要する平均時間などがあげられます。主にエンジニア組織内における生産性指標だとも言えます。

次のレベル2は期待付加価値の生産性です。作業の量そのものではなく、各施策がプロダクトにどれだけの価値をもたらすか、という視点で考えます。そのため、レベル1の生産性に加えて、タスクの優先順位が「投下作業量に対するプロダクトの価値」に基づいて適切に設定されているかが大事になってきます。

最後のレベル3は、実現付加価値の生産性であり、売上や主要KPIなどの指標が対象となります。そのため、エンジニア周辺だけでなく、マーケティング、セールス、カスタマーサクセスなどの組織横断で評価と改善に取り組んでいく必要があります。

それぞれの生産性の可視化のためには、レベルが上がるごとにエンジニア以外の生産性が及ぼす影響が大きくなるため、短期的な因果関係が見えづらく、長期的かつ包括的に評価していくものになっていきます。

可視化のためのフレームワーク

開発生産性の可視化を進めるにあたり、エンジニアメンバーからの反発が起きることもあります。過去の成功体験や現状維持バイアスなどから生じるもので、例えば「自分の業務が監視されているように感じる」という反応があります。そこから「自分の業務がどれだけできているのか、チーム内での認識を揃える」という意義にコンセンサスを得ていく必要があるのです。

具体的な指標として、本書ではFour Keysについて紹介されています。4つの指標に関して、本書の記載をまとめます。

1 デプロイ頻度：新しいコードがリリースされる頻度。主に開発チームの効率性を表している。
2 変更のリードタイム：コードの変更が行われてからデプロイされるまでの時間。主に開発チームの敏捷性を表している。
3 変更失敗率：デプロイ後に、障害や問題が発生する割合。主にリリースプロセスの質を表している。
4 平均修復機関：障害が発生してからサービスが復旧するまでの平均時間。主にシステムの回復力と問題解決の能力を表している。

4つのうち、肝となるのがデプロイ頻度であり、特にプルリクエストの粒度が関連します。粒度が粗すぎると一つの修正規模が大きくなりすぎ、レビュー効率の悪化や手戻りが増える傾向があり、その逆に粒度が細かすぎるとレビュー依頼の量が増えすぎて効率が悪化します。開発の単位を適切な大きさに分けることが、開発生産性を高める上で重要なポイントだと言えそうです。

LLMによる開発生産性の向上

これからの開発生産性の向上を考えるに当たり、生成AIの中核となるLLMを中心としたAIの進化は避けて通れないトピックです。開発生産性に影響を与えうるサービスは様々あるでしょうが、ここでは本書でも紹介されているChatGPTとGitHub Copilotについて紹介します。

ChatGPTは様々な媒体で紹介されて、世界的な流行を巻き起こしましたので、ここでは深くは触れません。例えば開発する機能の要件をChatGPTに入力することで、実装のアプローチのヒントが得られることや、様々な選択肢の比較・検討が行えます。また、既存のコードの説明を求めると、どのような動作が行われるかを平易な文章で説明してくれます。

GitHub Copilotでは、今までのコードや記載したコメントからまだ書いていないこの先のコードを自動生成する機能があります。コードの改善案を求めると、より簡潔で効率的なコードを提案してくれます。それらの機能により、コード実装の効率化やコードレビューの高速化が実現できている実例が多く報告されています。

このようにLLMの活用を組織的に促し、必要な訓練等を行うことで、現時点でも開発生産性の向上が図られます。今後LLMがより進化した際には更なる効率化ができるでしょう。

AIの時代だからこそエンジニアはより重要となる

AIの進化が進む時代において、エンジニアの可能性はどう変わるのか、様々な意見があります。一説ではプログラミングはAIができるようになるので、人はほとんど必要なくなると言われています。

ただ、私自身はE資格というAIのプログラミング資格を取り、自社で運営するサービスでもAIの活用を進めていく中で、今後はエンジニアの生産性がもっと上がり、世の中に提供する価値が高まることを想像しました。また、今までは一部の人が抱えていたノウハウがAIの学習を経て多くの人に解放されるため、プログラミングができる人も広がり、今後はさらにエンジニアが世界を動かすようになっていくように思います。

企業の運命を左右するほどに重要性が増したエンジニアチームが、持っているポテンシャルを発揮するために、様々なレベルの開発生産性を大切にすることは経営においても重要になります。

本書の内容はエンジニアやそのマネジャーだけでなく、事業を担う人も理解しておくと、これからのビジネスシーンでより活躍できるでしょう。幅広い読者にぜひ手に取っていただきたい一冊です。