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

Developers X Summit 2025（2025/11/19）での登壇資料です

1. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 重厚⻑⼤企業で顧客価値をスケールさせるための プロダクトづくりとプロダクト開発チームづくりの裏側 Developers X Summit 2025 2025/11/19 三菱重⼯業株式会社 デジタルイノベーション本部 DPI部 SoEグループ プロダクト開発チーム ⼭⽥悠太
2. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 2 ▪ 免責事項 今回の発表は個⼈の⾒解であり、 所属組織を代表するものではありません
3. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 3 ⼭⽥悠太 あだ名: モンゴル（@mongolyy） 内製開発組織のテックリード ・複数チーム横断の技術的課題解消 ・新しい技術分野の探索 ・複数チームの技術の壁打ち相⼿ 趣味：ドライブ、ラグビー観戦 ▪ ⾃⼰紹介
4. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 4 内製開発組織で開発をやっているよという⽅！ ✋
5. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 5 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
6. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 6 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
7. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 7 数⼗の事業部⾨から構成 プラント・インフラ エナジー 航空・防衛・宇宙 物流・冷熱・ ドライブシステム ▪ 三菱重⼯業について
8. © 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 ▪ デジタル内製組織について
9. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 9 拡張機能 UNTEN [機械運転] TANOMI [問合せ] HOJYU [部品購⼊] SHIRABE [ナレッジベース] SEIBI [作業依頼] HOSYU [機械整備] SAGASU [AIを活⽤した横断検索] [カスタマーポータル] TAYORI [ID管理] Web コールセンター チャット お客様 従業員 キーワードと質問 による検索 会話型検索 必要な部品を検索して、 すぐに依頼してみよう。 機械の調⼦がおかしいので、 ⾃分で調べてみよう。 ▪ デジタル内製組織について
10. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 10 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
11. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 11 ▪ 組織ができた頃の3本柱 EX (Employee Experience) CX (Customer Experience) PX (Product Transformation) Vision Strategy 従業員が働きやすくなる お客様が当社と 取引しやすくなる 弊社が次世代の製品を 開発できる 製品のデジタル化 顧客接点のデジタル化 業務のデジタル化 私の所属グループ
12. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 12 ▪ 顧客接点の課題 電話 メール FAX アフターサービスエンジニア 弊社のお客様 課題 弊社からの返答が遅い 外出により リアルタイムな返答は難しい 個別に連絡が来るので 対応が属⼈的になりがち 双⽅がつらい状態
13. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 13 ▪ 組織ができた頃の⽅向性 個別事業部の個別課題に焦点当てて、 仮説検証型アジャイル適⽤を試みながらプロダクトづくりを実践
14. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 14 ▪ 組織ができた頃の活動 PO 事業部⾨ 開発者 /ScM 開発者 開発者 デザイナー ScrumFestOsaka 2021資料より https://speakerdeck.com/mongolyy/scrum-fest-osaka- 2021
15. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 15 ▪ 部品⾒積・受注サイト構築プロジェクトでの苦労 Ø 事業部さんとの信頼貯⾦のなさ Ø 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
16. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 16 ▪ 課題を乗り越え、なんとか価値を提供できるようになった 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
17. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 17 ⼭を超えたら、新たな⼭が⾒えてきた
18. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 18 ▪ 組織ができた頃の⽅向性 個別事業部の要求の近しいところで開発ニーズを汲み取って開発 個別領域＆個別事業部に最適化 課題も解決し、 事業部⾨も⼤満⾜
19. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 19 めでたしめでたし…？ 🤔
20. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 20 ▪ この頃まで⾃分たちがやれたこと A事業部 B事業部 C事業部 営業 設計 製造 アフター サービス … … 9ヶ⽉かけて、1事業部⾨の1つの領域のプロダクトを顧客リリース
21. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 21 もっと早く、 もっと広い領域を⽀援できるようになりたい！ （私⾃⾝の想い）
22. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 22 全社8万⼈とその先の顧客を⽀援できるように なりたい！ （私⾃⾝の想い） 💪
23. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 23 ▪ とはいえ部⾨のニーズは異なる 「アフターサービス」というスコープに絞っても、事業部固有の背景があるため、 解くべき課題も事業部固有 海外⽐率が⾼い 国内⽐率が⾼い 少量・受注⽣産品 量産品 グローバル全体での 在庫管理に課題 B事業部 問い合わせの多⾔語対応 に課題 A事業部 ⼈員が増えず、新しい 保守プランが作れない D事業部 都度⾒積もりが多く、 ⾒積もりに時間がかかる C事業部 ⼀般論として..
24. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 24 🤔 > 全社8万⼈とその先の顧客を⽀援できるように なりたい！ そんなことできるんか？
25. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 25 ▪ 出会ったスライドで、「⼤義」を感じた 本⽇のオープニングキーノートを務められた岩瀬さんの 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
26. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 26 🤩 • 三菱重⼯が変われば、⽇本の製造業が変わる • ⽇本の製造業が変われば⽇本が変わる と、思ってチャンレンジしてみることにした （あくまで個⼈の考えです）
27. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 27 ▪ 縦 (業務) にも横 (事業) にもアジリティ⾼く展開！ A事業部 B事業部 C事業部 営業 設計 製造 アフター サービス … … もっと早く、もっと多くの業務、事業をカバーできることにチャレンジしてみる
28. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 28 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
29. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 29 ▪ 縦 (業務) のスケーリングを考えてみる A事業部 B事業部 C事業部 営業 設計 製造 アフター サービス … … まずはアフターサービス領域のカバー率を増やす
30. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 30 ▪ アフターサービス領域のカバー率を増やす 部品⾒積・発注 アフターサービス領域には複数のドメインがある 問い合わせ管理 マニュアル・FAQ … 機動的に開発できるようにドメインごとにプロダクトを開発し、プロダクト全体で アフターサービス領域のカバーを⽬指す ⼯事依頼 稼働監視
31. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 31 ▪ マルチプロダクトの体制 PO 開発者 部品⾒積・発注 デザイナー プロダクト毎に⾃律的に開発するために、1プロダクト1チームに … PO 開発者 デザイナー PO 開発者 デザイナー 問い合わせ管理 マニュアル・FAQ
32. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 32 ▪ プロダクトチーム制によるサイロ化問題 部品⾒積・発注チーム プロダクトごとに体験の⼀貫性がないという課題が発⽣ 例えば、プロダクトごとに検索画⾯のUI/UXが微妙に違う 問い合わせ管理チーム マニュアル・FAQチーム UIの問題であればデザインシステムを整えれば解決するかもしれない しかし、そもそも各チームが⾃プロダクトの視点で最適解を考えており、 プロダクト横断で対話して仕様をすり合わせるという営みができていなそう プロダクトチーム間のコミュニーケーションが⾜りていないことが原因では？
33. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 33 ▪ サイロ化問題解消のためのコミュニケーション促進 ⼤きく分けて2つの仕組みを作った 場作り 体制作り コミュニケーションする相⼿を限定、明確にするために、 チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム 関係性を構築するために、 協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADR/PDRづくり Ø カジュアルな場：エンジニアのたまり場 https://pub.jmam.co.jp/book/b593881.html
34. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 34 ▪ サイロ化問題解消のためのコミュニケーション促進 ⼤きく分けて2つの仕組みを作った 場作り 体制作り コミュニケーションする相⼿を限定、明確にするために、 チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム 関係性を構築するために、 協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADR/PDRづくり Ø カジュアルな場：エンジニアのたまり場
35. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 35 ▪ オフィシャルな場①：CX Tech どういう活動？ Ø プロダクトチーム横断のタスクや、チーム間のこぼれ球の対応 各チームが普段取り組めない技術探索や技術検証の取り組み Ø バックログを作って、1ヶ⽉に1~3個のタスクを実施 Ø タスクは最⼤1⽇で完了する内容とし、有識者や有志のメンバーでタスクの実施 例えば以下のようなことを決めた Ø AWS Healthの通知情報をキャッチする仕組みを考える Ø サポートするブラウザや推奨解像度を決める Ø BIツール（Amazon QuickSight）を使ってダッシュボードを作ってみる どうだった？ Ø プロダクトチーム外のメンバーと働く機会となり、相互理解、関係性が構築できた
36. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 36 ▪ オフィシャルな場②：プロダクトチーム横断のADR/PDR どういう活動？ Ø POも巻き込んで仕様に関して複数チームで意思決定し、⽂書化 Ø 部内ではADRと呼ばれているが、Architectureにかかわらず、プロダクトの仕様につい てのドキュメントが多いのでPDR(Product Decision Record)と⾔ったほうが正確かも 例えば以下のようなことを決めた Ø 多⾔語対応時の仕様 Ø 各プロダクトが⽤意する環境 Ø ドメイン名やテストユーザーの命名規則 どうだった？ Ø PDRで決まった事項については仕様の差異はなくなった Ø 決まっていない事項が発⾒されたら、すぐにPDRを作るという改善の流れができた
37. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 37 ▪ カジュアルな場：エンジニアのたまり場 どういう活動？ Ø 2部構成 Ø 3分間スピーチ：有志のエンジニアが最近⼯夫したこと、学んだことをLT Ø 井⼾端会議：参加メンバーが普段気になっていることをみんなに相談 Ø 隔週で1時間開催 Ø ⾃由参加でグループ外のメンバーもフリーに参加 Ø 3分間スピーチの例： Ø GitHub Copilotを使い倒す（Custom Instructions編） Ø 井⼾端会議の例： Ø 社内向けアドベントカレンダーのネタ相談 どうだった？ Ø フリーの活動ではあるが、各⾃が価値を感じており、常に有志がLTをやってくれている Ø ゆるく他チームに知⾒を共有できる場となり、他チームの改善にもつながっている
38. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 38 ▪ サイロ化問題解消のためのコミュニケーション促進 ⼤きく分けて2つの仕組みを作った 場作り 体制作り コミュニケーションする相⼿を限定、明確にするために、 チームトポロジーの「プラットフォームチーム」を作る Ø データ連携基盤チーム Ø 共通ヘッダーコンポーネントチーム 関係性を構築するために、 協働する「オフィシャルな場」、会話する「カジュアルな場」を⽤意 Ø オフィシャルな場：CX Tech、ADR/PDRづくり Ø カジュアルな場：エンジニアのたまり場 https://pub.jmam.co.jp/book/b593881.html
39. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 39 ▪ プラットフォームチーム：データ連携基盤チーム チームを作った背景 Ø 当初は、データモデルも連携の仕様も各チームが決めていた Ø 顧客に関するモデルは全プロダクトで使⽤されており、根幹となるデータであるため、 これが異なると体験が異なる Ø 複数チームから⼈を出してバーチャルチームを作ることも試みたが、 同期的な会話が難しく、責任範囲も不明瞭で 負担の偏りや意思決定スピードが鈍る問題があった 対応 Ø チーム横断で議論し、統⼀のモデルを作成した Ø 統⼀されたデータモデリングをベースに、データハブとそれを管理するチームを作った どうなった？ Ø 顧客に関するモデリングは統⼀された Ø 相談相⼿が明確になった データ ハブ 基幹Sys プロダ クトA プロダ クトB
40. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 40 ▪ プラットフォームチーム：共通ヘッダーチーム チームを作った背景 Ø デザインシステム開発を試みたことがあったが、プロダクト数が少ない、 ほとんど増えない状況において、⾒合った効果が得られないと判断し断念 (デザインシステムによって削減される⼯数) < (デザインシステム開発の⼯数 + 各プロダクトの乗り換え⼯ 数 ) Ø 各チームが乗り換えるコストが⼩さく、かつ、仕様が複雑になる構想のあった 共通ヘッダーを開発して配布することで複数チームの⼯数削減に寄与すると考えた どうなった？ Ø ヘッダーに関して挙動がプロダクト間で同⼀になった Ø ヘッダーの組み込みに関する質問、改善要望を出す相⼿が明確になった Ø ヘッダーチームがオーナーシップを持って、⾃律的に機能追加、改善できるようになった
41. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 41 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
42. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 42 ▪ 横(事業) のスケーリングを考えてみる A事業部 B事業部 C事業部 営業 設計 製造 アフター サービス … … それぞれの事業部に展開できるプロダクトを開発する必要がある
43. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 43 ▪ 複数事業部展開の難しさ 商流が異なる、既存のサブシステムが異なるので、求められる体験が異なる 例：既存システムで取引先とEDI連携されると、部品販売の機能は不要など 機能要件の実現 体制⾯ ⼀つのチームが複数の事業部や他のプロダクトチーム、 プラットフォームチームと同時にコミュニケーションするのが⼤変 製品や関連規制、商習慣が異なるので、細かい仕様も異なる 例：表⽰したい項⽬、送料の計算ロジックなど
44. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 44 ▪ 複数事業部展開の難しさに対する対応 複数の事業部の要件を同時に叶える、標準プロダクトの開発 機能要件の実現 体制⾯ コミュニケーションを円滑にするための、カスタマーサクセスチームの構築
45. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 45 ▪ 複数事業部展開の難しさに対する対応 複数の事業部の要件を同時に叶える、標準プロダクトの開発 機能要件の実現 体制⾯ コミュニケーションを円滑にするための、カスタマーサクセスチームの構築
46. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 46 ▪ 複数事業部展開に関する機能要件実現の⽅針 事業部⽬線：「変えたくない業務」「変えていきたい業務」「変えてもいい業務」がある プロダクトチーム⽬線：寄り添ったものを作りたいが、 他の事業部での良い業務フローも横展開していきたい 事業部の考え⽅や体制変更、他の事業部での知⾒を活かして柔軟に変更できるよう 仕様や挙動を設定可能にしたプロダクトを開発する これを標準プロダクトと呼ぶ
47. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 47 ▪ 標準プロダクトの開発 ありたい姿決め A事業部⾨への 提供機能 B事業部⾨への 提供機能 C事業部⾨への 提供機能 D事業部⾨への 提供機能 E事業部⾨への 提供機能 プラットフォーム化 仕様書作成 これまでの事業部で得た知⾒を元に 変更可能とする機能を決定し、 仕様書を作成 プラットフォームとしての主たる価値を 決め
48. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 48 ▪ 標準プロダクトを開発するための技術的⼯夫 環境変数や設定ファイルの値を 切り替えることで挙動を変える 設定ファイルと環境変数 テーブル設計 独⾃の項⽬は、SQLアンチパターン本 の「従属テーブル」の考え⽅で汎⽤的 に扱えるようにしておく 事業部特有となるビジネスロジックは 独⽴したAPIとする 別APIとして切り出す Feature Toggle 事業部固有で検証中の機能は Feature Toggle化して、他に影響がな いようにして検証する https://www.oreilly.co.jp/books/9784814400744/ .env
49. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 49 ▪ 複数事業部展開の難しさに対する対応 標準プロダクトの開発 機能要件の実現 体制⾯ カスタマーサクセスチームの体制構築
50. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 50 ▪ 体制⾯の課題 事業部が増えるごとに、複数プロダクトで⼀貫性のある体験を提供するために、 プロダクトチーム間でデータの仕様や標準プロダクトの設定をすり合わせをする必要が あり、コミュニケーションパスが多くなる 部品⾒積・発注チーム A事業部 B事業部 A事業部に展開する 他のプロダクトチーム x N B事業部に展開する 他のプロダクトチームx N
51. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 51 ▪ 体制⾯の課題に対する解決：カスタマーサクセス(CS)チー ム 事業部視点に⽴つカスタマーサクセスチームを作った 複数プロダクトチームの間を取り持ち、適度なコラボレーションを促す 事業部の課題を把握して優先順位を整理し、その優先順位に従い各チームを⽀援 部品⾒積・発注チーム A事業部向けCSチーム A事業部 B事業部 B事業部向けCSチーム 他のプロダクトチーム
52. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 52 ▪ CSチームを置いて良かったこと・難しかったこと ü 事業部視点で、全体の優先順位付けができるようになった ü 各プロダクトチームの間でボールが落ちることが減った ü CSチームがリードすることで チーム横断でKPIの確認、情報共有、ふりかえりをするようになり、⼀体感が増した 良かったこと 難しかったこと Ø 責任範囲が曖昧に Ø ただし、この課題もふりかえりすることで改善中
53. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 53 ▪ どうなった？ 当初は1事業部1プロダクト導⼊が9ヶ⽉ 1事業部3プロダクトが2ヶ⽉半で導⼊！
54. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 54 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
55. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 55 ▪ 現在の課題感 Ø 横に価値をスケーリングするためには、同時に縦⽅向の課題解決が求められる Ø 課題の解像度が粗いため、課題やソリューション特定のために仮説検証型で進める 必要があるが、時間がかかる A事業部 B事業部 C事業部 部品⾒積・発注 問い合わせ管理 課題中 課題⼤ マニュアル・ FAQ 他のアフター サービス領域 ー ー 課題⼤ 課題中 課題中 ー ー 課題中 課題中 課題⼤
56. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 56 ▪ どうすれば⾼速に仮説検証が回せるか？ 顧客の課題仮説を作る モノを作って検証する ソリューション仮説を作る Ø プロダクトオーナー Ø 顧客の課題仮説を作ることに注⼒ Ø 事業の成⻑やプロダクトがもたらす価値と向き合い、ビジョンをブラッシュアップ Ø 開発者 Ø ⽣成AIを使いこなし、検証のサイクルを上げる Ø 事業のビジネスモデル、業務プロセス理解により課題・ソリューション仮説構築に貢献 相対的に重要度が増す アフターサービスの新領域や 他の業務プロセスの話がでてくるので 難易度が⾼くなる ⽣成AIによって開発のハードルが下がるので、 ソリューション仮説の作り込みの必要性が下がる
57. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 57 三菱重⼯業とは？ 組織のこれまでの取り組みと課題 ▪ アジェンダ 1 2 3 縦⽅向（業務領域）の価値のスケーリング 4 5 横⽅向（事業領域）の価値のスケーリング 今後の展望 〜新たな領域の仮説検証の変化〜 6 まとめ
58. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 58 ▪ まとめ Ø 価値提供の範囲を広げるために、縦⽅向（業務）と横⽅向（事業）への展開を試みた Ø 縦⽅向のスケーリング Ø コミュニケーションしやすい仕組みづくり Ø 場作り Ø オフィシャルな場、カジュアルな場 Ø 組織体制の変更 Ø プラットフォームチームの⽴ち上げ Ø 横⽅向のスケーリング Ø 複数事業部に提供できる標準プロダクト作り Ø コミュニケーションしやすい仕組みづくり Ø 組織体制の変更 Ø カスタマーサクセスチームの⽴ち上げ