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

重厚長大な大企業で、軽快にスクラムを始めるために大事だったこと / Scrum Fest Os...

重厚長大な大企業で、軽快にスクラムを始めるために大事だったこと / Scrum Fest Osaka 2021

Scrum Fest Osaka 2021(2021/06/26)の発表資料です
https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15358

Avatar for モンゴル (mongolyy)

モンゴル (mongolyy)

June 26, 2021
Tweet

More Decks by モンゴル (mongolyy)

Other Decks in Business

Transcript

  1. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 重厚長大な大企業で、 軽快にスクラムを始めるために

    大事だったこと 2021/06/26 三菱重工業株式会社 成長推進室 デジタルエクスペリエンス推進室 山田 悠太
  2. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 2 今回の発表は個人の見解であり、所属組織を代表するものではありません

    今回の内容は、大企業の”既存事業”向けのサービス開発に関する観点でお話しています。 免責事項
  3. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 3 山田悠太

    (@mongolyy ) あだ名: モンゴル プロフィール 三菱重工業株式会社 成長推進室 デジタルエクスペリエンス推進室 ソフトウェアエンジニア 兼 スクラムマスター 好きな言語: Scala 最近触っている技術スタック: TypeScript, React, Next.js
  4. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 4 •

    三菱重工とは • スクラム導入の背景 • プロジェクト概要 • スクラム導入の壁 • 開発チーム内の問題 • 開発チーム外の問題 • まとめ 目次
  5. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 5 三菱重工の紹介

    - 事業領域 ・ 売上高構成比 (2019年度) パワー 航空・防衛・宇宙 インダストリー&社会基盤 17.4% 39.3% 44.0% 数十の事業部門から構成
  6. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 6 事業会社化

    三菱重工の紹介 - デジタルエクスペリエンスデザインの紹介 対応 資源 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 課題 ビジネスIT IoT AI SA Service Automation MA Marketing Automation 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 中規模 事業部門 UX Design Agile ハンズオン型 推進組織 - デジタル化の企画・開発・運用 インダストリー&社会基盤ドメイン デジタライゼーション推進グループ(2018/1-2020/3) (CEO直轄)成長推進室 デジタルエクスペリエンス推進グループ (2020/4-) DevOps
  7. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 7 スクラムを導入した背景

    上から言われたことをやるだけという姿勢 改善が 進みにくい 問題 世間から 置いてかれる 問題 現状維持の文化 外部(お客様、他社)に向き合えていない 自発的に改善できる組織、チーム 三菱重工が抱えている課題 あるべき姿 顧客エンゲージメントの改善 あるべき姿に近づけるためにスクラムを導入
  8. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 8 部品見積・受注サイト構築プロジェクトについて

    お客様 事業部のサービスマン 現在の運用 部品見積・受注が電話かFAX 課題 ・ 部品の発送状況の把握ができない ・ リピート発注が存在するが、過去の発注 は自分たちで管理しないといけない ・ 電話対応、部品の検索や見積書作成 の手間 部品見積・受注システムをWeb化し、課題を解決
  9. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 9 体制

    従来の開発体制 新しい開発体制:スクラムチーム 事業部門 ビジネスオーナー プロダクト オーナー アジャイルコーチ (外部コンサル) 開発者 事業部門 ビジネスオーナー プロダクト マネージャー 開発パートナー デザイン パートナー 委託 委託 ワンチームで開発推進 エンジニア エンジニア デザイナー [外部パートナー] リード エンジニア 兼 SM 他PJ含む 全体統括 (POのサポート)
  10. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 10 スクラム導入の壁

    エンドユーザー見えない問題 顧客と接するまでに複数の組織を経由することになる為、 ユーザーが遠い、ユーザーの理解度が低い コミュニケーションの問題 チーム内 チーム外 開発ナレッジの不足 スクラム自体を知らない問題 全員初対面 ECサイト構築経験者なし 今回採用の技術(React)が初のメンバーが2/3 私以外、アジャイル開発が初 POはシステム開発自体が初めてだった コアメンバーは全員初対面で信頼貯金が0 事業部門とワンチームに なれていない問題 コロナ禍により、対面打合せのハードルが上がる 座組が初めてで不慣れ、かつ焦りすぎ
  11. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 11 チーム外の問題について

    エンドユーザー見えない問題 ユーザーストーリーマッピング(USM)を事業部と作ってみる 発生した問題 対応 USMを作成することで、ユーザー像の解像度を上げてみる 開発チーム 事業部 エンドユーザー ユーザーストーリーマッピング
  12. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 12 すんなりとはいかなかった

    事業部門とワンチームになれていない問題 発生した問題 スクラムチームが 正しいものか見極めて作られているのかわからない 事業部と作ったUSM(≒要件)を絶対として 動くものを完成させることに集中してしまった すれ違いの発生 と 開発方針の向きなおり コミュニケーションも不足し、 一方通行の物が多かった 増える要件と追われるスケジュール 開発チーム 事業部 ユーザーストーリーマッピング
  13. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 13 原因と対応

    正しいものを 作ろうとしているのか 示せていなかった問題 複数アーキテクチャでPoCを作成し、 アーキテクチャを共に考えていく コミュニケーション 不足問題 事業部担当者を巻き込んだ スプリントレビューの開催 共に検討していくことの 必要性 共に検討していくことがカギになるのでは?
  14. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 14 共に検討するとは?

    建前的に承認を得るのではなく、本音で話して課題を見つけろ! 建前の打合せ 本音の打合せ
  15. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 15 共に検討するとどうなるの?

    コミュニケーションが多くなったことで 距離が近くなり 一緒に検討することで 共にエンドユーザー視点で考えるように 「俺たち vs 問題」の構図になるのでは? 開発チーム 事業部 エンドユーザー
  16. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 16 事業部を巻き込んだスプリントレビュー導入前後の比較

    スプリントレビュー導入前 スプリントレビュー導入後 部品受発注サイト構築チーム 関心の向きと距離が変わったことで「俺たち vs 問題」の構図になってきた 開発チーム 事業部 エンドユーザー ユーザーストーリーマッピング
  17. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 17 関心の距離と向きを変えた、スプリントレビューとシナリオ駆動開発①

    プロダクト お題 様子 お題 運用 1. スクラムチームがお題を用意 2. 事業部担当者は画面を共有しつつ、1人実況しながら、お題を解いていく 3. お題を解いたら、実況主によるフィードバックとスクラムチームからの質問 背景情報 お題
  18. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 18 関心の距離と向きを変えた、スプリントレビューとシナリオ駆動開発②

    効果 効果的だったこと ◼ ユーザー視点で操作することにより、フィードバックもユーザー視点に ◼ 事業部担当者はユーザーになりきろうとするが、わからないことがあることに気付き、ユーザーからのフィー ドバックの重要性に自発的に気付く ◼ FBを随時反映することにより、PJ運営、技術力に対しての信頼感が高まった ◼ スプリントゴール設定時にシナリオを考え、フィードバックされやすいように一連の操作ができるように作って いった。(シナリオ駆動開発) ◼ 実装機能について実況前に説明せず、実況中も黙って観察した エンドユーザーをよく知っている事業部と共にユーザー視点で製品を作っていく
  19. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 19 大企業ではまる落とし穴

    事業部の各部門の積極性が欠ける、スキルが低い、と考え、無視して進めると、、 開発チーム 事業部 企画部門 事業部 カスタマーサポート部門 エンドユーザー お客様のことわかっ てないなー 勧められないなー 私たちや顧客を見 ずに、開発していそ うだなー 開発チームが考え たエンドユーザーは 存在しない
  20. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 20 大企業での取り組み方①

    企画部門を巻き込んでみる 開発チーム 事業部 カスタマーサポート部門 お客様のことわかっ てないなー 勧められないなー システムをこうすれ ば、顧客使ってくれ るかな…? 少し近づいた… が、まだ改良の余 地はある エンドユーザー 事業部 企画部門 多分こっちやで
  21. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 21 大企業での取り組み方②

    カスタマーサポート部門を巻き込んでみる 開発チーム 事業部 企画部門 事業部 カスタマーサポート部門 こうしたら◦◦社の 方は喜んでくれそう だなー システムをこうすれ ば、顧客使ってくれ るかな 惜しい! かなり近づいている 多分こっちやで エンドユーザー
  22. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 22 大企業での取り組み方③

    エンドユーザーを巻き込んでみる 開発チーム 事業部 カスタマーサポート部門 こうしたら◦◦社の 方は喜んでくれそう だなー システムをこうすれ ば、顧客使ってくれ るかな エンドユーザー 実際に エンドユーザー に聞いてみる エンドユーザーの課 題解決にたどり着く 事業部 企画部門 多分こっちやで
  23. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 23 チーム外の問題の解決について

    ~まとめ~ 現在の私のPJでは、、 開発チーム 事業部 カスタマーサポート部門 エンドユーザー 実際に エンドユーザー に聞いてみる 私たちはここまで 巻き込み始めた 巻き込んで一体感を作る(≒事業部と近づいて盛り上げる)ことが大事 事業部 企画部門 多分こっちやで
  24. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 24 チーム内の問題の解決

    ~コミュニケーションの問題~ オンラインモブ部屋 対面MTG メンバー全員で事業部に出張 Pull型コミュニケーションの推進 同一の体験を経験することで 共通の認識を得る
  25. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 25 チーム内の問題の解決

    ~開発ナレッジの不足~ チーム内/チーム外勉強会 ペアプロ/モブプロ 得意分野に関わらずPBIをアサイン 知識をシェア やる気を引き出す 成長を引き起こす 他にも テスト設計勉強会等行った 出典:「りあクト! TypeScriptで始めるつらくないReact開発 第3.1版」、大岡由佳、「リファクタリング(第2版)」、Martin Fowler、「Game Programming Patterns ソフトウェア開発の問題解決メニュー」、Robert Nystrom
  26. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 26 チーム内の問題の解決

    ~スクラム自体を知らない問題~ プロによる支援 第三者の目で厳しくやってみる スクラムマスター勉強会 毎週、他チームのスクラムマスター + アジャイルコーチと 困りごとや気になったことを共有
  27. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 27 チーム内の問題を解決するために大事なこと

    もやみを減らしていく チーム内の問題の多くが もやみで構成されている もやみを引き出すための活動 スクラムマスターと 1on1 ふりかえり デイリースクラム もやみを常に共有できる環境/風土 フラットなチームを 作る 異なるスキルを 持ち合わせ、 互いに尊重しあう 挨拶と雑談と 感謝 コミュニケーションの問題 開発ナレッジ不足の問題 スクラム自体を知らない問題
  28. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 28 チーム内の問題解決に役立ったプラクティス~オンラインモブ部屋~

    運用 ◼ チームメンバー全員が、オンライン会議の部屋に常に参加 ◼ もやみが発生した時に適宜ミュートを外して、モブ部屋にいるメンバーに相談 効果 成功要因 ◼ 不安は最小、課題解決速度は最大に ◼ 『個人が頑張る!』ではなく、『チームで課題に対処する!』というマインドの浸透 ◼ “チーム内で助け合うことがプロダクト開発を効率的に進める秘訣”という認識に ◼ 強制ではなく、モブプロの延長線上に自然発生 ◼ モブ部屋に常にいる人(守護神)の存在 “Pull型”コミュニケーションの定着により、共通認識が急速に拡大
  29. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 29 チーム内の問題解決に役立ったプラクティス~エクストリームデイリースクラム~

    運用 ◼ スプリントゴールをチームが達成できそうかを5段階で表明 (5:余裕/4:まぁやれる/3:五分五分/2:ちょっとやばい/1:無理) ◼ 全員が4以上であれば、解散。3以下が1人でもいれば、議論。 効果 成功要因 ◼ 問題、相談、助けがほしい事項(もやみ)に対する議論に集中できるように ◼ チームメンバー全員がチームの進捗を気にするように ◼ PJが順調な時は、朝会が数分で終えられるように ◼ 自分たちの中でルールを決めた(ふりかえりの中で、デイリースクラムが形骸化していると いう指摘があり、それをきっかけに導入した) “タスク消化”から”スプリントゴール達成”を目指すチームに成長
  30. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 30 まとめ~全体を通して、どのように取り組んできたか~

    難しさがあるが、アウトカムのためにはここの巻き込みは必須 開発チーム 事業部 カスタマーサポート部門 エンドユーザー 実際に エンドユーザー に聞いてみる ステークホルダーを巻き込む。そのために、自分たちもうまくやれるようにする 事業部 企画部門 多分こっちやで ここが土台
  31. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 31 まとめ

    チーム外 事業部を巻き込んで、一体感を作る 矢印の向きと距離感を意識して、事業部と共にエンドユーザーを考え、盛り上げ、自然 とエンドユーザーにアプローチできる流れをつくる チーム内 もやみを減らしていく そのために、自然と共有される風土づくり、もやみを引き出す活動が大事 「俺たち vs 問題」の構図を作ることが大事
  32. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 32 宣伝

    三菱重工業のデジタルエクスペリエンス推進室(通称DED)では積極採用中です! 私たちと一緒に働いてみたい!と思われた方、話を聞いてみたいと思った方は Findyでイイネしてください! https://findy-code.io/companies/501