プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記

by 幡ヶ谷亭直吉

Slide 1

Slide 1 text

プロダクトという一杯を作るプロダクトチームが味の責任を持つまでの煮込み奮闘記 TechRAMEN 2025 Conference 幡ヶ谷亭直吉 @asagayanaoki ＃techramen25conf

Slide 2

Slide 2 text

自己紹介幡ヶ谷亭直吉 / Hatagayatei Naokichi / 髙橋直規出身:神奈川 / 居住:東京エンジニア歴:18年4か月、3社経験、いずれも受託企業好きな言語:Java / 現在:Python、TypeScript、AWS 役割:PjM、PdE、POアシスタント、SM、QA 趣味:アナログレコード、映画鑑賞、マンガ好きなラーメン:８３１家みそラーメン土日の過ごし方:５歳の娘ととにかく遊ぶ

Slide 3

Slide 3 text

本日お話すること https://fortee.jp/techramen-25-conf/proposal/ebf946a2-f90a-4e88-be93-a0d4c1cd9386

Slide 4

Slide 4 text

本日お話すること ※発言は個人の見解に基づくものであり、所属組織を代表するものではありません

Slide 5

Slide 5 text

本日お話すること受託企業のプロジェクトマネージャーとしてのプロダクト開発の実践の話・準委任契約での契約の成功を目的にした開発について・リリースの成功と失敗について・失敗の経験を通した学びとチームの醸成について

Slide 6

Slide 6 text

アジェンダ 1. 準委任のPjMとして、プロジェクトに挑む覚悟 2. 初回リリースを成功させるために選んだ“最適な戦略” 3. リリース達成の裏でうまくいかなかったこと 4. “チームで味を決める”までの試行錯誤 5. まとめ

Slide 7

Slide 7 text

準委任のPjMとして、プロジェクトに挑む覚悟

Slide 8

Slide 8 text

1. 準委任のPjMとして、プロジェクトに挑む覚悟新規プロダクトの立ち上げ、すべてが“初めて”だった・顧客による新規プロダクト開発プロジェクト・当初の契約範囲はシステムリリースまで・チームは顧客の内製メンバーと自社メンバーの混成編成・ほぼ全員が初対面

Slide 9

Slide 9 text

要件定義基本設計詳細設計実装・UT 結合テスト総合テスト UAT 詳細設計～結合テストはスクラム開発 1. 準委任のPjMとして、プロジェクトに挑む覚悟

Slide 10

Slide 10 text

プロジェクトマネージャーとして自分に課した3つの覚悟・プロジェクト（契約）を必ず成功させる・プロダクトのリリースに最大限の貢献をする・顧客の要望を実現し、自社の成功にもつなげる 1. 準委任のPjMとして、プロジェクトに挑む覚悟

Slide 11

Slide 11 text

初回リリースを成功させるために選んだ“最適な戦略”

Slide 12

Slide 12 text

2. 初回リリースを成功させるために選んだ“最適な戦略” プロジェクトが進む中でいくつかの課題が発生していった・設計の遅延・実装・テストの遅延・リリースの判断ができない品質状態

Slide 13

Slide 13 text

プロジェクトが進む中でいくつかの課題が発生していった・設計の遅延・実装・テストの遅延・リリースの判断ができない品質状態 2. 初回リリースを成功させるために選んだ“最適な戦略”

Slide 14

Slide 14 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・設計の遅延要件の大幅変更やメンバーの経験不足などによって設計工程が遅延。実装メンバーの参画時期も決まっていたため、次の工程を進めていきたい状態。基本設計詳細設計実装・UT 結合テスト

Slide 15

Slide 15 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 実装メンバーの参画タイミングは変えられないため、設計チームと開発チームを分離し、出来上がっている設計書をもとに開発チームが実装を先行開始。残る設計は設計チームが引き続き担当。基本設計詳細設計実装・UT 結合テストファストトラッキングで進めましょう

Slide 16

Slide 16 text

Slide 17

Slide 17 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・実装・テストの遅延はじめてのチームで、スキルセットとしても習熟したメンバーがいない中で開発が進んでいたため、計画よりも進捗が遅れている状態が継続。基本設計詳細設計実装・UT 結合テスト

Slide 18

Slide 18 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 結合テストを専任するQAチームを新設することで、開発チームから結合テスト分の作業量を削減。開発チームは作ることに専念し、結合テストを専門的な知見を持つQAチームで担当することで質とスピードを実現。基本設計詳細設計実装・UT 結合テスト専門家のテストでスピードをあげましょう

Slide 19

Slide 19 text

2. 初回リリースを成功させるために選んだ“最適な戦略” その結果

Slide 20

Slide 20 text

要件定義基本設計詳細設計実装・UT 結合テスト総合テスト UAT なかなか終わらないなかなか終わらない 2. 初回リリースを成功させるために選んだ“最適な戦略”

Slide 21

Slide 21 text

2. 初回リリースを成功させるために選んだ“最適な戦略” その結果

Slide 22

Slide 22 text

要件定義基本設計詳細設計実装・UT 結合テスト UAT 総合テスト 2. 初回リリースを成功させるために選んだ“最適な戦略”

Slide 23

Slide 23 text

Slide 24

Slide 24 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・リリースの判断ができない品質状態結合テストの結果を分析すると、リリース基準を満たせない状態であることが判明。また、総合テストの計画・設計ができる人間が設計チームに依存。 UAT 総合テスト

Slide 25

Slide 25 text

2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 品質を改善するための施策検討、総合テストの推進・品質分析などを自分が一手に引き受ける。私がやります…!! UAT 総合テスト

Slide 26

Slide 26 text

2. 初回リリースを成功させるために選んだ“最適な戦略” その結果

Slide 27

Slide 27 text

2. 初回リリースを成功させるために選んだ“最適な戦略” リリース達成

Slide 28

Slide 28 text

プロジェクトマネージャーとして自分に課した3つの覚悟（再掲）・プロジェクト（契約）を必ず成功させる・プロダクトのリリースに最大限の貢献をする・顧客の要望を実現し、自社の成功にもつなげる一律達成することはできた!!! …ただ、開発は続いていきます。 2. 初回リリースを成功させるために選んだ“最適な戦略”

Slide 29

Slide 29 text

リリース達成の裏でうまくいかなかったこと

Slide 30

Slide 30 text

リリース達成の裏でうまくいかなかったこと・設計チームの失敗・QAチームの失敗・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと

Slide 31

Slide 31 text

リリース達成の裏でうまくいかなかったこと・設計チームの失敗・QAチームの失敗・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと

Slide 32

Slide 32 text

3. リリース達成の裏でうまくいかなかったこと・設計チームの失敗設計チームでシステムで考慮すべき細かい仕様を詰めることはできた。ただ、開発チームに対するドキュメントベースでの伝達では、ドキュメントには表れない仕様の意図や背景を伝えることができなかった。記載してある仕様自体も充分には伝わらなかった。チームの分断は、暗黙的な考える人作る人の構造さえ生んでいた。基本設計詳細設計実装・UT

Slide 33

Slide 33 text

3. リリース達成の裏でうまくいかなかったことシステムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう、というのが基本的な主張だ。この事実がシステム設計の管理において重要な意味を持つことがわかった。主要な発見は、設計を行う組織を構造化するための基準である。コミュニケーションの必要性に応じた設計活動を行うべきなのだ。はじめにコンウェイの法則

Slide 34

Slide 34 text

リリース達成の裏でうまくいかなかったこと・設計チームの失敗・QAチームの失敗・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと

Slide 35

Slide 35 text

3. リリース達成の裏でうまくいかなかったこと・QAチームの失敗 QAチームでのテストにより一定の不具合を検出することはできた。ただ、検出した欠陥から得られるはずだった学びを、開発チームが充分に受けることができなかった。結果、開発チームのスプリント毎の品質改善に繋げることができなかった。開発チームの成果物は常に同じ程度の品質でQAチームに渡り続け、 QAチームが検出できなかった不具合は総合テストまで眠り続けた。実装・UT 結合テスト

Slide 36

Slide 36 text

3. リリース達成の裏でうまくいかなかったこと devopsに取り組んでおらずサイロ化している環境では共通理解が欠如している。（中略）意思疎通がないので、失敗する確率のほうが高くなるはずだ。組織では、進んでいく過程で、必ず予想外の問題や障害にぶつかる。しかし、全員が共同体に属しているという共通理解があれば、人は修復に向かっていく。 2章 devopsとは何か 2.3.2 devops共同体

Slide 37

Slide 37 text

リリース達成の裏でうまくいかなかったこと・設計チームの失敗・QAチームの失敗・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと

Slide 38

Slide 38 text

3. リリース達成の裏でうまくいかなかったこと・属人性の失敗プロジェクトマネージャーがひとりで行った品質分析や強化テストに向けた検討はチームのものにならなかった。プロジェクトの問題を解決に導くという機会からメンバーを遠ざけることで、プロダクトに対するオーナーシップを育む機会から遠ざけてしまっていた。 UAT 総合テスト

Slide 39

Slide 39 text

3. リリース達成の裏でうまくいかなかったことヒーローは本当にメンテナンス不可能な存在である。⾧時間労働と、コミュニケーションのコストを最小限にすることで（なぜ最小限にするかというと、他の大半の人たちは彼らほどできないからである）、彼らは短期間の生産性を高めるが、代わりに彼らの存在によって周りの人の効果が制限される。 5章文化:継続的に取り組んで育成する 5.6 ヒーローをやっつけ、頑張りすぎをやめる

Slide 40

Slide 40 text

リリース達成の裏でうまくいかなかったこと・設計チームの失敗・QAチームの失敗・属人性の失敗プロジェクトマネージャーとして最適と判断して選択した戦略により、リリースや契約の成功は実現したものの、プロダクト開発を持続可能とするチームの成⾧を阻害してしまっていた。プロダクト成⾧を持続可能とするには、開発の進め方を抜本的に見直す必要があった。 3. リリース達成の裏でうまくいかなかったこと

Slide 41

Slide 41 text

“チームで味を決める”までの試行錯誤

Slide 42

Slide 42 text

4. “チームで味を決める”までの試行錯誤初回リリース後のプロダクト開発についてプロダクトは事業要求により随時の機能拡張が求められる状態になった。初回リリース時のビッグバンリリースではなく、スプリント毎のリリースを繰り返すスクラム開発への移行が必要となった。

Slide 43

Slide 43 text

アジャイル型の適応型開発を実現するにあたる試行錯誤・ワンチーム性の導入・チームで仕様策定ができる状態に・チームで品質保証ができる状態に・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤

Slide 44

Slide 44 text

Slide 45

Slide 45 text

4. “チームで味を決める”までの試行錯誤・ワンチーム性の導入役割でのチーム制を廃止。開発チームをストリームアラインドチームとして、設計、開発、テスト、リリース、運用監視までを担当する役割に変更。スプリント毎のリリースを実現。

Slide 46

Slide 46 text

Slide 47

Slide 47 text

4. “チームで味を決める”までの試行錯誤・チームで仕様策定ができる状態にプロダクトで実現するものを検討するためのリファインメントを効果的に扱うことで、開発に着手する前に個人ではなくチームで仕様検討ができる状態に。スプリント中に開発をしながら検討された細かな仕様についても、担当者に属人化しないよう開発完了後にチーム内で共有するなどの施策も導入。

Slide 48

Slide 48 text

Slide 49

Slide 49 text

4. “チームで味を決める”までの試行錯誤・チームで品質保証ができる状態に開発チームでテスト計画、設計、実行、分析を担当する形に。初期はQAチームがイネーブリングチームとして開発チームが自走できる状態までサポート。開発チームが自ら発生した不具合を分析することでプロセスを改善していき、機能性でのバグを持ち越すことが稀となる状態を実現。

Slide 50

Slide 50 text

Slide 51

Slide 51 text

4. “チームで味を決める”までの試行錯誤・チームで問題解決ができる状態にただの個人の集まりではなく、チームとしてプロダクト開発に向き合えるようチームでの会話や同期での作業をできる時間を増やし、スクラムイベントでの忌憚のない議論を重ねることで、チームでの方針を決定できる状態を実現。

Slide 52

Slide 52 text

アジャイル型の適応型開発を実現するにあたる試行錯誤・ワンチーム性の導入・チームで仕様策定ができる状態に・チームで品質保証ができる状態に・チームで問題解決ができる状態に・必ずしもチームで実現しなくて良いことも 4. “チームで味を決める”までの試行錯誤

Slide 53

Slide 53 text

4. “チームで味を決める”までの試行錯誤・必ずしもチームで実現しなくて良いこともチームという単位で実現しなくても良いこともあった。リリース後に運用監視のための土台を築く必要があった。最初はチーム全員で何をするか検討しながら持ち回りに実施していた。その結果、いつまでも地盤が固まらない状態が続いた。運用監視に少しでも知見のある人間が、やるべきことを固め、その後チームで扱える状態にしていった。

Slide 54

Slide 54 text

アジャイル型の適応型開発を実現するにあたる試行錯誤・ワンチーム性の導入・チームで仕様策定ができる状態に・チームで品質保証ができる状態に・チームで問題解決ができる状態に・必ずしもチームで実現しなくて良いこともここまでの流れはプロジェクトマネージャーが一方的に推進したわけではなく、顧客であるPOも含めたスクラムチームが、自分たちでどうすれば健全なプロダクト開発を持続できるか検討した。 4. “チームで味を決める”までの試行錯誤

Slide 55

Slide 55 text

チームで判断し実行することで、チームがその結果に伴うフィードバックを直接受け取れる状態を実現できた。フィードバックからの学びを次の活動に活かすことで試行錯誤を繰り返し、チームの継続的な成⾧を実現している。 4. “チームで味を決める”までの試行錯誤

Slide 56

Slide 56 text

4. “チームで味を決める”までの試行錯誤その結果

Slide 57

Slide 57 text

4. “チームで味を決める”までの試行錯誤持続可能なプロダクト開発を実現

Slide 58

Slide 58 text

まとめ

Slide 59

Slide 59 text

5. まとめ・プロダクトは継続して成⾧していく初回リリースに対しては、プロジェクト（契約）の単位でしかプロダクト開発を捉えることができていなかった。継続可能なプロダクト開発の実現を考えるべきだった。そのためには、個人ではなくチームで開発を実現する必要があった。初回リリース迄適応型開発

Slide 60

Slide 60 text

5. まとめ・チームの成⾧にはフィードバックサイクルが重要初回リリースではチームの成⾧を意識できていなかった。チーム成⾧にはチームが活動しながら学ぶためのフィードバックサイクルが重要。チームが主軸となってプロダクト開発を経験することで、チームとプロダクトが健全な成⾧を続けることができる。基本設計詳細設計実装・UT 結合テスト

Slide 61

Slide 61 text

5. まとめ初回リリースまでの失敗をもとに、私たちは継続的に成⾧を繰り返しながらラーメンの味を良くしていけるチームになることができた。そのために必要だったのは、誰か一人に依存したり、役割でチームを分断する戦略ではなく、チームでおいしい一杯＝価値あるプロダクトをつくるための試行錯誤をしていくための文化醸成でした。プロダクトマネージャーとしてやるべきことはそうしたチームやプロダクトの成⾧を持続していくことであると気付くことができました。

Slide 62

Slide 62 text

ご清聴ありがとうございました!! プロダクトという一杯を作るプロダクトチームが味の責任を持つまでの煮込み奮闘記