Slide 1

Slide 1 text

北海道ガス株式会社 小笠原 元気 IT知識ゼロからのスタートで、 事業部における内製開発をどうやって 推進してきたか? 1 2024.8.29 Nikkei Tech Talk

Slide 2

Slide 2 text

⾃⼰紹介 Genki (⼩笠原 元気) 北海道ガス株式会社(2017〜) ・Job, Role フロントエンド・バックエンドエンジニア 開発チームのリードエンジニア 趣味︓旅⾏・筋トレ 最近興味があること︓Next.js, Vercel @geivk 2

Slide 3

Slide 3 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 3

Slide 4

Slide 4 text

今⽇のお話しする内容について ● 地⽅都市ガス会社で内製開発をどうやって進めてきたか ● IT知識ゼロから、どうやって内製開発するまでに⾄ったのか ● 事業化するにあたり上司をどうやって説得したか …など内製開発を進めてきたお話、今後の⽬指す姿についてお話しします︕ 4

Slide 5

Slide 5 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 5

Slide 6

Slide 6 text

北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給事業 ガス機器販売 851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円(連結) 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6

Slide 7

Slide 7 text

業務⽤省エネサービス「Mys3(ミース)」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢(少機能・低価格)が少ない。 Make your smart solution service Mys(ミース): スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7

Slide 8

Slide 8 text

「Mys3(ミース)」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔(往) 冷温⽔(還) アタッチメント型 制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス

Slide 9

Slide 9 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 9

Slide 10

Slide 10 text

Mys3 の構想の当初 10 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信 プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった

Slide 11

Slide 11 text

従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万 オーダーの発注 11 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況+ 社内ナレッジの取得 ⇒ 内製開発へ

Slide 12

Slide 12 text

メインの事業による組織的な構造の課題 ガス事業 電⼒事業 クラウド IoT トップダウンの⼤規模開発組織(密結合) ボトムアップのアジャイル的な組織(疎結合) 12 組織 / チームの形がシステムのアーキテクチャに影響する 内製開発を始めるには、従来の組織構造ではうまくいかなさそうだった 引用元:https://www.atlassian.com/blog/teamwork/what- is-conways-law-acmi

Slide 13

Slide 13 text

内製開発をスタートした経緯 ・業務⽤分野のエネルギーマネジメントにIoTプラットフォームが必要 ・顧客課題の解決のためクラウドプラットフォーム(AWS)を活⽤ ・業務⽤分野は家庭⽤分野と⽐べて、企画部⾨も⼿薄 → 企画・開発を1つのチーム(発⾜時4⼈)で始めることに Next︓ ・どうやって知識ゼロからエンジニアへ成⻑するのか︖ ・どうやって社内合意をとるのか︖

Slide 14

Slide 14 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 15

Slide 15

Slide 15 text

IT初⼼者からの脱却: 内製開発の始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ (プログラミングやIoT技術を中⼼に) 技術論者ではなく、技術的な思考と⾏動を 両⽴するスピーディな実践者の集まりが必要 クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 16

Slide 16

Slide 16 text

■技術習得 プログラミング⾔語 IoT技術 Raspberry Pi ESP32 モノ 通信 クラウド ■知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン 外部コミュニティ すべて独学 ・知的好奇⼼をベースとした「やってみた」の実践 ・部署・部⾨を超えて⾃由に報告しあうコミュニティの役割 ボトムアップの取り組み 学習→熱量→実践→共有→・・・の好循環 17

Slide 17

Slide 17 text

社内コミュニティの現在の役割と運営 ◆ 運営するモチベーション ・⼈数をモチベーションやKPIにすると達成できないことが多い → 社内の興味がある⼈が1⼈でも来ればOK ◆ コミュニティの役割 既存メンバーでの情報交換・他団体との取り組みも実施 毎⽉やると、ネタがなくなってくる → 2〜3ヶ⽉に1回の頻度で実施

Slide 18

Slide 18 text

環境と外部コミュニティ ● 「やってみる」の熱量 ● 「やってみなさい」の上司のサポート ⼼理的安全性や裁量があったことが重要 ● 外部コミュニティへの参加 初⼼者ながら「やってみた」を JAWS FESTA 2019 SAPPORO で発表 コミュニティの熱量を⽣で感じた クラウドの最新事例を常に収集できる 19

Slide 19

Slide 19 text

事業化への道のり: トップダウンでの課題解決の難しさ ステークホルダー (経営層) 企画部⾨ 事業部⾨ 経営層・企画 部⾨主導 企画部⾨の認識 事業部⾨の認識 認識の壁 ボトムアップからいきなり⼤規模プロジェクト化するのは苦しい アジャイルな開発・スモールスタートが難しくなる恐れがあった 20 ⼤規模プロジェクト(従来)の場合

Slide 20

Slide 20 text

事業部⾨ 事業化への道のり: ボトムアップ・事業部⾨主導 開発 PdM ステークホルダー (部⻑) 最⼩限のステークホルダー とのすり合わせができれば良い 企画 企画の認識 技術の認識 コミュニケーション コストが低い 21 事業部⾨主導の場合

Slide 21

Slide 21 text

とはいえ、どう上司をどう説得したのか︖ ・挑戦することに寛容な社内と雰囲気 ・何でもやってみなさい精神の上司がたまたまいた(ラッキー) → だが、事業として進めるにあたりどう説明するか︖ ・Working Backwards で⾔語化 ・クラウドで実現するお客さまへのメリットやコストメリットを具体的に訴求

Slide 22

Slide 22 text

事業部⾨ ボトムアップ・事業部⾨主導のコンセンサスの取り⽅ 開発 PdM ステークホルダー (部⻑) 企画 企画の認識 技術の認識 ⾔語化と共通認識 想定プレスリリース Working Backwards 23 裁量

Slide 23

Slide 23 text

業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 24

Slide 24

Slide 24 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 25

Slide 25

Slide 25 text

BizDevOps Biz, Dev, Ops チームが共通の KPI を持って いる状態=密な連携 ● 関⼼事は共通になっている ● お互いにそれぞれを理解している ● ⾼速に概念検証を繰り返す ● 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 他の業務を抱えながら兼業の状態で Biz, Dev, Ops それぞれを全員が経験している Biz Dev Ops 26

Slide 26

Slide 26 text

マネージドサービス/サーバレスのフル活⽤ BizDevOps を少⼈数チームでやり切るには、省⼒化が必要 ● 業務⽤向け︓スケール < 運⽤負荷 ● 運⽤コストが⾼いものは省く=とにかくマネージドサービス/サーバレス → インフラレイヤーの管理コストが低い PaaS を中⼼に利⽤ ● 開発時には全部⼊りのコンテナ環境を準備、 → エンジニアの教育がないので、環境構築のオーバーヘッドを解消 27

Slide 27

Slide 27 text

デバイスメーカーさんに協⼒頂き、 商⽤デバイスの開発に取り組む 2021年9⽉〜 社員3名 ・フロントエンド ・バックエンド ・クラウド ・通信 デバイスメーカーさん - デバイス - バックエンド - クラウド PLC MCU(マイコン) 各種モジュール コスト低減 半導体不⾜リスク低減 デバイスの仕様変更に向けた開発体制 28

Slide 28

Slide 28 text

フルスタック開発 デバイス開発 要件定義 デバイスメーカーへの”委託”体制(従来) 29 明確な分界点 (API、Shadow etc...) 請負契約 デバイスメーカー SIer等 発注者 ◆ 特徴 ・成果物が約束された契約 ・仕様変更が⽣じた場合の修正に時間とコストがかかる ・発注者が開発業務を理解していないために、責任の押し付け合いが発⽣する可能性有

Slide 29

Slide 29 text

フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制(今回) 30 発注者 デバイスメーカー 準委任契約 ◆ 特徴 ・成果物を約束しない契約 ・現場検証結果に応じた仕様変更が細かく実施されても柔軟に対応できる ・どちらも互いの開発領域をファジーに理解している

Slide 30

Slide 30 text

フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制 31 デバイスメーカー フロントエンド⇔バックエンド⇔デバイス 各領域間で変更に耐えうるフレキシブルな開発体制

Slide 31

Slide 31 text

Agenda 会社 / プロジェクト(Mys3︓ミース)概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 32

Slide 32

Slide 32 text

サービスローンチ後の機能追加 ● サービスローンチ後も、お客さまからのフィードバックで機能を実装 ● 曜⽇別・時間別のスケジュール運転機能 ● 気象情報による天気に連動した運転機能 ● 他の機器への拡張性・・・etc. デバイスへの実装は、影響が⼤きい クラウドにて素早く・柔軟に実装 ⾼速に実装し検証しながら フィードバックをもらう お客さま 開発チーム (お客さまに近い⽴場) 33

Slide 33

Slide 33 text

顧客が求めるコア機能は何か︖ 顧客の80%が求める機能 顧客の50%が求める機能 顧客の20%が求める機能 顧客の5%が求める機能 ・クリティカルユーザージャーニーの分析 ・顧客の潜在的な要望 ・PoC で顧客ニーズを発掘する 34

Slide 34

Slide 34 text

これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ 35

Slide 35

Slide 35 text

これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ ◆ 運⽤省⼒化をし過ぎた結果、チームの技術⼒が不⾜している領域がある →ビジネス上の要件からマネージドサービスに頼りきれない時に痛感 36

Slide 36

Slide 36 text

これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ ◆ 運⽤省⼒化をし過ぎた結果、チームの技術⼒が不⾜している領域がある →ビジネス上の要件からマネージドサービスに頼りきれない時に痛感 ◆ ビジネスのスケール=組織のスケールなので企画部分が弱いと感じている →兼業のデメリット(アンチパターン)になってしまっている 37

Slide 37

Slide 37 text

今後の展望と⽬指すチーム・組織の姿(1) ◆ 技術的負債、開発のボトルネックの解消 フロントエンド︓Vue.js から React.js IaC︓TypeScript から Python リプレイスををこの1年間で実施 トレードオフを再考し、他の技術選定も⾒直しをしたい 38

Slide 38

Slide 38 text

今後の展望と⽬指すチーム・組織の姿(1) ◆ 技術的負債、開発のボトルネックの解消 フロントエンド︓Vue.js から React.js IaC︓TypeScript から Python リプレイスををこの1年間で実施 トレードオフを再考し、他の技術選定も⾒直しをしたい ◆ チームメンバーのスコープの適正化 異動のリスクに耐えるため、浅く広くスキルをつけている 知識の深化という観点からも、ある程度分業しスコープを適正化したい 39

Slide 39

Slide 39 text

今後の展望と⽬指すチーム・組織の姿(2) ◆ ビジネス価値の向上と組織のスケール 付加価値やエンゲージメントを⾼める機能の開発 ビジネス価値向上とともに組織をスケールしたい (少なくとも、兼業状態の解消をしたい) 40

Slide 40

Slide 40 text

今後の展望と⽬指すチーム・組織の姿(2) ◆ ビジネス価値の向上と組織のスケール 付加価値やエンゲージメントを⾼める機能の開発 ビジネス価値向上とともに組織をスケールしたい (少なくとも、兼業状態の解消をしたい) ◆ 他事業部へのナレッジの展開 事業化やアプリケーション開発のナレッジを横展開 他事業部の⽀援やプロジェクト推進を加速 41

Slide 41

Slide 41 text

まとめ ● IT知識ゼロからでも、社内・社外コミュニティで着実にスキルアップし 内製開発から事業化までに取り組むことができた ● 事業化フェーズでは、Working Backwards で想定プレスリリースを作成し ⾔語化と共通認識を持つことが効果的であった ● マネージドサービス/サーバレスのフル活⽤で省⼒化し BizDevOps を実現 ● 従来形式の「請負」⽅式ではなく「伴⾛」体制をとることで変更に耐えうる フレキシブルな開発体制を構築 42

Slide 42

Slide 42 text

Thank you!