ハードとともに歩むアジャイル開発

Transcript

1. ハードウェアの製品開発サイクルを守りながら Agileなアプリ開発も目指す道のり Copyright 2024 Sony Group Corporation
2. 自己紹介 玉置 洋 (たまき ひろし) • 2009年ソニー入社 • ほぼずっとモバイルアプリ開発 • 2022年に認定スクラムマスター取得 町田 公佑 (まちだ こうすけ) • 2021年ソニー入社 • モバイルアプリ開発 / データ分析
3. 体制を2つに分けて WaterfallとAgileの両立を目指そう！ 慣れないAgileチームの立ち上げに対して、いろいろな取り組みやっています！ ハードウェアとの連携開発なので Agileなアプリ開発がツラい 前編 ハード連携開発特有の 悩みと取り組み 後編 Agileなチーム 立ち上げにむけて 全体の流れ
4. 開発プロダクト紹介 | Sony | Sound Connect
5. 開発プロダクト紹介 | Sony | Sound Connect
6. 体制を2つに分けて WaterfallとAgileの両立を目指そう！ 慣れないAgileチームの立ち上げに対して、いろいろな取り組みやっています！ ハードウェアとの連携開発なので Agileなアプリ開発がツラい 前編 ハード連携開発特有の 悩みと取り組み 後編 Agileなチーム 立ち上げに向けて
7. モバイルアプリケーション開発 リリースプラットフォームが整備されており、 ユーザーフィードバックも集めやすい！ 効率的・継続的に価値を高めていく Agile開発に向いていそう！ 私達の開発しているアプリ 前編Introduction
8. 実際には…
9. モバイルアプリケーション開発 リリースプラットフォームが整備されており、 ユーザーフィードバックも集めやすい！ 継続的・効率的に価値を高めていく アジャイル開発に向いていそう！ 私達の開発しているアプリ 連携しているヘッドホン ハードウェアとしてのヘッドホンとの連携した機能開発となるために、 なかなかAgile開発しにくい悩みがあります 本日は、現状の悩みと今後にむけた施策についてお話しします
10. Sound Connect の特徴 2016年のアプリ公開以降、 50以上のモデルとの連携に対応 ヘッドホン機能の設定UIの提供だけでなく、 アプリとしての多くの付加価値を提供 イコライザー などの音設定 スマホのセンサーを 活用し、様々なシーン での音楽の視聴履歴を 可視化 多くのモデル・多くの機能に対応 ヘッドホン機能への対応だけでなく、 アプリとしての付加価値機能も提供
11. Sound Connect 開発の背景 ヘッドホンの製品開発はQCD重視の Waterfall型開発 連携機能を開発するアプリ側についても、 それに合わせてWaterfall型開発が必要 となっている 毎年度ヘッドホンの新モデル発売があり、 年間のリリーススケジュール・ 開発マイルストーンを毎年策定している 2024年開発計画 年単位
12. 現状の開発アプローチ チャレンジの絵
13. Sound Connect 現状の開発スタイル モデルAの◦◦機能開発 モデルBの▽▽機能開発 モデルCの市場問題対対応 モデルAの××機能開発 企画 企画 品証 企画 アプリの◇◇機能開発 モデルCの利用率改善 アプリの◎◎機能改善 Product Backlog 2024年開発計画 年間リリース・開発計画 2週間サイクルのSprint開発
14. 実際には、Agile開発になりきれない点がいくつかある 悩みの絵
15. 現状の悩み | プロセス面 効率的でスピード感のある価値向上・リリースが実現できない 大枠はWaterfall開発なので、 フィードバックサイクルをベースとした 素早い改善がしづらい アプリの公開日程はヘッドホン側の 発売事情によって変化するため、 価値向上の定期リリースがしづらい 工場の量産遅れのため、 ××モデルの発売を 1か月延期しましょう 仕様策定からアプリ 公開までも年単位
16. 現状の悩み | 要件管理面 アプリとしての付加価値向上の機能開発の優先度が上がりにくい 年中追加の要求は発生するが、 優先度決定の裁量をもったメンバーがおらず その都度優先度・バーターの調整に難航する ヘッドホン側の商品性に関する機能や 市場問題への対応はどうしても優先される ため、アプリとしての付加価値機能・ 改善は後回しになってしまいがち なかなか改善案件 入れられない… 緊急！ MUST！ 最重要！ 必須！
17. もっとAgile開発を取り入れていきたいけど、 ヘッドホン側の開発も含めた変革はかなりハードルが高い 考え中の絵
18. まずはできるところからAgile開発を取り入れ、 実績・自信・信頼を積み重ねていこう！
19. アプリの◇◇ アプリの◎◎ アプリの△△ モデルAの◦◦ モデルBの▽▽ モデルCの☆☆ モデルAの×× モデルCの△△ モデルAの◦◦ モデルBの▽▽ モデルCの☆☆ モデルAの×× アプリの◇◇ モデルCの△△ アプリの◎◎ 現在始めている改善施策 | 体制・プロセス ヘッドホン案件チーム アプリ改善案件チーム Waterfall開発で QCDしっかり守り、 ヘッドホン案件に集中 Agile型開発で、 アプリ付加価値機能の 素早いリリース・価値向上を 行っていく アプリ案件の 権限移譲を受けたPO ヘッドホン案件とアプリ改善案件で体制・プロセスを分け、 アプリ改善側では権限委譲してもらい、Agile型開発を進める
20. 現在始めている改善施策 | リリース戦略 モデルAのWaterfall開発 モデルBのWaterfall開発 発売 発売 モデルAのWaterfall開発 モデルBのWaterfall開発 Agile 開発 Agile 開発 Agile 開発 Agile 開発 Agile 開発 Agile 開発 連携開発 連携開発 リリース リリース リリース リリース リリース リリース ヘッドホンの発売に合わせたリリースに加え、アプリ改善のリリースを定期的に実施
21. 前編のまとめ • ヘッドホンとの連携機能をもつアプリ開発における、 Agile開発への悩みと現在進めている施策をご紹介しました • ハード連携のアプリ開発は難しい面もありますが、 アプリだけでは実現できない機能の差別化ができる・ ユーザー獲得しやすいといったメリットも大きいため、 うまく開発を両立させメリットを最大限活かしていきたいです ヘッドホン案件チーム アプリ改善案件チーム
22. 体制を2つに分けて WaterfallとAgileの両立を目指そう！ 慣れないAgileチームの立ち上げに対して、いろいろな取り組みやっています！ ハードウェアとの連携開発なので Agileなアプリ開発がツラい 前編 ハード連携開発特有の 悩みと取り組み 後編 Agileなチーム 立ち上げにむけて
23. 後編Introduction • 権限移譲を受けたアプリ案件チームが、今まで分業制のWaterfall開発をしてきた中で どのようにAgileなチームとして立ち上がったかを共有する • Waterfall/Agile に関わらず“チームとして大きく変わる” という局面で役に立った プラクティスやフレームワークを共有する
24. Discoverチーム • Sound Connectアプリ開発チームの１つであり Discover というタブの開発を担当 • Product Owner + 設計 + 仕様（一部）の メンバーで１つのスクラムチームとして活動 機能・要件管理 Product Owner 企画 評価 仕様 デザイン チーム 仕様チーム 設計 設計チーム 評価チーム
25. タックマンモデル • チームの成長過程を5つのフェーズに分けたモデル • Discoverチームの立ち上がりのプロセスを、このモデルに沿って説明していく 今ココ ↓
26. 立ち上がり史 | 概観 ここまでのふりかえり むきなおり & 決起飲み会 Product Vision決定 Waterfall期 混乱期 統一期 PO・設計・仕様の責務分担 仕様チームを含めた 仕様検討プロセス策定 在るべき姿を目指すための ロードマップ作成 技術的負債の解消 本格化 Sprint Goalの 本格運用開始 Sprint Review 開始
27. 立ち上がり史 | Waterfall(旧体制)期 • Agileな開発プロセスのトライアルをする予定が、スケジュールの都合で中止になったが なぜAgileな改善が必要なのか（Why Agile?）は共有していて、熱意もあった • 飲み会を含む泥臭いコミュニケーションによってメンバー同士の相互理解は進み、 チームの透明性は高かった（形成期の完了） 確実なリリースのためにWaterfall開発に振り切っていた 何を作るか決める 企画 仕様に落とし込む 仕様 仕様に倣って作る 設計 Waterfall期 混乱期 統一期
28. 混乱期 Waterfall期 混乱期 統一期
29. 立ち上がり史 | 混乱期 • プロダクトの改善アイデアはたくさん出るが、それぞれ大事にしたがっているものが違う • ワンチームで改善を回すプロセスの議論を重ねたが、理想型を描き切ることは出来ず 目的や各自の役割について意見を発するようになり、衝突する 改善への 情熱と議論は すでにある それぞれ考えはあるが、見ている方向はバラバラ プロダクトの理想像 プロセスの理想像 と Waterfall期 混乱期 統一期
30. 立ち上がり史 | 混乱期 Waterfall期 混乱期 統一期 ここまでのふりかえり むきなおり & 決起飲み会 Product Vision決定 Waterfall期 混乱期 統一期 PO・設計・仕様の責務分担 仕様チームを含めた 仕様検討プロセス策定 在るべき姿を目指すための ロードマップ作成 技術的負債の解消 本格化 Sprint Goalの 本格運用開始 Sprint Review 開始
31. むきなおりの実施 | むきなおりとは？ • 短サイクルでの改善を繰り返していると、気がついたら本来の在るべき姿を見失っていて そこから大きくズレたものを目指していたということがよくある Sprintでの 改善 現在の姿 （As-Is） Sprintでの 改善 このまま 進み続けた姿 本来 在るべき姿 （To-Be） いつの間にか 出来てしまったズレ 立ち止まって “本来の在るべき姿” と “現在の姿” を見つめ直す Waterfall期 混乱期 統一期
32. むきなおりの実施 | やったこと プロダクトの在るべき姿（Product Vision）を再定義する • 叩き案を作ってきてもらい、全員参加で２時間ひたすら意見や想いをぶつけあった • この場は発散に終始して、収束は別場で少人数で実施 【叩き案】 自分を理解してくれて、 訪れるたびに価値や気づきを 提供してくれる “楽しい” 場所・存在に アプリ全体のVisionと 繋がりが薄い Discoverの 一部機能の価値しか 表現できていない “楽しい” は手段で ゴールではない 達成・未達成が 測定しづらい Waterfall期 混乱期 統一期
33. Product Visionの決定 【Product Vision】 アプリの再訪意欲を向上させて 訪れるたびに価値や気づきを最大限エンハンスしてくれる存在 • むきなおりでチーム内で出てきた意見を元に 最終的には POが判断して決定 （全員で考えて、少人数で決め切る） • 決まった後も、ことあるごとに引っ張り出して 再確認することでチームに浸透していき 意思決定の拠り所 になっていった Waterfall期 混乱期 統一期
34. 仕様チームを含めた仕様検討プロセス策定 • チーム皆で同じ方向を向くことは出来たが… ワンチームで改善サイクルがAgileに回せるような “プロセスの在るべき姿” についても目標が欲しくなった 役割別の分業体制は依然そのまま Waterfall開発時代からの名残で 提案からリリースまでの工程が一直線 “ワンチームで改善を回している” という実感はほぼ無い Sprint Reviewでフィードバックを集めても プロダクトに反映する工程が無い Waterfall期 混乱期 統一期
35. 仕様チームを含めた仕様検討プロセス策定 | 現在の姿を可視化する • 現状の提案からリリースまでの全工程をバリューストリームマッピング風に可視化して そこに対する不満を書き出した 提案からリリースまでの現在の姿（黄色が各プロセスでピンクが不満） 一方通行のプロセスかつ仕様と設計が完全に分断されている Waterfall期 混乱期 統一期
36. 仕様チームを含めた仕様検討プロセス策定 | 在るべき姿を描く • 書き出した不満を解消するような理想のプロセスを全員で描いた • 仕様と設計の界面が曖昧になり、受けたフィードバックを反映できる 工程が足された 提案からリリースまでの理想の姿 “プロセスの在るべき姿” も関係者全員で定義した Waterfall期 混乱期 統一期
37. 統一期 Waterfall期 混乱期 統一期
38. 立ち上がり史 | 統一期 • チームの全員が プロダクトとプロセスの在るべき姿を共有 しているため、 それらが議論の拠り所になり、よりAgileで生産的な意思決定 が可能になった • 目指したい姿に近づくためのアクションを洗い出して着実に実行していくのみ 目的や各自の役割期待が一致して、チームの関係性が安定した Product Goal 理想のプロセス Waterfall期 混乱期 統一期
39. 立ち上がり史 | 概観 Waterfall期 混乱期 統一期 ここまでのふりかえり むきなおり & 決起飲み会 Product Vision決定 Waterfall期 混乱期 統一期 PO・設計・仕様の責務分担 仕様チームを含めた 仕様検討プロセス策定 在るべき姿を目指すための ロードマップ作成 技術的負債の解消 本格化 Sprint Goalの 本格運用開始 Sprint Review 開始
40. PO・設計・仕様の責務分担 • プロセスの在るべき姿は決まったものの、実際の生活には旧体制の名残が多く残っていて 各メンバーが 顕在化されていない役割や仕事 を大量に抱えていた（特にPO） • これらを顕在化・整理した上で、適切なメンバーに再分配を行う必要がある メンバーが日常で行っている仕事を洗い出し 誰かに引き継ぐべき仕事や誰かが手伝える仕事を選定して委譲する Waterfall期 混乱期 統一期
41. PO・設計・仕様の責務分担 | ドラッカー風エクササイズ • 全員が今の仕事・役割を洗い出して、① 引き続き取り組むこと ② 手伝ってもらうこと ③ 誰かに引き取ってもらうこと にマッピングする • ②と③については、メンバーの挙手性で誰が引き受けるかを決める チームの生活における全仕事・役割に対して、持つべき人を割り振った Waterfall期 混乱期 統一期
42. 在るべき姿を目指すためのロードマップ作成 • ここまでのプロセスで出てきた ”在るべき姿を目指すためのアクション” の全てを ロードマップに落とし込み、誰がやるか と いつやるか の２点を明確にした 実施時期まで明確にすることでアクションの確実な実施に繋げる Waterfall期 混乱期 統一期
43. 現在地と今後の展望 • Agileな組織として立ち上がったものの、まだ 統一期の前半 というステータスであり バリューを産むという観点ではスタートラインに立ったに過ぎない 1. 在るべき姿になるための多くのアクションがこれから 2. 市場からのフィードバックをプロダクトに反映できていない • ヘッドホンのスケジュールに影響されずに改善を回せる恵まれた環境を貰えているので 現状に満足することなく、今後もプロダクトとプロセスを磨いていく アプリ全体の体験価値や売上に貢献できるように改善を続ける
44. なぜ素早く立ち上がることが出来たか？ 想ったことを言い合える透明性 改善に対する情熱と議論 プロダクトとプロセスの在るべき姿の共通のビジョン ↓ ここまでの土壌が備わっていた ↓ これらの安定した土台の上で 改善サイクルを回す
45. なぜ素早く立ち上がることが出来たか？ | 先人の知恵とプロのサポート • 身近に先行して上手くAgile開発を回している チームがいたため、取り組みを盗んで 自分たち向けにカスタム した • 混乱期を抜けるための議論は、発散しがちで決め切ることが出来ていなかったので 外部のプロである スクラムコーチの支援 を受けた • ワークショップの開催とファシリテーション • チームが迷った時の都度のアドバイス すでに上手くいっている組織のプラクティスを真似したり 外部のプロのサポートを貰って困難を乗り越えることも効果的
46. チームの成長に伴うパフォーマンスの向上 • 混乱期を超えたことで 消化チケット数・Velocity 共に大きく向上 した • 在るべき姿を共有して “迷い” が減った ことでパフォーマンス向上に繋がったと考える 混乱期 統一期 在るべき姿をチームで共有することは、パフォーマンス向上にも繋がる チームVelocity
47. 後編まとめ • チームの立ち上がりには、まず “変化への議論と情熱がある” という混乱期を目指すが メンバーの相互理解を地道に進めて、 想ったことが言い合える透明性 があったことで すぐにそのフェーズに行くことが出来た • チームの混乱期におけるあらゆる意思決定を “誰かから答えが与えられた” のではなく “全員で立ち止まってアクションを考えた” ことで、結論への当事者意識が芽生えた (決め切るのに時間がかかる場合には 人数を絞る ことも効果的) • 立ち止まってプロダクトやプロセスの在るべき姿を考えるのには一定の時間がかかるが それらは より生産的かつAgileな意思決定の拠り所となってプロセスを早くする ので 長期的にチームのパフォーマンスを上げることに繋がる
48. 体制を2つに分けて WaterfallとAgileの両立を目指そう！ 慣れないAgileチームの立ち上げに対して、いろいろな取り組みやっています！ ハードウェアとの連携開発なので Agileなアプリ開発がツラい 前編 ハード連携開発特有の 悩みと取り組み 後編 Agileなチーム 立ち上げにむけて 全体まとめ
49. SONYはソニーグループ株式会社の登録商標または商標です。 各ソニー製品の商品名・サービス名はソニーグループ株式会社またはグループ各社の登録商標または商標です。その他の製品および会社名は、各社の商号、登録商標または商標です。