【エンジニアリングとビジネス】：エンジニアリング力からビジネス価値を生み出すまでの生産性について整理する
こんにちは。
PharmaXエンジニアリング責任者の上野（@ueeeeniki）です！
今回はついに、エンジニアの生産性について整理をしたいと思います。
【エンジニアリングとビジネス】シリーズ第3段です。
ソフトウェアエンジニア界隈で何度も議論になる「開発生産性」「エンジニアの生産性」。
もはや安易に触れると怪我をする話題と言っても過言ではありません。
しかし、『【エンジニアリングとビジネス】：エンジニアチームの力とビジネス価値の関係性を紐解く〜『CTOの頭の中：技術を財務で表現する』から考える』で議論したようにエンジニアチームの生産力からビジネス価値が生み出されるまでの段階を整理すれば、生産性の議論も非常に見通しが良くなります。
2022年のアドベントカレンダーで話題になった広木さんの『開発生産性について議論する前に知っておきたいこと』という記事の中で広木さんが展開していたレイヤーという概念と、私が記事の中で展開している生産段階の概念が上図のようにきれいに一致しているので、対応付けて整理したいと思います。
なぜ開発生産性の議論に注意が必要なのか
広木さんの記事でも述べられていますが、私たちが「生産性」と言葉を使うときにどの部分の生産性なのかによって意味が大きく異なってしまうからです。
議論している者同士でも本当に同じ意味で使っているのかが怪しくなりがちです。
生産性=アウトプット/インプット
であり、インプットとアウトプットに何を入れるのかで生産性の意味合いが大きく異なってしまうのです。
そこで、開発生産性を考える上では3つのレイヤーをきちんと区別して議論することが重要です。
プロダクト開発のレイヤーが見やすいように全体図から、プロダクト開発のみを抜き出したのが以下の図です。
それぞれのレイヤーについて詳細に説明します。
開発生産性のレイヤー構造
レイヤー1：仕事量の生産性
レイヤー1の生産性は、シンプルにどれだけの生産物を生み出しか？を表しています。
書けた工数に対して、どれだけのコードやプルリクなどを生み出したか？という指標です。
エンジニアチーム内に閉じた生産性であるといえるでしょう。
レイヤー2：期待付加価値の生産性
レイヤー2の生産性は、プロダクト資産をどれだけ積み上げ、負債をどれだけ減じたか（＝どれだけの純資産を作ったか）を表しています。
このレイヤーの生産性を評価するのは難しく、現実的にはリリースした機能がどの程度プロダクトの価値を高めたのかを評価するには時間がかかります。
広木さんの言葉を借りれば、プロダクトチーム全体で価値があると「期待している」施策がどの程度リリースできたのかに注目することで、プロダクト開発に関する効率の良さやコストパフォーマンスの良さを評価するしかありません。
また、単純に資産を積み上げたと思っても同時に負債も積んでいるのが常であり思っているよりも純資産（＝資産−負債）は増えないため、より正確に捉えるのは難しくなります。
ここは、プロダクトチームの生産性であると捉えることができます。
レイヤー3：実現付加価値の生産性
レイヤー3は、売上やKPIなどの実際の成果・パフォーマンスを評価するレイヤーです。
つまり、かけた工数や人件費に対してどれだけのビジネス価値が生み出されたのか？で生産性を考えます。
当然、この生産性はプロダクトチームだけではなく、マーケティングチームやオペレーションチーム、営業チームなど事業部全体の活動成果として実現されます。
つまり、インプットとしてもエンジニアの工数や人件費だけを含めても仕方がなく、事業部内のさまざまなチームの工数や人件費を含めて議論しなければ意味がありません。
かなり複雑である上にどうしても遅行指標になるため、評価が最も難しい生産性になります。
レイヤー1からレイヤー3までの生産性を区別して議論することが重要
レイヤー1からレイヤー3の生産性とアウトプットの対応をまとめると下図のようになります。
レイヤー1では、エンジニアが効率的な開発環境を構築できているか？デリバリーを妨げる要因が排除できているのか？などが影響を与えるファクターとなります。
レイヤー2では、プロダクト開発の優先順位が正しく付けられるかが重要です。また、そのタスクを無駄に負債を生むことなく完了できるかなども指標となります。
そしてレベル3では、そのタスクが実際にビジネス価値をどの程度生み出しているのか？が指標になります。
レイヤーを区別しない生産性の議論は混乱のもとです。
話している人のポジションによっても、どのレイヤーを重視するかが異なってしまい、無駄な対立を生み出してしまうかもしれません。
組織全体でレイヤー構造を意識した議論を行いましょう。
経営者であるCTOの仕事は、もちろん最終的にはレイヤー3の生産性を高めることですが、ただ漠然と最終的な生産性を高めようと考えても難しいのが常です。
レイヤーが高くなればなるほど、エンジニアチームだけの問題には閉じなくなっていくため、さまざまな部門を巻き込んでいく必要も出てきます。
そのため、比較的取り組みやすい下位のレイヤーの生産性向上から取り組むことも重要です。
一方で、下位のレイヤーに取り組んだだからといって、最終的なビジネス価値が生産性高く生み出されるとは限らないのもまた事実です。
自分たちが行っている生産性向上施策がどのレイヤーの生産性向上に寄与しているのか？を常に捉えることが重要です。
生産性のレイヤー構造はプロダクト開発だけではなく、育成・採用活動などにも存在する
下図のようにレイヤー構造が存在するのは何もプロダクト開発だけではありません。
エンジニアが工数を使って生産活動を行っている以上、育成・採用系の活動にもレイヤー構造が生じます。
プロダクト開発と同様にレイヤーが上がれば上がるほど、エンジニアチームだけで閉じなくなっていきます。
最後に
今回は開発生産性のレイヤー構造について解説しました。
何度も申し上げているように、レイヤー構造を意識しない生産性の議論は危険です。
議論を行う前にきちんと生産性の定義について認識をすり合わせた上で、議論を行いましょう。
また「開発生産性を上げたい」と漠然と考えるのではなく、どのレイヤーの生産性をなぜ、どのようにして上げていくのか？についてきちんと考えましょう。
開発生産性を高めたいと思っているCTOや経営層の方の思考整理に少しでも役に立ったら幸いです！
いつでもご連絡ください
もし今回の生産性の整理についてやその他マネジメントのことについてより詳しくディスカッションしたいという方がいらっしゃれば、YOUTRUSTまたはTwitter DMからお気軽にご連絡ください！
この記事が気に入ったらサポートをしてみませんか？