「お客さまとの対話」を加速する、エンタープライズアジャイルことはじめ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

|　© Muture Corp. All rights reserved. ⾃⼰紹介 | Yuta Kanehara ソフトウェアエンジニアとしてキャリアをスタート。コンシューマー向けサービスやグローバルプラットフォームの開発及びPMを担当。その後、プロダクトマネージャーとしてOMOプラットフォーム及びSaaS製品群のプロダクト責任者を務める。 2023年3⽉にMutureへ⼊社し、丸井グループにおけるプロダクトマネジメントや組織⽀援を中⼼に担当をしている。 2 ⼀貫して「IT企業」で「⾃社事業」を担当していた⼈間が現職では「⼤企業」の「⽀援事業」を担当しています

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

|　© Muture Corp. All rights reserved. そもそも“モノ”と”ソフトウェア”はなにが違うのか？ 22 👠モノ 📱ソフトウェア形単位スケール 🤯 抽象化された概念の集合 🙂 物理的な形状がある 🤯 ない 🙂 サイズ, 形状, 重さ... 📈 1の継続的な運⽤/改善 👟👟 1をNに量産化 👟👟 モノとソフトウェアは根本的に性質が異なる別物プロセスウォーターフォール開発アジャイル開発 📦製造管理モデル

Slide 23

Slide 23 text

|　© Muture Corp. All rights reserved. “モノ”の作り⽅を転⽤して”ソフトウェア”を作るのは悪⼿ 23 形単位スケール 🤯 抽象化された概念の集合 🙂 物理的な形状がある 🤯 ない 🙂 サイズ, 形状, 重さ... 👟👟 1をNに量産化 👟👟 プロセスだけ転⽤してソフトウェアを作っても、作って終わりでありその先がない結果としてアウトプットが⽬的となる、いわゆるビルドトラップに陥る󰷺 プロセス 📦製造管理モデル思想が近く転⽤がしやすい 📈 1の継続的な運⽤/改善ウォーターフォール開発アジャイル開発 ※ このような背景からか”モノ”の作り⽅に慣れている組織において、”ソフトウェア”の新規開発案件に限り、要件さえ固まればそれなりに形として出来上がる印象があります 👠モノ 📱ソフトウェア

Slide 24

Slide 24 text

|　© Muture Corp. All rights reserved. ”ソフトウェア”に適した「環境」を新たに⽤意することが重要に 24 形単位スケール 🤯 抽象化された概念の集合 🙂 物理的な形状がある 🤯 ない 🙂 サイズ, 形状, 重さ... 📈 1の継続的な運⽤/改善 👟👟 1をNに量産化 👟👟 プロセスウォーターフォール開発アジャイル開発 📦製造管理モデルソフトウェアを前提とした組織や制度を、現⾏の仕組みとは別で新たに設計モノづくりの良さは残しつつも、ソフトウェアに適した環境を整備することが重要 👠モノ 📱ソフトウェア

Slide 25

Slide 25 text

|　© Muture Corp. All rights reserved. “モノ”と”ソフトウェア”における「対話」の違い「お客さまとの対話」という観点で⽐較すると、ソフトウェアのほうが「お客さまを知る」ための⼿法は多い。また、ソフトウェアを通じた対話など対話そのものにも⾼度なスキルが求められる点が⼤きく異なる。 25 正しい”課題”を⾒つける正しい”解決策”を⾒つけるモノソフトウェア ● お客さまの声 ● お客さま会議 ● サンプルチェック ● インタビュー ● サービスブループリント ● コンセプトプロトタイピング ● アクティビティ分析 etc… ● プロトタイピング ● ユーザビリティーテスト ● ユーザーストーリーマッピング ● A/Bテスト etc… 定性×定量と扱う情報量が爆発的に増加検証サイクルは⾼速化し、⼿法も⾼度化 UX/UI, プロダクトマネジメント, ソフトウェア開発⼿法などといった専⾨性を組織として獲得していく必要性

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

|　© Muture Corp. All rights reserved. ”ソフトウェア”でも「対話の⽂化」を実現するためにソフトウェアでも「お客さまとの対話」に基づいたものづくりを実現するためには、以下のような取り組みが求められる。 IT企業等でのアジャイル開発の導⼊とはスコープが⼤きく異なるため「エンタープライズアジャイル」とも呼ばれる。 29 ① ソフトウェアビジネスに適した組織や制度を新たに設計 ② ソフトウェア開発に必要となる専⾨性の獲得 💡IT企業との違いについて IT企業の場合は、ソフトウェアを起点としたビジネスを展開していくという前提があるため、創業時よりソフトウェアビジネスに最適化された組織や制度設計がなされており問題にならない。 💡IT企業との違いについて IT企業の場合は、ソフトウェアビジネスに必要となる専⾨性に対する理解はすでにあるため、これに適合するポジションを定義したうえで、不⾜する要件を満す専⾨⼈材を採⽤していくことで内製化を進めていく。⼀⽅で⼤企業では総合職⼈材の割合が⾼く、またIT系の専⾨⼈材を採⽤するためのハードルが⾼いため、結果として専⾨性を培いづらい環境であることが多い。故に専⾨性についてはアウトソースされ、ナレッジが内に貯まらない

Slide 30

Slide 30 text

|　© Muture Corp. All rights reserved. アジャイルソフトウェア開発宣⾔の12原則と、⼤企業で実践する際の課題 30 アジャイル宣⾔の12原則顧客の満⾜を求め続ける要求の本質を⾒抜き、変更を前向きに進捗も品質も現物でムダ＝価値を⽣まない、を探してヤメる全員で共通の⽬標に向かおうよい技術、よい設計、よい品質の追求⼈の意欲は信頼からコミュニケーションは直接対話でよいモノはよいチームから⾃分たちのやり⽅を毎週、調整する成果物を2-3週間で、リリースし続ける⼀定のペースでプロジェクトにリズムを組織構造の変⾰ (階層型組織, 機能別組織, 上意下達, サイロ化) ソフトウェアに関するスキル習得 (UX/UI, プロダクトマネジメント, ソフトウェア開発⼿法) ⼤企業で実践するために ※ 意思決定プロセスの変⾰ (ウォーターフォール, 決裁構造, 内部統制) ※ 情報処理推進機構, 『アジャイルソフトウェア開発宣⾔の読みとき⽅』における表現を利⽤している

Slide 31

Slide 31 text

|　© Muture Corp. All rights reserved. アジャイルソフトウェア開発宣⾔の12原則と、⼤企業で実践する際の課題 31 アジャイル宣⾔の12原則顧客の満⾜を求め続ける要求の本質を⾒抜き、変更を前向きに進捗も品質も現物でムダ＝価値を⽣まない、を探してヤメる全員で共通の⽬標に向かおうよい技術、よい設計、よい品質の追求⼈の意欲は信頼からコミュニケーションは直接対話でよいモノはよいチームから⾃分たちのやり⽅を毎週、調整する成果物を2-3週間で、リリースし続ける⼀定のペースでプロジェクトにリズムを⼤企業で実践するために ※ ② ソフトウェア開発に必要な専⾨性の獲得 ① ソフトウェアビジネスに適した組織や制度を新たに設計組織構造の変⾰ (階層型組織, 機能別組織, 上意下達, サイロ化) 意思決定プロセスの変⾰ (ウォーターフォール, 決裁構造, 内部統制) ソフトウェアに関するスキル習得 (UX/UI, プロダクトマネジメント, ソフトウェア開発⼿法) ※ 情報処理推進機構, 『アジャイルソフトウェア開発宣⾔の読みとき⽅』における表現を利⽤している

Slide 32

Slide 32 text

|　© Muture Corp. All rights reserved. エンタープライズアジャイルにおいて求められる変⾰の範囲 32 組織伴⾛ / スキル⽀援事業レイヤーとの対話経営レイヤーとの対話マルイグループ DX推進室エポスカード (事業会社) M&C (システム会社) 事業部⾨アプリ部⾨チームA 外部パートナー等チームB チームC チームD 「アジャイル開発は開発部⾨の話じゃないの？」という認識がある場合も多いですが、エンタープライズアジャイルとして扱う範囲としては「企業全体」に及びます。開発部⾨組織構造の変⾰ (階層型組織, 機能別組織, 上意下達, サイロ化) 意思決定プロセスの変⾰ (ウォーターフォール, 決裁構造, 内部統制) ソフトウェアに関するスキル習得 (UX/UI, プロダクトマネジメント, ソフトウェア開発⼿法)

Slide 33

Slide 33 text

|　© Muture Corp. All rights reserved. マルイグループエンタープライズアジャイル実現にむけた歩み 33 ④ 組織伴⾛ / スキル⽀援 ② 対象とする事業領域選定 ① アジャイル推進への基本合意 DX推進室エポスカード (事業会社) M&C (システム会社) 事業部⾨アプリ部⾨チームA チームB チームC チームD 開発部⾨ ③ 職能横断型組織編成 ⑥ 社内規定や慣例の壁の突破 ⑦ アジャイル開発の実⾏⽀援変⾰を推進していくためには、縦横上下様々な取り組みを連鎖的に実⾏し拡⼤をしていく必要がある。中でも「⑥社内規定や慣例の壁」は⾮常に⾼く、ステークホルダー全員の協⼒なしには成し得えない。 ⑨ 先⾏事例化 & 全社展開 ⑤ アジャイル案件の組成トップダウンボトムアップ ⑧ 外部パートナーとの関係性強化外部パートナー等