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

XP祭り2024
多様性のあるプロダクトチームを目指した共創の3年間の変化
https://confengine.com/conferences/xp2024/proposal/20495/

Transcript

1. ©ADWAYS DEEE Inc. 1 多様性のあるプロダクトチームを 目指した共創の3年間の変化 2024.9.28 Omagari Tomohisa
2. ©ADWAYS DEEE Inc. 2 ADWAYS DEEEの紹介 - 広告システムを作っております 2 ※　Adways IR資料（2023年12月期 決算説明会）
3. ©ADWAYS DEEE Inc. 3 ADWAYS DEEEの紹介 - 広告システムを作っております - 認知メインの広告（ディスプレイ広告）ではなく 体験メインの広告（アフィリエイト、リワード）を扱っている 3
4. ©ADWAYS DEEE Inc. 4 自己紹介 大曲 智久（オオマガリ トモヒサ） - ADWAYS DEEE 取締役CTO - テクノロジー、プロダクト 4 セミナー ・UXへの投資と組織変革 ─ ビジネスに貢献するUXチームの飛躍 ─ ・Tanzu Labs Meetup 2024 開催レポート エンジニアブログで書いた記事（2012年から続くブログ） ・20周年を迎えたサービスでビジネスドメインと向き合いモダナイゼーションを推進 ・エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 ・新たな組織改善にチームトポロジーを活用したいと思っているところ ・プロダクト開発のロードマップや優先度付けでプロダクトマネージャーが利用する図の話
5. ©ADWAYS DEEE Inc. 5 伝えたいこと - プロダクトチームの組織設計の参考 - 多様性のあるチームでの課題に対する 解決策の事例 - マインド形成とプロセスづくりのバランス判断 （苦悩に近い内容） 5
6. 6 アジェンダ ©ADWAYS DEEE Inc.
7. ©ADWAYS DEEE Inc. 7 アジェンダ - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 7
8. 8 MGRのPdM兼務時代 ©ADWAYS DEEE Inc.
9. ©ADWAYS DEEE Inc. 9 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 9
10. 10 組織の変化（MGRのPdM兼務時代） - PdMをMGRが兼務している - デザイナーは専門チーム（適宜チームにJOINしている） - ビジネス側にディレクターがおり、一緒に仮説検証を推進してくれた 組織図の特徴 ©ADWAYS DEEE Inc.
11. 11 開発プロセス - 事業戦略・プロダクト戦略をロジックモデルや優先度MAPという形で説明できるように改善 （PdMを大曲や別のMGRが兼務、サブPdMとして開発チームの中でやれそうな人にお願いする） - UX、データ分析が専門チームとして独立しサービス全体と向き合えるようにしていた 組織の変化（MGRのPdM兼務時代） ©ADWAYS DEEE Inc.
12. 12 組織の変化（MGRのPdM兼務時代） 2019年くらい？ 開発組織が自分たちで開発する 価値を判断するために動き始 め、MVPキャンバスを活用して 仮説検証をサイクルを回す ※　安定した開発を求めてリリーストレインを導入してみた話 ©ADWAYS DEEE Inc.
13. 13 組織の変化（MGRのPdM兼務時代） ©ADWAYS DEEE Inc. UXリサーチとして、生活者のユーザーインタビュー・アンケートからペルソナ策定 経験値を共有する、プロジェクト横断型プロセス設計のススメ 自社メディアがなくてもリサーチできる、3つのポイント
14. 14 組織の変化（MGRのPdM兼務時代） ロジックモデル 事業のミッションに対して短中長期の繋がりを説明（ビジネスとの関連性も追加） ※　プロダクト開発のロードマップや優先度付けでプロダクトマネージャー（PM,PdM）が利用する図の話 ©ADWAYS DEEE Inc.
15. 15 組織の変化（MGRのPdM兼務時代） ※　プロダクト開発のロードマップや優先度付けでプロダクトマネージャー（PM,PdM）が利用する図の話 優先度MAP 仮説検証の状態と 事業の優位性への影響 を表し継続的に事業全 体に価値を提供できて いるか確認 ©ADWAYS DEEE Inc.
16. 16 組織の変化（MGRのPdM兼務時代） 事業貢献を可視化し、 P/Lに近い目標設定 ※　エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 ©ADWAYS DEEE Inc.
17. 17 組織の変化（MGRのPdM兼務時代） 定量化を行い、事業貢献への影響を測定 - 新機能開発後の売上貢献度の計測 - 工数から新規価値の割合の計測 ※　エンジニアの事業貢献のために、開発生産性っぽいものを定量化した話 ©ADWAYS DEEE Inc.
18. 18 組織の変化（MGRのPdM兼務時代） まとめ - 開発組織が事業貢献に向けて意識が上がり プロダクトの価値や課題ベースの会話が増えた - 専属ではないPdMでもあるため、 もっとできる余地あるのにやりきれない悔しさがあった 兼務を行う判断に後悔はなかった （責任者が価値と向き合うことはよかった） ©ADWAYS DEEE Inc.
19. ©ADWAYS DEEE Inc. 19 プロダクトチームの誕生
20. ©ADWAYS DEEE Inc. 20 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 20
21. ©ADWAYS DEEE Inc. 21 21 組織が子会社化した ※会社分割（簡易新設分割）による子会社設立に関するお知らせ 組織の変化（プロダクトチームの誕生）
22. ©ADWAYS DEEE Inc. 22 組織の変化（プロダクトチームの誕生） 22 データドリブンでユーザーを幸せにする ミッション ビジョン 開発組織からプロダクト組織へ 圧倒的にセールスしやすいプロダクトを作るチーム データ・・広告データだけでなくユーザーの感情データも含まれる ユーザー・・生活者、広告主、メディア
23. ©ADWAYS DEEE Inc. 23 23 組織の変化（プロダクトチームの誕生） Tanzu Labs（旧 Pivotal Labs）が推奨している Lean XPのバランスチームを強く意識するようになった （フィーチャーチームとも言ったりしている） 特徴 - PdM、プロダクトデザイナー、エンジニアの3ロールで構成し、 オーナーは存在しない（スクラムのPOとは違う） - プログラミング手法が多いXPに対して リーンスタートアップとユーザー中心設計を組み合わせたもの ※　お客様の DX を支援する Tanzu Labs とは (パート 1） 　　スクラムは何であって何ではないのか。XP、そしてLeanXPは何が違うのか
24. ©ADWAYS DEEE Inc. 24 24 組織の変化（プロダクトチームの誕生） - PdMを専任化（ビジネス組織 からディレクターを移動） - デザイナーも専門チーム化を やめた - エンジニアはシニア層を出来 るだけプロダクトチームに移 動させた 組織図の変化
25. 25 組織の変化（プロダクトチームの誕生） 開発プロセス - プロダクトチームとしてチーム設計、ディレクターをPdMを抜擢し、専門のPdMチームの設立、 プロダクトデザイナー（UI/UXデザイナー）が常にPdMと並走 - UXチームはプロダクトチームにJOIN、データ分析は専門チーム継続
26. ©ADWAYS DEEE Inc. 26 26 組織の変化（プロダクトチームの誕生） 色々な問題は出た - 「PdMの教育方針が定まらない」 - 「新規チームとして設立したばかりで営業との連携が未完成」 - 「プロダクトチーム内でのロールごとの連携」 体制やプロセスを整理しても上手くいくわけがなく。。。。。 その中でも優先度高い問題として プロダクトチーム内で 複数プロジェクトが並走してしまう
27. ©ADWAYS DEEE Inc. 27 27 組織の変化（プロダクトチームの誕生） チームの中で常に複数のプロジェクトがあり スプリトレビューの議題も複数のプロジェクトが入り乱れる状態にもなった
28. ©ADWAYS DEEE Inc. 28 28 組織の変化（プロダクトチームの誕生） 課題を深掘りすると、色々な観点が出た リソースがもったいないと考え、 やりたいことはたくさんあるため プロジェクトを作った デリバリーフェーズにおいて共創 が少ない（ディスカバリーフェー ズの共創はよく話題に出る） プロジェクトで前倒しで 出来るものがあるかを常に 意識できていない
29. ©ADWAYS DEEE Inc. 29 29 組織の変化（プロダクトチームの誕生） リソース効率重視問題を組織設計で、強制的に１チーム１プロジェクト状態に移行 まずは１プロジェクトをどれだけ 早くできるかだけを考えよう
30. ©ADWAYS DEEE Inc. 30 30 組織の変化（プロダクトチームの誕生） 理想とするチーム（A,B,C）も できる一方でD・Eチームのような 兼務前提のチームが増えてしまっ た リソースが充実しているわけでは ないので、それでも推し進めない と開発するべき機能はあり無理で も仕方ないとやってみた
31. ©ADWAYS DEEE Inc. 31 31 組織の変化（プロダクトチームの誕生） プロジェクトが減ったことでフロー効率を意識させる動きが活発になり、 前倒しできる部分を探す思考が身に付きやすくなった また、チームの振り返りでプロセス単位（VSM）と向き合ったり、 定量化された数値（Findy Team+）も意識した振り返りを行った
32. ©ADWAYS DEEE Inc. 32 32 組織の変化（プロダクトチームの誕生） チームをスモール化してみてどうだったか？ よかった部分 - チームとしてのフットワークは軽くなった - エンジニアがインタビューに参加したり、 プロダクトKPIを全員で考えたりと価値を考える動きは活発になった - フロー効率のみを考える環境を作れた（振り返りや１チーム１プロジェクトの強制力） モヤモヤ部分 - 事業的にどうしても進めたいプロジェクトもあり、兼務前提のチームが出来た - デリバリーフェーズになるとエンジニアの負担が増える
33. ©ADWAYS DEEE Inc. 33 33 組織の変化（プロダクトチームの誕生） Objective Key Results 2023年 上半期 プロダクトチームとしてスピー ディーに価値を提供する - ユーザーにインパクトを与えたリリース7件 - スクラム成熟度を上げるための改善実績30件 - 開発組織の価値向上 10件 - 未来を見据えた技術改善 8件 2023年 下半期 スピーディーな価値提供のため に、チームとして最短距離を自 発的に考えて行動できるように 徹底する - プロダクト開発に集中しやすい体制構築 - ムダを無くした行動　40件 組織全体の目標も分野（プロダクト、スクラム、テクノロジー）毎で分割していた 組織として最優先とする課題に対して集中するために分野毎での分割をやめた （MGRの動きもフィーチャーチームにしよう）
34. ©ADWAYS DEEE Inc. 34 34 組織の変化（プロダクトチームの誕生） 「プロダクト開発に集中しやすい体 制構築」の一部でProdOps (Product Operations)チームが設立した ・プロダクト戦略のテンプレート化 ・ステークホルダーマップ作成 ..etc ※　ProdOpsチームで解決！プロダクトチームの生産性を高める組織戦略とは
35. ©ADWAYS DEEE Inc. 35 35 組織の変化（プロダクトチームの誕生） まとめ - 徹底的なフロー効率を求めた組織設計 - 各ロール（PdM、デザイナー、エンジニア）を揃えた上でスモールチームにすることにした - フローを意識した振り返り（VSMやFindy Team+）の実施 - 組織目標もまたロールを超えた越境の設計に変更 - 分野ごとの目標から複数のロールが関係する目標設計に変更 - ProdOps（戦略策定と管理、チーム内外コミュニケーション）チームの誕生
36. ©ADWAYS DEEE Inc. 36 チームとしての型の確立
37. ©ADWAYS DEEE Inc. 37 組織の変化 - 2022年　MGRのPdM兼務時代 - 2023年　プロダクトチームの誕生 - 2024年　チームとしての型の確立 37
38. ©ADWAYS DEEE Inc. 38 38 組織の変化（チームとしての型の確立） 開発プロセス - ProdOpsがプロダクトを取り巻く環境をサポート プロダクト戦略策定・振り返りサポート、PMMの役割策定、 プロダクト全体（開発、営業）定例推進、コミュニケーション設計
39. ©ADWAYS DEEE Inc. 39 39 組織の変化（チームとしての型の確立） 「オーナーシップを持とう」、 「越境しよう」、「共創しよう」 「エンジニアも価値を意識しよ う」...etc 全て共感はできる。 ただ、組織として再現性を高める動きや 言語化の難しさがあった ※複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン
40. ©ADWAYS DEEE Inc. 40 40 組織の変化（チームとしての型の確立） ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
41. ©ADWAYS DEEE Inc. 41 41 組織の変化（チームとしての型の確立） ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
42. ©ADWAYS DEEE Inc. 42 42 組織の変化（チームとしての型の確立） プロダクトの価値を決めるために ３つの分野・ロールを大事にしている ↓ ３つのアウトプットがプロダクトの価値を決める ↓ チーム自身は３つのアウトプットの品質が足りて いるか確認する必要がある 品質＝仮説の不確実性が低く、 価値の見込みが高いと言えるか
43. ©ADWAYS DEEE Inc. 43 43 組織の変化（チームとしての型の確立） プロジェクト開始当初は ３つ（ビジネス、デザイン、テクノロジー）の 分野は全て不確実性が高い ※ディスカバリーにおいて 上記のすべての作業の完了必須の意図はない あくまでイメージです ソリューションの決定 日々のアウトプットを通して ３つのうちどれが一番不確実性が高くなって いるかを意識すること大事 ※　日々のアウトプットの変化＝ DSするごとに変わると全然ある ※　不確実性が高いポイント＝赤色で表示 ↓ それを最重要なタスクとして チーム全体でフォローし合う 分野を担当する職種がチームをリードする ※　プロジェクトの管理責任を持ちやすいPdMやスクラムマス ターがチームの議論をリードしがちだけどそれはベストではない
44. ©ADWAYS DEEE Inc. 44 44 組織の変化（チームとしての型の確立） テクノロジーの不確実性が 高いパターン 前提： ソリューション案でAI使ってよしなにできるじゃね？ タスク： 技術調査をしよう 直面する課題： 技術調査をする範囲が広すぎる。自社に知見が少ない。 やろうと思えばなんでも出来そう。 対応策： ➔ テクノロジー・・ 技術調査はメインで頑張る ➔ ビジネス・・・・ どのパターンのみをAI化できればビジネス貢献が高いか考える 顧客にとってAIの効果を実感できるのか ➔ デザイン・・・・ AIを活用した体験はどう変化してどんな課題を解決できるのかを考える
45. ©ADWAYS DEEE Inc. 45 45 組織の変化（チームとしての型の確立） 通常のタスク ディスカバリー のタスク
46. ©ADWAYS DEEE Inc. 46 46 組織の変化（チームとしての型の確立） - 不確実性が高いタスクほど全ての範囲をやる必要はない - どの事実・学びが判明したら、次のステップに進めるかを見極めることが大事 - 他ロールの動きによって切り口が見つかり、必要最低限のポイントが絞られたりする - 自身の専門性を活かした他ロールへの貢献を考えることが一番やるべき越境であり、共創である - エンジニアがPdMっぽいことをやっても全然良いと思うが、（逆も然りPdMがエンジニアっぽいことやる） 全てにおいてそれが良いというわけではない ディスカバリーのタスクの特徴
47. ©ADWAYS DEEE Inc. 47 47 組織の変化（チームとしての型の確立） ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
48. ©ADWAYS DEEE Inc. 48 48 組織の変化（チームとしての型の確立） AIに関しての技術調査タスクのイメージ図
49. ©ADWAYS DEEE Inc. 49 49 組織の変化（チームとしての型の確立） テクノロジーの不確実性の壁を越えたら、次はデザインの不確実性が高かった。。。。 フライングとは タスクの中盤〜終盤での作業をロールを超えたペア作業をやること
50. ©ADWAYS DEEE Inc. 50 50 組織の変化（チームとしての型の確立） ロールを超えたペア作業をやることで ➔ 他ロールのアウトプットの品質が向上する ◆ プロトタイプ作成でエンジニアの実現可能性を盛り込んだ方が絶対に良い..etc ➔ 担当しているロールの仕事にも良い影響がある ◆ アーキテクチャ設計でユーザー体験視点の重要性を理解した上でアーキテクチャ設計を することでプロダクト価値を意識した技術選定が可能になる..etc
51. ©ADWAYS DEEE Inc. 51 51 組織の変化（チームとしての型の確立） - チーム全体で不確実性が高い分野を判断し、フォローし合う（共創） - 自身の専門分野がチームにとって一番不確実性が高い場合に 積極的なリーダーシップを取りチームの議論をリードする（オーナーシップ） - アウトプットを待つのではなくフライングして一緒にアウトプットをつくる（越境） - 専門外に対しても自身の専門分野で貢献できる余地を探し出来るだけ早く合流すること - 例：デザイナーのプロトタイプ作成では、大枠が決まったらエンジニアも合流することでプロトタイプの 実現性が向上するかつどこまで何をやれるかの選択肢の幅も広がる 初めからエンジニアが付きっきりで一緒にやることが必須ではない（何も関わらないはNG） 目指している状態
52. ©ADWAYS DEEE Inc. 52 52 組織の変化（チームとしての型の確立） ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
53. ©ADWAYS DEEE Inc. 53 53 組織の変化（プロダクトチームの誕生） リソースがもったいないと考え、 やりたいことはたくさんあるため プロジェクトを作った デリバリーフェーズにおいて共創 が少ない（ディスカバリーフェー ズの共創はよく話題に出る） プロジェクトで前倒しで 出来るものがあるかを常に 意識できていない
54. ©ADWAYS DEEE Inc. 54 54 組織の変化（チームとしての型の確立） デリバリーフェーズは、エンジニア任せでも良いとも思っていた リリース後の分析やマーケティングをPdMやデザイナーは進めれば良いため ストーリーライティングを通じた 開発プロセスを体験したら考えが変わりました
55. ©ADWAYS DEEE Inc. 55 55 組織の変化（チームとしての型の確立） WHY As ペルソナは I want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ※　ユーザーストーリーを元にした会話と定着 ストーリーの形式
56. ©ADWAYS DEEE Inc. 56 56 組織の変化（チームとしての型の確立） ストーリーの粒度は、2~3日で実装できる規模が多い - 「XX バリデーション処理を実行する」「XX Cookieに保存する」..etc - エンジニアと議論して、テストしやすい受け入れ基準の決めたりする - エラーケースや非機能要件はエンジニアがリードしてPdMに提案する（=全ての要件をPdMが決めない） - デザイナーはデザインに関わるストーリー（アニメーションやデザイン反映..etc）を作成する （自分で作成して自分で消化することもあり） ストーリーの優先度もPdMがベースを考える（フロー図などを用いて何から着手するかを決める） 最初のストーリーのフロー図 最後のストーリーのフロー図
57. ©ADWAYS DEEE Inc. 57 57 組織の変化（チームとしての型の確立） 効果 - PdMが何をどこから開発すべきかを考えてくれる - エンジニアが開発作業にのみ集中できる - デザイナーはデザインシステムを通して開発効率化に貢献 - ストーリーを通じたチームコミュニケーションの活性化 - 全てのロールの全ての作業を情報共有はだいぶ過多になりがち（透明性は大事だ けど） - ストーリーは価値ベースなので常に価値を認識し続けられる
58. ©ADWAYS DEEE Inc. 58 58 組織の変化（チームとしての型の確立） ディスカバリーからデリバリーまでチームとして共創することで チームの分断（認知負荷が高い..etc）も無く一体感を持って進められる 分断している状態
59. ©ADWAYS DEEE Inc. 59 59 組織の変化（チームとしての型の確立） ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
60. ©ADWAYS DEEE Inc. 60 60 組織の変化（チームとしての型の確立） エンジニアは、5~7時間のペアプロを推奨　（休憩大事、Discordでずっと話す、Tupleで画面共有） TDD x ペアプロ x Copilotは最強。 PdMやデザイナーも出来るだけペア作業を推奨。
61. ©ADWAYS DEEE Inc. 61 61 組織の変化（チームとしての型の確立） ※　アジャイルソフトウェア開発宣言 リモートに慣れてツールでの コミュニケーションが当たり前になってしまった ずっと話し続けるペア作業を通すことで 自然とプロセスが無くなった （ペアプロでレビュー作業が無くなる..etc） 話したいと思ったらすぐにDiscordで話しかける （ペア作業しているのでツールで聞かない） 同期的なコミュニケーションの重要性を確認
62. ©ADWAYS DEEE Inc. 62 62 組織の変化（チームとしての型の確立） 「越境しよう」「共創しよう」とか を以下の取り組みや考え方を通して行動にまで言及している ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
63. ©ADWAYS DEEE Inc. 63 63 組織の変化（チームとしての型の確立）ProdOps ステークホルダーマップを活用し、意思決定や営業も含めたコミュニケーション設計の推進 （最初は良いが、プロジェクトが進むにつれてレポートラインがゴチャゴチャになりがち.....） AS IS TO BE ※　ProdOpsチームで解決！プロダクトチームの生産性を高める組織戦略とは
64. ©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)： プロダクトが市場の需要に適合し、顧客から十分な価値を得られると感じられ、市場で成功 する可能性が高いと証明される。
65. ©ADWAYS DEEE Inc. 65 65 組織の変化（チームとしての型の確立）ProdOps 部署を超えた 定例会の実施を推進 ※　セールス、プロダクトが相互理解を持つための取り組み
66. ©ADWAYS DEEE Inc. 66 66 組織の変化（チームとしての型の確立） まとめ - ロールを超えた共創の形が見えつつある - ディスカバリーフェーズ：専門分野以外にも興味を持ち、チーム全体で不確実性の高い分 野をフォローする（時には全員でやりきることも良い手段） - デリバリーフェーズ：PdMやデザイナーにおいてもストーリーライティングを通してエン ジニアのみのリソースから限界突破を実現可能 - チーム全体：リモートが当たり前化している中で、対面の重要性を理解しペア作業の徹底 を行うことでチームとしての同期頻度を高め、認知負荷を減らし、一体感を高められる - ProdOpsを通して 着実にプロダクトチームを支える体制が出来つつある
67. ©ADWAYS DEEE Inc. 67 まとめ
68. ©ADWAYS DEEE Inc. 68 まとめ 68 - プロダクトチームはフロー効率を徹底的に意識させる 開発フローや組織設計が大事 - 越境はエンジニアだけはない PdMやデザイナーがデリバリーフェーズはもっと開発が早くなる！！ - プロダクトチームとしてオーナーシップを保つために それを外部からサポートするチームの存在（ProdOps）は重要
69. ©ADWAYS DEEE Inc. 69 伝えたいこと - プロダクトチームの組織設計の参考 →　チームをスモールにして正しい連携ができるように慣らす - 多様性のあるチームでの課題に対する解決策の事例 →　ディスカバー（フライング..etc）、 　　デリバリー（ストーリーライティング）、ペア作業の徹底 - マインド形成とプロセスづくりのバランス判断（苦悩に近い内容） →　全てが良い言語化・プロセス化が出来るとは思ってはいないが 　　挑戦し続けなければいけない 　　チームから離れた横断組織（ProdOps）が大事 69
70. ©ADWAYS DEEE Inc. 70 おわり