Upgrade to Pro — share decks privately, control downloads, hide ads and more …

IT知識ゼロからのスタートで、 事業部における内製開発をどうやって 推進してきたか?/How ...

Genki Ogasawara
August 29, 2024
180

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

Genki Ogasawara

August 29, 2024
Tweet

More Decks by Genki Ogasawara

Transcript

  1. 北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給事業 ガス機器販売

    851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円(連結) 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6
  2. 業務⽤省エネサービス「Mys3(ミース)」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢(少機能・低価格)が少ない。 Make your smart

    solution service Mys(ミース): スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
  3. 「Mys3(ミース)」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔(往) 冷温⽔(還) アタッチメント型

    制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス
  4. Mys3 の構想の当初 10 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信

    プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった
  5. 従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万

    オーダーの発注 11 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況+ 社内ナレッジの取得 ⇒ 内製開発へ
  6. メインの事業による組織的な構造の課題 ガス事業 電⼒事業 クラウド IoT トップダウンの⼤規模開発組織(密結合) ボトムアップのアジャイル的な組織(疎結合) 12 組織 /

    チームの形がシステムのアーキテクチャに影響する 内製開発を始めるには、従来の組織構造ではうまくいかなさそうだった 引用元:https://www.atlassian.com/blog/teamwork/what- is-conways-law-acmi
  7. IT初⼼者からの脱却: 内製開発の始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ (プログラミングやIoT技術を中⼼に) 技術論者ではなく、技術的な思考と⾏動を

    両⽴するスピーディな実践者の集まりが必要 クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 16
  8. ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi ESP32 モノ 通信 クラウド ▪知⾒獲得

    機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン 外部コミュニティ すべて独学 ・知的好奇⼼をベースとした「やってみた」の実践 ・部署・部⾨を超えて⾃由に報告しあうコミュニティの役割 ボトムアップの取り組み 学習→熱量→実践→共有→・・・の好循環 17
  9. 事業化への道のり: トップダウンでの課題解決の難しさ ステークホルダー (経営層) 企画部⾨ 事業部⾨ 経営層・企画 部⾨主導 企画部⾨の認識 事業部⾨の認識

    認識の壁 ボトムアップからいきなり⼤規模プロジェクト化するのは苦しい アジャイルな開発・スモールスタートが難しくなる恐れがあった 20 ⼤規模プロジェクト(従来)の場合
  10. 業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ

    イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 24
  11. BizDevOps Biz, Dev, Ops チームが共通の KPI を持って いる状態=密な連携 • 関⼼事は共通になっている

    • お互いにそれぞれを理解している • ⾼速に概念検証を繰り返す • 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 他の業務を抱えながら兼業の状態で Biz, Dev, Ops それぞれを全員が経験している Biz Dev Ops 26
  12. マネージドサービス/サーバレスのフル活⽤ BizDevOps を少⼈数チームでやり切るには、省⼒化が必要 • 業務⽤向け︓スケール < 運⽤負荷 • 運⽤コストが⾼いものは省く=とにかくマネージドサービス/サーバレス →

    インフラレイヤーの管理コストが低い PaaS を中⼼に利⽤ • 開発時には全部⼊りのコンテナ環境を準備、 → エンジニアの教育がないので、環境構築のオーバーヘッドを解消 27
  13. デバイスメーカーさんに協⼒頂き、 商⽤デバイスの開発に取り組む 2021年9⽉〜 社員3名 ・フロントエンド ・バックエンド ・クラウド ・通信 デバイスメーカーさん -

    デバイス - バックエンド - クラウド PLC MCU(マイコン) 各種モジュール コスト低減 半導体不⾜リスク低減 デバイスの仕様変更に向けた開発体制 28
  14. フルスタック開発 デバイス開発 要件定義 デバイスメーカーへの”委託”体制(従来) 29 明確な分界点 (API、Shadow etc...) 請負契約 デバイスメーカー

    SIer等 発注者 ◆ 特徴 ・成果物が約束された契約 ・仕様変更が⽣じた場合の修正に時間とコストがかかる ・発注者が開発業務を理解していないために、責任の押し付け合いが発⽣する可能性有
  15. フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制(今回) 30 発注者

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

    フロントエンド⇔バックエンド⇔デバイス 各領域間で変更に耐えうるフレキシブルな開発体制
  17. 今後の展望と⽬指すチーム・組織の姿(1) ◆ 技術的負債、開発のボトルネックの解消 フロントエンド︓Vue.js から React.js IaC︓TypeScript から Python リプレイスををこの1年間で実施

    トレードオフを再考し、他の技術選定も⾒直しをしたい ◆ チームメンバーのスコープの適正化 異動のリスクに耐えるため、浅く広くスキルをつけている 知識の深化という観点からも、ある程度分業しスコープを適正化したい 39
  18. まとめ • IT知識ゼロからでも、社内・社外コミュニティで着実にスキルアップし 内製開発から事業化までに取り組むことができた • 事業化フェーズでは、Working Backwards で想定プレスリリースを作成し ⾔語化と共通認識を持つことが効果的であった •

    マネージドサービス/サーバレスのフル活⽤で省⼒化し BizDevOps を実現 • 従来形式の「請負」⽅式ではなく「伴⾛」体制をとることで変更に耐えうる フレキシブルな開発体制を構築 42