【DevOpsDays Tokyo 2024】エンジニアゼロからのDevOps​ ​ ~ エンジニア文化のない大企業での内製開発成功への軌跡 ~

DevOpsDays Tokyo 2024の登壇資料です。

Transcript

1. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. エンジニアゼロからのDevOps ~ エンジニア文化のない大企業での内製開発成功への軌跡~ 東京ガス株式会社 中島 潤耶 DevOpsDays Tokyo 2024
2. 2 自己紹介 シンクタンク系大手SIer インフラエンジニア 大手ネット系企業 大手損害保険会社 大手流通系企業 東京ガス myTOKYOGASの内製化 デジタル部隊で内製化 デジタル部隊で内製化 業務システムの内製化 新規事業の検討 中島 潤耶 東京ガス リビング戦略部 ソフトウェアエンジニアリングT チームリーダ兼テックリード
3. 3 自己紹介 シンクタンク系大手SIer インフラエンジニア 大手ネット系企業 大手損害保険会社 大手流通系企業 東京ガス myTOKYOGASの内製化 デジタル部隊で内製化 デジタル部隊で内製化 業務システムの内製化 新規事業の検討 内製化 中島 潤耶 東京ガス リビング戦略部 ソフトウェアエンジニアリングT チームリーダ兼テックリード
4. 4 本日お話すること
5. 5 本日お話すること myTOKYOGASというプロダクトにおいて ビジネスに追随できる柔軟な開発体制が必須だと判断し、内製化に取り組みました。 - 開発体制 歴史ある大きな企業の中で、どのように内製化を進めていったのかをご紹介します。 - 開発サイクル - 内製化の戦略 - レガシーシステムとの向き合い方 ポイント
6. 6 なぜ内製化に踏み切ったのか？
7. 7 家庭用事業が置かれている現状 2016年4月に電力、2017年4月に都市ガスが、小売全面自由化となり、家庭用の分野においても、エネルギー会社はお客さまから選ばれ る存在になった。その結果、デジタル接点によるお客さまの獲得や体験の向上が急務となっている。
8. 8 myTOKYOGASとは ガスや電気の使用量・料金の確認、 貯まったポイントの交換などが行える会員サービス エンジニアゼロ からの内製化へ
9. 9 myTOKYO GASの内製化へ 受発注の関係での開発では、高品質とビジネスニーズに応じた柔軟な開発の両立が困難と判断し、 会員サービス「myTOKYOGAS」の内製化に踏み切り、2023年11月にリリースまで行った。
10. 10 古く歴史のある大企業でどのように内製開発を推進していったか？
11. 11 内製化は、ある一人のマネージャの当事者意識から始まった - エンジニアがゼロの状態のため、外部の支援を受けて開発プロセスの改善やツールの導入を実施 お客さまが求める声に柔軟 かつ素早く対応できるよう にしたい！ このままじゃダメなんだ!! ・グループマネージャー(GM)である及川が「お客さまが求める声に柔軟かつ素早く対応できる体制にする必要がある」と当時 の開発体制に並々ならぬ危機感を抱き、内製化を決断する。 ・中途でエンジニアやデザイナーの採用を及川自らが開始 及川敬仁GM - TypeScriptやGraphQLなどの技術的な用語を理解して、エンジニアと会話するレベルに到達 - 及川の「本気で内製化する。このままではダメなんだ！」という熱に呼応してエンジニアやデザイナーが 続々と参画 - GMも自らシステム開発について学び始める ・エンジニア１号の中島(私)が参画した段階でツールなど基本的なものは導入されていた - エンジニアからオーダしたのは開発端末のMacのみ（それもすぐさま整備された） - 誰かからDX進めなさい！などの指示があったわけではなく、自発的な熱量と当事者意識から始まった - Notion, Miro, Figma, GitHub, Linear, Slackなどのツールは導入済みだった
12. 12 どの範囲を内製化するか？
13. 13 どの範囲を内製化するか？ - 内製化領域においては、フルリプレイスを行う決断(Next.js, GraphQL, NestJSなどでリプレイス) ・内製化する範囲についてはテストが自動化されていて、CI/CDが動いているなどDevOpsを実現したい ・内製化を始めたばかりで、いきなり大きく内製化するのは難しい - ユーザに近いフロントエンドの領域から内製化を決断(他社と差別化したく、最も成果が出やすいと判断) - DevOpsが実現できなければ、品質を維持しながら柔軟な開発をしたいという目的を達成できない ・バックエンドについては、引き続きグループ会社での開発としクラウドリフトのみを進める。 - フロントエンド(アジャイル開発)、バックエンド(ウォータフォール)の混在での開発 - 大企業のシステムは重厚長大。歴史もあり、複雑なものとなっている。
14. 14 内製化の対象をしぼる バックエンド 基幹システム BFF フロントエンドの領域の技術スタックとアーキテクチャを刷新しながら、内製化 GraphQL NestJS Next.js 内製化(フルリプレイス) グループ会社開発(クラウドリフト) CIサーバ 開発者 ユーザ
15. 15 どうやって開発をまわしていくか？
16. 16 開発サイクルをどうしていくか？ ・MVPを定義し、優先度順に開発を行い、間に合わないものはリリース後の実装とする方針とした ・リリースは2023年11月でほぼ必須 - ウォータフォールの混在プロジェクトなので、嫌な予感はしていた - 実装したい機能を洗い出し、簡単なポイント化し、ROI順に並べて整理した。 - 結果として、初期リリースの機能は削られたが、DevOpsを導入して、品質が向上しつつ、より柔軟な開発が可能になったことをチー ムが体感することで、テストの自動化だったり、CI/CDの稼働が当たり前の文化になっていった。 - DevOpsを実現しなければ、品質を維持した柔軟な開発は難しい。CI/CDの整備やテスト自動化などにコストを かけるべきだが、どうしたいか？実現したいことは何か？をチームに問い、チームはDevOpsの実現を選択した。 - 見積もりもされていないが、お尻(リリース日)が決まった「尻ジャイル」だった(絶望)。 - 内製開発で人海戦術は不可能。どうする？ - ROIが高いものから実装していき、ベロシティを計測して、開発の状況を可視化。そこから間に合うかを判断する。
17. 17 開発体制をどうするか？
18. 18 内製開発チームを作る ・社員エンジニアの採用 - リファラルの活用 - コーディングテストの導入 ・既存システムを担当している東京ガスinetからの出向 - とにかく「仲間」としてチームに来てもらうことにこだわった。 - 既存システムとの接続は避けられない。既存システムの知識や人脈は必ず必要。 ・フリーランスエンジニアの力を借りる - 社員エンジニアより柔軟な参画が可能 - 社員エンジニアが自らコードを書き、レビューもすることができるという前提があってこそ - そのまま社員エンジニアになった方も
19. 19 エンジニアがビジネスに溶け込む体制を作る 全員で共通の目的を持ってプロダクトを変えていくという 当事者意識を持てるようにビジネスメンバーと開発メンバーが一体になるような開発体制を構築 myTOKYOGASチーム PO エンジニア デザイナー エンジニア TL TL デザイナーT プロダクトマネジメントT TL エンジニアリングT TL
20. 20 エンジニアもビジネスを考える文化を作る エンジニアも自分たちのビジネスを学び、当事者意識を持ってエンジニアの立場から意見を述べる プロダクトビジョンを考えるワークショップの様子
21. 21 ビジネスメンバーからも全面的なバックアップ ・マネージャー、POを始めとしたビジネスメンバーもプログラミングを学習 - 業務時間の合間でプログラミング研修を受講 - システム開発を他人事としない当事者意識 ・社内の手続きなどはビジネスメンバーによる巻き取り - 社内事情に詳しくない中途エンジニアには特に開発を阻害される要因だった - 「エンジニアに開発に集中してもらおう」というビジネスメンバーからの提案 ・システム開発の課題に対してもエンジニアに伴走しての支援 - マネージャー、ビジネスメンバーとしてできることを常に考えてくれる姿勢(管理ではなく支援) - POから常に感謝の言葉が飛び交う。エンジニアからもPOを支えたいという言葉や空気感が生まれる。
22. 22 レガシーシステムと向き合う
23. 23 レガシーシステムと向き合う ・異なる組織間でのコミュニケーションを可能とするべくPMOを配置 - フロントエンド側とバックエンド側の両方に兼務で所属し、2つのシステム間でのコミュニケーションを促進 ・ウォータフォール側の対応は変更できないため、アジャイル開発の体制が合わせる ・レガシーコードの影響をドメイン層で止める - レガシーシステムの改修は難しい - BFFがファットになることは許容し、ソースコード全体にレガシーシステムの影響が及ばないようにした - 内製化という取り組みに対してバックエンドからの可能な限りの情報提供などの協力をいただいた - ウォータフォール側との結合が必要な機能は、PBIの優先順位を上げる
24. 24 レガシーコードと向き合う ファットBFF mtgバックエンド WEB 基幹システム スマホ ドメイン層 契約 ポイント 会員 ・ ・ ・ WEB用 xっっっx 契約追加 契約を追加する 契約を追加する 料金 ・ ・ ・ 契約追加 * 1. 現在のXXXXを取得します。 * 2. YYYYを追加します。 * 3. ZZZZZZZを変更します。 * 4. XYZXYZを更新します。 契約追加 スマホアプリ用 ・ ・ ・ レガシーコードとの接点をドメイン層に閉じ込めて、影響を極小化する 開発組織の境界線 内製化 グループ会社
25. 25 リリースからエンハンスへ
26. 26 2023年11月のリリースとその後 ・2023年11月に無事リリースして以降、安定稼動 - 2週間1スプリントでのスクラム開発の実践 - 自動テストとCI/CDの稼動 ・ビジネスとエンジニアが融合した文化に変化 - ビジネスメンバーがエンジニアリングを他人事として捉えない当事者意識の高い文化 - ROIに基づいて行われる開発 - 継続的なインテグレーションとデリバリー実現のための自動テスト実装への理解(テストを書く、自動化するのが当たり前の文化) 内製化前後で「myTOKYOGAS開発チーム」の開発手法やツール、そして、文化そのものが大きく変わった。 - エンジニアもビジネスを意識してコードを書く・行動する文化 - DevOpsを実現しないと内製化は困難。
27. 27 お伝えしたいこと
28. 28 お伝えしたいこと ・全員が「当事者意識」と「熱量」を持つ ・ビジョンや目的を共有できるようにエンジニアとビジネスメンバーが一体となった開発体制を作る ・価値に基づいて行動するチームや文化を作る - 当事者意識と熱量が環境や文化を変えていく。 - 内製化のメリットはこの体制が作りやすいこと。 - ただ作るだけの組織のモチベーションの維持は難しい。やる意義をしっかりとチームに展開する。 - 価値を追っているからこそ、MVPを定義できた。初期リリースでは機能を削って、DevOpsを進めるという決断もできた。 - エンジニアがいるだけで、DXや内製化できるわけではない。チーム全体の当事者意識必要。これがすべての土台。 - これができないのであれば、内製をやる意義は薄い。社内での受発注関係へと近づく。