事業価値と Engineering 2026年度版

2026年度リクルート エンジニアコース新人研修の講義資料です。

1. 事業価値と Engineering 2026年度版 黒田 樹
2. 自己紹介 株式会社インディードリクルートテクノロジーズ プロダクトディベロップメント2ユニット Vice President 黒田 樹 FFS : A凝縮性3, B受容性8, C弁別性15, D拡散性8, E保全性12（CE） ▪経歴 2004年 大手SIer 新卒入社 2011年 株式会社リクルート 入社 2018年 株式会社リクルートテクノロジーズ エンジニアリング部 部長 兼 株式会社リクルートジョブズ 2019年 株式会社リクルートテクノロジーズ HR領域エンジニアリングユニット 執行役員 オフショアソリューション部 部長 兼 株式会社リクルートジョブズ 兼 株式会社リクルートキャリア 2021年 株式会社リクルート アプリケーションソリューションユニット Vice President 2025年 株式会社インディードリクルートテクノロジーズ プロダクトディベロップメント 2ユニット Vice President Sierにて官公庁系システムのエンジニア、アプリケーションアーキテクトとして従事。 2011年リクルートに入社。新規事業の企画・開発を複数経験。その後、既存事業の HR領域へ異動。HRの内製エンジニア組織 をマネジメント。2021年からはオフショア部隊や社内フレームワーク開発を行う部隊等含め、リクルートの横断エンジニア機能組 織を担当。現在は、HR領域のエンジニアリングを担当。 ▪趣味 システム開発。 ・2015年 Developers Summit ベストスピーカー（総合1位、ベストバリュー賞、公募賞） ・Developers Summit 実行委員 2018/2019/2020 ・2022年 Developers Summit 公募賞（平均満足度1位） ゲーム、バイク、車
3. 実は、、、、コードと、事業価値は一致しない では、コードと事業価値は、どうつながっているのか。 ・何が事業価値に意味があるのか ・何が事業価値に意味がないのか ・何を速く作るべきなのか ・何を作らないべきなのか ・作ったものを、どうすれば価値として持続させられるのか AIによって作ることが速く安くなる時代ほど、この問いの重要性は上がる。
4. 生産性ぽいもの。「パ」ってなんだ？？？ 高速で新機能をリリース しまくっている。 生産性は高い？低い？
5. 生産性ぽいもの。「パ」ってなんだ？？？ 高速で新機能をリリース しまくっている。 生産性は高い？低い？ ただ、ほとんどの機能が まったく使われていない。 生産性は高い？低い？
6. 事業はプロダクト単体では成立しない 事業価値は、プロダクト単体ではなく、ユーザー、クライアント、営業、マーケティング、運用を含む事業シ ステムの中で発生する。だからEngineeringは、コードだけでなく、価値が発生する構造を理解する必要 がある。
7. 価値が創出される経路が、開発スタイルを決める 同じプロダクト開発でも、価値化の経路が違えば、最適な開発の進め方も変わる。 ・ユーザー行動で検証できるものは、小さく速く試す（アジャイルとかいわれたりもする？なんか違いそう） ・営業、業務、顧客合意を伴うものは、事前に揃えて計画的に作る（ウォーターフォールっていわれる？でも違いそう） 重要なのは、開発手法の名前ではない。どの進め方が、事業価値を最大化するかである。 求人情報の出向枠の追 加や掲載期間、掲載形 式等の商品そのものに 関する開発 →計画的、硬め 求人情報の理解や応募等 につながるCVR向上を目 的とした、UI/UXの継続的 な改善・開発 →仮説検証的、柔軟
8. 事業価値の面積モデル 開発した機能やUXは、それ自体が事業価値ではない。リリースされ、使われ、意味があって初めて事業価値に変換される。 開発中は、事業価値は発生しない。したがって、最大化すべきものは「開発量」ではなく、時間軸上に積み上がる事業価値の 面積である。AIで作ることが速く安くなる時代でも、この構造は変わらない。むしろ、使われないもの、売れないもの、運用で きないものを速く作れるようになる分、この構造の理解がより重要になる。
9. 事業価値の面積を最大化する 5つの操作 Engineeringが事業価値の面積を増やす操作は、大きく 5つある。 • 価値が生まれるまでの時間を短くする • 生まれる価値を大きくする • 障害等で価値を生まなくなっている部分を最小化する • 将来、価値を生まなくなる部分を最小化する（ EOSLの対応等） • この状態を持続可能にする
10. 事業フェーズでもエンジニアリングは変わる
11. まとめて作ることが合理的なケース 既存市場に後発参入する場合や、商品開発のように営業開始日、販売オペレーション、顧客接点がロック される場合は、大規模Project型が合理的になることがある。この場合、重要なのは「小さく何度も作るこ と」ではない。市場投入のタイミングに間に合わせ、当たり前品質を満たし、営業や業務が一斉に動ける 状態を作ることである。
12. 小さく検証することが合理的なケース 不確実性が高い場合は、大きく作り切るより、小さく失敗と学びを繰り返す方が事業価値の面積を最大化しや すい。UI/UX改善のように、実際にユーザーに使われるまで結果が読めないものは、作って市場に問うほうが 効率的なことが多い。ここで重要なのは、開発方法論の名前ではない。不確実性をどの順番で下げれば、事業 価値に最短で近づくかである。
13. 作る、作らない、まとめる、小さく作る 現実の開発には、複数の選択肢がある。 作らず検証する、小さく作って検証する、まとめて作る、複数案を並走させる、作らない。 事業の文脈で最も効率よく事業価値を最大化できるHOWを選択する。
14. アウトプットは点、アウトカムは面 アウトプットは点である。アウトカムは時間軸上に積み上がる面である。リリースした瞬間にアウトプットは増え る。しかし、アウトカムは、使われ、売れ、運用され、価値を生み続けて初めて積み上がる。したがって、生産性 を見るときは「どれだけ作ったか」ではなく、「どれだけ価値として積み上がったか」を見る。
15. アウトプットが直接アウトカムに変換されるケース インターネットサービスでは、エンジニアが開発したアウトプットがプロダクション環境にデプロイされ、ユーザーに使われるこ とでアウトカムに変換される。 UI/UX改善やCVR改善では、アウトプットとアウトカムの距離が比較的近い。この場合、開発 リードタイムの短縮やリリース頻度の向上が、ビジネストライ回数の増加につながりやすい。ただし、これはアウトプットが直 接アウトカムに作用する場合の話である。 （参考）P2M マガジン No.14, pp.37-42 (2022) インターネットサービスにおけるアジャイルの位置づけ 株式会社リクルート 大島將義 https://www.jstage.jst.go.jp/article/iaptwombulletin/14/0/14_37/_pdf/-char/ja
16. アウトプットが間接的にアウトカムに変換されるケース 商品開発では、アウトプットが直接アウトカムになるとは限らない。新しい広告枠や掲載商品のような開発で は、営業活動、クライアント合意、販売オペレーションを経由して初めて売上に変換される。この場合、開発アウ トプットからアウトカムまでの距離は長い。開発を速くするだけでは、アウトカム変換のボトルネックが解消され ないことがある。 （参考）P2M マガジン No.14, pp.37-42 (2022) インターネットサービスにおけるアジャイルの位置づけ 株式会社リクルート 大島將義 https://www.jstage.jst.go.jp/article/iaptwombulletin/14/0/14_37/_pdf/-char/ja
17. アウトプットからアウトカムまでの距離は開発の種類で違う すべての開発アウトプットが、同じ距離でアウトカムに変換されるわけではない。 UI/UX改善は、ユーザー行動を通じて、比較的近い 距離でアウトカムに変換される。リコメンド改善は、近いが、評価設計が必要になる。商品開発は、営業、クライアント合意、販売オペ レーションを介すため距離が遠い。ログイン、設定、権限などの当たり前機能等は、欠けると困るが、単独では価値増分を生みにく い。作ることが速く安くなる時代ほど、アウトカムに変換されないアウトプットも増えやすい。だから、どのアウトプットがどのアウトカム 変換ドライバーに接続しているかを見る必要がある。 （参考）P2M マガジン No.14, pp.37-42 (2022) インターネットサービスにおけるアジャイルの位置づけ 株式会社リクルート 大島將義 https://www.jstage.jst.go.jp/article/iaptwombulletin/14/0/14_37/_pdf/-char/ja
18. アウトプット (コード)総量は未来の開発生産性を下げる 開発して積み上げた資産、つまりコードが増えると、未来の開発生産性は落ちる。未来に何らかの変更を行うたびに、既存 コードに対する仕様確認、影響範囲調査、設計、テスト、運用確認が発生するからである。これは、そのコードが事業価値を 生んでいる場合でも、生んでいない場合でも同じである。作るコストが下がる時代ほど、コード総量は増えやすい。しかし、 コードは書いた瞬間から保守対象になる。したがって重要なのは、コードを書く量ではなく、ソースコードに対する事業価値濃 度を上げることである。
19. 開発作業は、事業価値のアドオンだけではない 開発作業は、事業価値をアドオンする作業だけではない。調査、テスト、障害対応、 EOSL対応、改善活動、依存関係対応など、既 存資産を維持する作業が必ず発生する。コード総量が増えると、これらの対象数も増える。 つまり、体制を定数にすると、生産性は悪化していくし、逆に、生産性を定数にすると、体制が拡大していく。
20. 事業価値を維持しながら、コード総量を減らす 理想は、事業価値の総量を維持・拡大しながら、コード総量を減らすことである。これは単なるリファクタリングではない。 ・価値を生んでいない機能を除却する ・重複した実装を整理する ・保守性の低いコードを改善する ・使われていない資産を閉じる 作れる時代ほど、資産除却と保守対象削減の価値は高くなる。
21. 2種類の技術的負債 ソースコードに対する事業価値濃度を最大化するには、 2つの技術的負債に向き合う必要がある。 1つ目は、ビジネスドメインの技術的負債である。これは、価値を生まない機能、使われなくなった仕様、過去の前提に依存したコードである。 2つ目は、プログラミングの技術的負債である。これは、価値は生んでいるが、保守性、変更容易性、品質に問題があるコードである。 どちらも未来の開発生産性を下げる。どちらもEngineeringの対象である。
22. オーバーエンジニアリングは、期待値の見誤りから起きる いろいろなことがあって、オーバーエンジニアリングは増えやすい。 ・ほぼ存在しないユーザーを想定して、レアケース仕様を大量に増やす ← 大きな少数の声が全体だと錯覚 ・将来必要かもしれない拡張性を過度に盛り込む ← 数年後の拡張性問題が、明日くらいに発生すると錯覚 ・全体の性能ネックではない部分を高性能化する ← 何でも高性能にすべきという錯覚 ・優先度の低いバグを、事業インパクトを見ずにすべて直す ← 眼の前で起きたこと全てが大問題だと錯覚
23. オーバーエンジニアリングは、期待値の見誤りから起きる 事業や開発の文脈を正しく理解していないと、前述のような錯覚によりオーバーエンジニアリングが発生する。全ての可能性が全て発生した世界が 多分オーバーエンジニアリングの理論上最大拡張幅とも言える。 このような錯覚を引き起こさないためには「事業理解」が極めて重要である。事業理解とは業界市場規模や競合を暗記してて言えるとか、ビジネスモ デルのP/L、B/S等に関する知識とかそういう話よりもっと手前の・・・・・ ・事象Aが1年に1度しか起きないことを知っている ・事象Bが1%しか起きないことを知っている ・事象Cが起きたとしても軽微なインパクトであると知っている とかでまずは充分である。これは日々の現場の業務にて身につく現場感である。この事業における相場観がないと、 ・事象Aが1年の毎日 発生すると思い込む ・事象Bが100%発生すると思い込む ・事象Cがおきたとしたらインパクトが大きく致命的だと思いこむ ことになってしまう。期待値を正しく見積もるための事業理解があることで、オーバーエンジニアリングを抑制することが可能になる。 期待値 = インパクト x 発生確率
24. コードの事業価値濃度を上げる ソースコードに対する事業価値濃度を上げるとは、次の 状態を目指すことである。 ・本当に必要なコードを増やす ・事業価値を生まないコードを増やさない ・既に価値を生まなくなったコードを除却する ・価値を生むコードの保守性を上げる 作ることが速く安くなる時代ほど、価値濃度の低いコード は増えやすい。 Engineeringの重要な仕事は、作ることだけではなく、作 らないこと、削ること、維持できる形にすることである。
25. 作る量が増えると、保守対象も増える 開発量が増えると、保守対象も増える。 保守対象が増えると、次の対象も増える。 ・監視 ・障害対応 ・セキュリティ対応 ・依存関係管理 ・EOSL対応 ・問い合わせ対応 ・資産除却 作ることが速く安くなる時代ほど、 動かし続ける力が事業価値の上限になる。
26. まとめて作るか、 1個ずつ価値化するか 複数のことをまとめて開発すると、リリースまで価値が発生しない。1つずつ開発してリリースすると、早い段階から価値が発生し、学習も始ま る。この差が、事業価値の面積差になる。ただし、何でも1つずつ出せばよいわけではない。独立して価値化・検証できるものは小さく流す。 営業開始日や商品一斉展開が重要なものは、まとめて作る。判断基準は、事業価値の面積である。 A案件、 B案件、 C案件を 3つまとめて開発
27. まとめて作るか、 1個ずつ価値化するか 複数のことをまとめて開発すると、リリースまで価値が発生しない。1つずつ開発してリリースすると、早い段階から価値が発生し、学習も始ま る。この差が、事業価値の面積差になる。ただし、何でも1つずつ出せばよいわけではない。独立して価値化・検証できるものは小さく流す。 営業開始日や商品一斉展開が重要なものは、まとめて作る。判断基準は、事業価値の面積である。 A案件、 B案件、 C案件を 1つずつ 開発
28. リソース効率とフロー効率 リソース効率は、リソースの稼働率にフォーカスする。フロー効率は、流れる対象、つまり価値が発生するまでの時間にフォーカスする。人が 忙しくても、価値が流れていなければ事業価値は増えない。逆に、人の稼働率が100%でなくても、価値が早く流れていれば事業貢献は大き い場合がある。
29. リソース効率とフロー効率のトレードオフの関係
30. リソース効率とフロー効率と事業価値発生までの時間 リソース効率を重視して開発した場合 事業価値発生までのリードタイム フロー 効率を重視して開発した場合
31. 真のボトルネックは、開発から維持保守へ移る AIによって作る力が増えるほど、開発対象は増 える可能性が高い。 開発対象が増えるほど、維持保守、運用、障害 対応、依存関係管理の総量が増える。 したがって、これからのEngineeringでは、新しく 作る力だけでなく、作ったものを止めずに動かし 続ける力が重要になる。 価値を作るEngineeringと、価値を止めない Engineeringは、同じ事業貢献である。
32. 「パ」は開発量ではなく、事業価値である コスパ、タイパ、 ROI、生産性。 分母は比較的はっきりしている。 コスト、時間、 Investment。 一方で、分子である「パフォーマンス」は曖昧にな りやすい。 高速で新機能をリリースしていても、 ほとんど使われていなければ、生産性が高いとは 言えない。 パフォーマンスとは、アウトプット（開発量）ではな く、アウトカム（事業価値）そのものの量である。
33. Engineeringのミッション 事業価値の積み上がる効率を Engineeringにより最大化することが、我々 のミッションである。 作ることが速く安くなる時代でも、このミッションは変わらない。 むしろ、作れるものが増えるからこそ、次がより重要になる。 ・事業価値に変換されるものを選ぶ ・価値に変換されないアウトプットを増やさない ・コード総量と保守対象を増やしすぎない ・価値を生むコードの濃度を上げる ・障害、EOSL、依存関係、運用により価値が止まる時間を減らす ・この状態を持続可能にする AI時代のEngineeringは、たくさん作ることではない。 価値になるものを作り、価値にならないものを作らず、作った価値を止め ないことである。
34. Appendix
35. 昨年度の資料(今年から分量を半分以下に削りました） 事業価値とエンジニアリング2025年度版 https://speakerdeck.com/recruitengineers/engineering-2025