昨今と言わずここ数年エンジニア界隈で「開発生産性」というワードをよく目にする。役割上、これは必ず意識しなければいけないし、毎年チームの生産性が同じという訳にもいかず、今年が10なら、来年は20、再来年は、、、とチームもしくは会社の生産性向上を行わなければいけないのである。（つまりチームメンバーのスキルアップ、開発体制や環境の整備、高い目標を達成するためのチーム作りをする必要がある）
ただ、「開発生産性」というのはエンジニア視点だけではなく、ビジネス側から見た視点での評価も必要であり、とても議論が難しい。また役割によって見えている（見ている）フィールドが違ったりするので開発生産性が高い状態とは何かチーム全体（ましてや会社）で理解することのハードルは高い。
さらに「この指標が高いから開発生産性が高い」と言える指標もないと思う。（「Four Keys」の評価が高い（エリートやハイ）状態であったとしても、それだけで開発生産性が高い状態と呼ぶのは無理があると考えている）
これが共通理解を持ちにくい最大の原因だと思う。
あとは「開発生産性が高い」=「開発スピードが速い」と勘違いしてしまう人も多い。確かにそれもあるが、必ずしもそうではないと思う。
ではどうする。
広木さんのブログ『開発生産性について議論する前に知っておきたいこと』にあるように「開発生産性の3階層」を区別するをまずやっていく。それぞれのレイヤーで「開発生産性が高い」状態を定義していきたい。
レベル1：仕事量の生産性
一段階目が、仕事量の生産性です。これは、その仕事の価値や売上貢献などはいったん置いておいて、作業量としてどの程度の仕事をこなすことができたのかを評価する生産性です。仕事量の生産性が十分高くても、レベル2以降の生産性が高いとは言えませんが、少なくとも作業の効率が悪いというわけではないことを評価するために使います。これは、一開発者やエンジニアリングチームでも改善がしやすいため、まずはこういった生産性に注目することが多いです。
レベル2:期待付加価値の生産性
二段階目が、期待付加価値の生産性です。これは、仕事量だけではなく個々の施策がどの程度プロダクトにとって価値があることなのかを踏まえて評価したい場合に使います。しかし、現実的にはリリースした施策にどの程度の価値があったのかを評価するのには時間がかかります。そのため、プロダクトチーム全体で価値があると「期待している」施策がどの程度リリースできたのかに注目することで、プロダクト開発に関する効率の良さやコストパフォーマンスの良さを評価する為に使います。この点は、施策を考え決めていくプロダクト開発組織全体のアウトプットを評価することに用いることができます。
レベル3：実現付加価値の生産性
三段階目が、実現付加価値の生産性です。これは、売上やKPIなどの実際のサービスに対しての貢献を評価するときに用います。この生産性は、開発チームやプロダクト開発組織だけでなく、カスタマーサクセスやセールス、マーケティングなど事業に関わる様々な部門の全体の貢献によって実現されます。多くの場合、遅行指標になるため、最終的な判断には使うことができますが、リアルタイムな評価には不向きです。
大体のエンジニアが話す「開発生産性」はレベル1の話をするけど、管理職や経営陣は全てで話しをしている。これが上述している「議論が難しい」の正体でもある。（人件費の話など、全員にできない話しはあるけど）
ちなみに「開発者体験が良い」とは、エンジニアが働きやすい・開発しやすい（レベル1）、という意味ではなく、レベル2にエンジニアが積極的に介入できる状態のことだと自分は思っている。（日本CTO協会の理事の方のブログ、読んでみてほしい）
まずはレベル1、このレイヤーで開発生産性が高いを定義して、レベル2を達成できるようにする。レベル2やレベル3はエンジニアチームだけでコントロールできない項目を含んだ目標設定をしなければいけないので評価基準の定義が重要になるので気をつける必要がある。
新規プロジェクトから始めてみるかな。
*参考
興味があれば長いけど、広木さんのブログも読んでみてほしい。広木さんの著書『エンジニアリング組織論への招待』や各ブログ記事はマネージャー職・目指す人は必読だと思う。
「Four Keys」を知らない人は読んでみてほしい。
「付加価値」が何かわからない人は読んでみてほしい。