「開発生産性」が経営層に伝わらないのは、言語が違うから
開発生産性の議論がうまくいき始めても、次に石垣氏が直面したのは「開発者だけでなく、事業責任者や経営層にどう説明するか」という重圧だった。
開発案件のリードタイムを分解すると、実は開発フェーズそのものより、その前の要件定義や後工程のQAに時間がかかっていることは少なくない。エンジニアはFour Keysや1人あたりのスループットを見るが、EMやPMはそれを工数というコストとして見て、事業責任者であるPMがそれを金額に変換する。経営層に至っては、PLやバランスシートといった財務会計の言葉でしか物事を捉えない。
同じ「開発生産性」という言葉でも、レイヤーごとに測っているものも、使う言語もまったく違う。だからこそ、Four Keysのデータを無理に経営指標へ飛躍させれば机上の空論になる。
一つひとつ丁寧に翻訳していく地道な作業こそが、開発生産性の議論には欠かせないと石垣氏は強調する。
DMM.comでは実際、下図のような構成でモニタリングしている。このモニタリングでチームパフォーマンスを可視化する一方、勤怠から得られる工数データや金額、資産価値、減価償却といった管理会計・財務会計のデータをすべてBigQueryに集約し、Lookerやスプレッドシートで接続して見られるようにしている。
プロジェクトごとの工数と担当者の単価から算出したコスト、チームの等級や雇用形態、採用・育成計画までを一つの「ヘルスチェックレポート」としてつなぎ合わせることで、プロジェクトが遅れている本当の理由（負債の蓄積なのか、チームのスキルなのか、予算や採用の制約なのか）が初めて見えてくるという。
AIのコストについても、単なるツール費ではなく人材管理費として捉え直す視点を石垣氏は示す。月100万円の単価のエンジニアがAIコストを使えば、実質的には200万円の単価を持つ人材として見なすべきだという発想だ。
標準化という重圧に抗い、自分たちで指標をつくるチームへ
物語の終盤では、うまくいったチームの取り組みを全社標準にできないかという問いが浮上する。しかし石垣氏は、Four Keysの測り方をトップダウンで標準化することには慎重だ。プロダクトの性質もチームの技術レベルも異なる以上、同じ数字を当てはめて比較することにあまり意味はない。1年前に自分たちが嫌っていた「数値だけを追う組織」を、標準化の名のもとに再現しかねないからだ。
広げるべきは指標そのものではなく、学習速度や適応力だと石垣氏は語る。外部から与えられた指標を監視・管理のために追うのではなく、自分たちがユーザーに価値をより早く届けたいという内発的な動機から逆算して、チーム自身が指標をつくる。
重圧からの脱却とは、重圧そのものがなくなることではなく、レイヤーごとに異なる言語を翻訳しながら判断できるようになることだ。数字を超えた価値、すなわち負債の返済、育成、説明責任を評価に組み込んでいくこと。
それこそが、誤解だらけの開発生産性から一歩抜け出す道だと、石垣氏はセッションを締めくくった。
