なぜ開発生産性は部門で隔たりがあるのか

牛窪：私たちは国内最大級のビジネスチャット「Chatwork」を開発・提供しています。業界のパイオニアとして国内利用者数No.1を誇り、（Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。）導入社数は91.4万社（2025年3月末時点）を突破しています。

これまでは、チャットをコミュニケーション手段のDXとして中小企業様に提供してきました。今後はチャットを経由して、ビジネス上発生する様々な業務を私たちが請け負い解決していく、いわゆるBPaaS（Business Process as a Service）の領域を目指しています。



本題に入ります。なぜ開発生産性が部門を超えて理解が進まないのでしょうか。

私たちがよく使うFour Keysなどの開発生産性指標は、エンジニアチーム内での健康度や技術的パフォーマンスの測定に重点を置いています。一方、他部門やビジネス職観点で重視されることの多い指標は、売上や利益により直結した目標やKPIが設定されるケースが多いように思います。

この2つの指標体系には、根本的な違いが存在します。

まず、時間軸の違いです。開発チームはスプリント単位での短期改善サイクルで指標を見るのに対し、ビジネス側は月次、年次、さらには2〜3年の中長期で株主に向けた成果を重視します。

次に、言語の違いです。生産性指標は他部門にとって理解が困難な技術概念である一方、ビジネス指標は金額として表現されるためシンプルで理解しやすい特徴があります。

最後に、成功基準の違いです。Four Keysでは速度や品質の向上が成功基準となりますが、ビジネス職観点では売上・利益への直接的な貢献度が重視されます。

広木大地さんが提唱する生産性レベルの図表を参考にすると、レベル1に相当するエンジニアの活動と、レベル3以上に該当するビジネス価値・指標との間には、明確な部門を跨ぐ壁が存在しています。



組織規模が拡大するにつれて、「エンジニア組織は本当に成果を出しているのか」という疑問が経営層から提起されることもありうるのではないでしょうか。この課題を解決するためには、新たなアプローチが必要です。

この壁を突破するには、部門間の「言語の翻訳」が不可欠です。技術的な成果を事業的価値に変換し、相互理解可能な共通言語と指標の設計が求められます。そこで本日は、部門間の共通言語と指標をどのように連携・解釈していくかについてお話しします。

部分言語の理解と構築

他の部門や経営が持っている数値・指標を皆さんは理解しているでしょうか。これは当たり前のことのように思えますが、私にとっても発見が多くありました。

まず重要なのは、各部門のKPI・経営数値を徹底的に確認することです。決算資料やIR資料で追っている数値、部門別レポートや課題意識、経営指標やプロダクト上のKPIなど、そういったものはいくつか共有されていると思います。

しかし、マネージャーである私でも、これらを本当に知っているかというと難しいところがあります。共通言語をまず作っていく上で、こういったところを確認していく必要があると考えています。

重要な観点は、「数値を見つけました、理解しました」だけではなく、「なぜその数値が大事なのか」「それがどう測定されていて、誰がどの部門がオーナーシップを持っているのか」というところまできちんと理解していくことです。後の共通言語構築の成功を決める重要な要素となります。



次に、私たちの場合、どのような取り組みを行ったかご紹介します。

まず、部門別にヒアリングを実施しました。エンジニアやEMに対しては「生産性指標をどうやって使っていますか？」「どういうものを測っていますか？」「どうやって測っていますか？」といった質問をしました。すると各部門で全く違う回答が出てきました。

プロダクト部門や事業管理部門には「実際エンジニア組織ってどう見えていますか？」「今後プロジェクトを改善していくために、私たちの組織はどう振る舞うのがよいでしょうか？」といった話をしました。

最後に経営層とも1on1を実施し、「エンジニア組織が実際どう見えているのか」「何かうまく連携できることはないだろうか」といった点についてお話ししました。

決算資料等も詳細に確認し、経営上のダッシュボードやエンジニアがよく使っているダッシュボードを調査しました。弊社ではFindy Team+もよく活用しています。

調査の結果、重要視しているのは売上高・利益・EBITDAであることが分かりました。KPIとしてはARR（年間経常収益）、登録ID数、課金ID数、ARPU（課金IDあたりの平均単価）を追っていることが判明しました。

営業利益を単純に分解してみました。売上 - 費用 = 営業利益という構造です。エンジニアの活動がどう関わるのかを厳しく見させてもらったところ、直接的には売上に関与しづらいという整理をしました。

ただ一方で、費用の削減は可能です。例えば筋肉質化と言われるようなシステム費用削減や、データベースリプレースによる費用削減などです。しかし、これは確かに必要なことですが、ずっと続けられるわけではありません。人が増えてプロジェクトも大きくなってくると、ある程度は許容しなければならない部分があります。



別の軸を探した結果、EBITDA（営業利益 + 減価償却費）とソフトウェア資産計上の関係性を発見しました。

SaaS企業として、開発にかかった費用のうち一定の要件を満たすものを「ソフトウェア」として無形固定資産に計上できます。計上されたものは何年にもわたって減価償却されていきます。

つまり、エンジニアが資産計上しうるプロダクト開発をしていくことによって、EBITDAが増えていくという構造です。これにより、経営指標に直接貢献できることが分かりました。



私たちの場合はこのようなアプローチで部分言語を作りましたが、皆さんの場合はどういう数字を追っているのかを確認していただきたいと思います。エンジニア組織の指標だけでもよいですし、経営や他部門、プロダクトが追っている指標が何なのかを改めて見ていただければと思います。

分からないことがあれば1on1で聞いてみたり、資料を掘り出して見るだけでもよいのではないでしょうか。

そこから、実際にアウトプットをどんどんしていってほしいと思います。【誰が】→【何をしたら】→【結果こうなる】という簡単なテンプレートでも構いません。

例えば、

• 【エンジニアが】→【新規施策を開発したら】→【結果EBITDAが向上する】
• 【エンジニアが】→【DBリプレイスしたら】→【結果費用が削減される】

このような関係性をどんどんアウトプットしていくことで、部分言語の構築を進めていきました。

共通言語の設計

ここまでで作ったものを整理してみましょう。経営・他部門向けの部分言語として、エンジニアの活動がどの指標に結びつくものなのかという言語化と知識があります。一方で、エンジニア向けの部分言語として、開発生産性指標（Four Keys）などがあります。

しかし、課題はまだ分離したままで、2つの部分言語がつながっていません。解決策として架け橋を作る必要があります。



そこで、私たちの場合は相関マップを作成しました。これまでの部分言語の組み合わせを使いながら、実際このエンジニアの活動が経営上の数値にどう結びつくのかをひたすらつなげていきました。その上でそれぞれその活動や追っている数値が、誰がオーナーシップを持っているかというところをマッピングしたのが、この相関マップです。

こういった生産性をどうやって事業価値に実際に変えていくのかという話は本当に正解がないと思います。それぞれのアプローチがあってよく、大事なのは、いかにそれから仮説を出していくか、そこに対していかに対話を重ねていくかです。

相関マップにより各職能ごとに何がねらいなのかが見えてきました。経営層はどれだけEBITDAを増やせるかを重視し、CTO/CPOはどれだけ資産計上できる施策を「フロー効率で」積み上げられるかを見ています。PdMやEMはどうやってロードマップ通り積み上げていくか、どれだけ効率的にその施策を完了できているかを考え、エンジニアはどれだけその施策に割り当てられた工数・チケットを効率的に開発して、プルリクエストでマージしていくかに注力しています。



これにより、EBITDAを高めていくというところで一本線が引けると思いました。全職種の人がフロー効率でリードタイムを短く、この資産計上できそうな施策をどんどん積み上げていけるかというところに寄与できれば、それは全職種の人たちが望むことだし、それがビジネス上の成長につながることだという形で整理しました。

私たちの場合は工数というところを中心に組み上げました。施策が始まった時に、施策ごとにメンバーがアサインされ、その人たちはそれぞれ能力は違うかもしれませんが、例えば一日の時間の6割くらいは施策開発をしているという稼働率を把握できます。

そういったものがどんどん積み上がっていくと、本当に原始に立ち返れば工数をどんどん積み上げていって、それが施策が完了しそうな工数に達した時に、そこを全部満たすことができれば、プロジェクトは完了し、そこまでの開始と終了がリードタイムであるという整理をしました。

もちろん、これは開発プロセスや施策の種別によって違います。プロセス間の依存関係（要求要件定義がないと設計に移りづらいなど）や、施策の種別による違い（新しいものを作るものは比較的どんどん積み上げられるが、既存機能をリプレースする場合は技術負債により時間が延びる）があり、企業のフェーズやプロダクト戦略によって重要度が変わります。



そういったような共通言語を、ぜひ皆さんの中でも作っていけたらよいのではないでしょうか。大事にしたいのが、これまで作った部分的な言語をいかにして見える化していくかというところです。それが今の段階で正しいもの、精緻なものじゃなくてもよく、そこから対話を重ねていく仮説ベースで作っていくことが大事です。そういった対話を通じていけば、それはやがて共通言語になっていくと思います。小さく始めてよいと思います。

共通言語から指標化

指標を作成する際の重要なポイントをお話しします。

まず、これまで作ってきた可視化や共通言語の部分と整合性が取れる指標設計である必要があります。指標が取得できないものもありますし、指標は正しそうに見えるが可視化する過程で見えてこなかった場合は、そもそも可視化した設計方針に問題があるかもしれません。漏れがある可能性もあるため、相互に検証していく必要があります。

次に、指標から何を期待し、誰がどのような行動に落とし込むかが想像できることが重要です。指標が悪化した際にどのような行動ができるかが浮かばなければ、ただ数字が並ぶだけになってしまいます。一方で、何をするかは分かっているが誰が実行すべきかが不明な場合、その数値は改善されません。このような点を重視する必要があります。

最後に、精緻なものを作りがちですが、いきなり多くの指標を作成する必要はありません。全てのビジネス指標と全ての開発生産性指標を結びつける必要はなく、一部のものからストーリーとして開始し、段階的に拡張または縮小していくアプローチが適切です。



私たちの具体的な指標設計と追跡している数値をご紹介します。

基本構造として、工数を使って施策を実施するというシンプルな整理を行いました。施策あたりの工数を継続的に測定することで、種別や施策によって違いはあるものの、平均化すると効率化の進展や遅延の原因が傾向として把握できます。ただし、工数という指標には注意が必要です。1人当たりの平均工数は人数で算出できますが、単純に人員を増やせば解決するわけではありませんし、残業時間を増やして平均工数を向上させることが正しいアプローチとは限りません。指標だけを見るのではなく、関連する数値も含めて総合的に確認しています。

EBITDAの目的に立ち返り、現在は月次でいくつかの指標を取得しています。まず、EBITDAを満たすための金額に達しているか、資産化された金額が想定していたEBITDAの数値から算出できる金額の割合になっているかを確認しています。この割合を高めるためには、施策を継続的に実施していく必要があります。

低い割合であっても、莫大な工数を使用してそれが資産計上できるものであれば問題ありません。重要なのは、当初想定していたプロダクトロードマップ通りに実行できているかという点です。このような観点から、実際の施策の種別も記録しています。新規開発なのか、成長系の施策なのか、運用保守なのかを分類し、施策完了時にそれを計上しています。

施策の実施割合を高めるには、個々の施策にかかる時間を短縮することと、施策数を増やすことの両方が必要です。施策があまり実施できていない場合、どこかの施策で遅延が発生しているか、そもそも十分な数の施策を実行していない可能性があります。この2つの要因を追跡しています。

リードタイムに関しては、プロセスごとに分類が可能です。要求要件定義、開発、QAなどのプロセスを整理し、各ステップの時間を測定しています。これにより、施策実行時のボトルネックを特定できます。エンジニアの作業もこのプロセスに含まれるため、変更リードタイムに反映されるという整理をしています。

施策数については、デプロイ頻度を重視して追跡しています。

このように、ビジネス指標と開発生産性を繋ぐ要因を整理し、それを改善するためのアプローチを明確化しながら、最終的にFour Keysの一部と結びつけています。重要なのは、要因を段階的に深掘りできる指標設計にすることです。



例えば、リードタイム短縮のためにはプロセスのボトルネックを見つけて改善し、そのためにエンジニアができることをFour Keysの数値を見ながらコードレベルで対応していく、という一連のブレークダウンしたアプローチを可能にする接続の設計方針が重要となります。

その後の注意点

共通言語と指標を構築した後も、継続的な運用において重要な注意点があります。私たちもまだ改善すべき点や抜けているロジックが存在するため、実際の運用で見えてきた課題をお話しします。



まず、因果関係が曖昧になることがあります。共通言語と指標を作成しても、その仮説と検証をセットで継続的に実行しなければ、特に相関関係として整理した場合に、因果関係が不明確になる段階が訪れます。

特に重要なのは、こういった指標には遅効性があることです。遅れて現れてくる性質が非常に強いのです。例えば、技術的負債を解消してデプロイ頻度が向上したとしても、その負債解消の効果が次の施策で同様に活用されるとは限りません。このような改善がどのように価値に現れるかは、時間を置いて発現する特性があります。

次に、抽象化と数値化のバランス感については、組織内でコンセンサスを形成しながら決定していく必要があります。言語だけでは曖昧になってしまいますし、一方で指標だけを追求しても独り歩きしてしまう危険性があります。

重要なのは、その言語と指標がどのように活用されるのかというコンテキストもセットで共有することです。これがなければ形骸化してしまいます。また、生産性指標の議論は合理的な判断に偏りがちですが、組織に属する以上、信頼関係や文化といった数値化困難な要素も重要です。これらの価値も尊重しながら進めていく必要があります。

最後に、小さく始めることの重要性を強調したいと思います。仮説が間違っていれば、それを修正して新しいものを作り直せばよいのです。

生産性は育てていく「生きた言語」

今日は、どのように開発生産性を部門間の共通言語・生産性指標とつなげ昇華させていくかについてお話しました。



やはり大事なのは、こういったものは数値が悪いから責任を追及するとか、数値が良いから監視を強化するという話ではないということです。一度作って終わりでもありません。対話を通じて改善し続ける「生きた言語」として取り組んでいただきたいと思っています。

皆さんが言語を話す上でも、死語が出てきたり、新語として流行語が生まれたりしますよね。同様に、こういった指標の話も、対話を重ねながら部門間の信頼関係を構築し、数値による説明責任を果たしていく必要があります。

本日お話しした3つのステップ、部分言語の理解と構築、共通言語の設計、そして指標化を通じて、皆さんの組織でも開発生産性を組織全体の生産性向上に結びつける、その一歩を一緒に踏み出していただければと思います。ご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です