エンジニアゼロの組織から内製開発の DX をどう実現したのか / How did we achieve DX in in-house development in an organization with zero engineers?

Transcript

1. 北海道ガス株式会社 小笠原 元気 エンジニアゼロの組織から 内製開発の DX をどう実現したのか 1 2024.5.16 CCoE実践者コミュニティ関西
2. ⾃⼰紹介 Genki （⼩笠原 元気） 北海道ガス株式会社（2017〜） ・Job, Role フロントエンド・バックエンド両⽅やる⼈ 開発チーム(4⼈)のテックリード（⾃称） 趣味︓旅⾏・筋トレ 最近興味があること︓Next.js, Vercel @geivk
3. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
4. How to do 内製開発︖ ◆ チームの⽴ち上げ ← 今⽇はこっちの話 ・チームの存在意義をどうやって確⽴させたのか ・エンジニアゼロから内製開発にどう⽴ち向かったのか ◆ サービスリリース後の安定運⽤ ← 助けてほしいです ロールをどうするか、オンボーディング、組織のスケール、HR の巻き込み
5. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
6. 北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給業 ガス機器販売 907名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,748億円（連結） 2023年10月7日時点 お客さま 件数 ガス︓600,882件 電⼒︓234,083件 会社概要 6
7. 業務⽤省エネサービス「Mys3（ミース）」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢（少機能・低価格）が少ない。 Make your smart solution service Mys（ミース）: スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
8. 「Mys3（ミース）」i-Ch / REM 8 常時計測・監視 データの⾒える化 モニタリング画⾯ 冷温⽔ （往） 冷温⽔ （還） お客さまに提供 するサービス データの⾒える化 モニタリング画⾯ CO2・温度・湿度データ セントラル空調機器 計 測 器 計 測 器 計 測 器 今 後 も サ ー ビ ス 拡 充 予 定
9. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
10. クラウド活⽤推進組織（CCoE）が機能する3つの環境条件※ ・会社／組織としてクラウド活⽤の意思を持つ ・クラウド活⽤において、組織横断かつ構造上の課題を有する ・クラウド活⽤スキルの不⾜やリソースの偏りがある ※ 今から始める CCoE、3 つの環境条件と 3 つの⼼構えとは https://aws.amazon.com/jp/blogs/news/how-to-get-started-your-own-ccoe/
11. クラウド活⽤推進組織（CCoE）が機能する3つの環境条件※ ◆ 当社の2019年時点の状況 ・会社／組織としてクラウド活⽤の意思を持つ 共通基盤プロジェクトが発⾜ ・クラウド活⽤において、組織横断かつ構造上の課題を有する キャパシティプランニングのノウハウはなく、組織構造の課題もあり（持論） ・クラウド活⽤スキルの不⾜やリソースの偏りがある 社内にエンジニアがいない会社 CCoE が 活躍できそう ※ 今から始める CCoE、3 つの環境条件と 3 つの⼼構えとは https://aws.amazon.com/jp/blogs/news/how-to-get-started-your-own-ccoe/
12. メインの事業による組織的な構造の課題 ガス事業 電⼒事業 クラウド IoT 安全第⼀が求められる組織（密結合） アジャイル的な組織（疎結合） 12 組織 / チームの形がシステムのアーキテクチャに影響する 内製開発を始めるには、従来の組織構造ではうまくいかなさそうだった
13. CCoE の不在と事業部の内製開発の関係 クラウドジャーニーにおける障壁を突破するための組織が CCoE → 2019年における⾃部⾨と当社内の状況 1. 社内におけるクラウド活⽤への意志が醸成中 2. 社内 DX の組織 = CCoE ではなく DX プロジェクトチーム 3. クラウド利⽤の問題が解決される環境がない 4. 部⾨内で最後まで解決できそうな課題 CCoE 不在の状態で、課題解決のためにクラウドを使いたかった
14. CCoE の存在とプロジェクトの関係 CCoE 事業部 プロジェクト 共通基盤プロジェクト 事業部 プロジェクトB 事業部 プロジェクトC プラットフォーム （おそらく）これが望ましい姿 クラウド環境 共通ライブラリ
15. 2019年の⾃部⾨状況を振り返ると・・・ CCoE 事業部 プロジェクト 共通基盤プロジェクト 事業部 プロジェクトB 事業部 プロジェクトC プラットフォーム プラット フォーム︖ 汎⽤的なプラットフォームを作るのは難しい エンジニアがいない会社だと作っても使われない可能性が⾼い クラウド環境 共通ライブラリ
16. その結果・・・ ・業務⽤分野のエネルギーマネジメントにIoTプラットフォームが必要 ・顧客課題の解決のためクラウドプラットフォーム(AWS)を活⽤ ・業務⽤分野は家庭⽤分野と⽐べて、企画部⾨も⼿薄 → 企画・開発を１つのチーム（発⾜時4⼈）で始めることに Next︓ ・どうやって知識ゼロからエンジニアへ成⻑するのか︖ ・どうやって社内合意をとるのか︖
17. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
18. 社内コミュニティの始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ （プログラミングやIoT技術を中⼼に） 技術論者ではなく、技術的な思考と⾏動を 両⽴するスピーディな実践者の集まりが必要 クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 18
19. ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi ESP32 モノ 通信 クラウド ▪知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン 外部コミュニティ すべて独学 ・知的好奇⼼をベースとした「やってみた」の実践 ・部署・部⾨を超えて⾃由に報告しあうコミュニティの役割 ボトムアップの取り組み 学習→熱量→実践→共有→・・・の好循環 19
20. 今考えると、これらを満たしている⼈間が 社内コミュニティに集まっていた ※ 今から始める CCoE、3 つの環境条件と 3 つの⼼構えとは https://aws.amazon.com/jp/blogs/news/how-to-get-started-your-own-ccoe/
21. 社内コミュニティの現在の役割と運営の話 ◆ 運営するモチベーション ・⼈数をモチベーションやKPIにすると達成できないことが多い ・社内に感度の⾼い⼈はそもそも少数派 → 1⼈でも社内の興味がある⼈が来ればOK ◆ コミュニティの役割 既存メンバーでの情報交換・他団体との取り組みも実施 毎⽉やると、ネタがなくなってくる → 2〜3ヶ⽉に1回の頻度で実施
22. 社外コミュニティとのかかわり ・HTB三浦さんの存在 → ⾝近にサーバレスですごいことをやってる⼈がいる・・・︕ のちに、JAWS FESTA 2019 への登壇につながる 2023年秋には、AWS Carnival（コミュニティイベント）も⾃社で実施
23. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
24. 現場課題をトップダウンで解決する難しさ ステークホルダー （経営層） 企画部⾨ 事業部⾨ 経営層・企画 部⾨主導 企画部⾨の認識 事業部⾨の認識 認識の壁 事業部⾨や顧客はそこまで求めておらず 現場課題の理解不⾜により 課題に落とし込むことが難しい 24
25. 事業部⾨ ボトムアップ・事業部⾨主導のコミュニケーション⽅法 開発 PdM ステークホルダー （部⻑） 最⼩限のステークホルダー とのすり合わせができれば良い 企画 企画の認識 技術の認識 コミュニケーション コストが低い 25
26. とはいえ、どう上司をどう説得したのか︖ ・挑戦することに寛容な社内と雰囲気 ・何でもやってみなさい精神の上司がたまたまいた（ラッキー） → だが、事業として進めるにあたりどう説明するか︖ ・Working Backwards で⾔語化 ・クラウドで実現するお客さまへのメリットやコストメリットを具体的に訴求
27. 事業部⾨ ボトムアップ・事業部⾨主導のコンセンサスの取り⽅ 開発 PdM ステークホルダー （部⻑） 企画 企画の認識 技術の認識 ⾔語化と共通認識 想定プレスリリース Working Backwards 27
28. 事業部⾨ ボトムアップ・事業部⾨主導のコミュニケーション⽅法 開発 PdM ステークホルダー （部⻑） 企画 企画の認識 技術の認識 28 裁量 調整 他部⾨ 他部⾨
29. 内製開発のターニングポイント 業務⽤ 分野の EMS推進 経営のミッション 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 DX 知的好奇⼼ ビ ジ ネ ス サ イ ド ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 経営課題への 取り組み 29
30. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
31. 従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 従来のシステム開発の課題 IoT クラウド 通信 プログラミング 技術 要件 ? ? ? ? 多額初期投資ができない状況＋ 社内ナレッジの取得 ⇒ 内製開発へ 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万 オーダーの発注 31
32. なんやかんや PoC は成功
33. デバイスメーカーさんに協⼒頂き、 商⽤デバイスの開発に取り組む 2021年9⽉〜 社員3名 ・フロントエンド ・バックエンド ・通信 デバイスメーカーさん - デバイス - バックエンド PLC MCU(マイコン) 各種モジュール コスト低減 半導体不⾜リスク低減 新仕様に向けた体制変更 33
34. まずは⾃らで仕様変更に挑む 34 PLC MCU (マイコン) 各種 モジュール PoC仕様 リリース仕様 AWS IoT Core IoT Shadow SORACOMサービス ・より安価な構成 ・更なる拡張性 ・半導体リスクの解決 クラウド・ バックエンド
35. まずは⾃らで仕様変更に挑む 35 PLC MCU (マイコン) 各種 モジュール PoC仕様 リリース仕様 AWS IoT Core IoT Shadow SORACOMサービス ・マイコンの難しさ ・サーバレス構成の複雑性 ・⼈的リソース不⾜
36. フルスタック開発 デバイス開発 要件定義 デバイスメーカーへの”委託”体制（従来） 36 明確な分界点 （API、Shadow etc...） 請負契約 デバイスメーカー SIer等 発注者 ◆ 特徴 ・成果物が約束された契約 ・仕様変更が⽣じた場合の修正に時間とコストがかかる ・発注者が開発業務を理解していないために、責任の押し付け合いが発⽣
37. フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制（今回） 37 発注者 デバイスメーカー 準委任契約 ◆ 特徴 ・成果物を約束しない契約 ・現場検証結果に応じた仕様変更が細かく実施されても柔軟に対応できる ・どちらも互いの開発領域をファジーに理解している
38. クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制 38 デバイスメーカー クラウド・バックエンドに触れてもらう ⇒ 何ができるか分かったうえでデバイス開発 ⇒ デバイスと密接な要素のバックエンド開発
39. クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制 39 発注者 ”まずは挑戦”の恩恵 ⇒ 的確な開発、修正指⽰
40. フロントエンド 開発 クラウド バックエンド 開発 デバイスメーカーとの”伴⾛”体制 40 発注者 バックエンドとフロントエンドの 押し付け合いや調整が少ない
41. フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制 41 デバイスメーカー フロントエンド⇔バックエンド⇔デバイス 各領域間でフレキシブルな変更に耐えうる組織体制
42. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 CCoE が機能する条件から考える内製開発の舵取り 実践者を集める社内・社外コミュニティの役割 内製開発チームの社内⽣き残り戦略 プラクティス︓内製開発における伴⾛体制 まとめ
43. 社内への波及効果 ◆ PoC 成功 / サービスリリース後の波及効果 → 社内のメンバーから相談があり、他部⾨でもクラウド利⽤開始 ・家庭⽤発電機の管理システム ・電⼒の需要予測 ・社内コミュニティに参加したメンバーで熱量が⾼い⼈をつかまえる ・⾃分たちのノウハウを積極的に社内展開、サポート
44. 失敗したこと / 現在の課題 ・組織がスケールしない 春の⼈事異動で今回もメンバー2名減・・・ 全員他の業務と掛け持ちでやっており、0.3〜0.6⼈⼯しかとれない ・スコープの広さ デザイン・フロントエンド・バックエンド・クラウド・セキュリティ・Ops 兼任の内製開発チームには荷が重すぎるスコープの広さ ⽣成 AI により若⼲負荷は下がる⾒込みだが、それまでもなかなか⼤変
45. まとめ ・エンジニアゼロの組織から、内製開発をスタート CCoE 不在の条件下で部⾨でやり切れる課題に対してスタート エンジニアゼロの組織であったが、社内・社外コミュニティをフル活⽤ ・内製開発の「壁」はパートナー企業と協業することで解決 開発における明確な分界点を設けずに、伴⾛体制を構築した
46. 社外講演の宣伝 6/15(⼟) 10:30〜 @札幌 登壇者︓⼩笠原 クラウドネイティブな省エネ サービスの内製開発で、 BizDevOpsを実現する 6/20(⽊) 15:20〜 @幕張メッセ 登壇者︓栗⽥（執⾏役員） 國奥 「魔の川」「死の⾕」を内製開発 で越境する 〜ガス会社が挑む エネマネサービスの開発〜
47. Thank you!