プロダクトプラットフォーム開発におけるフィー ドバックループの回し方

2023/10/24に、TECH PLAYで発表した、吉岡の資料です。

Transcript

1. プロダクトプラットフォーム開発における フィードバックループの回し方 株式会社リクルート 小中高プロダクト基盤開発グループ 吉岡 良治 @ojiry 2023.10.24 【SmartHR/カケハシ/リクルート】 複雑化する開発体制におけるエンジニアの社内巻き込み術
2. こんばんは！ • 吉岡 良治 / @ojiry • スタディサプリで基盤開発グループのEMをしている • RailsエンジニアとしてWeb開発をしていた時期が一番長いが、最近はGo やRustを推している（尚、業務ではほぼコードを書いていない） • ヘアドネーションのために2021年から髪を伸ばしている
3. スタディサプリ 小学生から受験生や大人まで、学習したい全ての人が学べる月額制のオンライン学習サービス。 約4万本の録画授業動画が見られるベーシックプランのほか、オンラインコーチングプランや生配信で授業を受けら れるライブプランなど、一人一人が自由に学習できるよう、様々なプランを展開しています。 先生方が生徒個々人のレベルに合った最適な学習を提供できる校内インフラサービス。クラス全員に特定の講義や 確認テスト、宿題を配信することができるほか、アクティブラーニングに使える教材も提供。 生徒が夢中になって学び、希望する進路を実現することを支援しています。 ※ENGLISHは開発組織と採用経路が別です 隙間時間で1回3分から学習できる英語サービス。リスニングと発話を鍛えられる「新日常英会話コース」、短期間 でのスコアアップを狙う「TOEIC®L&R TEST対策コース」、「ビジネス英語コース」があり、業界初オンライン完 結型コーチングも提供しています。
4. 基盤開発でフィードバックループ をどのように実現したか 今日話すこと
5. 三行サマリー • 基盤開発グループがぶつかった課題と組織的な制約 • エンジニア主導で実践するプロダクトマネジメント • グループで実践しているプラクティス紹介
6. Agenda｜ スタディサプリの基盤開発 基盤開発で発生した課題 ドメイン境界を定める Platform as a Product プロセスの最適化 存在感を出す 01 02 03 04 05 06
7. スタディサプリの基盤開発 01 00:01
8. スタディサプリにおける基盤は二種類ある • アプリケーションプラットフォーム ◦ SREが提供するアプリケーションを開発するための基盤 ◦ Kubernetes ManifestやTerraformなどを書いて利用する • プロダクトプラットフォーム ◦ 認証や動画配信などの機能を利用するための基盤 ◦ REST / JSON-RPC over HTTPのAPIとして利用する
9. スタディサプリにおける基盤は二種類ある • アプリケーションプラットフォーム ◦ SREが提供するアプリケーションを開発するための基盤 ◦ Kubernetes ManifestやTerraformなどを書いて利用する • プロダクトプラットフォーム ◦ 認証や動画配信などの機能を利用するための基盤 ◦ REST / JSON-RPC over HTTPのAPIとして利用する
10. プロダクトプラットフォームがない世界 • 複数のサービスに分散している処理がある • 変更を加えるには影響範囲の確認が必要 • 実装の負荷が非常に高い • 仕様のズレが起きやすい 学習者API 先生API 保護者 動画入稿 管理画面 学習者Web 先生Web バッチ処理 iOS/Android アーキテクチャ図（旧）
11. プロダクトプラットフォームがある世界 学習者API 先生API 保護者 動画入稿 管理画面 認証基盤 動画基盤 • 特定の処理がサービスとして集約 • 使いたい機能のAPIを呼ぶだけで良い • 実装の負荷が軽い • 仕様のズレが起きない
12. そんな世界を目指しています （まだ道半ばです😅）
13. 基盤開発で発生した課題 02 00:03
14. 開発を進めていく中で二つの大きな課題に遭遇 認知負荷の増大 スプリントレビューの形骸化
15. 認知負荷の増大 • 基盤開発グループは機能開発で初めての横断領域チーム ◦ 発足当初は正式な組織ではなく兼務メンバーのプロジェクトチーム • 複数のサービスから参照されるモジュールはオーナーシップが曖昧 ◦ そこにいい感じにオーナーシップを持てるチームが生まれた ◦ 事業的に優先度の高い横断プロジェクトなどが差し込まれる • 開発支援グループ誕生 ◦ 領域横断的な課題を解決するグループ ◦ ４名のプロダクトプラットフォームエンジニアが所属
16. 認知負荷の増大 • ４名のチームで横断領域にある複数の課題を同時に進める ◦ バックログの優先順位付けが複雑化 ◦ アラートや他チームからの差し込み対応 ◦ コンテキストスイッチが多発 • 本来やりたかった基盤開発のプロジェクト一時停止 ◦ 再始動しても当時の事は記憶が曖昧で。。。 ◦ そして暫く立つとまた差し込みが😇
17. スプリントレビューの形骸化 • 当時の開発プロセスはスクラムガイドにほぼ準拠したスクラムらしきもの ◦ 専任のプロダクトオーナーがいない ◦ 専任のスクラムマスターもいない ◦ それ以外はスクラムガイド通り • 目標はAs-Isのまま機能をマイクロサービスへ切り出すこと ◦ 新しい機能は実装しない ◦ 整合性を担保しながらデータを移行する ◦ 参照先を古いデータベースから新しいサービスに切り替える
18. スプリントレビューの形骸化 • プロダクトバックログは技術中心な内容に ◦ 組織のTPMはビジネス寄りなため、技術中心のバックログ管理は難しい ◦ インクリメントも技術的な内容が中心に ▪ 組織にレビューできる人、レビューの意思を持てる人がいない • 結果関係者を集めてレビューを実施しても進捗確認の場にしかならず ◦ フィードバックループが回らなかった ▪ どんなフィードバックが欲しいかもチームは把握できてなかった ◦ 考慮漏れによる手戻りも多数発生していた
19. そこでチームは考えた🤔
20. ドメイン境界を定める 03 00:06
21. 自分達がなぜここにいるのかを問うた • グループワークで Vision/Mission/Values を作成 • Vision (目指す世界観) ◦ プロダクトチームが価値の提供に集中できる世界の実現 • Mission (果たす役割) ◦ プロダクト開発を支援する堅牢なプロダクトプラットフォームを作る • Values (大切にする価値観) ◦ Presence ◦ Be fault tolerant ◦ Code-driven ◦ Prioritize safety
22. 横断領域の課題を全て解決するわけではない • 自分達ができることは限られている ◦ 何を成すべきか選択と集中 ◦ 差し込みに対して意思決定する際にはVision/Missionに立ち戻る ▪ 異なるならNoと言って別の解決案を一緒に考える • 自分達のミッションを表す組織名に変更 ◦ 旧）開発支援グループ ◦ 新）小中高プロダクト基盤開発グループ ◦ 名前から受ける印象は大事 ▪ チーム内外で影響があると（自分は）実感
23. チーム内で決めて終わりではない • 自分達が何をしているグループなのか社内にアピールする ◦ 部内キックオフで発表 ◦ random-tech-talk（毎週実施されている技術に関する雑談会） ◦ GitHub Issueで一筆認める • とにかく能動的にPresenceを出していく ◦ 過剰なくらいで丁度いい ◦ 少ないと認知されない
24. それでも高い認知負荷 • グループ内のドメインやコンテキストの増大は防いだ ◦ それでも既にある複数のコンテキストをハンドリングするのは難しい ◦ スプリントプランニングは変わらずに時間がかかる • 理想は一つのチームが一つのドメインに集中すること ◦ 差し込みや並行作業によるコンテキストスイッチを最小化したい ◦ とは言えグループの人数は4名でチーム分割すると2名チームに
25. ドメインチームの立ち上げ • 思い切って１チーム２名の体制を構築 ◦ 採用を強化してメンバーを充足させること前提 • グループとして最優先で進めたかった認証ドメインを切り出す ◦ 残ったドメインは引き続き１チームで進める • リスク観点は考慮しながら失敗を恐れずチャレンジをした ◦ まず試すことでフィードバックを得ることを最優先 ▪ 今回はリスクもあるので厳しければ直ぐに戻す前提 ◦ 事前にメンバーと期待値調整は手厚めに行う
26. ドメインチームにした結果 • 試みは成功しチームのスループットが向上した ◦ 計画していたロードマップは大幅な変更や遅延なく完遂 ◦ プランニングもスムーズに行えるようになった • コンテキストスイッチのコストはバカにできない ◦ メンバーからも作業がやりやすくなったという感想が • その後採用も無事に出来たので今は安定して２チームの体制を作れている
27. Platform as a Product 04 00:10
28. スクラムに変わる何かを探していた • 形骸化したスプリントレビューを何とかしたい ◦ 専属のプロダクトオーナーやスクラムマスターを用意するのは難しい ◦ 正しいスクラムは諦めなければいけない • スクラムに変わる開発プロセスは？ ◦ 色々探してはみたけど見つけられない ◦ ぼんやり発散してたのである
29. ある日偶然とあるブログを見つける 社内PlatformチームのProduct Management https://deeeet.com/writing/2020/10/07/internal-platform-product-management/ • 基盤（プラットフォーム）も社内向けプロダクトとして捉える ◦ 衝撃を受ける • プロダクトオーナーの責務を考えれば自然なことだった ◦ チームにはプロダクトマネジメントが必要 ◦ As-Isでの移行開発という性質が思考に制限をかけていた？ • やるべきことは見えてきた ◦ あとは行動するのみ ◦ プロダクトマネジメントの本を何冊か読む
30. 得られた知見を元にチームでミニマムに検証 • リリースサイクルという６週間のサイクルを定義 ◦ basecampのThe Six Week Cycleを参考 ▪ https://3.basecamp-help.com/article/35-the-six-week-cycle • サイクル内で開発するインクリメントをリリースアイテムとして管理 ◦ 初期バージョンのフォーマットは下記の３つ ▪ 概要、提供される価値、どのように利用するか ◦ 必ずユーザーが実際に使えて試せるものを開発する • GitHub IssueとしてGitHub Projectsでロードマップとして社内に公開
31. 実際にやってみる • ６週間で動くものを提供する ◦ 開発のスコープを強制的に削減させられる ◦ 重厚長大な設計議論などをしていると何も出来ない • 誰に対して価値を提供しているのか ◦ 提供する対象=レビュワー • 利用方法は評価方法を明確にする ◦ 〇〇をする機能というをA moduleのz methodとして実装する ◦ z methodを使ってやりたいことが出来ているのかをみる
32. 開発したリリースアイテムをレビューする • レビュー対象は参加できているか？ ◦ この時点ではまだチームで見るケースしかなかった • ちゃんと動くものが出来ているか？ ◦ 実際に動くコードで確認する ◦ この機能に求められる価値を出せているのか • レビューの実施者はまだ自分達であるものの、進捗管理だけのレビューでは なくなってきているのを実感 ◦ スプリントレビューが息を吹き替えした！
33. プロセスの最適化 05 00:14
34. Platform as a Productという取り組み自体を仮説検証 • ミニマムに始めて上手くいきそうな手応えを掴めた • より良くしていくためには何が必要かを考える ◦ 課題を見つけ分析、それを仮説として改善に取り組む ◦ フィードバックループの思考は大体のことに適応できる • 半期毎のスコープで検証する ◦ リリースサイクルが６週間なので、半期でも回せるのは４サイクル ◦ 大きめのテーマをいくつか選び取り組んた
35. フィードバックの質を高める • リリースアイテムのフォーマットを改善 ◦ 概要、仮説、リリース、検証の４項目へ ◦ より詳細かつ必要な観点を記載 • チーム外からの評価を貰う ◦ ユーザーインタビューの実施 ◦ 実際に作成したサービスのインターフェースに置き換えたPRのDiffをレ ビューしてもらう ▪ 新旧で比較してどの程度シンプルに利用できるようになったか
36. リリースサイクルにプランニングとレビューを導入 • プロダクトマネジメントをチームに委譲したい • 必要な準備 ◦ GitHub Issueのフォーマットを整備 ◦ プランニングとレビューのプロセスをリリースサイクルに組み込み ◦ 責任者の任命（マネージャーの自分が担当） • 各チーム毎のテックリードに依頼 ◦ プランニング前にリリースアイテムを作成 ◦ レビューではリリースアイテム毎の状況を確認 ▪ 定義を満たしていれば責任者が承認する（Labelをつける）
37. 実際のフォーマット
38. 他にも次のようなことをやっています • 開発ロードマップIssueの作成 • 新規開発でのPlatform as a Productの検証 • All-Hands Meetingの実施 • グループ用Handbookを作成 • etc
39. 存在感を出す 06 00:17
40. Presence “開発した機能を評価して貰うために、能動的な成果の共有を大切にす る。評価から学びを得て次の開発に活かす” • 基盤開発グループValuesの内の一つ • 開発しただけでは使って貰えない ◦ 使って貰えないとフィードバックが得られない • そのためにも能動的にアピールしていくという意志が込められている • いくつか社内で行っている取り組みを軽く紹介する
41. リリースノート 隔週のAll-Hands Meetingで作成し関係者のいるチャンネルで共有
42. プロダクトチャンネル • 関係者を集めてやりとりするチャンネル ◦ 必要な情報などを集約して関係者と共有 • Darklaunch v2にも#darklaunch-dev-jaというチャンネルがあります
43. 部内キックオフ 主にチーム毎のロードマップ計画と進捗やグループの戦略・戦術などを共有 右のような資料を作成 して説明しています 👉
44. ブログ ブログも立派な社内へのアピールツールになる 弊社ではブログ記事を様々な関係者がレビューしてくれるので、プラットフォー ムの記事を書くだけで社内への宣伝になる 　　https://blog.studysapuri.jp/entry/2022/12/19/darklaunch-ujihisa
45. つまるところ認知して貰うことが重要なのかもしれない • 目的はプラットフォームを利用してもらいフィードバックを得ること ◦ でも知って貰わなければ便利な機能も使って貰えない ◦ つまりフィードバックは得られない • ここまで考えてValuesにPresenceを含めたわけではない ◦ ただ結果としてとても重要なValueにはなっている 社内にPresenceを出していけ！
46. まとめ • 自分達がなぜここにいるのかをちゃんと言語化する • 基盤をプロダクトとして捉えプロダクトマネジメントの手法を活用する • どのような改善もフィードバックループを素早く回すことが大事 • フィードバックを得るには能動的に成果を共有し認知してもらう
47. ご清聴ありがとうございました
48. 参考資料 • 社内PlatformチームのProduct Management | Taichi Nakashima • The Six Week Cycle - Basecamp Help