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

Transcript

1. 北海道ガス株式会社 小笠原 元気 IT知識ゼロからのスタートで、 事業部における内製開発をどうやって 推進してきたか？ 1 2024.8.29 Nikkei Tech Talk
2. ⾃⼰紹介 Genki （⼩笠原 元気） 北海道ガス株式会社（2017〜） ・Job, Role フロントエンド・バックエンドエンジニア 開発チームのリードエンジニア 趣味︓旅⾏・筋トレ 最近興味があること︓Next.js, Vercel @geivk 2
3. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 3
4. 今⽇のお話しする内容について • 地⽅都市ガス会社で内製開発をどうやって進めてきたか • IT知識ゼロから、どうやって内製開発するまでに⾄ったのか • 事業化するにあたり上司をどうやって説得したか …など内製開発を進めてきたお話、今後の⽬指す姿についてお話しします︕ 4
5. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 5
6. 北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給事業 ガス機器販売 851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円（連結） 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6
7. 業務⽤省エネサービス「Mys3（ミース）」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢（少機能・低価格）が少ない。 Make your smart solution service Mys（ミース）: スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
8. 「Mys3（ミース）」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔（往） 冷温⽔（還） アタッチメント型 制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス
9. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 9
10. Mys3 の構想の当初 10 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信 プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった
11. 従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万 オーダーの発注 11 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況＋ 社内ナレッジの取得 ⇒ 内製開発へ
12. メインの事業による組織的な構造の課題 ガス事業 電⼒事業 クラウド IoT トップダウンの⼤規模開発組織（密結合） ボトムアップのアジャイル的な組織（疎結合） 12 組織 / チームの形がシステムのアーキテクチャに影響する 内製開発を始めるには、従来の組織構造ではうまくいかなさそうだった 引用元：https://www.atlassian.com/blog/teamwork/what- is-conways-law-acmi
13. 内製開発をスタートした経緯 ・業務⽤分野のエネルギーマネジメントにIoTプラットフォームが必要 ・顧客課題の解決のためクラウドプラットフォーム(AWS)を活⽤ ・業務⽤分野は家庭⽤分野と⽐べて、企画部⾨も⼿薄 → 企画・開発を１つのチーム（発⾜時4⼈）で始めることに Next︓ ・どうやって知識ゼロからエンジニアへ成⻑するのか︖ ・どうやって社内合意をとるのか︖
14. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 15
15. IT初⼼者からの脱却: 内製開発の始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ （プログラミングやIoT技術を中⼼に） 技術論者ではなく、技術的な思考と⾏動を 両⽴するスピーディな実践者の集まりが必要 クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 16
16. ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi ESP32 モノ 通信 クラウド ▪知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン 外部コミュニティ すべて独学 ・知的好奇⼼をベースとした「やってみた」の実践 ・部署・部⾨を超えて⾃由に報告しあうコミュニティの役割 ボトムアップの取り組み 学習→熱量→実践→共有→・・・の好循環 17
17. 社内コミュニティの現在の役割と運営 ◆ 運営するモチベーション ・⼈数をモチベーションやKPIにすると達成できないことが多い → 社内の興味がある⼈が1⼈でも来ればOK ◆ コミュニティの役割 既存メンバーでの情報交換・他団体との取り組みも実施 毎⽉やると、ネタがなくなってくる → 2〜3ヶ⽉に1回の頻度で実施
18. 環境と外部コミュニティ • 「やってみる」の熱量 • 「やってみなさい」の上司のサポート ⼼理的安全性や裁量があったことが重要 • 外部コミュニティへの参加 初⼼者ながら「やってみた」を JAWS FESTA 2019 SAPPORO で発表 コミュニティの熱量を⽣で感じた クラウドの最新事例を常に収集できる 19
19. 事業化への道のり: トップダウンでの課題解決の難しさ ステークホルダー （経営層） 企画部⾨ 事業部⾨ 経営層・企画 部⾨主導 企画部⾨の認識 事業部⾨の認識 認識の壁 ボトムアップからいきなり⼤規模プロジェクト化するのは苦しい アジャイルな開発・スモールスタートが難しくなる恐れがあった 20 ⼤規模プロジェクト（従来）の場合
20. 事業部⾨ 事業化への道のり: ボトムアップ・事業部⾨主導 開発 PdM ステークホルダー （部⻑） 最⼩限のステークホルダー とのすり合わせができれば良い 企画 企画の認識 技術の認識 コミュニケーション コストが低い 21 事業部⾨主導の場合
21. とはいえ、どう上司をどう説得したのか︖ ・挑戦することに寛容な社内と雰囲気 ・何でもやってみなさい精神の上司がたまたまいた（ラッキー） → だが、事業として進めるにあたりどう説明するか︖ ・Working Backwards で⾔語化 ・クラウドで実現するお客さまへのメリットやコストメリットを具体的に訴求
22. 事業部⾨ ボトムアップ・事業部⾨主導のコンセンサスの取り⽅ 開発 PdM ステークホルダー （部⻑） 企画 企画の認識 技術の認識 ⾔語化と共通認識 想定プレスリリース Working Backwards 23 裁量
23. 業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 24
24. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 25
25. BizDevOps Biz, Dev, Ops チームが共通の KPI を持って いる状態＝密な連携 • 関⼼事は共通になっている • お互いにそれぞれを理解している • ⾼速に概念検証を繰り返す • 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 他の業務を抱えながら兼業の状態で Biz, Dev, Ops それぞれを全員が経験している Biz Dev Ops 26
26. マネージドサービス/サーバレスのフル活⽤ BizDevOps を少⼈数チームでやり切るには、省⼒化が必要 • 業務⽤向け︓スケール ＜ 運⽤負荷 • 運⽤コストが⾼いものは省く＝とにかくマネージドサービス/サーバレス → インフラレイヤーの管理コストが低い PaaS を中⼼に利⽤ • 開発時には全部⼊りのコンテナ環境を準備、 → エンジニアの教育がないので、環境構築のオーバーヘッドを解消 27
27. デバイスメーカーさんに協⼒頂き、 商⽤デバイスの開発に取り組む 2021年9⽉〜 社員3名 ・フロントエンド ・バックエンド ・クラウド ・通信 デバイスメーカーさん - デバイス - バックエンド - クラウド PLC MCU(マイコン) 各種モジュール コスト低減 半導体不⾜リスク低減 デバイスの仕様変更に向けた開発体制 28
28. フルスタック開発 デバイス開発 要件定義 デバイスメーカーへの”委託”体制（従来） 29 明確な分界点 （API、Shadow etc...） 請負契約 デバイスメーカー SIer等 発注者 ◆ 特徴 ・成果物が約束された契約 ・仕様変更が⽣じた場合の修正に時間とコストがかかる ・発注者が開発業務を理解していないために、責任の押し付け合いが発⽣する可能性有
29. フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制（今回） 30 発注者 デバイスメーカー 準委任契約 ◆ 特徴 ・成果物を約束しない契約 ・現場検証結果に応じた仕様変更が細かく実施されても柔軟に対応できる ・どちらも互いの開発領域をファジーに理解している
30. フロントエンド 開発 クラウド バックエンド 開発 デバイス 開発 デバイスメーカーとの”伴⾛”体制 31 デバイスメーカー フロントエンド⇔バックエンド⇔デバイス 各領域間で変更に耐えうるフレキシブルな開発体制
31. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 内製開発のスタート時に抱えていた課題 IT 初⼼者からの脱却と事業化フェーズの取り組み 技術選定・開発のプラクティス Future works・まとめ 32
32. サービスローンチ後の機能追加 • サービスローンチ後も、お客さまからのフィードバックで機能を実装 • 曜⽇別・時間別のスケジュール運転機能 • 気象情報による天気に連動した運転機能 • 他の機器への拡張性・・・etc. デバイスへの実装は、影響が⼤きい クラウドにて素早く・柔軟に実装 ⾼速に実装し検証しながら フィードバックをもらう お客さま 開発チーム （お客さまに近い⽴場） 33
33. 顧客が求めるコア機能は何か︖ 顧客の80%が求める機能 顧客の50%が求める機能 顧客の20%が求める機能 顧客の5%が求める機能 ・クリティカルユーザージャーニーの分析 ・顧客の潜在的な要望 ・PoC で顧客ニーズを発掘する 34
34. これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ 35
35. これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ ◆ 運⽤省⼒化をし過ぎた結果、チームの技術⼒が不⾜している領域がある →ビジネス上の要件からマネージドサービスに頼りきれない時に痛感 36
36. これまでの反省と現在の課題 ◆ マイクロサービスは少⼈数でやるのはコミュニケーションコストが⾼い →フロントエンドのフレームワークを使い、モジュラーモノリスを⽬指したほ うが良かったかも・・・︖ ◆ 運⽤省⼒化をし過ぎた結果、チームの技術⼒が不⾜している領域がある →ビジネス上の要件からマネージドサービスに頼りきれない時に痛感 ◆ ビジネスのスケール＝組織のスケールなので企画部分が弱いと感じている →兼業のデメリット（アンチパターン）になってしまっている 37
37. 今後の展望と⽬指すチーム・組織の姿（１） ◆ 技術的負債、開発のボトルネックの解消 フロントエンド︓Vue.js から React.js IaC︓TypeScript から Python リプレイスををこの1年間で実施 トレードオフを再考し、他の技術選定も⾒直しをしたい 38
38. 今後の展望と⽬指すチーム・組織の姿（１） ◆ 技術的負債、開発のボトルネックの解消 フロントエンド︓Vue.js から React.js IaC︓TypeScript から Python リプレイスををこの1年間で実施 トレードオフを再考し、他の技術選定も⾒直しをしたい ◆ チームメンバーのスコープの適正化 異動のリスクに耐えるため、浅く広くスキルをつけている 知識の深化という観点からも、ある程度分業しスコープを適正化したい 39
39. 今後の展望と⽬指すチーム・組織の姿（２） ◆ ビジネス価値の向上と組織のスケール 付加価値やエンゲージメントを⾼める機能の開発 ビジネス価値向上とともに組織をスケールしたい （少なくとも、兼業状態の解消をしたい） 40
40. 今後の展望と⽬指すチーム・組織の姿（２） ◆ ビジネス価値の向上と組織のスケール 付加価値やエンゲージメントを⾼める機能の開発 ビジネス価値向上とともに組織をスケールしたい （少なくとも、兼業状態の解消をしたい） ◆ 他事業部へのナレッジの展開 事業化やアプリケーション開発のナレッジを横展開 他事業部の⽀援やプロジェクト推進を加速 41
41. まとめ • IT知識ゼロからでも、社内・社外コミュニティで着実にスキルアップし 内製開発から事業化までに取り組むことができた • 事業化フェーズでは、Working Backwards で想定プレスリリースを作成し ⾔語化と共通認識を持つことが効果的であった • マネージドサービス/サーバレスのフル活⽤で省⼒化し BizDevOps を実現 • 従来形式の「請負」⽅式ではなく「伴⾛」体制をとることで変更に耐えうる フレキシブルな開発体制を構築 42
42. Thank you!