Biz/Dev二刀流からの実践知 - 大企業で挑むプロダクト開発における思考と判断 -

Transcript

1. Biz/Dev 二刀流からの​ 実践知 2025/10/23 三菱重工業株式会社 デジタルイノベーション本部​ DPI 部​ SoE グループ 釘宮 諒 - 大企業で​ 挑むプロダクト開発に​ おける​ 思考と​ 判断 -
2. Profile ♢​ 氏​ 名​ ♢ 趣味 ♢ 年齢 ・釘宮 諒 ・30 歳​ （1994 年生まれ、​ 大谷翔平と​ 同い​ 年）​ ・サッカー、​ ゴルフ、​ お笑い、​ 重工業 経歴 2018 2019 2020 2021 2022 2023 2025 2024 事業部​ 門時代​ （火力部​ 門）​ 大型火力発電所​ （GTCC プラント）の​ 設計​ （機械系）​ IoT サービスの​ 開発と​ データ分析​ （OT 系）​ デジタル部​ 門時代 お客様向けの​ 部​ 品購入アプリ・Customer Portal の​ 開発​ （IT 系）​
3. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 目次 5 プロダクトエンジニアと​ しての​ 取り組み姿勢・マインド
4. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 目次 5 プロダクトエンジニアと​ しての​ 取り組み姿勢・マインド
5. 開発者がメイン 開発者とプロダクトオーナーを兼務 自分​ 自身の​ 役割の​ 変化 今日伝えたい事 ~ 2025/3 2025/4 ~
6. エンジニアからプロダクトエンジニアになってぶつかった課題と、どう対処したかを共有し プロダクトエンジニアとして業務を行う上でのTips や​ ヒントを​ 提供できれば​ 今日伝えたい事
7. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 目次 5 前提と​ なる​ 取り組み姿勢・マインド
8. エナジー 物流・​ 冷熱・ドライブシステム プラント・インフラ 三菱重工とデジタル内製組織、プロダクトの説明 航空​ ・防衛・宇宙 数十の​ 事業部​ 門から​ 構成
9. 三菱重工とデジタル内製組織、プロダクトの説明 資源​ 課題 対応 事業部​ 門​ ・事業会​ 社 ビジネスIT ​ 事業部​ 門​ ​ 事業部​ 門​ ​ ​ 事業部​ 門​ ​ 事業部​ 門​ 事業部​ 門​ CRM SFA MA IoT AI UX Design Agile ​ 事業部​ 門​ ​ 事業部​ 門​ ​ ​ 事業部​ 門​ ​ 事業部​ 門​ 事業部​ 門​ デジタル内製組織
10. 三菱重工とデジタル内製組織、プロダクトの説明
11. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 5 前提と​ なる​ 取り組み姿勢・マインド 目次
12. 開発者がメイン 開発者とプロダクトオーナーを兼務 自分​ 自身の​ 役割の​ 変化 どういった課題に向き合ったのか ~ 2025/3 2025/4 ~
13. 兼務する​ 事の​ メリット コミュニケーションリレーが​ 減り、​ 戦略立案、​ 意思決定から​ 実装、​ 運用までの​ 隙間を​ 埋める​ ことができ、​ Biz/Dev/Ops の​ 一体​ 感を​ 醸成できる​ コミュニケーション 全体最適な判断 複数領域を​ 1 人格が​ 担うことに​ より、​ それぞれの​ 領域に​ おける​ 制約や​ 状況の​ 把握を​ 1 人の​ 思考で​ 実現。​ 全体​ 最適な​ 判断が​ できるように​ どういった課題に向き合ったのか
14. 課題1 ：開発を​ しながら、​ PO と​ して​ プロダクトの​ 中長期的な​ 視点を​ 持つことが​ 難しい​ 開発者と​ しては​ 目の前の​ 課題と​ 向き合い、​ PO と​ しては​ 中長期の​ Vision や​ 戦略を​ 描く​ 責任が​ ある。​ PO と​ しての​ 意思決定は​ " 質" 的な​ 難しさが​ あり、​ 元々が​ 開発者であるが​ 故に、​ 悩むぐらいなら​ 手を​ 動かして​ 開発を​ 進める​ 方が​ 生産的な​ ものを​ 生み出せる、と​ いう​ 引力との​ 鬩ぎ合い​ 短期的な課題に追われるだけでも意味が無く、​ 一方で​ 大局的なビジョンを考えてばかりで目の前の 痛みや実行性を無視しても意味がない。Biz/Dev の​ バランスを​ 上手く​ 取りながら​ 推進する​ 必要が​ ある​ 時間や思考負荷といった自分自身のリソースの使い方に悩む どういった課題に向き合ったのか
15. チームの​ 次の​ アクションを​ 決める​ 際、​ 「新しい​ 価値を​ ユーザーに​ 届ける​ こと​ （User Outcome ）」と​ 「将来的な​ 拡張性や​ 保守性の​ 観点から​ 開発サイドの​ 事情​ （Supplier Outcome ）」の​ どちらを​ 優先するかの​ 判断が​ 難しい​ エンジニアであるが​ 故に、​ 開発者視点の​ 改善や​ 改修が​ 目に​ 入りやすく、​ どうしても​ 開発者都合​ （Supplier Outcome ）を​ 優先してしまいが​ ちに​ なってしまう​ どういった課題に向き合ったのか チームと​ しての​ 優先順位の​ 決め方に​ 悩む 課題2 ：優先順位付けに​ おいて​ 開発側都合を​ 優先してしまいが​ ち
16. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 5 前提と​ なる​ 取り組み姿勢・マインド 目次
17. 他の​ PO メンバー達と​ 全体​ ・個別プロダクトの​ Vision や​ 戦略を​ 考える​ 際は、​ 技術的な​ 実現難易度を​ 一旦​ 忘れる。​ 技術的な​ ツッコミを​ 入れない。​ 1 人で​ Vision や​ 戦略を​ 考える​ 際には、​ Editor や​ Terminal などの​ エンジニアリングツールを​ 全て​ 落とす​ （ノンテックな​ 環境を​ 構築する）​ 今後の​ マイルストーンや​ 開発スケジュールなどを​ 書き出す際には、​ プロダクトの​ 機能ベースではなく​ ユーザーの​ 体験ベースで​ 考える。​ 「どの​ 機能を​ いつ作るか」ではなく​ 「ユーザーが​ どのような​ 体験を​ いつ得られるか」を​ 軸に​ 整理する。​ どのような解決策を実施したのか 開発者としてだけでなくPO と​ しての​ 効果的な​ 時間も​ 確保 解決策1 ：意識的に​ 開発者と​ PO の​ 帽子を​ 被り分ける​
18. Vision や​ 戦略を​ 考え、​ 仮説を​ 立案・検証するには、​ 施策" 前後" の​ ユーザーアクションを​ 正確に​ 捉える​ 必要が​ ある。​ ユーザーの​ 行動​ （KR ）を​ 測定する​ ための​ 開発は​ なるべく​ 優先度を​ 上げる。​ バック​ ログを​ 見て​ すぐに​ 分かる​ よう、​ KR 測定の​ ための​ タスクには、​ 「KR 取得」​ ラベルを​ 貼る。​ slack に​ Work Out Loud スレッドを​ 設け、​ 気付きや​ 違和感を​ 気軽に​ つぶやき感覚で​ 投稿できるように​ する。​ 投稿内容は​ 毎日の​ 夕会や、​ 週1 の​ Tech Lead との​ 相談会で​ 共有し、​ Outcome の​ 創出に​ 障壁と​ なる​ 理由を​ きちんと​ 言語化できれば、​ チームが​ 納得した上で​ 優先順位を​ 上げる。​ 「なんとなく​ 不安」​ 「違和感が​ 拭えない」など​ 上手く​ 言語化できないのであれば​ 見送る​ （キリが​ 無いので）​ 優先順位付けにおいて無駄な迷いが減る どのような解決策を実施したのか 解決策2 ：数値化​ （KR の​ 設定）を​ 優先し、​ 価値の​ 言語化を​ 徹底する​
19. 1 2 3 4 今日​ 伝えたい​ 事 三菱重工と​ デジタル内製組織、​ プロダクトの​ 説明 どう​ いった​ 課題に​ 向き合ったのか どのような​ 解決策を​ 実施したのか 5 前提と​ なる​ 取り組み姿勢・マインド 目次
20. 解決策1, 2 を​ 実施しても、​ 開発を​ 進める​ 上で​ 先が​ 見えない、​ 判断が​ できない​ ことは​ 一定存在する。​ 不可抗力的な​ 曖昧さは​ 受け入れた​ 上で、​ 前に​ 進むことも​ 大事と​ まず​ 考える​ （≠ 思考放棄）​ ある​ 程度 Action してみないと​ 塩梅が​ 分からない​ 事象に​ 対しては、​ まずプランA で​ 手を​ 動かし、​ ある​ 程度​ 進んだ​ 時点での​ 情報を​ 元に、​ 何かしらの​ 判断軸で​ 方​ 向性を​ 再検討する。​ 自分​ 自身も​ 開発者であるが​ 故に、​ 手を​ 動か​ したり具体的な​ Action へ​ 取り掛かる​ ための​ 行動コストが​ 低く、​ 兼務の​ メリットを​ 活かしやすい。​ プロダクトエンジニアとしての取り組み姿勢・マインド 自身も開発者である事を活かして、​ 曖昧な​ 状況でも​ 前進させていく​ 1 ）​ 自分で​ 手を​ 動かせる​ メリットを​ 最大限に​ 活用する​
21. プロダクトエンジニアは​ ビジネス価値と​ 開発実態の​ 両方を​ 理解している​ ため、​ 「リアルな​ ユーザーデータ」​ ＋​ 「開発知見ベース」で​ 意思決定を​ 行う​ 事が​ できる。​ 現場起点で​ 合理的な​ 判断と​ 推進が​ できる​ 人材へと​ 成長できる​ 可能性が​ ある。​ AI など​ 技術の​ 進化に​ よって、​ 仕事や​ スキルの​ 前提が​ 急速に​ 変わる​ 現代に​ おいて、​ 「正しい​ 物を​ 探索し、​ 正しく​ 作り続ける​ 力」は​ より​ 重要に​ なる。​ 短期的な​ 越境活動​ （プロジェクト・施策）ではなく、​ 兼務者と​ して​ 異なる​ 専門性を​ 恒常的に​ 融合させる​ ことで、​ 自分​ 自身が​ 従来の​ 職務境界を​ 越えた​ 「新たな​ 職種」や​ 「新しい​ 価値提供モデル」に​ なる​ ことを​ 見据えてみる。​ プロダクトエンジニアとしての取り組み姿勢・マインド 短期的な​ " 越境" だけでなく、​ 恒久的な​ " 融合" を​ 目指す 2 ）​ 「越境」から​ 「融合」​ へ​ 進むことを​ 見据える​