Google Cloud を用いたソフトウェア開発の内製化組織の早期立ち上げの実現 / Rapid Establishment of In-House Software Development Teams Using Google Cloud

August 2, 2024 @ Google Cloud Next Tokyo '24

Transcript

1. Proprietary Google Cloud を 用いたソフトウェア 開発の内製化組織の 早期立ち上げの実現
2. 02 Google Cloud Next Tokyo ’24 後藤 優一 株式会社EARTHBRAIN 技術開発グループ
3. 03 Google Cloud Next Tokyo ’24 Proprietary 2015 年 ピクスタ入社 大学院修了後、エンジ ニアとして入社。 同年、同社は当時の 東証マザーズ市場に 上場。 スピーカーについて 2020 年 執行役員 CTO 就任 EM を経て当時最年少の 執行役員に就任。 100 名弱規模の企業の 経営の執行に従事。 2023 年 EARTHBRAIN 入社 ビジョンと事業内容に 惹かれて入社。 入社 3 日目に渡米し、 現地で内製化組織立ち 上げに従事。 2024 年 Data Platform 担当 後述する Data Platform チームへ異動。現在に 至る。
4. 04 Google Cloud Next Tokyo ’24 Proprietary EARTHBRAIN について • 2021 年 7 月創業 • コマツ、NTTコミュニケーションズ、 ソニーセミコンダクタソリューションズ、 野村総合研究所による合弁会社 • Smart Construction® を開発、提供、保守
5. 05 Google Cloud Next Tokyo ’24 Proprietary Smart Construction® とは • 建設生産プロセスの生産性・安全性の 向上を実現するデジタル ソリューション • 相互連携する複数のソフトウェア・ハード ウェアの形で提供 • プロダクトの一部は世界 20 カ国以上で利用
6. Google Cloud Next Tokyo ’24 Proprietary Q. 開発の内製化を担当 されていますか？
7. 07 Proprietary 本発表の目的 対象の方 • ソフトウェア開発の内製化組織の 立ち上げを推進されている方 • ソフトウェア開発の内製化組織で 働く開発者の方 ゴール • Google Cloud を活用した内製化 組織の早期立ち上げ例を知ること • 内容を担当のプロジェクトで活用 しよう、と思えていること
8. 08 Proprietary 01 EARTHBRAIN での 開発内製化について 02 内製化組織の早期 立ち上げのポイント 03 今後の課題と挑戦 アジェンダ
9. 09 Google Cloud Next Tokyo ’24 Proprietary 01　EARTHBRAIN での開発 内製化について
10. 010 Google Cloud Next Tokyo ’24 Proprietary ソリューション概観
11. 011 Google Cloud Next Tokyo ’24 Proprietary 旧 Data Platform の課題 機能追加の柔軟性 外部ベンダーのパッケージを 利用していたため、機能の 追加に制限があった。 開発にかかる時間 期待する速度で機能追加が 進んでいなかった。 開発にかかる費用 機能追加の度に高い開発費が 発生していた。 仮に費用が許容できても、 対象のパッケージが継続的に 開発される保証はない。
12. 012 Google Cloud Next Tokyo ’24 Proprietary ソフトウェア開発という経済活動を 対象としたコントローラビリティを、 リーズナブルな範囲の予算 /時間という 入力条件の中で、 ビジネス上必要な システムの機能追加 をしつづけられる ことと定義しましょう。 ” 一般社団法人日本 CTO 協会理事　広木 大地 氏 出典: https://qiita.com/hirokidaichi/items/64b444a89410190d965f（引用・顔写真の掲載許諾取得済）
13. 013 Google Cloud Next Tokyo ’24 根本課題はコントローラ ビリティの低さ 本課題を解決するため、 Data Platform 開発の内製化を実施。
14. 014 Google Cloud Next Tokyo ’24 Proprietary 2021 年 12 月 開発内製化に着手 開発パートナー主導の 体制で開始。 内製人員 3 、外製人員 12 名という構成。 開発内製化のタイムライン 2022 年 11 月 仕切り直し 開発進捗が悪かった ため、EARTHBRAIN 主導の体制へ変更。 内製・外製人員の比は 1:1 に。 2023 年 9 月 開発内製化の着手 新システムの本番環境 へのリリース完了。 内製・外製人員の比は 2:1 に。 2024 年 1 月〜 自立自走体制へ 初期より参画していた 開発パートナー人員が 0 名になる。
15. 015 Proprietary • 社外ではなく社内の専属の内製チームに 開発ノウハウが蓄積するようになった • 開発にかかる時間が短縮できた（2 週間に 1 回の頻度で成果物をリリース） • Application / Digitization Layer の要望に 対して柔軟に対応できるようになった 結果 開発内製化により、 DX 時代に最低限 必要なソフトウェアのコントローラ ビリティを獲得できた。
16. 016 Google Cloud Next Tokyo ’24 技術スタック カテゴリ 主な技術要素 言語・ランタイム TypeScript / JavaScript / Node.js / Go フレームワーク React / Next.js / NestJS パブリッククラウド DevOps GitHub Actions / Docker / Kubernetes / Terraform / SonarCloud
17. 017 Google Cloud Next Tokyo ’24 Proprietary 02　内製化組織の早期立ち 上げのポイント
18. 018 Google Cloud Next Tokyo ’24 Proprietary 1 2 コア業務・技術を中心に内製化 2 つのポイント フルマネージド サービスの積極採用
19. 019 Google Cloud Next Tokyo ’24 Proprietary なぜコア業務・技術を内製化？ A. コア業務・技術のシステムのコントローラ ビリティが高ければ、変化の激しい環境下 でも利益を増大したり、競争優位性を維持 できる可能性が高まるから
20. 020 Google Cloud Next Tokyo ’24 Proprietary スタートアップに限った話ではない ICT スタートアップ • 経済合理性だけでは説明 できない顧客のニーズの 仮説検証を行うため • 更なる利益増大のために 隣接市場に参入するため メガベンチャー・大企業 • 自社の持つ市場を他社に 奪われないため • 顧客が持つ自社製品の 継続的な改善への期待に 応えるため 規模によらず高いコントローラ ビリティが重要
21. 021 Google Cloud Next Tokyo ’24 Proprietary EARTHBRAIN の場合 • コア業務・技術は Data Platform と 3D 技術の根幹となるプロダクト群と判断 • 最初にこれらの内製化に集中した ことで、 内製化組織を早期で立ち上げられた
22. 022 Proprietary & Confidential Google Cloud Next Tokyo ’24 出典: https://speakerdeck.com/hirokidaichi/nei-zhi-hua-falsekotutowana?slide=25（使用許諾取得済）
23. 023 Google Cloud Next Tokyo ’24 Proprietary 1 2 コア業務・技術を中心に内製化 2 つのポイント フルマネージド サービスの積極採用 再掲
24. 024 Google Cloud Next Tokyo ’24 Proprietary ノンコア業務・技術はどうする？ A. なるべく内製化しない。 ※ コア業務の中にノンコア技術が含まれうる ことに注意。
25. 025 Google Cloud Next Tokyo ’24 Proprietary Data Platform 開発の場合 • インフラ領域において Google Cloud の フルマネージド サービスを積極採用 • インフラ構築・運用工数の削減 により、 内製化組織を早期で立ち上げられた
26. 026 Google Cloud Next Tokyo ’24 Proprietary ※画像の置換方法 グレーボックスを選択し、 右クリックで「画像を置換」 を選択し、配置したい画像に差し替えてください。本テ キストは削除してください。
27. 027 Google Cloud Next Tokyo ’24 Proprietary 2 つのプロダクトの概要 AlloyDB PostgreSQL との完全な互換性を 持つフルマネージド データベース サービス。 ストレージ層の分離をはじめとした 設計レベルの改善により、通常の PostgreSQL より機能・性能が向上 している。 Cloud Run コンテナとしてパッケージ化された ウェブサイト、アプリケーション、 ジョブを実行するフルマネージド サーバーレス プラットフォーム 。 特定の言語では、ソースコードから 直接デプロイにも対応している。
28. 028 Google Cloud Next Tokyo ’24 Proprietary AlloyDB 採用のメリット 高可用性 プライマリ インスタンスの スケールアップ・ダウンが 1 秒未満で実行できるため、 事前の厳密なキャパシティ プランニングが不要。 高速な分析クエリ カラム型エンジンにより分析 クエリが自動で高速化される ため、分析用の DB スナップ ショットや DWH の構築が 不要*。 移植性 前述の通り PostgreSQL との 完全な互換性があるため、 Cloud SQL や他のパブリック クラウドに移行できる。 * RDB 以外のデータを掛け合わせた分析や、サービスを横断した分析ニーズがある場合、 DWH が必要となる。
29. 029 Google Cloud Next Tokyo ’24 Proprietary Cloud Run 採用のメリット クラスタ運用不要 4 ヶ月に 1 回の Kubernetes （K8s）アップデート業務が 不要になるため、運用工数が 小さい。 オートスケール コンテナが自動的にスケール アウト・インするため、運用 工数が小さい。 移植性 OSS の Knative を基盤として いるため、GKE や他のパブ リック クラウドに移行できる。
30. 030 Google Cloud Next Tokyo ’24 Proprietary これまでの話を抽象化すると • どちらも事業の競争優位性に繋がる領域に 経営資源* を効率よく投下すべき点で共通 • 国内のエンジニア採用の難易度を鑑みると 「メリハリをつける」ことはとても重要 *「［新版］企業戦略論【上】基本編」（ジェイ B.バーニー、ダイヤモンド社）によると、経営資源は「財務的資源」「物的資源」 「人的資源」「組織的資源」の 4 つに分類できる。
31. 031 Google Cloud Next Tokyo ’24 Proprietary “言うは易く行うは難し ” • 今から内製化を実施するとしたら「まずは OS レベルから作ろう」とはならない • 一方で、Internal Developer Platform のうち どこを内製化すべきか？というような判断 ＝コア技術の見極めは難しい
32. 032 Google Cloud Next Tokyo ’24 Proprietary 03　今後の課題と挑戦
33. 033 Google Cloud Next Tokyo ’24 Proprietary ソフトウェア開発という経済活動を 対象としたコントローラビリティを、 リーズナブルな範囲の予算 /時間という 入力条件の中で、 ビジネス上必要な システムの機能追加 をしつづけられる ことと定義しましょう。 ” 一般社団法人日本 CTO 協会理事　広木 大地 氏 出典: https://qiita.com/hirokidaichi/items/64b444a89410190d965f（引用および顔写真の掲載許諾取得済） 再掲
34. 034 Google Cloud Next Tokyo ’24 Proprietary 内製化後の課題解決の難しさ • 内製化前は解決すべき課題が明確 • 内製化後は不明確になる（下手すると そのまま社内受託化する） • 内製開発・組織のあるべき姿と現状の ギャップを分析し、注力課題を設定して 解決していく動きが必要
35. 035 Google Cloud Next Tokyo ’24 Proprietary 課題設定にあたり参考になるもの State of DevOps 2014 年から DORA が年次で 発行しているレポート。 企業へのアンケート結果に 基づく調査。 State of Software Delivery 2019 年から CircleCI が年次 で発行しているレポート。 主に CircleCI の実データに 基づく調査。 DX Criteria 日本 CTO 協会が監修・編纂 している企業のデジタル化と ソフトウェア活用のための ガイドライン。
36. 036 Google Cloud Next Tokyo ’24 Proprietary DORA とは • DevOps Research and Assessment • Google Cloud 傘下の研究・調査チーム • ソフトウェアのデリバリーや組織の パフォーマンスを改善するプラクティスを 研究
37. 037 Google Cloud Next Tokyo ’24 4 つの指標とクラスタ 出典: https://zenn.dev/google_cloud_jp/articles/state-of-devops-report-2023（使用許諾取得済）
38. 038 Google Cloud Next Tokyo ’24 Proprietary 新 Data Platform での課題設定 • 各指標における Elite の値と現状の値の ギャップを解決すべき課題と定義 • 中でも特にギャップの大きい指標の改善を 注力課題として設定
39. 039 Google Cloud Next Tokyo ’24 2 つの指標改善に注力 出典: https://zenn.dev/google_cloud_jp/articles/state-of-devops-report-2023（使用許諾取得済）
40. 040 Google Cloud Next Tokyo ’24 Proprietary 改善にかかる労力の違い デプロイ頻度 • 大きな労力が必要 • 自動テストの信頼性・ パフォーマンスの課題に 帰着するため • テストカバレッジと CI の パフォーマンスの可視化 から一歩ずつ実施中 サービス復旧にかかる時間 • 相対的に少ない労力で可能 • 関連する Google Cloud の プロダクトが存在するため • システムの性質にもよるが、 こちらが短縮できれば オンデマンドデプロイに 移行できる場合もある
41. 041 Google Cloud Next Tokyo ’24 Proprietary 障害発生 「サービス復旧にかかる時間」の構造 障害検知 対処開始 障害復旧 Time To Detect (TTD) Time To Engage (TTE) Time To Fix (TTF) 出典: 「SREの探求」（David N. Blank-Edelman著、株式会社オライリー・ジャパン）
42. 042 Google Cloud Next Tokyo ’24 Proprietary TTD / TTF 改善の施策 Cloud Deploy の導入 TTF 短縮に寄与 各環境へのデプロイの度に コンテナイメージをビルド しなくて済むようにする。 Burn-rate Alerting TTD 短縮に寄与 Burn-rate に基づく SLO アラートを設定することで、 障害に早く気づけるように する。 カナリアリリース TTF 短縮に寄与 新しい変更を一部の顧客へ リリースし、問題があれば 自動でロールバックできる ようにする。 実施済 実施済
43. 043 Google Cloud Next Tokyo ’24 Cloud Deploy の導入
44. 044 Google Cloud Next Tokyo ’24 Burn-rate Alerting
45. 045 Google Cloud Next Tokyo ’24 Proprietary おわりに
46. 046 Google Cloud Next Tokyo ’24 Proprietary 1 2 3 EARTHBRAIN では、コアシステムのコントローラ ビリティ向上の ため、その開発の内製化を実施し、2 年弱で完了できた 本発表の要旨 内製化組織の早期立ち上げのポイントは、事業の競争優位性に 繋がる領域に経営資源を効率よく投下すること 内製化後は更なるコントローラ ビリティ向上のため、 DORA が 提唱する指標の一部の改善を注力課題として、解決に挑んでいる
47. Thank you 047 Proprietary