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

プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
TechRAMEN 2025 Conference
2025年7月26日（土）
https://fortee.jp/techramen-25-conf/proposal/ebf946a2-f90a-4e88-be93-a0d4c1cd9386

Transcript

1. プロダクトという一杯を作る プロダクトチームが味の責任を持つまでの煮込み奮闘記 TechRAMEN 2025 Conference 幡ヶ谷亭直吉 @asagayanaoki ＃techramen25conf
2. 自己紹介 幡ヶ谷亭直吉 / Hatagayatei Naokichi / 髙橋直規 出身:神奈川 / 居住:東京 エンジニア歴:18年4か月、3社経験、いずれも受託企業 好きな言語:Java / 現在:Python、TypeScript、AWS 役割:PjM、PdE、POアシスタント、SM、QA 趣味:アナログレコード、映画鑑賞、マンガ 好きなラーメン:８３１家 みそラーメン 土日の過ごし方:５歳の娘ととにかく遊ぶ
3. 本日お話すること https://fortee.jp/techramen-25-conf/proposal/ebf946a2-f90a-4e88-be93-a0d4c1cd9386
4. 本日お話すること ※発言は個人の見解に基づくものであり、所属組織を代表するものではありません
5. 本日お話すること 受託企業のプロジェクトマネージャーとしてのプロダクト開発の実践の話 ・準委任契約での契約の成功を目的にした開発について ・リリースの成功と失敗について ・失敗の経験を通した学びとチームの醸成について
6. アジェンダ 1. 準委任のPjMとして、プロジェクトに挑む覚悟 2. 初回リリースを成功させるために選んだ“最適な戦略” 3. リリース達成の裏でうまくいかなかったこと 4. “チームで味を決める”までの試行錯誤 5. まとめ
7. 準委任のPjMとして、 プロジェクトに挑む覚悟
8. 1. 準委任のPjMとして、プロジェクトに挑む覚悟 新規プロダクトの立ち上げ、すべてが“初めて”だった ・顧客による新規プロダクト開発プロジェクト ・当初の契約範囲はシステムリリースまで ・チームは顧客の内製メンバーと自社メンバーの混成編成 ・ほぼ全員が初対面
9. 要件定義 基本設計 詳細設計 実装・UT 結合テスト 総合テスト UAT 詳細設計～結合テストは スクラム開発 1. 準委任のPjMとして、プロジェクトに挑む覚悟
10. プロジェクトマネージャーとして自分に課した3つの覚悟 ・プロジェクト（契約）を必ず成功させる ・プロダクトのリリースに最大限の貢献をする ・顧客の要望を実現し、自社の成功にもつなげる 1. 準委任のPjMとして、プロジェクトに挑む覚悟
11. 初回リリースを成功させるために 選んだ“最適な戦略”
12. 2. 初回リリースを成功させるために選んだ“最適な戦略” プロジェクトが進む中でいくつかの課題が発生していった ・設計の遅延 ・実装・テストの遅延 ・リリースの判断ができない品質状態
13. プロジェクトが進む中でいくつかの課題が発生していった ・設計の遅延 ・実装・テストの遅延 ・リリースの判断ができない品質状態 2. 初回リリースを成功させるために選んだ“最適な戦略”
14. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・設計の遅延 要件の大幅変更やメンバーの経験不足などによって設計工程が遅延。 実装メンバーの参画時期も決まっていたため、次の工程を進めていきたい状態。 基本設計 詳細設計 実装・UT 結合テスト
15. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 実装メンバーの参画タイミングは変えられないため、 設計チームと開発チームを分離し、 出来上がっている設計書をもとに開発チームが実装を先行開始。 残る設計は設計チームが引き続き担当。 基本設計 詳細設計 実装・UT 結合テスト ファストトラッキング で進めましょう
16. 2. 初回リリースを成功させるために選んだ“最適な戦略” プロジェクトが進む中でいくつかの課題が発生していった ・設計の遅延 ・実装・テストの遅延 ・リリースの判断ができない品質状態
17. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・実装・テストの遅延 はじめてのチームで、スキルセットとしても習熟したメンバーがいない中で 開発が進んでいたため、計画よりも進捗が遅れている状態が継続。 基本設計 詳細設計 実装・UT 結合テスト
18. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 結合テストを専任するQAチームを新設することで、 開発チームから結合テスト分の作業量を削減。 開発チームは作ることに専念し、 結合テストを専門的な知見を持つQAチームで担当することで質とスピードを実現。 基本設計 詳細設計 実装・UT 結合テスト 専門家のテストで スピードをあげましょう
19. 2. 初回リリースを成功させるために選んだ“最適な戦略” その結果
20. 要件定義 基本設計 詳細設計 実装・UT 結合テスト 総合テスト UAT なかなか終わらない なかなか終わらない 2. 初回リリースを成功させるために選んだ“最適な戦略”
21. 2. 初回リリースを成功させるために選んだ“最適な戦略” その結果
22. 要件定義 基本設計 詳細設計 実装・UT 結合テスト UAT 総合テスト 2. 初回リリースを成功させるために選んだ“最適な戦略”
23. 2. 初回リリースを成功させるために選んだ“最適な戦略” プロジェクトが進む中でいくつかの課題が発生していった ・設計の遅延 ・実装・テストの遅延 ・リリースの判断ができない品質状態
24. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・リリースの判断ができない品質状態 結合テストの結果を分析すると、 リリース基準を満たせない状態であることが判明。 また、総合テストの計画・設計ができる人間が設計チームに依存。 UAT 総合テスト
25. 2. 初回リリースを成功させるために選んだ“最適な戦略” ・私が選んだ“最適な戦略” 品質を改善するための施策検討、 総合テストの推進・品質分析などを自分が一手に引き受ける。 私がやります…!! UAT 総合テスト
26. 2. 初回リリースを成功させるために選んだ“最適な戦略” その結果
27. 2. 初回リリースを成功させるために選んだ“最適な戦略” リリース達成
28. プロジェクトマネージャーとして自分に課した3つの覚悟（再掲） ・プロジェクト（契約）を必ず成功させる ・プロダクトのリリースに最大限の貢献をする ・顧客の要望を実現し、自社の成功にもつなげる 一律達成することはできた!!! …ただ、開発は続いていきます。 2. 初回リリースを成功させるために選んだ“最適な戦略”
29. リリース達成の裏で うまくいかなかったこと
30. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 ・QAチームの失敗 ・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと
31. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 ・QAチームの失敗 ・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと
32. 3. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 設計チームでシステムで考慮すべき細かい仕様を詰めることはできた。 ただ、開発チームに対するドキュメントベースでの伝達では、 ドキュメントには表れない仕様の意図や背景を伝えることができなかった。 記載してある仕様自体も充分には伝わらなかった。 チームの分断は、 暗黙的な考える人作る人の構造さえ生んでいた。 基本設計 詳細設計 実装・UT
33. 3. リリース達成の裏でうまくいかなかったこと システムを設計する組織は、その構造をそっ くりまねた構造の設計を生み出してしまう、 というのが基本的な主張だ。この事実がシス テム設計の管理において重要な意味を持つこ とがわかった。主要な発見は、設計を行う組 織を構造化するための基準である。コミュニ ケーションの必要性に応じた設計活動を行う べきなのだ。 はじめに コンウェイの法則
34. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 ・QAチームの失敗 ・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと
35. 3. リリース達成の裏でうまくいかなかったこと ・QAチームの失敗 QAチームでのテストにより一定の不具合を検出することはできた。 ただ、検出した欠陥から得られるはずだった学びを、 開発チームが充分に受けることができなかった。 結果、開発チームのスプリント毎の品質改善に繋げることができなかった。 開発チームの成果物は常に同じ程度の品質でQAチームに渡り続け、 QAチームが検出できなかった不具合は総合テストまで眠り続けた。 実装・UT 結合テスト
36. 3. リリース達成の裏でうまくいかなかったこと devopsに取り組んでおらずサイロ化してい る環境では共通理解が欠如している。（中 略）意思疎通がないので、失敗する確率の ほうが高くなるはずだ。 組織では、進んでいく過程で、必ず予想外 の問題や障害にぶつかる。しかし、全員が 共同体に属しているという共通理解があれ ば、人は修復に向かっていく。 2章 devopsとは何か 2.3.2 devops共同体
37. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 ・QAチームの失敗 ・属人性の失敗 3. リリース達成の裏でうまくいかなかったこと
38. 3. リリース達成の裏でうまくいかなかったこと ・属人性の失敗 プロジェクトマネージャーがひとりで行った 品質分析や強化テストに向けた検討はチームのものにならなかった。 プロジェクトの問題を解決に導くという機会から メンバーを遠ざけることで、プロダクトに対する オーナーシップを育む機会から遠ざけてしまっていた。 UAT 総合テスト
39. 3. リリース達成の裏でうまくいかなかったこと ヒーローは本当にメンテナンス不可能な存在 である。⾧時間労働と、コミュニケーション のコストを最小限にすることで（なぜ最小限 にするかというと、他の大半の人たちは彼ら ほどできないからである）、彼らは短期間の 生産性を高めるが、代わりに彼らの存在に よって周りの人の効果が制限される。 5章 文化:継続的に取り組んで育成する 5.6 ヒーローをやっつけ、頑張りすぎをやめ る
40. リリース達成の裏でうまくいかなかったこと ・設計チームの失敗 ・QAチームの失敗 ・属人性の失敗 プロジェクトマネージャーとして最適と判断して選択した戦略により、 リリースや契約の成功は実現したものの、 プロダクト開発を持続可能とするチームの成⾧を阻害してしまっていた。 プロダクト成⾧を持続可能とするには、 開発の進め方を抜本的に見直す必要があった。 3. リリース達成の裏でうまくいかなかったこと
41. “チームで味を決める”までの 試行錯誤
42. 4. “チームで味を決める”までの試行錯誤 初回リリース後のプロダクト開発について プロダクトは事業要求により随時の機能拡張が求められる状態になった。 初回リリース時のビッグバンリリースではなく、 スプリント毎のリリースを繰り返すスクラム開発への移行が必要となった。
43. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤
44. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤
45. 4. “チームで味を決める”までの試行錯誤 ・ワンチーム性の導入 役割でのチーム制を廃止。 開発チームをストリームアラインドチームとして、 設計、開発、テスト、リリース、運用監視までを担当する役割に変更。 スプリント毎のリリースを実現。
46. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤
47. 4. “チームで味を決める”までの試行錯誤 ・チームで仕様策定ができる状態に プロダクトで実現するものを検討するための リファインメントを効果的に扱うことで、 開発に着手する前に個人ではなくチームで仕様検討ができる状態に。 スプリント中に開発をしながら検討された細かな仕様についても、 担当者に属人化しないよう 開発完了後にチーム内で共有するなどの施策も導入。
48. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤
49. 4. “チームで味を決める”までの試行錯誤 ・チームで品質保証ができる状態に 開発チームでテスト計画、設計、実行、分析を担当する形に。 初期はQAチームがイネーブリングチームとして 開発チームが自走できる状態までサポート。 開発チームが自ら発生した不具合を分析することでプロセスを改善していき、 機能性でのバグを持ち越すことが稀となる状態を実現。
50. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に 4. “チームで味を決める”までの試行錯誤
51. 4. “チームで味を決める”までの試行錯誤 ・チームで問題解決ができる状態に ただの個人の集まりではなく、チームとしてプロダクト開発に向き合えるよう チームでの会話や同期での作業をできる時間を増やし、 スクラムイベントでの忌憚のない議論を重ねることで、 チームでの方針を決定できる状態を実現。
52. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に ・必ずしもチームで実現しなくて良いことも 4. “チームで味を決める”までの試行錯誤
53. 4. “チームで味を決める”までの試行錯誤 ・必ずしもチームで実現しなくて良いことも チームという単位で実現しなくても良いこともあった。 リリース後に運用監視のための土台を築く必要があった。 最初はチーム全員で何をするか検討しながら持ち回りに実施していた。 その結果、いつまでも地盤が固まらない状態が続いた。 運用監視に少しでも知見のある人間が、 やるべきことを固め、その後チームで扱える状態にしていった。
54. アジャイル型の適応型開発を実現するにあたる試行錯誤 ・ワンチーム性の導入 ・チームで仕様策定ができる状態に ・チームで品質保証ができる状態に ・チームで問題解決ができる状態に ・必ずしもチームで実現しなくて良いことも ここまでの流れはプロジェクトマネージャーが一方的に推進したわけではなく、 顧客であるPOも含めたスクラムチームが、 自分たちでどうすれば健全なプロダクト開発を持続できるか検討した。 4. “チームで味を決める”までの試行錯誤
55. チームで判断し実行することで、 チームがその結果に伴うフィードバックを直接受け取れる状態を実現できた。 フィードバックからの学びを次の活動に活かすことで試行錯誤を繰り返し、 チームの継続的な成⾧を実現している。 4. “チームで味を決める”までの試行錯誤
56. 4. “チームで味を決める”までの試行錯誤 その結果
57. 4. “チームで味を決める”までの試行錯誤 持続可能な プロダクト開発を実現
58. まとめ
59. 5. まとめ ・プロダクトは継続して成⾧していく 初回リリースに対しては、プロジェクト（契約）の単位でしか プロダクト開発を捉えることができていなかった。 継続可能なプロダクト開発の実現を考えるべきだった。 そのためには、個人ではなくチームで開発を実現する必要があった。 初回リリース迄 適応型開発
60. 5. まとめ ・チームの成⾧にはフィードバックサイクルが重要 初回リリースではチームの成⾧を意識できていなかった。 チーム成⾧にはチームが活動しながら学ぶための フィードバックサイクルが重要。 チームが主軸となってプロダクト開発を経験することで、 チームとプロダクトが健全な成⾧を続けることができる。 基本設計 詳細設計 実装・UT 結合テスト
61. 5. まとめ 初回リリースまでの失敗をもとに、 私たちは継続的に成⾧を繰り返しながら ラーメンの味を良くしていけるチームになることができた。 そのために必要だったのは、誰か一人に依存したり、 役割でチームを分断する戦略ではなく、 チームでおいしい一杯＝価値あるプロダクトをつくるための 試行錯誤をしていくための文化醸成でした。 プロダクトマネージャーとしてやるべきことは そうしたチームやプロダクトの成⾧を持続していくこと であると気付くことができました。
62. ご清聴ありがとうございました!! プロダクトという一杯を作る プロダクトチームが味の責任を持つまでの煮込み奮闘記