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

Slide 1

Slide 1 text

プロダクトプラットフォーム開発におけるフィードバックループの回し方株式会社リクルート小中高プロダクト基盤開発グループ吉岡良治 @ojiry 2023.10.24 【SmartHR/カケハシ/リクルート】複雑化する開発体制におけるエンジニアの社内巻き込み術

Slide 2

Slide 2 text

こんばんは！ ● 吉岡良治 / @ojiry ● スタディサプリで基盤開発グループのEMをしている ● RailsエンジニアとしてWeb開発をしていた時期が一番長いが、最近はGo やRustを推している（尚、業務ではほぼコードを書いていない） ● ヘアドネーションのために2021年から髪を伸ばしている

Slide 3

Slide 3 text

スタディサプリ小学生から受験生や大人まで、学習したい全ての人が学べる月額制のオンライン学習サービス。約4万本の録画授業動画が見られるベーシックプランのほか、オンラインコーチングプランや生配信で授業を受けられるライブプランなど、一人一人が自由に学習できるよう、様々なプランを展開しています。先生方が生徒個々人のレベルに合った最適な学習を提供できる校内インフラサービス。クラス全員に特定の講義や確認テスト、宿題を配信することができるほか、アクティブラーニングに使える教材も提供。生徒が夢中になって学び、希望する進路を実現することを支援しています。 ※ENGLISHは開発組織と採用経路が別です隙間時間で1回3分から学習できる英語サービス。リスニングと発話を鍛えられる「新日常英会話コース」、短期間でのスコアアップを狙う「TOEIC®L&R TEST対策コース」、「ビジネス英語コース」があり、業界初オンライン完結型コーチングも提供しています。

Slide 4

Slide 4 text

基盤開発でフィードバックループをどのように実現したか今日話すこと

Slide 5

Slide 5 text

三行サマリー ● 基盤開発グループがぶつかった課題と組織的な制約 ● エンジニア主導で実践するプロダクトマネジメント ● グループで実践しているプラクティス紹介

Slide 6

Slide 6 text

Agenda｜スタディサプリの基盤開発基盤開発で発生した課題ドメイン境界を定める Platform as a Product プロセスの最適化存在感を出す 01 02 03 04 05 06

Slide 7

Slide 7 text

スタディサプリの基盤開発 01 00:01

Slide 8

Slide 8 text

スタディサプリにおける基盤は二種類ある ● アプリケーションプラットフォーム ○ SREが提供するアプリケーションを開発するための基盤 ○ Kubernetes ManifestやTerraformなどを書いて利用する ● プロダクトプラットフォーム ○ 認証や動画配信などの機能を利用するための基盤 ○ REST / JSON-RPC over HTTPのAPIとして利用する

Slide 9

Slide 9 text

Slide 10

Slide 10 text

プロダクトプラットフォームがない世界 ● 複数のサービスに分散している処理がある ● 変更を加えるには影響範囲の確認が必要 ● 実装の負荷が非常に高い ● 仕様のズレが起きやすい学習者API 先生API 保護者動画入稿管理画面学習者Web 先生Web バッチ処理 iOS/Android アーキテクチャ図（旧）

Slide 11

Slide 11 text

プロダクトプラットフォームがある世界学習者API 先生API 保護者動画入稿管理画面認証基盤動画基盤 ● 特定の処理がサービスとして集約 ● 使いたい機能のAPIを呼ぶだけで良い ● 実装の負荷が軽い ● 仕様のズレが起きない

Slide 12

Slide 12 text

そんな世界を目指しています（まだ道半ばです😅）

Slide 13

Slide 13 text

基盤開発で発生した課題 02 00:03

Slide 14

Slide 14 text

開発を進めていく中で二つの大きな課題に遭遇認知負荷の増大スプリントレビューの形骸化

Slide 15

Slide 15 text

認知負荷の増大 ● 基盤開発グループは機能開発で初めての横断領域チーム ○ 発足当初は正式な組織ではなく兼務メンバーのプロジェクトチーム ● 複数のサービスから参照されるモジュールはオーナーシップが曖昧 ○ そこにいい感じにオーナーシップを持てるチームが生まれた ○ 事業的に優先度の高い横断プロジェクトなどが差し込まれる ● 開発支援グループ誕生 ○ 領域横断的な課題を解決するグループ ○ ４名のプロダクトプラットフォームエンジニアが所属

Slide 16

Slide 16 text

認知負荷の増大 ● ４名のチームで横断領域にある複数の課題を同時に進める ○ バックログの優先順位付けが複雑化 ○ アラートや他チームからの差し込み対応 ○ コンテキストスイッチが多発 ● 本来やりたかった基盤開発のプロジェクト一時停止 ○ 再始動しても当時の事は記憶が曖昧で。。。 ○ そして暫く立つとまた差し込みが😇

Slide 17

Slide 17 text

スプリントレビューの形骸化 ● 当時の開発プロセスはスクラムガイドにほぼ準拠したスクラムらしきもの ○ 専任のプロダクトオーナーがいない ○ 専任のスクラムマスターもいない ○ それ以外はスクラムガイド通り ● 目標はAs-Isのまま機能をマイクロサービスへ切り出すこと ○ 新しい機能は実装しない ○ 整合性を担保しながらデータを移行する ○ 参照先を古いデータベースから新しいサービスに切り替える

Slide 18

Slide 18 text

スプリントレビューの形骸化 ● プロダクトバックログは技術中心な内容に ○ 組織のTPMはビジネス寄りなため、技術中心のバックログ管理は難しい ○ インクリメントも技術的な内容が中心に ■ 組織にレビューできる人、レビューの意思を持てる人がいない ● 結果関係者を集めてレビューを実施しても進捗確認の場にしかならず ○ フィードバックループが回らなかった ■ どんなフィードバックが欲しいかもチームは把握できてなかった ○ 考慮漏れによる手戻りも多数発生していた

Slide 19

Slide 19 text

そこでチームは考えた🤔

Slide 20

Slide 20 text

ドメイン境界を定める 03 00:06

Slide 21

Slide 21 text

自分達がなぜここにいるのかを問うた ● グループワークで Vision/Mission/Values を作成 ● Vision (目指す世界観) ○ プロダクトチームが価値の提供に集中できる世界の実現 ● Mission (果たす役割) ○ プロダクト開発を支援する堅牢なプロダクトプラットフォームを作る ● Values (大切にする価値観) ○ Presence ○ Be fault tolerant ○ Code-driven ○ Prioritize safety

Slide 22

Slide 22 text

横断領域の課題を全て解決するわけではない ● 自分達ができることは限られている ○ 何を成すべきか選択と集中 ○ 差し込みに対して意思決定する際にはVision/Missionに立ち戻る ■ 異なるならNoと言って別の解決案を一緒に考える ● 自分達のミッションを表す組織名に変更 ○ 旧）開発支援グループ ○ 新）小中高プロダクト基盤開発グループ ○ 名前から受ける印象は大事 ■ チーム内外で影響があると（自分は）実感

Slide 23

Slide 23 text

チーム内で決めて終わりではない ● 自分達が何をしているグループなのか社内にアピールする ○ 部内キックオフで発表 ○ random-tech-talk（毎週実施されている技術に関する雑談会） ○ GitHub Issueで一筆認める ● とにかく能動的にPresenceを出していく ○ 過剰なくらいで丁度いい ○ 少ないと認知されない

Slide 24

Slide 24 text

それでも高い認知負荷 ● グループ内のドメインやコンテキストの増大は防いだ ○ それでも既にある複数のコンテキストをハンドリングするのは難しい ○ スプリントプランニングは変わらずに時間がかかる ● 理想は一つのチームが一つのドメインに集中すること ○ 差し込みや並行作業によるコンテキストスイッチを最小化したい ○ とは言えグループの人数は4名でチーム分割すると2名チームに

Slide 25

Slide 25 text

ドメインチームの立ち上げ ● 思い切って１チーム２名の体制を構築 ○ 採用を強化してメンバーを充足させること前提 ● グループとして最優先で進めたかった認証ドメインを切り出す ○ 残ったドメインは引き続き１チームで進める ● リスク観点は考慮しながら失敗を恐れずチャレンジをした ○ まず試すことでフィードバックを得ることを最優先 ■ 今回はリスクもあるので厳しければ直ぐに戻す前提 ○ 事前にメンバーと期待値調整は手厚めに行う

Slide 26

Slide 26 text

ドメインチームにした結果 ● 試みは成功しチームのスループットが向上した ○ 計画していたロードマップは大幅な変更や遅延なく完遂 ○ プランニングもスムーズに行えるようになった ● コンテキストスイッチのコストはバカにできない ○ メンバーからも作業がやりやすくなったという感想が ● その後採用も無事に出来たので今は安定して２チームの体制を作れている

Slide 27

Slide 27 text

Platform as a Product 04 00:10

Slide 28

Slide 28 text

スクラムに変わる何かを探していた ● 形骸化したスプリントレビューを何とかしたい ○ 専属のプロダクトオーナーやスクラムマスターを用意するのは難しい ○ 正しいスクラムは諦めなければいけない ● スクラムに変わる開発プロセスは？ ○ 色々探してはみたけど見つけられない ○ ぼんやり発散してたのである

Slide 29

Slide 29 text

ある日偶然とあるブログを見つける社内PlatformチームのProduct Management https://deeeet.com/writing/2020/10/07/internal-platform-product-management/ ● 基盤（プラットフォーム）も社内向けプロダクトとして捉える ○ 衝撃を受ける ● プロダクトオーナーの責務を考えれば自然なことだった ○ チームにはプロダクトマネジメントが必要 ○ As-Isでの移行開発という性質が思考に制限をかけていた？ ● やるべきことは見えてきた ○ あとは行動するのみ ○ プロダクトマネジメントの本を何冊か読む

Slide 30

Slide 30 text

得られた知見を元にチームでミニマムに検証 ● リリースサイクルという６週間のサイクルを定義 ○ basecampのThe Six Week Cycleを参考 ■ https://3.basecamp-help.com/article/35-the-six-week-cycle ● サイクル内で開発するインクリメントをリリースアイテムとして管理 ○ 初期バージョンのフォーマットは下記の３つ ■ 概要、提供される価値、どのように利用するか ○ 必ずユーザーが実際に使えて試せるものを開発する ● GitHub IssueとしてGitHub Projectsでロードマップとして社内に公開

Slide 31

Slide 31 text

実際にやってみる ● ６週間で動くものを提供する ○ 開発のスコープを強制的に削減させられる ○ 重厚長大な設計議論などをしていると何も出来ない ● 誰に対して価値を提供しているのか ○ 提供する対象=レビュワー ● 利用方法は評価方法を明確にする ○ 〇〇をする機能というをA moduleのz methodとして実装する ○ z methodを使ってやりたいことが出来ているのかをみる

Slide 32

Slide 32 text

開発したリリースアイテムをレビューする ● レビュー対象は参加できているか？ ○ この時点ではまだチームで見るケースしかなかった ● ちゃんと動くものが出来ているか？ ○ 実際に動くコードで確認する ○ この機能に求められる価値を出せているのか ● レビューの実施者はまだ自分達であるものの、進捗管理だけのレビューではなくなってきているのを実感 ○ スプリントレビューが息を吹き替えした！

Slide 33

Slide 33 text

プロセスの最適化 05 00:14

Slide 34

Slide 34 text

Platform as a Productという取り組み自体を仮説検証 ● ミニマムに始めて上手くいきそうな手応えを掴めた ● より良くしていくためには何が必要かを考える ○ 課題を見つけ分析、それを仮説として改善に取り組む ○ フィードバックループの思考は大体のことに適応できる ● 半期毎のスコープで検証する ○ リリースサイクルが６週間なので、半期でも回せるのは４サイクル ○ 大きめのテーマをいくつか選び取り組んた

Slide 35

Slide 35 text

フィードバックの質を高める ● リリースアイテムのフォーマットを改善 ○ 概要、仮説、リリース、検証の４項目へ ○ より詳細かつ必要な観点を記載 ● チーム外からの評価を貰う ○ ユーザーインタビューの実施 ○ 実際に作成したサービスのインターフェースに置き換えたPRのDiffをレビューしてもらう ■ 新旧で比較してどの程度シンプルに利用できるようになったか

Slide 36

Slide 36 text

リリースサイクルにプランニングとレビューを導入 ● プロダクトマネジメントをチームに委譲したい ● 必要な準備 ○ GitHub Issueのフォーマットを整備 ○ プランニングとレビューのプロセスをリリースサイクルに組み込み ○ 責任者の任命（マネージャーの自分が担当） ● 各チーム毎のテックリードに依頼 ○ プランニング前にリリースアイテムを作成 ○ レビューではリリースアイテム毎の状況を確認 ■ 定義を満たしていれば責任者が承認する（Labelをつける）

Slide 37

Slide 37 text

実際のフォーマット

Slide 38

Slide 38 text

他にも次のようなことをやっています ● 開発ロードマップIssueの作成 ● 新規開発でのPlatform as a Productの検証 ● All-Hands Meetingの実施 ● グループ用Handbookを作成 ● etc

Slide 39

Slide 39 text

存在感を出す 06 00:17

Slide 40

Slide 40 text

Presence “開発した機能を評価して貰うために、能動的な成果の共有を大切にする。評価から学びを得て次の開発に活かす” ● 基盤開発グループValuesの内の一つ ● 開発しただけでは使って貰えない ○ 使って貰えないとフィードバックが得られない ● そのためにも能動的にアピールしていくという意志が込められている ● いくつか社内で行っている取り組みを軽く紹介する

Slide 41

Slide 41 text

リリースノート隔週のAll-Hands Meetingで作成し関係者のいるチャンネルで共有

Slide 42

Slide 42 text

プロダクトチャンネル ● 関係者を集めてやりとりするチャンネル ○ 必要な情報などを集約して関係者と共有 ● Darklaunch v2にも#darklaunch-dev-jaというチャンネルがあります

Slide 43

Slide 43 text

部内キックオフ主にチーム毎のロードマップ計画と進捗やグループの戦略・戦術などを共有右のような資料を作成して説明しています 👉

Slide 44

Slide 44 text

ブログブログも立派な社内へのアピールツールになる弊社ではブログ記事を様々な関係者がレビューしてくれるので、プラットフォームの記事を書くだけで社内への宣伝になる　　https://blog.studysapuri.jp/entry/2022/12/19/darklaunch-ujihisa

Slide 45

Slide 45 text

つまるところ認知して貰うことが重要なのかもしれない ● 目的はプラットフォームを利用してもらいフィードバックを得ること ○ でも知って貰わなければ便利な機能も使って貰えない ○ つまりフィードバックは得られない ● ここまで考えてValuesにPresenceを含めたわけではない ○ ただ結果としてとても重要なValueにはなっている社内にPresenceを出していけ！

Slide 46

Slide 46 text

まとめ ● 自分達がなぜここにいるのかをちゃんと言語化する ● 基盤をプロダクトとして捉えプロダクトマネジメントの手法を活用する ● どのような改善もフィードバックループを素早く回すことが大事 ● フィードバックを得るには能動的に成果を共有し認知してもらう

Slide 47

Slide 47 text

ご清聴ありがとうございました

Slide 48

Slide 48 text

参考資料 ● 社内PlatformチームのProduct Management | Taichi Nakashima ● The Six Week Cycle - Basecamp Help