$30 off During Our Annual Pro Sale. View Details »

多様性のあるプロダクトチームを目指した共創の3年間の変化 / Three Years of C...

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

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

Tomohisa Omagari

September 28, 2024
Tweet

More Decks by Tomohisa Omagari

Other Decks in Technology

Transcript

  1. ©ADWAYS DEEE Inc. 4 自己紹介 大曲 智久(オオマガリ トモヒサ) - ADWAYS

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

    圧倒的にセールスしやすいプロダクトを作るチーム データ・・広告データだけでなくユーザーの感情データも含まれる ユーザー・・生活者、広告主、メディア
  3. ©ADWAYS DEEE Inc. 23 23 組織の変化(プロダクトチームの誕生) Tanzu Labs(旧 Pivotal Labs)が推奨している

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

    デザイナーも専門チーム化を やめた - エンジニアはシニア層を出来 るだけプロダクトチームに移 動させた 組織図の変化
  5. ©ADWAYS DEEE Inc. 26 26 組織の変化(プロダクトチームの誕生) 色々な問題は出た - 「PdMの教育方針が定まらない」 -

    「新規チームとして設立したばかりで営業との連携が未完成」 - 「プロダクトチーム内でのロールごとの連携」 体制やプロセスを整理しても上手くいくわけがなく。。。。。 その中でも優先度高い問題として プロダクトチーム内で 複数プロジェクトが並走してしまう
  6. ©ADWAYS DEEE Inc. 28 28 組織の変化(プロダクトチームの誕生) 課題を深掘りすると、色々な観点が出た リソースがもったいないと考え、 やりたいことはたくさんあるため プロジェクトを作った

    デリバリーフェーズにおいて共創 が少ない(ディスカバリーフェー ズの共創はよく話題に出る) プロジェクトで前倒しで 出来るものがあるかを常に 意識できていない
  7. ©ADWAYS DEEE Inc. 30 30 組織の変化(プロダクトチームの誕生) 理想とするチーム(A,B,C)も できる一方でD・Eチームのような 兼務前提のチームが増えてしまっ た

    リソースが充実しているわけでは ないので、それでも推し進めない と開発するべき機能はあり無理で も仕方ないとやってみた
  8. ©ADWAYS DEEE Inc. 32 32 組織の変化(プロダクトチームの誕生) チームをスモール化してみてどうだったか? よかった部分 - チームとしてのフットワークは軽くなった

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

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

    ・プロダクト戦略のテンプレート化 ・ステークホルダーマップ作成 ..etc ※ ProdOpsチームで解決!プロダクトチームの生産性を高める組織戦略とは
  11. ©ADWAYS DEEE Inc. 35 35 組織の変化(プロダクトチームの誕生) まとめ - 徹底的なフロー効率を求めた組織設計 -

    各ロール(PdM、デザイナー、エンジニア)を揃えた上でスモールチームにすることにした - フローを意識した振り返り(VSMやFindy Team+)の実施 - 組織目標もまたロールを超えた越境の設計に変更 - 分野ごとの目標から複数のロールが関係する目標設計に変更 - ProdOps(戦略策定と管理、チーム内外コミュニケーション)チームの誕生
  12. ©ADWAYS DEEE Inc. 39 39 組織の変化(チームとしての型の確立) 「オーナーシップを持とう」、 「越境しよう」、「共創しよう」 「エンジニアも価値を意識しよ う」...etc

    全て共感はできる。 ただ、組織として再現性を高める動きや 言語化の難しさがあった ※複雑性と難易度の高いサービスリニューアルにおけるサービスデザイン
  13. ©ADWAYS DEEE Inc. 40 40 組織の変化(チームとしての型の確立) ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める -

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

    フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
  15. ©ADWAYS DEEE Inc. 42 42 組織の変化(チームとしての型の確立) プロダクトの価値を決めるために 3つの分野・ロールを大事にしている ↓ 3つのアウトプットがプロダクトの価値を決める

    ↓ チーム自身は3つのアウトプットの品質が足りて いるか確認する必要がある 品質=仮説の不確実性が低く、 価値の見込みが高いと言えるか
  16. ©ADWAYS DEEE Inc. 43 43 組織の変化(チームとしての型の確立) プロジェクト開始当初は 3つ(ビジネス、デザイン、テクノロジー)の 分野は全て不確実性が高い ※ディスカバリーにおいて

    上記のすべての作業の完了必須の意図はない あくまでイメージです ソリューションの決定 日々のアウトプットを通して 3つのうちどれが一番不確実性が高くなって いるかを意識すること大事 ※ 日々のアウトプットの変化= DSするごとに変わると全然ある ※ 不確実性が高いポイント=赤色で表示 ↓ それを最重要なタスクとして チーム全体でフォローし合う 分野を担当する職種がチームをリードする ※ プロジェクトの管理責任を持ちやすいPdMやスクラムマス ターがチームの議論をリードしがちだけどそれはベストではない
  17. ©ADWAYS DEEE Inc. 44 44 組織の変化(チームとしての型の確立) テクノロジーの不確実性が 高いパターン 前提: ソリューション案でAI使ってよしなにできるじゃね?

    タスク: 技術調査をしよう 直面する課題: 技術調査をする範囲が広すぎる。自社に知見が少ない。 やろうと思えばなんでも出来そう。 対応策: ➔ テクノロジー・・ 技術調査はメインで頑張る ➔ ビジネス・・・・ どのパターンのみをAI化できればビジネス貢献が高いか考える 顧客にとってAIの効果を実感できるのか ➔ デザイン・・・・ AIを活用した体験はどう変化してどんな課題を解決できるのかを考える
  18. ©ADWAYS DEEE Inc. 46 46 組織の変化(チームとしての型の確立) - 不確実性が高いタスクほど全ての範囲をやる必要はない - どの事実・学びが判明したら、次のステップに進めるかを見極めることが大事

    - 他ロールの動きによって切り口が見つかり、必要最低限のポイントが絞られたりする - 自身の専門性を活かした他ロールへの貢献を考えることが一番やるべき越境であり、共創である - エンジニアがPdMっぽいことをやっても全然良いと思うが、(逆も然りPdMがエンジニアっぽいことやる) 全てにおいてそれが良いというわけではない ディスカバリーのタスクの特徴
  19. ©ADWAYS DEEE Inc. 47 47 組織の変化(チームとしての型の確立) ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める -

    フライングすること デリバリー - 全員で開発作業に関わためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
  20. ©ADWAYS DEEE Inc. 50 50 組織の変化(チームとしての型の確立) ロールを超えたペア作業をやることで ➔ 他ロールのアウトプットの品質が向上する ◆

    プロトタイプ作成でエンジニアの実現可能性を盛り込んだ方が絶対に良い..etc ➔ 担当しているロールの仕事にも良い影響がある ◆ アーキテクチャ設計でユーザー体験視点の重要性を理解した上でアーキテクチャ設計を することでプロダクト価値を意識した技術選定が可能になる..etc
  21. ©ADWAYS DEEE Inc. 51 51 組織の変化(チームとしての型の確立) - チーム全体で不確実性が高い分野を判断し、フォローし合う(共創) - 自身の専門分野がチームにとって一番不確実性が高い場合に

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

    フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
  23. ©ADWAYS DEEE Inc. 53 53 組織の変化(プロダクトチームの誕生) リソースがもったいないと考え、 やりたいことはたくさんあるため プロジェクトを作った デリバリーフェーズにおいて共創

    が少ない(ディスカバリーフェー ズの共創はよく話題に出る) プロジェクトで前倒しで 出来るものがあるかを常に 意識できていない
  24. ©ADWAYS DEEE Inc. 55 55 組織の変化(チームとしての型の確立) WHY As ペルソナは I

    want 〜したい So that そうすることで、〜からだ Acceptance Criteria Given 〜の場合 When 〜の時 Then 〜なる ※ ユーザーストーリーを元にした会話と定着 ストーリーの形式
  25. ©ADWAYS DEEE Inc. 56 56 組織の変化(チームとしての型の確立) ストーリーの粒度は、2~3日で実装できる規模が多い - 「XX バリデーション処理を実行する」「XX

    Cookieに保存する」..etc - エンジニアと議論して、テストしやすい受け入れ基準の決めたりする - エラーケースや非機能要件はエンジニアがリードしてPdMに提案する(=全ての要件をPdMが決めない) - デザイナーはデザインに関わるストーリー(アニメーションやデザイン反映..etc)を作成する (自分で作成して自分で消化することもあり) ストーリーの優先度もPdMがベースを考える(フロー図などを用いて何から着手するかを決める) 最初のストーリーのフロー図 最後のストーリーのフロー図
  26. ©ADWAYS DEEE Inc. 57 57 組織の変化(チームとしての型の確立) 効果 - PdMが何をどこから開発すべきかを考えてくれる -

    エンジニアが開発作業にのみ集中できる - デザイナーはデザインシステムを通して開発効率化に貢献 - ストーリーを通じたチームコミュニケーションの活性化 - 全てのロールの全ての作業を情報共有はだいぶ過多になりがち(透明性は大事だ けど) - ストーリーは価値ベースなので常に価値を認識し続けられる
  27. ©ADWAYS DEEE Inc. 59 59 組織の変化(チームとしての型の確立) ディスカバリー - プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める -

    フライングすること デリバリー - 全員で開発作業に関わるためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
  28. ©ADWAYS DEEE Inc. 61 61 組織の変化(チームとしての型の確立) ※ アジャイルソフトウェア開発宣言 リモートに慣れてツールでの コミュニケーションが当たり前になってしまった ずっと話し続けるペア作業を通すことで

    自然とプロセスが無くなった (ペアプロでレビュー作業が無くなる..etc) 話したいと思ったらすぐにDiscordで話しかける (ペア作業しているのでツールで聞かない) 同期的なコミュニケーションの重要性を確認
  29. ©ADWAYS DEEE Inc. 62 62 組織の変化(チームとしての型の確立) 「越境しよう」「共創しよう」とか を以下の取り組みや考え方を通して行動にまで言及している ディスカバリー -

    プロジェクトの不確実の高い分野を特定し、チーム全体で取り組める - フライングすること デリバリー - 全員で開発作業に関わためのストーリーライティング チーム全体 - ペア作業の徹底による同期的コミュニケーションの活性化
  30. ©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): プロダクトが市場の需要に適合し、顧客から十分な価値を得られると感じられ、市場で成功 する可能性が高いと証明される。
  31. ©ADWAYS DEEE Inc. 66 66 組織の変化(チームとしての型の確立) まとめ - ロールを超えた共創の形が見えつつある -

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

    越境はエンジニアだけはない PdMやデザイナーがデリバリーフェーズはもっと開発が早くなる!! - プロダクトチームとしてオーナーシップを保つために それを外部からサポートするチームの存在(ProdOps)は重要
  33. ©ADWAYS DEEE Inc. 69 伝えたいこと - プロダクトチームの組織設計の参考 → チームをスモールにして正しい連携ができるように慣らす - 多様性のあるチームでの課題に対する解決策の事例

    → ディスカバー(フライング..etc)、   デリバリー(ストーリーライティング)、ペア作業の徹底 - マインド形成とプロセスづくりのバランス判断(苦悩に近い内容) → 全てが良い言語化・プロセス化が出来るとは思ってはいないが   挑戦し続けなければいけない   チームから離れた横断組織(ProdOps)が大事 69