開発内製化のその先へ―技術・組織の協調設計によるプロダクト付加価値向上の実践

Yuichi Goto | 開発生産性Conference 2025 on July 4, 2025

発表者について

  • 👤Yuichi Goto
  • 🌐@yasaichi
  • 🏢株式会社EARTHBRAIN
  • 📋東証グロース上場企業CTO(〜2023)

EARTHBRAINについて

  • 2021年7月創業(現在、従業員約200名規模)
  • 小松製作所、NTTドコモビジネス、ソニーセミコンダクタソリュー
    ションズ、野村総合研究所による合弁会社
  • Smart Construction®を開発・提供・保守

Smart Construction®について

  • 建設生産プロセスの生産性・安全性の向上を実現するデジタル
    ソリューション
  • 相互連携する複数のソフトウェア・ハードウェアの形で提供
  • プロダクトの一部は世界20カ国以上で利用

本発表について

👥 対象の方

  • ソフトウェア開発の内製組織の
    立ち上げを推進されている方
  • 大規模なプロダクト開発組織に
    携わる方

🚩 ゴール

  • 内製組織早期立ち上げとデリバリ
    パフォーマンスの向上事例を知る
  • 大規模開発における技術・組織の協調設計の重要性を理解する

Agenda

  1. 内製組織の早期立ち上げ事例とポイント 👈
  2. デリバリパフォーマンスの向上における課題設定と解決
  3. プロダクトの期待付加価値向上における課題設定と解決

ソリューション概観

複数のプロダクト間で共通のデータ・ロジックを持つ

旧Data Platformの課題

  • 🔧 機能追加の柔軟性: 外部ベンダーのパッケージ製品を利用していた
      ため、機能の追加に制限があった
  • ⏰ 開発にかかる時間: 期待する速度で機能追加が進んでいなかった
  • 💰 開発にかかる費用: 機能追加の度に高い開発費が発生していた

根本課題はコントローラビリティの低さ

ソフトウェア開発という経済活動を対象としたコントローラビリティを、リーズナブルな範囲の予算/時間という入力条件の中で、ビジネス上必要なシステムの機能追加をしつづけられることと定義しましょう。

一般社団法人日本CTO協会 理事 広木大地 氏 [1]

注: 太字強調は引用者によるもの

本課題を解決するため、
Data Platform開発の内製化を実施

内製化のタイムライン

  1. 2021年12月: 開発パートナー主導の体制で旧システムのリプレース開始
  2. 2022年11月: EARTHBRAIN主導の体制へ変更して仕切り直し
  3. 2023年9月: 新システムの本番環境へのリリース完了
  4. 2024年1月: 初期より参画していた開発パートナー人員が0名に

結果: 最低限必要なコントローラビリティを獲得

  • 社外ではなく社内のチームに開発ノウハウが蓄積するようになった
  • 開発にかかる時間が短縮できた(2週間に1回成果物をリリース)
  • Application/Digitization Layerの要望に対して柔軟に対応できる
    ようになった

約2年で実現できたのはなぜか

2つのポイント

  1. コア業務・技術を中心に内製化 👈
  2. フルマネージドサービスの積極採用

なぜコア業務・技術を内製化するのか

内製開発によりコア業務・技術のシステム(以降「コアシステム」)のコントローラビリティが高ければ、変化の激しい環境下でも

  • 事業の利益を増大できるから
  • 事業の競争優位性を維持できるから

EARTHBRAINの場合

  • コアシステムはData Platformと3D技術の根幹となるプロダクト群と判断
  • 最初に限られた数のシステムの内製化に集中したことで、内製組織を早期で立ち上げられた

Q. ノンコアシステムはどうする?

A. なるべく内製化しない

再掲: 2つのポイント

  1. コア業務・技術を中心に内製化
  2. フルマネージドサービスの積極採用 👈

Data Platform開発の場合

  • Data Platform自体はコアシステムだが、要素技術であるインフラ
    ストラクチャの構築・運用はコア技術ではないと判断
  • 当領域においてGoogle Cloudが提供するフルマネージドサービスを積極採用したことで、内製組織を早期で立ち上げられた

本パートの要点

  • コアシステムのコントローラビリティ向上のために開発の内製化を
    実施
    し、2年弱で完了できた
  • 内製組織の早期立ち上げのポイントは、どちらも事業の競争優位性に繋がる領域に経営資源*を効率よく投下すべきという点で共通
  • 昨今の国内でのソフトウェアエンジニアの採用難易度を鑑みると、「メリハリをつける」ことはとても重要
* Jay B. Barneyによると、「財務的資源」「物的資源」「人的資源」「組織的資源」の4つに分類できる [3]

Agenda

  1. 内製組織の早期立ち上げ事例とポイント
  2. デリバリパフォーマンスの向上における課題設定と解決 👈
  3. プロダクトの期待付加価値向上における課題設定と解決

新Data Platformでの課題設定

  • まず最初にデリバリパフォーマンス(≒ 仕事量の生産性)の向上を
    通じて、さらなるコントローラビリティの向上に取り組んだ
  • DORA*の State of DevOps Report における 「Eliteクラスタ」を
    あるべき姿として設定
* Google Cloud傘下の研究・調査チームのことで、“DevOps Research and Assessment”のアクロニム

「サービス復旧にかかる時間」改善の取り組み

関連するフルマネージドサービスが存在するため、こちらから実施。

  • ✅ SLO・バーンレートアラートの設定: Cloud Monitoringを活用
  • ✅ CDパイプラインの高速化: Cloud Deployによる段階的Promote
  • 🚧 カナリアリリースの導入: SLOベースの自動ロールバックを検証中

「デプロイ頻度」改善の取り組み

根本課題である自動テストから着手し、時間をかけて段階的に解決。

  1. ✅ テストカバレッジ等の可視化・改善: SonarQube Cloudを活用
  2. ✅ プルリクエストごとに専用環境を構築: Cloud Run/GitHubを活用
  3. 🚧 準本番環境へのオンデマンドデプロイ: デプロイフローを変更中

結果: 改善の見込みはあるが道半ば

  • Time to Detect: 特筆すべき改善なし。SLI/SLO設定に改善余地あり
  • Time to Fix: 前述のオンデマンドデプロイの実現後に短縮見込み
  • デプロイ頻度:
    • 準本番環境: 2週間→オンデマンド(Elite)に短縮見込み
    • 本番環境: 別途組織課題*があり、直近では2週間に1回の頻度を維持
* Smart Construction®の販売チャネルに関連しているが、本題から脱線するため割愛

本パートの要点

  • 内製後は最初にデリバリパフォーマンスの向上を通じて、さらなる
    コントローラビリティの向上
    に取り組んだ
  • State of DevOps Report における「Eliteクラスタ」をあるべき姿として設定し、ギャップの大きかった2指標の改善に注力した
  • デリバリパフォーマンスの向上に必要なのは基本的にノンコア技術
    なので、外部サービスを積極活用している

Agenda

  1. 内製組織の早期立ち上げ事例とポイント
  2. デリバリパフォーマンスの向上における課題設定と解決
  3. プロダクトの期待付加価値向上における課題設定と解決 👈

プロダクト期待付加価値向上における課題

各プロダクトの新機能開発においてData Platform開発チームがボトルネックとなり、期待付加価値の生産性が低い状態。

👩‍💼「プロダクトA,BでX機能の開発を検討中で、YできるAPIがほしい」
🧑‍💻「ざっくり2スプリントかかるので、最短で1ヶ月後リリースです」
👨‍💼「プロダクトC,Dで(以下略)」
🧑‍💻「あわわ」

3つの要因

要因1: Smart Construction®のMoat

センサー開発や点群データ作成など個々のサービスを展開する企業は多く、解析や
分析に別のアプリが必要だったりするが、Smart Constructionはデータを横断して
一元的に活用できるのが他に無い特長だ

EARTHBRAIN 執行役員CTO/CIO 井川甲作 [5]

注: 太字強調は引用者によるもの

要因2: 相互連携する複数のプロダクト・専属チーム

要因3: Data Platformの役割と要素技術

  • 役割: 複数のプロダクト間で共通のデータ・ロジックを持つ
  • 要素技術:
    • 旧システムを踏襲し、REST API(JSON形式)で共通データの
      参照・更新操作を提供
    • 内製化後しばらくはREST以外のAPIが存在しなかった*
* 現在は共通データの参照操作の一部をGraphQL APIとして提供し始めている

3つの要因が生み出す組織重力

🧑‍💼 各プロダクトのPdM

複数のプロダクトがスムーズに
連携するようにしたい

➡︎ 共通データ・ロジックを持つ
  Data Platformへの要望が増加

🧑‍💻 Data Platform開発チーム

提供するREST APIはなるべく汎用
的なものにしなければならない

➡︎ 要件収集・定義、設計にかかる
  時間が増加

典型的な「合成の誤謬」に陥っていた

解決策の方向性

2024年のレポートでSocio-technical architectureが初登場

Socio-technical architectureとは

The foundation of Sociotechnical Architecture is to have a co-design approach to architecture, where we don’t just look at the technical systems architecture of the product, but also to the organization system (teams) building and owning it.

Eduardo da Silva, Independent Consultant [7]

注: 太字強調は引用者によるもの

技術・組織システムの両方を考慮する理由

Why? Because they [technical and organizational systems] have a lot of influence on each other and neglecting is not allowing for a proper design and developments.

Eduardo da Silva, Independent Consultant [7]

注: 太字強調は引用者によるもの

Socio-technical architecture視点での現状分析

  • コアシステムのコントローラビリティ向上のための内製化、デリバリパフォーマンスの向上はどちらもtechnical systemsに着目していた
  • 複数のプロダクト・チームが相互連携する状況では、organizational systemも考慮した協調設計が必要だった
  • 協調設計が不十分だったため、前述の「合成の誤謬」に陥っていた

協調設計の実践

協調設計のフレームワーク: 5つの特性

  1. Conway's Law
  2. Team Cognitive Load
  3. Team Boundaries & Interrelations
  4. Continuous Discovery & Delivery in Team
  5. Understand your context & Design based on that
各ポイントの詳細はEduardo da Silva氏のブログポスト [8] を参照のこと

課題感の大きい2つの特性に焦点

  • Conway's Law:
    新機能を迅速に開発するため、複数のプロダクトのシステム同士が
    個別にAPI連携をした結果、依存関係が複雑になり始めていた
  • Team Boundaries & Interrelations:
    あるプロダクトのユースケースに特化したAPI改修の要望を受ける
    など、Data Platform開発チームの役割が曖昧になり始めていた

解決策: インターフェイス(I/F)と実装の分離

  • Data Platform開発チームの新しい役割:
    • コアドメイン(機労材)のデータ操作のI/Fの設計・実装
    • 他の共通データ操作のI/Fの標準化*と統合エンドポイントの提供
  • プロダクト開発チームの新しい役割: コアドメイン以外の共通データ操作のI/Fの提案・実装
* 例: URIのリソースの命名規則、リクエスト・レスポンスの形式、認証・認可の方式の統一

本解決策の理論的背景

  • 逆コンウェイ戦略の実践:
    各プロダクトとData Platform開発チーム間のコミュニケーション
    構造を変更することで、望ましいアーキテクチャを実現する
  • Thinnest Viable Platform*の実践:
    Data Platform開発チームが提供するシステムを実用最小限にし、
    各プロダクトの新機能開発のボトルネックにならないようにする
* 詳細は『チームトポロジー』 [9] の5章を参照のこと

実施中および今後の取り組み

  • あるプロダクトが提供する小規模なREST APIを題材に選定済み
  • 対象APIを複数プロダクトに提供する際に、新しい開発フローを試験導入する予定
  • 統合エンドポイントの実現技術としてのApigee*の技術検証予定
    例: 認可処理、オブザーバビリティ、循環参照検出、社内ポータル
* Google Cloudが提供するAPI管理プラットフォームで、読み方はApp-ih-gee

本パートの要点

  • 複数のプロダクト・チームが相互連携する状況下で、Data Platform開発チームが期待付加価値向上のボトルネックになっていた
  • Socio-technical architectureの視点を導入したところ、これまでの
    取り組みでは技術・組織の協調設計が不十分だったことを認識した
  • Data Platform開発チームが担っていた共通データAPIの実装をプロダクト開発チームに一部移譲することで、本課題の解決に挑んでいる

全体のまとめ & ご清聴ありがとうございました

  • EARTHBRAINでは、コアシステム「Data Platform」のコントローラビリティ向上のために開発の内製化を実施し、2年弱で完了できた
  • 内製組織の早期立ち上げのポイントは、事業の競争優位性に繋がる領域に経営資源を効率よく投下すること
  • 内製後は最初にフルマネージドサービスを活用したデリバリパフォーマンスの向上を通じて、さらなるコントローラビリティの向上に取り組んだ
  • プロダクトの期待付加価値向上の過程で、大規模開発における技術・組織の
    協調設計の重要性を認識し、現在はその実践に挑んでいる

参考文献

  1. 「技術的負債」への処方箋と「2つのDX」↩
  2. 内製化のコツとワナ↩
  3. [新版]企業戦略論【上】基本編↩
  4. DORA 2023 度版 State of DevOps Report↩
  5. 建機の電動化とスマートコンストラクションで、コマツが仕掛ける建設現場の未来変革↩
  6. InfoQ Software Architecture and Design Trends Report - April 2024↩
  7. Introduction to Sociotechnical Architecture: Why & What is it↩
  8. Introduction to Sociotechnical Architecture: Traits and Strategies↩
  9. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計↩