EMConf JP 2026 開発生産性と言う時に本質的に目指すところは事業生産性である。それを如何に解剖するか

GMOペパボのエンジニアとして、EMConf JP 2026に参加してきた。

特に印象的だったのは、EMの仕事を「カネ」の観点から捉え直す以下のセッションだった。

speakerdeck.com

これまで私はチームビルディングや採用・オンボーディングなどの「ヒト」の部分、そしてスクラム開発の中で何を作るかやどのように作るかの「モノ」の部分について意識して扱うことはあったが、「カネ」の部分については苦手意識があるのか、あまり意識して扱えてこなかった自覚がある。

この発表で改めて「ヒト・モノ・カネを戦略的に活用し事業を成功へ導く」ことがEMの1つのお仕事なんだろうなと理解した。

そして、この発表を聞いて、これまで苦手意識のあった「カネ」の部分についての勘所を教えてもらうことができた点で、とても印象に残ったのだ。

開発生産性上げたい!ん、開発生産性ってなんや

開発生産性を上げたい、となったときに、本当の意味するところは「事業生産性」を上げたいということである。例えばPRの量が3倍になっても事業活動の成果が横ばいであるのならば、それは私たちの望むところではない。(むしろ生産性は下がっている?!)

以下のスライドでいうところの、「レベル3生産性」が最も私たちの志向するところである。

開発生産性について議論する前に知っておきたいこと

https://speakerdeck.com/onecareer_tech/kai-fa-sheng-chan-xing-dehanaku-shi-ye-sheng-chan-xing-kosogaben-zhi-roicdeniu-jie-ku-kai-fa-no-jia-guli-nozui-da-hua?slide=26

 

ではいかにして事業生産性を上げられるのか。発表ではROICという観点から、その構造を捉え直していた。

ROIC: Return On Invested Capital

ROICとは、Return On Invested Capitalの略称で「ロイック」と読みます。企業と債権者(銀行など)から調達したお金に対して、どれだけ効率的に利益をあげることができたかを測定する財務指標です。日本語では投下資本利益率と言われます。

ROICとは? メリットやROE・ROAとの違いとは? |転職ならdoda(デューダ)

 

簡単にいうと、ROICは、投下したリソースに対してどれだけの利益を生んだかを示す指標らしい。これを因数分解すると、EMが日々確認すべき具体的な項目が見えてくる。

https://speakerdeck.com/onecareer_tech/kai-fa-sheng-chan-xing-dehanaku-shi-ye-sheng-chan-xing-kosogaben-zhi-roicdeniu-jie-ku-kai-fa-no-jia-guli-nozui-da-hua?slide=30

https://speakerdeck.com/onecareer_tech/kai-fa-sheng-chan-xing-dehanaku-shi-ye-sheng-chan-xing-kosogaben-zhi-roicdeniu-jie-ku-kai-fa-no-jia-guli-nozui-da-hua?slide=31

分母である投下資本の中に、基本的にソフトウェアエンジニアが日々向き合っている無形固定資産(ソフトウェア)が含まれていて、資本的支出(CAPEX)という。

また、分子である税引後営業利益の要素の中に、人件費やインフラ費など事業運営に関わる事業運営費(OPEX)がある。

今と同じかより少ない資本の投下で、より大きな利益を出すことができれば、ROICは上げられそうだ。

分母である投下資本を下げる営みとは。例えばこんなものか

開発コストの削減
  • マネージドサービスの利用 — インフラの構築・運用を委ねる(RDS, Cloud Run等)
  • コード生成・AIツールの活用 — ボイラープレートや定型作業を自動化する。AIによるコードレビュー
  運用コストの削減
  • CI/CDの整備 — デプロイ・テストの手作業を排除する
  • Infrastructure as Code — 環境構築の再現性を担保し、属人化を防ぐ
  • サーバーレス・従量課金型アーキテクチャ — 使った分だけ払う構成にする
人的コストの削減
  • ドキュメント・ADRの整備 — オンボーディングコストや意思決定の再議論を減らす
  • 自動テスト — 手動QAの工数とリグレッションの修正コストを下げる
  • リファクタリング — 技術的負債の利子(変更コスト増大)を抑える
  • 認知負荷の低減 — シンプルな設計、明確な命名、適切なモジュール分割
  失敗コストの削減
  • カナリアリリース・段階的ロールアウト — 障害の影響範囲を限定する
  • ブルー/グリーンデプロイ — 切り戻しを即座に行えるようにする
  • フィーチャーフラグ — ロールバックコストを下げる

分子である税引後営業利益を上げる(つまり発生する事業運営費を下げる)営みとは。例えばこんなものか

  • lambdaやEC2をamdからgraviton化する
  • 過剰にpodが立っているためmax podsを下げる
  • CloudWatchに吐いていたクエリログをS3に引っ越す
  • スロークエリやN+1の解消
  • etc...

終わりに

何事も、考え方のフレームワーク・パターンというのは大事で、それらは大抵もう既に人生の諸先輩方が作ってくれているので素直に学ばせてもらおう。

EMConfは初の参加だったが、結構カネに焦点を当てたセッションが多く、大学時代を思い出すぐらい、たくさん知らないことを学ばせてもらった。登壇者の皆さん、参加者の皆さん、そして何より運営された皆さん、大変ありがとうございました。