IT知識ゼロからのスタートで、事業部における内製開発をどうやって推進してきたか？/How did we promote in-house development by starting from scratch?

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)を活⽤・業務⽤分野は家庭⽤分野と⽐べて、企画部⾨も⼿薄 → 企画・開発を１つのチーム（発⾜時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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Thank you!