多様性のあるプロダクトチームを目指した共創の3年間の変化 / Three Years of Co-Creation for Diverse Product Teams Change

by Tomohisa Omagari

Slide 1

Slide 1 text

©ADWAYS DEEE Inc. 1 多様性のあるプロダクトチームを目指した共創の3年間の変化 2024.9.28 Omagari Tomohisa

Slide 2

Slide 2 text

©ADWAYS DEEE Inc. 2 ADWAYS DEEEの紹介 - 広告システムを作っております 2 ※　Adways IR資料（2023年12月期決算説明会）

Slide 3

Slide 3 text

©ADWAYS DEEE Inc. 3 ADWAYS DEEEの紹介 - 広告システムを作っております - 認知メインの広告（ディスプレイ広告）ではなく体験メインの広告（アフィリエイト、リワード）を扱っている 3

Slide 4

Slide 4 text

©ADWAYS DEEE Inc. 4 自己紹介大曲智久（オオマガリトモヒサ） - ADWAYS DEEE 取締役CTO - テクノロジー、プロダクト 4 セミナー・UXへの投資と組織変革 ─ ビジネスに貢献するUXチームの飛躍 ─ ・Tanzu Labs Meetup 2024 開催レポートエンジニアブログで書いた記事（2012年から続くブログ）・20周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進・エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話・新たな組織改善にチームトポロジーを活用したいと思っているところ・プロダクト開発のロードマップや優先度付けでプロダクトマネージャーが利用する図の話

Slide 5

Slide 5 text

©ADWAYS DEEE Inc. 5 伝えたいこと - プロダクトチームの組織設計の参考 - 多様性のあるチームでの課題に対する解決策の事例 - マインド形成とプロセスづくりのバランス判断（苦悩に近い内容） 5

Slide 6

Slide 6 text

6 アジェンダ ©ADWAYS DEEE Inc.

Slide 7

Slide 7 text

©ADWAYS DEEE Inc. 7 アジェンダ - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 7

Slide 8

Slide 8 text

8 MGRのPdM兼務時代 ©ADWAYS DEEE Inc.

Slide 9

Slide 9 text

©ADWAYS DEEE Inc. 9 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 9

Slide 10

Slide 10 text

10 組織の変化（MGRのPdM兼務時代） - PdMをMGRが兼務している - デザイナーは専門チーム（適宜チームにJOINしている） - ビジネス側にディレクターがおり、一緒に仮説検証を推進してくれた組織図の特徴 ©ADWAYS DEEE Inc.

Slide 11

Slide 11 text

11 開発プロセス - 事業戦略・プロダクト戦略をロジックモデルや優先度MAPという形で説明できるように改善（PdMを大曲や別のMGRが兼務、サブPdMとして開発チームの中でやれそうな人にお願いする） - UX、データ分析が専門チームとして独立しサービス全体と向き合えるようにしていた組織の変化（MGRのPdM兼務時代） ©ADWAYS DEEE Inc.

Slide 12

Slide 12 text

12 組織の変化（MGRのPdM兼務時代） 2019年くらい？開発組織が自分たちで開発する価値を判断するために動き始め、MVPキャンバスを活用して仮説検証をサイクルを回す ※　安定した開発を求めてリリーストレインを導入してみた話 ©ADWAYS DEEE Inc.

Slide 13

Slide 13 text

13 組織の変化（MGRのPdM兼務時代） ©ADWAYS DEEE Inc. UXリサーチとして、生活者のユーザーインタビュー・アンケートからペルソナ策定経験値を共有する、プロジェクト横断型プロセス設計のススメ自社メディアがなくてもリサーチできる、3つのポイント

Slide 14

Slide 14 text

14 組織の変化（MGRのPdM兼務時代）ロジックモデル事業のミッションに対して短中長期の繋がりを説明（ビジネスとの関連性も追加） ※　プロダクト開発のロードマップや優先度付けでプロダクトマネージャー（PM,PdM）が利用する図の話 ©ADWAYS DEEE Inc.

Slide 15

Slide 15 text

15 組織の変化（MGRのPdM兼務時代） ※　プロダクト開発のロードマップや優先度付けでプロダクトマネージャー（PM,PdM）が利用する図の話優先度MAP 仮説検証の状態と事業の優位性への影響を表し継続的に事業全体に価値を提供できているか確認 ©ADWAYS DEEE Inc.

Slide 16

Slide 16 text

16 組織の変化（MGRのPdM兼務時代）事業貢献を可視化し、 P/Lに近い目標設定 ※　エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 ©ADWAYS DEEE Inc.

Slide 17

Slide 17 text

17 組織の変化（MGRのPdM兼務時代）定量化を行い、事業貢献への影響を測定 - 新機能開発後の売上貢献度の計測 - 工数から新規価値の割合の計測 ※　エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 ©ADWAYS DEEE Inc.

Slide 18

Slide 18 text

18 組織の変化（MGRのPdM兼務時代）まとめ - 開発組織が事業貢献に向けて意識が上がりプロダクトの価値や課題ベースの会話が増えた - 専属ではないPdMでもあるため、もっとできる余地あるのにやりきれない悔しさがあった兼務を行う判断に後悔はなかった（責任者が価値と向き合うことはよかった） ©ADWAYS DEEE Inc.

Slide 19

Slide 19 text

©ADWAYS DEEE Inc. 19 プロダクトチームの誕生

Slide 20

Slide 20 text

©ADWAYS DEEE Inc. 20 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 20

Slide 21

Slide 21 text

©ADWAYS DEEE Inc. 21 21 組織が子会社化した ※会社分割（簡易新設分割）による子会社設立に関するお知らせ組織の変化（プロダクトチームの誕生）

Slide 22

Slide 22 text

©ADWAYS DEEE Inc. 22 組織の変化（プロダクトチームの誕生） 22 データドリブンでユーザーを幸せにするミッションビジョン開発組織からプロダクト組織へ圧倒的にセールスしやすいプロダクトを作るチームデータ・・広告データだけでなくユーザーの感情データも含まれるユーザー・・生活者、広告主、メディア

Slide 23

Slide 23 text

©ADWAYS DEEE Inc. 23 23 組織の変化（プロダクトチームの誕生） Tanzu Labs（旧 Pivotal Labs）が推奨している Lean XPのバランスチームを強く意識するようになった（フィーチャーチームとも言ったりしている）特徴 - PdM、プロダクトデザイナー、エンジニアの3ロールで構成し、オーナーは存在しない（スクラムのPOとは違う） - プログラミング手法が多いXPに対してリーンスタートアップとユーザー中心設計を組み合わせたもの ※　お客様の DX を支援する Tanzu Labs とは (パート 1）　　スクラムは何であって何ではないのか。XP、そしてLeanXPは何が違うのか

Slide 24

Slide 24 text

©ADWAYS DEEE Inc. 24 24 組織の変化（プロダクトチームの誕生） - PdMを専任化（ビジネス組織からディレクターを移動） - デザイナーも専門チーム化をやめた - エンジニアはシニア層を出来るだけプロダクトチームに移動させた組織図の変化

Slide 25

Slide 25 text

25 組織の変化（プロダクトチームの誕生）開発プロセス - プロダクトチームとしてチーム設計、ディレクターをPdMを抜擢し、専門のPdMチームの設立、プロダクトデザイナー（UI/UXデザイナー）が常にPdMと並走 - UXチームはプロダクトチームにJOIN、データ分析は専門チーム継続

Slide 26

Slide 26 text

©ADWAYS DEEE Inc. 26 26 組織の変化（プロダクトチームの誕生）色々な問題は出た - 「PdMの教育方針が定まらない」 - 「新規チームとして設立したばかりで営業との連携が未完成」 - 「プロダクトチーム内でのロールごとの連携」体制やプロセスを整理しても上手くいくわけがなく。。。。。その中でも優先度高い問題としてプロダクトチーム内で複数プロジェクトが並走してしまう

Slide 27

Slide 27 text

©ADWAYS DEEE Inc. 27 27 組織の変化（プロダクトチームの誕生）チームの中で常に複数のプロジェクトがありスプリトレビューの議題も複数のプロジェクトが入り乱れる状態にもなった

Slide 28

Slide 28 text

©ADWAYS DEEE Inc. 28 28 組織の変化（プロダクトチームの誕生）課題を深掘りすると、色々な観点が出たリソースがもったいないと考え、やりたいことはたくさんあるためプロジェクトを作ったデリバリーフェーズにおいて共創が少ない（ディスカバリーフェーズの共創はよく話題に出る）プロジェクトで前倒しで出来るものがあるかを常に意識できていない

Slide 29

Slide 29 text

©ADWAYS DEEE Inc. 29 29 組織の変化（プロダクトチームの誕生）リソース効率重視問題を組織設計で、強制的に１チーム１プロジェクト状態に移行まずは１プロジェクトをどれだけ早くできるかだけを考えよう

Slide 30

Slide 30 text

©ADWAYS DEEE Inc. 30 30 組織の変化（プロダクトチームの誕生）理想とするチーム（A,B,C）もできる一方でD・Eチームのような兼務前提のチームが増えてしまったリソースが充実しているわけではないので、それでも推し進めないと開発するべき機能はあり無理でも仕方ないとやってみた

Slide 31

Slide 31 text

©ADWAYS DEEE Inc. 31 31 組織の変化（プロダクトチームの誕生）プロジェクトが減ったことでフロー効率を意識させる動きが活発になり、前倒しできる部分を探す思考が身に付きやすくなったまた、チームの振り返りでプロセス単位（VSM）と向き合ったり、定量化された数値（Findy Team+）も意識した振り返りを行った

Slide 32

Slide 32 text

©ADWAYS DEEE Inc. 32 32 組織の変化（プロダクトチームの誕生）チームをスモール化してみてどうだったか？よかった部分 - チームとしてのフットワークは軽くなった - エンジニアがインタビューに参加したり、プロダクトKPIを全員で考えたりと価値を考える動きは活発になった - フロー効率のみを考える環境を作れた（振り返りや１チーム１プロジェクトの強制力）モヤモヤ部分 - 事業的にどうしても進めたいプロジェクトもあり、兼務前提のチームが出来た - デリバリーフェーズになるとエンジニアの負担が増える

Slide 33

Slide 33 text

©ADWAYS DEEE Inc. 33 33 組織の変化（プロダクトチームの誕生） Objective Key Results 2023年上半期プロダクトチームとしてスピーディーに価値を提供する - ユーザーにインパクトを与えたリリース7件 - スクラム成熟度を上げるための改善実績30件 - 開発組織の価値向上 10件 - 未来を見据えた技術改善 8件 2023年下半期スピーディーな価値提供のために、チームとして最短距離を自発的に考えて行動できるように徹底する - プロダクト開発に集中しやすい体制構築 - ムダを無くした行動　40件組織全体の目標も分野（プロダクト、スクラム、テクノロジー）毎で分割していた組織として最優先とする課題に対して集中するために分野毎での分割をやめた（MGRの動きもフィーチャーチームにしよう）

Slide 34

Slide 34 text

©ADWAYS DEEE Inc. 34 34 組織の変化（プロダクトチームの誕生）「プロダクト開発に集中しやすい体制構築」の一部でProdOps (Product Operations)チームが設立した・プロダクト戦略のテンプレート化・ステークホルダーマップ作成 ..etc ※　ProdOpsチームで解決！プロダクトチームの生産性を高める組織戦略とは

Slide 35

Slide 35 text

©ADWAYS DEEE Inc. 35 35 組織の変化（プロダクトチームの誕生）まとめ - 徹底的なフロー効率を求めた組織設計 - 各ロール（PdM、デザイナー、エンジニア）を揃えた上でスモールチームにすることにした - フローを意識した振り返り（VSMやFindy Team+）の実施 - 組織目標もまたロールを超えた越境の設計に変更 - 分野ごとの目標から複数のロールが関係する目標設計に変更 - ProdOps（戦略策定と管理、チーム内外コミュニケーション）チームの誕生

Slide 36

Slide 36 text

©ADWAYS DEEE Inc. 36 チームとしての型の確立

Slide 37

Slide 37 text

©ADWAYS DEEE Inc. 37 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 37

Slide 38

Slide 38 text

©ADWAYS DEEE Inc. 38 38 組織の変化（チームとしての型の確立）開発プロセス - ProdOpsがプロダクトを取り巻く環境をサポートプロダクト戦略策定・振り返りサポート、PMMの役割策定、プロダクト全体（開発、営業）定例推進、コミュニケーション設計

Slide 39

Slide 39 text

©ADWAYS DEEE Inc. 39 39 組織の変化（チームとしての型の確立）「オーナーシップを持とう」、「越境しよう」、「共創しよう」「エンジニアも価値を意識しよう」...etc 全て共感はできる。ただ、組織として再現性を高める動きや言語化の難しさがあった ※複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン

Slide 40

Slide 40 text

©ADWAYS DEEE Inc. 40 40 組織の変化（チームとしての型の確立）ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わるためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 41

Slide 41 text

©ADWAYS DEEE Inc. 41 41 組織の変化（チームとしての型の確立）ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わるためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 42

Slide 42 text

©ADWAYS DEEE Inc. 42 42 組織の変化（チームとしての型の確立）プロダクトの価値を決めるために３つの分野・ロールを大事にしている ↓ ３つのアウトプットがプロダクトの価値を決める ↓ チーム自身は３つのアウトプットの品質が足りているか確認する必要がある品質＝仮説の不確実性が低く、価値の見込みが高いと言えるか

Slide 43

Slide 43 text

©ADWAYS DEEE Inc. 43 43 組織の変化（チームとしての型の確立）プロジェクト開始当初は３つ（ビジネス、デザイン、テクノロジー）の分野は全て不確実性が高い ※ディスカバリーにおいて上記のすべての作業の完了必須の意図はないあくまでイメージですソリューションの決定日々のアウトプットを通して３つのうちどれが一番不確実性が高くなっているかを意識すること大事 ※　日々のアウトプットの変化＝ DSするごとに変わると全然ある ※　不確実性が高いポイント＝赤色で表示 ↓ それを最重要なタスクとしてチーム全体でフォローし合う分野を担当する職種がチームをリードする ※　プロジェクトの管理責任を持ちやすいPdMやスクラムマスターがチームの議論をリードしがちだけどそれはベストではない

Slide 44

Slide 44 text

©ADWAYS DEEE Inc. 44 44 組織の変化（チームとしての型の確立）テクノロジーの不確実性が高いパターン前提：ソリューション案でAI使ってよしなにできるじゃね？タスク：技術調査をしよう直面する課題：技術調査をする範囲が広すぎる。自社に知見が少ない。やろうと思えばなんでも出来そう。対応策： ➔ テクノロジー・・技術調査はメインで頑張る ➔ ビジネス・・・・どのパターンのみをAI化できればビジネス貢献が高いか考える顧客にとってAIの効果を実感できるのか ➔ デザイン・・・・ AIを活用した体験はどう変化してどんな課題を解決できるのかを考える

Slide 45

Slide 45 text

©ADWAYS DEEE Inc. 45 45 組織の変化（チームとしての型の確立）通常のタスクディスカバリーのタスク

Slide 46

Slide 46 text

©ADWAYS DEEE Inc. 46 46 組織の変化（チームとしての型の確立） - 不確実性が高いタスクほど全ての範囲をやる必要はない - どの事実・学びが判明したら、次のステップに進めるかを見極めることが大事 - 他ロールの動きによって切り口が見つかり、必要最低限のポイントが絞られたりする - 自身の専門性を活かした他ロールへの貢献を考えることが一番やるべき越境であり、共創である - エンジニアがPdMっぽいことをやっても全然良いと思うが、（逆も然りPdMがエンジニアっぽいことやる）全てにおいてそれが良いというわけではないディスカバリーのタスクの特徴

Slide 47

Slide 47 text

©ADWAYS DEEE Inc. 47 47 組織の変化（チームとしての型の確立）ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 48

Slide 48 text

©ADWAYS DEEE Inc. 48 48 組織の変化（チームとしての型の確立） AIに関しての技術調査タスクのイメージ図

Slide 49

Slide 49 text

Slide 50

Slide 50 text

©ADWAYS DEEE Inc. 50 50 組織の変化（チームとしての型の確立）ロールを超えたペア作業をやることで ➔ 他ロールのアウトプットの品質が向上する ◆ プロトタイプ作成でエンジニアの実現可能性を盛り込んだ方が絶対に良い..etc ➔ 担当しているロールの仕事にも良い影響がある ◆ アーキテクチャ設計でユーザー体験視点の重要性を理解した上でアーキテクチャ設計をすることでプロダクト価値を意識した技術選定が可能になる..etc

Slide 51

Slide 51 text

©ADWAYS DEEE Inc. 51 51 組織の変化（チームとしての型の確立） - チーム全体で不確実性が高い分野を判断し、フォローし合う（共創） - 自身の専門分野がチームにとって一番不確実性が高い場合に積極的なリーダーシップを取りチームの議論をリードする（オーナーシップ） - アウトプットを待つのではなくフライングして一緒にアウトプットをつくる（越境） - 専門外に対しても自身の専門分野で貢献できる余地を探し出来るだけ早く合流すること - 例：デザイナーのプロトタイプ作成では、大枠が決まったらエンジニアも合流することでプロトタイプの実現性が向上するかつどこまで何をやれるかの選択肢の幅も広がる初めからエンジニアが付きっきりで一緒にやることが必須ではない（何も関わらないはNG）目指している状態

Slide 52

Slide 52 text

©ADWAYS DEEE Inc. 52 52 組織の変化（チームとしての型の確立）ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わるためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 53

Slide 53 text

©ADWAYS DEEE Inc. 53 53 組織の変化（プロダクトチームの誕生）リソースがもったいないと考え、やりたいことはたくさんあるためプロジェクトを作ったデリバリーフェーズにおいて共創が少ない（ディスカバリーフェーズの共創はよく話題に出る）プロジェクトで前倒しで出来るものがあるかを常に意識できていない

Slide 54

Slide 54 text

©ADWAYS DEEE Inc. 54 54 組織の変化（チームとしての型の確立）デリバリーフェーズは、エンジニア任せでも良いとも思っていたリリース後の分析やマーケティングをPdMやデザイナーは進めれば良いためストーリーライティングを通じた開発プロセスを体験したら考えが変わりました

Slide 55

Slide 55 text

©ADWAYS DEEE Inc. 55 55 組織の変化（チームとしての型の確立） WHY As ペルソナは I want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ※　ユーザーストーリーを元にした会話と定着ストーリーの形式

Slide 56

Slide 56 text

©ADWAYS DEEE Inc. 56 56 組織の変化（チームとしての型の確立）ストーリーの粒度は、2~3日で実装できる規模が多い - 「XX バリデーション処理を実行する」「XX Cookieに保存する」..etc - エンジニアと議論して、テストしやすい受け入れ基準の決めたりする - エラーケースや非機能要件はエンジニアがリードしてPdMに提案する（=全ての要件をPdMが決めない） - デザイナーはデザインに関わるストーリー（アニメーションやデザイン反映..etc）を作成する（自分で作成して自分で消化することもあり）ストーリーの優先度もPdMがベースを考える（フロー図などを用いて何から着手するかを決める）最初のストーリーのフロー図最後のストーリーのフロー図

Slide 57

Slide 57 text

©ADWAYS DEEE Inc. 57 57 組織の変化（チームとしての型の確立）効果 - PdMが何をどこから開発すべきかを考えてくれる - エンジニアが開発作業にのみ集中できる - デザイナーはデザインシステムを通して開発効率化に貢献 - ストーリーを通じたチームコミュニケーションの活性化 - 全てのロールの全ての作業を情報共有はだいぶ過多になりがち（透明性は大事だけど） - ストーリーは価値ベースなので常に価値を認識し続けられる

Slide 58

Slide 58 text

Slide 59

Slide 59 text

©ADWAYS DEEE Inc. 59 59 組織の変化（チームとしての型の確立）ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わるためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 60

Slide 60 text

©ADWAYS DEEE Inc. 60 60 組織の変化（チームとしての型の確立）エンジニアは、5~7時間のペアプロを推奨　（休憩大事、Discordでずっと話す、Tupleで画面共有） TDD x ペアプロ x Copilotは最強。 PdMやデザイナーも出来るだけペア作業を推奨。

Slide 61

Slide 61 text

©ADWAYS DEEE Inc. 61 61 組織の変化（チームとしての型の確立） ※　アジャイルソフトウェア開発宣言リモートに慣れてツールでのコミュニケーションが当たり前になってしまったずっと話し続けるペア作業を通すことで自然とプロセスが無くなった（ペアプロでレビュー作業が無くなる..etc）話したいと思ったらすぐにDiscordで話しかける（ペア作業しているのでツールで聞かない）同期的なコミュニケーションの重要性を確認

Slide 62

Slide 62 text

©ADWAYS DEEE Inc. 62 62 組織の変化（チームとしての型の確立）「越境しよう」「共創しよう」とかを以下の取り組みや考え方を通して行動にまで言及しているディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすることデリバリー - 全員で開発作業に関わためのストーリーライティングチーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化

Slide 63

Slide 63 text

©ADWAYS DEEE Inc. 63 63 組織の変化（チームとしての型の確立）ProdOps ステークホルダーマップを活用し、意思決定や営業も含めたコミュニケーション設計の推進（最初は良いが、プロジェクトが進むにつれてレポートラインがゴチャゴチャになりがち.....） AS IS TO BE ※　ProdOpsチームで解決！プロダクトチームの生産性を高める組織戦略とは

Slide 64

Slide 64 text

©ADWAYS DEEE Inc. 64 64 組織の変化（チームとしての型の確立）ProdOps プロダクト戦略の効率化や仮説検証のフェーズを明確にし、チームとして新機能の現在地点を意識させ、満たすべき要素は何かを認識させる ※　ProdOpsチームで解決！プロダクトチームの生産性を高める組織戦略とは事業目標・事業KPI・ビジョン・プロダクトKPI..etc フェーズ CPF (Customer Problem Fit)：顧客の問題が明確であり、解決のための代替手段が明らかになっている。 FPF (Founder Problem Fit)：創業者(重要ステークホルダーや上長)が顧客の問題を理解している。 (組織としてそれを進めることに同意し熱量を持てている状態) PSF (Problem Solution Fit)：ソリューションが顧客の問題を解決する可能性があると証明される。 SPF (Solution Product Fit)：ソリューションを具体的なプロダクトやサービスとして持続的に提供できるようになっている。 PMF (Product Market Fit)：プロダクトが市場の需要に適合し、顧客から十分な価値を得られると感じられ、市場で成功する可能性が高いと証明される。

Slide 65

Slide 65 text

Slide 66

Slide 66 text

©ADWAYS DEEE Inc. 66 66 組織の変化（チームとしての型の確立）まとめ - ロールを超えた共創の形が見えつつある - ディスカバリーフェーズ：専門分野以外にも興味を持ち、チーム全体で不確実性の高い分野をフォローする（時には全員でやりきることも良い手段） - デリバリーフェーズ：PdMやデザイナーにおいてもストーリーライティングを通してエンジニアのみのリソースから限界突破を実現可能 - チーム全体：リモートが当たり前化している中で、対面の重要性を理解しペア作業の徹底を行うことでチームとしての同期頻度を高め、認知負荷を減らし、一体感を高められる - ProdOpsを通して着実にプロダクトチームを支える体制が出来つつある

Slide 67

Slide 67 text

Slide 68

Slide 68 text

©ADWAYS DEEE Inc. 68 まとめ 68 - プロダクトチームはフロー効率を徹底的に意識させる開発フローや組織設計が大事 - 越境はエンジニアだけはない PdMやデザイナーがデリバリーフェーズはもっと開発が早くなる！！ - プロダクトチームとしてオーナーシップを保つためにそれを外部からサポートするチームの存在（ProdOps）は重要

Slide 69

Slide 69 text

©ADWAYS DEEE Inc. 69 伝えたいこと - プロダクトチームの組織設計の参考 →　チームをスモールにして正しい連携ができるように慣らす - 多様性のあるチームでの課題に対する解決策の事例 →　ディスカバー（フライング..etc）、　　デリバリー（ストーリーライティング）、ペア作業の徹底 - マインド形成とプロセスづくりのバランス判断（苦悩に近い内容） →　全てが良い言語化・プロセス化が出来るとは思ってはいないが　　挑戦し続けなければいけない　　チームから離れた横断組織（ProdOps）が大事 69