重厚長大企業で、顧客価値をスケールさせるためのプロダクトづくりとプロダクト開発チームづくりの裏側 / Developers X Summit 2025

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 重厚⻑⼤企業で顧客価値をスケールさせるためのプロダクトづくりとプロダクト開発チームづくりの裏側
Developers X Summit 2025 2025/11/19 三菱重⼯業株式会社デジタルイノベーション本部 DPI部 SoEグループプロダクト開発チーム⼭⽥悠太

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 2 ▪
免責事項今回の発表は個⼈の⾒解であり、所属組織を代表するものではありません

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 3 ⼭⽥悠太
あだ名: モンゴル（@mongolyy）内製開発組織のテックリード・複数チーム横断の技術的課題解消・新しい技術分野の探索・複数チームの技術の壁打ち相⼿趣味：ドライブ、ラグビー観戦 ▪ ⾃⼰紹介

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 4 内製開発組織で開発をやっているよという⽅！
✋

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 5 三菱重⼯業とは？
組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング今後の展望〜新たな領域の仮説検証の変化〜 6 まとめ

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 7 数⼗の事業部⾨から構成
プラント・インフラエナジー航空・防衛・宇宙物流・冷熱・ドライブシステム ▪ 三菱重⼯業について

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 8 事業部⾨・事業会社
対応資源中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨課題ビジネスIT IoT AI CRM Service Automation 中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨中規模事業部⾨ UX Design Agile DevOps デジタル内製組織 ʻ18/1- 事業ドメイン組織・ʼ20/4- 全社組織 SFA Sales Automation MA Marketing Automation ▪ デジタル内製組織について

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 9 拡張機能
UNTEN [機械運転] TANOMI [問合せ] HOJYU [部品購⼊] SHIRABE [ナレッジベース] SEIBI [作業依頼] HOSYU [機械整備] SAGASU [AIを活⽤した横断検索] [カスタマーポータル] TAYORI [ID管理] Web コールセンターチャットお客様従業員キーワードと質問による検索会話型検索必要な部品を検索して、すぐに依頼してみよう。機械の調⼦がおかしいので、⾃分で調べてみよう。 ▪ デジタル内製組織について

組織ができた頃の3本柱 EX (Employee Experience) CX (Customer Experience) PX (Product Transformation) Vision Strategy 従業員が働きやすくなるお客様が当社と取引しやすくなる弊社が次世代の製品を開発できる製品のデジタル化顧客接点のデジタル化業務のデジタル化私の所属グループ

顧客接点の課題電話メール FAX アフターサービスエンジニア弊社のお客様課題弊社からの返答が遅い外出によりリアルタイムな返答は難しい個別に連絡が来るので対応が属⼈的になりがち双⽅がつらい状態

組織ができた頃の⽅向性個別事業部の個別課題に焦点当てて、仮説検証型アジャイル適⽤を試みながらプロダクトづくりを実践

組織ができた頃の活動 PO 事業部⾨開発者 /ScM 開発者開発者デザイナー ScrumFestOsaka 2021資料より https://speakerdeck.com/mongolyy/scrum-fest-osaka- 2021

部品⾒積・受注サイト構築プロジェクトでの苦労 Ø 事業部さんとの信頼貯⾦のなさ Ø 100点の完成度で作りたい事業部⾨と、少しずつ作って検証しながら作っていきたい私達のギャップ ScrumFestOsaka 2021資料より pmconf 2024 武智資料より https://speakerdeck.com/mongolyy/scrum-fest-osaka-2021 https://speakerdeck.com/tkchy/zhong-hou-chang-da-namonodukuriqi-ye- niokerupurodakutomanezimentonotiao-zhan-toku-nao

課題を乗り越え、なんとか価値を提供できるようになった ScrumFestOsaka 2021資料より pmconf 2024 武智資料より https://speakerdeck.com/mongolyy/scrum-fest-osaka-2021 https://speakerdeck.com/tkchy/zhong-hou-chang-da-namonodukuriqi-ye- niokerupurodakutomanezimentonotiao-zhan-toku-nao

組織ができた頃の⽅向性個別事業部の要求の近しいところで開発ニーズを汲み取って開発個別領域＆個別事業部に最適化課題も解決し、事業部⾨も⼤満⾜

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 19 めでたしめでたし…？
🤔

この頃まで⾃分たちがやれたこと A事業部 B事業部 C事業部営業設計製造アフターサービス … … 9ヶ⽉かけて、1事業部⾨の1つの領域のプロダクトを顧客リリース

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 21 もっと早く、
もっと広い領域を⽀援できるようになりたい！（私⾃⾝の想い）

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 22 全社8万⼈とその先の顧客を⽀援できるように
なりたい！（私⾃⾝の想い） 💪

とはいえ部⾨のニーズは異なる「アフターサービス」というスコープに絞っても、事業部固有の背景があるため、解くべき課題も事業部固有海外⽐率が⾼い国内⽐率が⾼い少量・受注⽣産品量産品グローバル全体での在庫管理に課題 B事業部問い合わせの多⾔語対応に課題 A事業部⼈員が増えず、新しい保守プランが作れない D事業部都度⾒積もりが多く、⾒積もりに時間がかかる C事業部⼀般論として..

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 24 🤔
> 全社8万⼈とその先の顧客を⽀援できるようになりたい！そんなことできるんか？

出会ったスライドで、「⼤義」を感じた本⽇のオープニングキーノートを務められた岩瀬さんの RSGT(Regional Scrum Gathering Tokyo) 2023のクロージングキーノートに強く共感した https://speakerdeck.com/iwashi86/the-reason-why-changing-organization-is-so-hard-what-i-thought-and-faced-for-more-than-several-years

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 26 🤩
• 三菱重⼯が変われば、⽇本の製造業が変わる • ⽇本の製造業が変われば⽇本が変わると、思ってチャンレンジしてみることにした（あくまで個⼈の考えです）

縦 (業務) にも横 (事業) にもアジリティ⾼く展開！ A事業部 B事業部 C事業部営業設計製造アフターサービス … … もっと早く、もっと多くの業務、事業をカバーできることにチャレンジしてみる

縦 (業務) のスケーリングを考えてみる A事業部 B事業部 C事業部営業設計製造アフターサービス … … まずはアフターサービス領域のカバー率を増やす

アフターサービス領域のカバー率を増やす部品⾒積・発注アフターサービス領域には複数のドメインがある問い合わせ管理マニュアル・FAQ … 機動的に開発できるようにドメインごとにプロダクトを開発し、プロダクト全体でアフターサービス領域のカバーを⽬指す⼯事依頼稼働監視

マルチプロダクトの体制 PO 開発者部品⾒積・発注デザイナープロダクト毎に⾃律的に開発するために、1プロダクト1チームに … PO 開発者デザイナー PO 開発者デザイナー問い合わせ管理マニュアル・FAQ

プロダクトチーム制によるサイロ化問題部品⾒積・発注チームプロダクトごとに体験の⼀貫性がないという課題が発⽣例えば、プロダクトごとに検索画⾯のUI/UXが微妙に違う問い合わせ管理チームマニュアル・FAQチーム UIの問題であればデザインシステムを整えれば解決するかもしれないしかし、そもそも各チームが⾃プロダクトの視点で最適解を考えており、プロダクト横断で対話して仕様をすり合わせるという営みができていなそうプロダクトチーム間のコミュニーケーションが⾜りていないことが原因では？

サイロ化問題解消のためのコミュニケーション促進⼤きく分けて2つの仕組みを作った場作り体制作りコミュニケーションする相⼿を限定、明確にするために、チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム関係性を構築するために、協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADRづくり Ø カジュアルな場：エンジニアのたまり場 https://pub.jmam.co.jp/book/b593881.html

サイロ化問題解消のためのコミュニケーション促進⼤きく分けて2つの仕組みを作った場作り体制作りコミュニケーションする相⼿を限定、明確にするために、チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム関係性を構築するために、協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADR/PDRづくり Ø カジュアルな場：エンジニアのたまり場

オフィシャルな場①：CX Tech どういう活動？ Ø プロダクトチーム横断のタスクや、チーム間のこぼれ球の対応各チームが普段取り組めない技術探索や技術検証の取り組み Ø バックログを作って、1ヶ⽉に1~3個のタスクを実施 Ø タスクは最⼤1⽇で完了する内容とし、有識者や有志のメンバーでタスクの実施例えば以下のようなことを決めた Ø AWS Healthの通知情報をキャッチする仕組みを考える Ø サポートするブラウザや推奨解像度を決める Ø BIツール（Amazon QuickSight）を使ってダッシュボードを作ってみるどうだった？ Ø プロダクトチーム外のメンバーと働く機会となり、相互理解、関係性が構築できた

オフィシャルな場②：プロダクトチーム横断のADR/PDR どういう活動？ Ø POも巻き込んで仕様に関して複数チームで意思決定し、⽂書化 Ø 部内ではADRと呼ばれているが、Architectureにかかわらず、プロダクトの仕様についてのドキュメントが多いのでPDR(Product Decision Record)と⾔ったほうが正確かも例えば以下のようなことを決めた Ø 多⾔語対応時の仕様 Ø 各プロダクトが⽤意する環境 Ø ドメイン名やテストユーザーの命名規則どうだった？ Ø PDRで決まった事項については仕様の差異はなくなった Ø 決まっていない事項が発⾒されたら、すぐにPDRを作るという改善の流れができた

カジュアルな場：エンジニアのたまり場どういう活動？ Ø 2部構成 Ø 3分間スピーチ：有志のエンジニアが最近⼯夫したこと、学んだことをLT Ø 井⼾端会議：参加メンバーが普段気になっていることをみんなに相談 Ø 隔週で1時間開催 Ø ⾃由参加でグループ外のメンバーもフリーに参加 Ø 3分間スピーチの例： Ø GitHub Copilotを使い倒す（Custom Instructions編） Ø 井⼾端会議の例： Ø 社内向けアドベントカレンダーのネタ相談どうだった？ Ø フリーの活動ではあるが、各⾃が価値を感じており、常に有志がLTをやってくれている Ø ゆるく他チームに知⾒を共有できる場となり、他チームの改善にもつながっている

サイロ化問題解消のためのコミュニケーション促進⼤きく分けて2つの仕組みを作った場作り体制作りコミュニケーションする相⼿を限定、明確にするために、チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム関係性を構築するために、協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADR/PDRづくり Ø カジュアルな場：エンジニアのたまり場 https://pub.jmam.co.jp/book/b593881.html

プラットフォームチーム：データ連携基盤チームチームを作った背景 Ø 当初は、データモデルも連携の仕様も各チームが決めていた Ø 顧客に関するモデルは全プロダクトで使⽤されており、根幹となるデータであるため、これが異なると体験が異なる Ø 複数チームから⼈を出してバーチャルチームを作ることも試みたが、同期的な会話が難しく、責任範囲も不明瞭で負担の偏りや意思決定スピードが鈍る問題があった対応 Ø チーム横断で議論し、統⼀のモデルを作成した Ø 統⼀されたデータモデリングをベースに、データハブとそれを管理するチームを作ったどうなった？ Ø 顧客に関するモデリングは統⼀された Ø 相談相⼿が明確になったデータハブ基幹Sys プロダクトA プロダクトB

プラットフォームチーム：共通ヘッダーチームチームを作った背景 Ø デザインシステム開発を試みたことがあったが、プロダクト数が少ない、ほとんど増えない状況において、⾒合った効果が得られないと判断し断念 (デザインシステムによって削減される⼯数) < (デザインシステム開発の⼯数 + 各プロダクトの乗り換え⼯数 ) Ø 各チームが乗り換えるコストが⼩さく、かつ、仕様が複雑になる構想のあった共通ヘッダーを開発して配布することで複数チームの⼯数削減に寄与すると考えたどうなった？ Ø ヘッダーに関して挙動がプロダクト間で同⼀になった Ø ヘッダーの組み込みに関する質問、改善要望を出す相⼿が明確になった Ø ヘッダーチームがオーナーシップを持って、⾃律的に機能追加、改善できるようになった

横(事業) のスケーリングを考えてみる A事業部 B事業部 C事業部営業設計製造アフターサービス … … それぞれの事業部に展開できるプロダクトを開発する必要がある

複数事業部展開の難しさ商流が異なる、既存のサブシステムが異なるので、求められる体験が異なる例：既存システムで取引先とEDI連携されると、部品販売の機能は不要など機能要件の実現体制⾯⼀つのチームが複数の事業部や他のプロダクトチーム、プラットフォームチームと同時にコミュニケーションするのが⼤変製品や関連規制、商習慣が異なるので、細かい仕様も異なる例：表⽰したい項⽬、送料の計算ロジックなど

複数事業部展開の難しさに対する対応複数の事業部の要件を同時に叶える、標準プロダクトの開発機能要件の実現体制⾯コミュニケーションを円滑にするための、カスタマーサクセスチームの構築

複数事業部展開に関する機能要件実現の⽅針事業部⽬線：「変えたくない業務」「変えていきたい業務」「変えてもいい業務」があるプロダクトチーム⽬線：寄り添ったものを作りたいが、他の事業部での良い業務フローも横展開していきたい事業部の考え⽅や体制変更、他の事業部での知⾒を活かして柔軟に変更できるよう仕様や挙動を設定可能にしたプロダクトを開発するこれを標準プロダクトと呼ぶ

標準プロダクトの開発ありたい姿決め A事業部⾨への提供機能 B事業部⾨への提供機能 C事業部⾨への提供機能 D事業部⾨への提供機能 E事業部⾨への提供機能プラットフォーム化仕様書作成これまでの事業部で得た知⾒を元に変更可能とする機能を決定し、仕様書を作成プラットフォームとしての主たる価値を決め

標準プロダクトを開発するための技術的⼯夫環境変数や設定ファイルの値を切り替えることで挙動を変える設定ファイルと環境変数テーブル設計独⾃の項⽬は、SQLアンチパターン本の「従属テーブル」の考え⽅で汎⽤的に扱えるようにしておく事業部特有となるビジネスロジックは独⽴したAPIとする別APIとして切り出す Feature Toggle 事業部固有で検証中の機能は Feature Toggle化して、他に影響がないようにして検証する https://www.oreilly.co.jp/books/9784814400744/ .env

複数事業部展開の難しさに対する対応標準プロダクトの開発機能要件の実現体制⾯カスタマーサクセスチームの体制構築

体制⾯の課題事業部が増えるごとに、複数プロダクトで⼀貫性のある体験を提供するために、プロダクトチーム間でデータの仕様や標準プロダクトの設定をすり合わせをする必要があり、コミュニケーションパスが多くなる部品⾒積・発注チーム A事業部 B事業部 A事業部に展開する他のプロダクトチーム x N B事業部に展開する他のプロダクトチームx N

体制⾯の課題に対する解決：カスタマーサクセス(CS)チーム事業部視点に⽴つカスタマーサクセスチームを作った複数プロダクトチームの間を取り持ち、適度なコラボレーションを促す事業部の課題を把握して優先順位を整理し、その優先順位に従い各チームを⽀援部品⾒積・発注チーム A事業部向けCSチーム A事業部 B事業部 B事業部向けCSチーム他のプロダクトチーム

CSチームを置いて良かったこと・難しかったこと ü 事業部視点で、全体の優先順位付けができるようになった ü 各プロダクトチームの間でボールが落ちることが減った ü CSチームがリードすることでチーム横断でKPIの確認、情報共有、ふりかえりをするようになり、⼀体感が増した良かったこと難しかったこと Ø 責任範囲が曖昧に Ø ただし、この課題もふりかえりすることで改善中

どうなった？当初は1事業部1プロダクト導⼊が9ヶ⽉ 1事業部3プロダクトが2ヶ⽉半で導⼊！

現在の課題感 Ø 横に価値をスケーリングするためには、同時に縦⽅向の課題解決が求められる Ø 課題の解像度が粗いため、課題やソリューション特定のために仮説検証型で進める必要があるが、時間がかかる A事業部 B事業部 C事業部部品⾒積・発注問い合わせ管理課題中課題⼤マニュアル・ FAQ 他のアフターサービス領域ーー課題⼤課題中課題中ーー課題中課題中課題⼤

どうすれば⾼速に仮説検証が回せるか？顧客の課題仮説を作るモノを作って検証するソリューション仮説を作る Ø プロダクトオーナー Ø 顧客の課題仮説を作ることに注⼒ Ø 事業の成⻑やプロダクトがもたらす価値と向き合い、ビジョンをブラッシュアップ Ø 開発者 Ø ⽣成AIを使いこなし、検証のサイクルを上げる Ø 事業のビジネスモデル、業務プロセス理解により課題・ソリューション仮説構築に貢献相対的に重要度が増すアフターサービスの新領域や他の業務プロセスの話がでてくるので難易度が⾼くなる⽣成AIによって開発のハードルが下がるので、ソリューション仮説の作り込みの必要性が下がる

まとめ Ø 価値提供の範囲を広げるために、縦⽅向（業務）と横⽅向（事業）への展開を試みた Ø 縦⽅向のスケーリング Ø コミュニケーションしやすい仕組みづくり Ø 場作り Ø オフィシャルな場、カジュアルな場 Ø 組織体制の変更 Ø プラットフォームチームの⽴ち上げ Ø 横⽅向のスケーリング Ø 複数事業部に提供できる標準プロダクト作り Ø コミュニケーションしやすい仕組みづくり Ø 組織体制の変更 Ø カスタマーサクセスチームの⽴ち上げ

重厚長大企業で、顧客価値をスケールさせるためのプロダクトづくりとプロダクト開発チームづくりの裏...

重厚長大企業で、顧客価値をスケールさせるためのプロダクトづくりとプロダクト開発チームづくりの裏側 / Developers X Summit 2025

More Decks by モンゴル (mongolyy)

Other Decks in Technology

Featured

Transcript