約2年で内製化を達成！その背景にある2つのポイント

後藤：株式会社EARTHBRAINの後藤優一と申します。本日は、内製化達成後にある課題とその解決策という、未来を先取りした話をしたいと思います。



最初に、私たちのソリューション概観をご紹介します。Digitization Layer、Platform Layer、Application Layerといった3層で構成され、各層の中に複数のプロダクトがあり、それぞれの専属チームが開発を担当するという組織構成です。

Platform Layerの主要素であるData Platformは、複数のプロダクト間で共通のデータ、ロジックを持っています。例えば、ユーザーの認証認可やライセンスのユーザーアクセスマネジメントといった機能は、Data Platformが担っています。

このData Platformには新旧世代があり、旧Data Platformには、3つの課題がありました。1つ目は機能追加の柔軟性です。もともと外部ベンダーのパッケージ製品を利用していたため、機能追加に制限が発生していました。

2つ目は開発にかかる時間です。これは言葉通りで、他社にもサービスを提供しているため、期待する速度では機能開発が進んでいませんでした。

3つ目は開発にかかる費用の課題です。機能追加のたびに高額な開発費が発生していました。

これらの根本課題は、広木大地氏の「『技術的負債』への処方箋と『2つのDX』」に書かれている「ソフトウェアのコントローラビリティが低い」という点に尽きると思っています。つまり、合理的な予算と時間の中で、ビジネスに必要なシステムの機能追加を続けられない状態でした。

私たちはこの課題を解決するため、Data Platform開発の内製化に着手することを決意しました。



内製化のタイムラインは上図のようなイメージです。当初はスムーズに進んでおらず、開始から約1年後にEARTHBRAIN主導の体制へと移行しました。そして、2024年1月ごろには、Data Platformのシステム開発の内製化を達成しました。

内製化を達成した結果、最低限必要なコントローラビリティを獲得できました。社内のチームに開発ノウハウが蓄積され、開発時間を短縮でき、2週間に1回の頻度で成果物をリリースできるようになりました。何より、DigitizationおよびApplicationという2つのレイヤーからの要望に、柔軟に対応できるようになったことは大きな成果でした。

何もないところからスタートし、2年という比較的短い期間で内製化を達成できた背景には、2つのポイントがあったと認識しています。

1つ目は、コア業務・技術を中心に内製化するということ。なぜなら、コア業務・技術のシステム（以下、コアシステム）のコントローラビリティが高ければ、変化の激しい環境下でも事業の利益を増大し、事業の競争優位性を維持できるからです。

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



この話を聞いて「自分たちの所属する企業のコアシステムは何か？」と思われた方は、広木大地氏のプレゼンテーション「内製化のコツとワナ」で紹介されている簡易的なアセスメントを実施してみてください。

これの面白いところが、大半のコアシステムがノンコアシステムだという結果になることです。もし、これがノンコアシステムだと判定された時はどうすべきでしょうか？答えは「なるべく内製化しない」だと思います。

2つ目のポイントは、フルマネージドサービスの積極採用です。Data Platformに話を戻すと、これ自体はコアシステムであるものの、要素技術であるインフラストラクチャの構築・運用は自分たちで行う必要はないと判断しました。そこで、Google Cloudが提供するフルマネージドサービスを積極的に採用することで、内製組織を早期に立ち上げることができました。



これは、Data Platformのシステムアーキテクチャの概観です。Google Cloudのサービスが多く使われていることがお分かりいただけると思います。先ほどData Platformで認証認可などの機能も実装しているとお話ししましたが、ここについても外部サービスを採用しています。

本パートの要点をまとめます。EARTHBRAINは、コアシステムのコントローラビリティ向上のために開発の内製化を実施し、約2年で完了させました。早期立ち上げの2つのポイントには、事業の競争優位性に繋がる領域に経営資源を効率的に投下するという共通点がありました。AIで変わりつつあるものの、エンジニアの採用難易度が上がっている中では、「メリハリ」をつけることが重要なのではないかと考えています。

Eliteクラスタを目指し、改善施策を継続中

後藤：続いて、新Data Platformでの課題設定について話します。

まず、デリバリーパフォーマンス（≒仕事量の生産性）の向上を通じて、さらなるコントローラビリティの向上に取り組みました。具体的には、DORAの「State of DevOps Report」におけるEliteクラスタをあるべき姿として設定しました。



これが2023年当時の分析結果で、赤丸で囲っている部分が私たちの指標の値です。これをもとに、Eliteと特にギャップの大きかった「サービス復旧にかかる時間」と「デプロイ頻度」という2つの指標の改善に注力しました。

Google Cloudには関連サービスが多く存在するため、これらを活用して「サービス復旧にかかる時間」の改善から着手しました。

具体的には、Cloud MonitoringでSLO・バーンレートアラートを設定したり、Dockerイメージを一度ビルドして開発・ステージング・本番環境へと段階的にプロモートできるCloud Deployを採用したりすることで、高速化を実現しました。

以前は、Dockerイメージを各環境へデプロイする際に毎回ビルドし直していたのですが、段階的にプロモートする形を採用したことで、キャッシュ効果が得られたことが改善のポイントでした。

現在は、SLOベースでカナリアリリースして、問題があればロールバックする仕組みを検証しているところです。Google Cloudサービスだけでは利用できないため、なかなか難航しています。



具体例として、バーンレートアラートの設定画面をご紹介します。こちらはGoogleが提供するサービスということもあり、書籍『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』で紹介されているアラートが、画面から簡単に設定できます。

次に「デプロイ頻度」の改善についてお話しします。デプロイ頻度について、根本的な課題は自動テストの信頼性にあります。そのため、現在に至るまで時間をかけ、段階的に取り組んでいます。

さらに、Cloud RunとGitHubを使って、PRごとに専用環境を構築できるようにしました。これにより、マージ前に確認可能となり、リリース前のステージング環境における統合的テストを行う必要がなくなりました。

現在は、準本番環境（ステージング環境）へのオンデマンドデプロイを実現するべく、デプロイフローの変更を進めています。



例として、PRごとの専用環境をご紹介します。GitHubのDeployment APIを活用しており、これにより専用環境の状態とURLを確認できるようになっています。

改善の成果については、正直に申し上げると「まだ道半ば」です。サービスの復旧にかかる時間の構成要素であるTime to Detectについては特筆すべき部分がなく、SLI/SLOの設定には改善の余地があると考えています。もう1つの構成要素であるTime to Fixは、オンデマンドデプロイの実現後に短縮される見込みです。

デプロイ頻度については、準本番環境へのデプロイは2週間に1回でしたが、これもオンデマンドへと短縮できる見込みです。一方で、本番環境については別途組織課題が存在しますが、発表の本題から外れるため、今回は言及しません。現状では、まだ2週間に1回の頻度を維持しています。

本パートの要点をまとめます。Data Platformというコアシステムの開発内製化後、デリバリーパフォーマンスの向上を通じて、さらなるソフトウェアのコントローラビリティの向上に取り組みました。この時に「State of DevOps Report」を用いてあるべき姿を定量的に設定し、現状とのギャップを課題と捉え、その解消に努めました。デリバリーパフォーマンスのギャップを埋める施策は、基本的にノンコアの技術で実現できるため、引き続き外部サービスを積極的に活用していくつもりです。

「合成の誤謬」を乗り越える技術・組織の協調設計

後藤：最後に、これまでお話しした取り組みの先にある課題と、その解決策についてお話しします。

内製化を達成した2024年1月からしばらく経った頃、私はテクニカルプロダクトマネージャーを務めていました。状況としては、各プロダクトの新機能開発において、Data Platformチームがボトルネックとなり、期待付加価値の生産性が低下しているという課題感を持っていました。

例えば、あるPdMがプロダクトAとBを横断する機能開発を検討する際に「プロダクトA,BでX機能の開発を検討中で、YできるAPIがほしい」という要望を私たちに伝えてきたとします。私たちは「約2スプリント（1ヶ月くらいほど）かかり、その後リリース可能です」と回答し、要件定義に着手します。しかし、その間に別のチームからも同様の要望が寄せられ、その優先順位が高いと言われた場合、私たちは対応に困ってしまいます。たとえ優先順位が低かったとしても、リリースまでには比較的時間を要するといった状態でした。これは優先順位の決定方法にも課題があったため、その点は別の取り組みで改善しています。

このような状況を引き起こした背景には、3つの要因があったと考えられます。1つ目は、自社サービスである「Smart Construction」が持つ競争優位性です。CTO・井川の言葉を借りると「『Smart Construction』はデータを横断して一元的に活用できる」と。つまり「Smart Construction」を利用することで他社サービスを介することなくスムーズに連携可能だという点が特徴だと言えます。

2つ目は、相互連携する複数のプロダクト専属チームの存在です。冒頭でも述べたように、このソリューションは3層構成で、各層のプロダクトをそれぞれ別のチームが開発しています。これらのプロダクトは緩やかに連携しており、ソリューション全体で1つの機能を実装する、もしくはLTVを向上する際には、複数チーム間での調整が必要です。

3つ目は、Data Platformの役割と要素技術です。先述の通り、Data Platformシステムは、複数のプロダクト間で共通のデータやロジックを持っています。また、現在は参照操作の一部をGraphQLで提供していますが、当時は内製化前の旧システムを踏襲していたため、基本的にはREST APIしかありませんでした。



この3つの要因が、組織重力を生み出していたのだと思います。各プロダクトのPdMは「Smart Construction」の優位性を強めるため、プロダクト間のスムーズな連携を実現したいと考えます。そのため、共通のデータロジックを持つData Platformへの要望が増加します。一方で、Data Platformの開発チームは、REST APIしか提供されていないため、そのAPIを汎用的なものにしなければならないと考えていました。

その結果、要件定義や情報収集の段階、もしくは設計におけるコストや時間が増加していました。特化した機能を実装するだけなら簡単ですが、他のプロダクトにも使えるような汎化を求められる際は、そこがボトルネックになっていました。

皆が良いことをやっていると思っていたら全体としては悪くなっているという、まさに「合成の誤謬」に陥っていました。



解決策の方向性を探っていたところ、InfoQの「Software Architecture and Design InfoQ Trends Report」に、ヒントを発見することができました。これはInfoQが2019年から毎年刊行しているもので、Innovators／Early Adapters／Early Majority／Late Mjorityと書かれたグラフと、その技術要素が書かれているレポートです。

2024年のレポートで初登場した項目として、Socio-technical architectureという概念が紹介されており、これが私の目に留まりました。



Socio-technical architectureとは、コンサルタントであるEduardo da Silva氏の言葉を借りれば、プロダクトの技術システムアーキテクチャだけでなく、それを構築・所有する組織システム、つまりチームを含めた協調設計のアプローチを持つことを基盤とする概念です。

この概念の基礎となったものとして、Socio-technical systemという言葉が存在します。Socio-technical architecture自体には明確な定義や提唱者はいませんが、この言葉で調べると彼のブログがよく出てくるため、今回は彼の定義をご紹介しました。

なぜ、技術と組織システムの両方を考慮するのかというと、互いに大きな影響を与えあっていて、無視すると適切な設計や開発ができないからです。

この概念の視点から先ほどの状況を分析すると、より高い解像度で何が起きていたか理解することができます。具体的には、本日お話しした「コアシステムのコントローラビリティ向上のための内製化」や「デリバリーパフォーマンスの向上」の取り組みは、どちらもtechnical systemに着目していたと言えると思います。

しかし、私たちのように複数プロダクトチームが相互に連携する状況では、organizational systemも考慮した協調設計が必要でした。協調設計が不十分だったために、先述のような合成の誤謬に陥ってしまっていたのではないかと思っています。

協調設計の実施と重要性が理解できたところで、実践の話に移ります。



先ほどご紹介したEduardo da Silva氏によると、Socio-technical architectureには5つの特性があります。これには、コンウェイの法則や、チームの認知負荷、チーム境界の話が含まれていることから、Team Topologiesをさらに発展させたような内容であることがお分かりいただけると思います。個々の説明は割愛しますので、ご興味がある方はEduardo da Silva氏のブログポスト「Introduction to Sociotechnical Architecture: Traits and Strategies」を参照してください。

実践のフレームワークとして使用する上で、今回は課題感が大きい2つの特性として「Conway’s Law」と「Team Boundaries & Interrelations」に焦点を当てました。なお、この課題の大きさは、あくまで定性的な評価に基づいています。

Conway’s Lawの観点では、新機能を迅速に開発するため、システム同士が個別にAPI連携をするということが起きていました。結果として、システム間の依存関係が複雑化していることが課題でした。

Team Boundaries & Interrelationsでは、あるプロダクトがすでにプラットフォームのAPIを使用している状況で個別のユースケースに特化したAPI改修の要望を受けることがあり、Data Platform開発チームの役割が曖昧になり始めていました。

これらの課題の解決策として、APIのインターフェースと実装の分離を実施しています。Data Platform開発チームの新しい役割は「コアドメインのデータ操作のインターフェースの設計と実装」と「他の共通データのインターフェースの標準化と統合エンドポイントの提供」です。それ以外は、プロダクトチームに実装してもらう方向で進めようとしています。

この解決策の理論的な背景にあるのは、逆コンウェイ戦略とThinnest Viable PlatformというTeam Topologiesの概念です。各プロダクトとデータプラットフォーム開発チームのコミュニケーション構造を変更することで望ましいアーキテクチャを実現し、Data Platformチームが提供するシステムを実用最小限にすることで、ボトルネックにならないようにする狙いがあります。

現在の状況としては、あるプロダクトが提供する小規模なREST APIを題材に選定し、そのAPIが複数プロダクトに提供する際の新しい開発フローの試験導入を予定しています。また、統合エンドポイントの実現技術としては、Google CloudサービスであるApigeeの技術検証も予定しています。

本パートの要点をまとめます。複数プロダクトチームが相互に連携する状況において、Data Platform開発チームが期待付加価値向上のボトルネックになっていました。ここにSocio-technical architectureの視点を導入したことで、これまでの取り組みでは組織の協調設計が不十分だったと認識できました。その上で、Data Platform開発チームが担っていた共通データAPIのうち、コアドメイン以外をプロダクト開発チームに実装を移譲することで、この課題の解決策に挑んでいます。

解決策はともかく、技術と組織を協調設計するという考え方は、AI関連の課題解決にも活かせるのではないかと考えています。

最後に、私たちEARTHBRAINは、日本初のグローバル開発組織として、建設業界の未来をつくっています。もしご興味を持っていただけたなら、お気軽にお声掛けください。

本日はご清聴ありがとうございました。

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