フロー効率の向上から始める開発生産性の高め方 ~ モブワークを沿えて ~ / how to go on high peformance with mob work

by 面川泰明

Slide 1

Slide 1 text

フロー効率の向上から始める開発生産性の高め方 YAPC::Japan::Online 2022 #yapcjapan | 2022/3/5 track B | @omokawa_yasu モブワークを沿えて 1

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

3 副業：占い師おもかわやすあき

Slide 4

Slide 4 text

モブワークフロー効率高めたよ 4 トークテーマで一句

Slide 5

Slide 5 text

概要 5 1. モブワークでフロー効率を上げることができた 2. モブワークでフロー効率が上がった理由をふりかえる 3. 今後、さらにフロー効率を高めるには？

Slide 6

Slide 6 text

当時の開発体制 6 PdMチームプロダクトオーナー開発チーム QAチーム QA担当一般メンバーテックリードスクラムマスターデザイナー

Slide 7

Slide 7 text

スプリントバックログ当時の開発手法 7 デイリースクラム 1週間のスプリントスプリントレトロスペクティブスプリントプランニングスプリントレビューインクリメントプロダクトバックログ

Slide 8

Slide 8 text

発生した課題：コードレビューがボトルネックに 8 PdMチーム開発チーム QAチーム QA担当一般メンバーテックリードスクラムマスターレビュー依頼多すぎてキャパオーバープロダクトオーナーデザイナー

Slide 9

Slide 9 text

解決策：コードレビューをモブワークにした 9 レビュイーレビュアー ①　オンライン or オフラインで開発メンバーが全員集まる。レビュイーが担当タスクの背景と実装意図を説明 ②　軽く質疑応答した後、モブプログラミング。その場でマージ・デプロイまで行う

Slide 10

Slide 10 text

結果：デプロイまでの時間が短縮され、　　　フロー効率が向上した ● タスク着手からデプロイまでの時間（リードタイム） ○ 185%向上 ● 1スプリントあたりのベロシティ ○ 115%向上 10

Slide 11

Slide 11 text

185% リードタイムの向上率はかなりよかったベロシティはむしろ下がると思ってた（稼働率が下がったので） 11

Slide 12

Slide 12 text

モブワークの効果をふりかえってみた 12

Slide 13

Slide 13 text

効果１：アイドルタイムの削減 13 レビュイーレビュアープルリクエストレビュー修正マージプルリクエストレビュー修正マージモブワーク Before After

Slide 14

Slide 14 text

効果２：マルチタスク防止リアルタイムにフィードバックが得られるため、レビュイーがマルチタスクを防止できる 14

Slide 15

Slide 15 text

効果３：レビュアーの負担を軽減 ● モブワークで初めて分かったが、最もレビュアーが時間を掛けるのは実装意図や背景の理解だった ● レビュイーに口頭で説明してもらえるため、レビュアーの理解が進む 15

Slide 16

Slide 16 text

効果４：チーム全体の学習を促進 ● 網羅的にコードレビューするとドメイン知識が深まる ● 1人だと実装パターンのアイデアは2~3個だが、モブワークすると5~6個くらい出る ● メンバーの集合知がテックリードに勇気を与える ○ テックリードに集中したプレッシャーを全員で分担 ○ メンバーの多角的な視点は最高の学習機会 16

Slide 17

Slide 17 text

効果５：テックリードがレビューするときの　　　　思考過程が全員に伝わる ● 特に印象深かったチェック観点 ○ エッジケースが足りてるか、かなり時間を掛けて見てた ○ プルリクエスト作成者にもしものことがあったら、レビューしているコードを引き継ぐ責任を取れるかどうか見てた ○ コード規約・フォーマットは、Rubocopなどのリンターに任せているのでレビューしてなかった 17

Slide 18

Slide 18 text

効果６：参加メンバー全員のモチベーション向上 ● リアルタイムにコードがデプロイされるとテンションが上がる ● ライブコーディングは基本的に楽しい（人にもよるけど） ● 1人で詰まると地獄だが、みんなで詰まると心が折れない 18

Slide 19

Slide 19 text

モブワークの成功をサポートした要素 19

Slide 20

Slide 20 text

ウチの組織では、技術面とチーム面の2つの要素がモブワークをサポートしてくれました 20 モブワークの成功 ● 継続的デリバリーの整備 ○ 自動テスト ○ トランクベース開発 ○ 監視 ○ 高いテストカバレッジ ● 心理的安全性の確保 ○ ワーキングアグリーメント明文化 ○ タイムボックス確保 ○ コラボレーションスペース確保

Slide 21

Slide 21 text

技術面の要素について補足 ● トランクベース開発でビッグバンリリースを防ぐ ○ ブランチは1日でマージできるくらいのサイズに調整する ○ フラグで表示制限して段階的にリリースできるようにする ● 高いテストカバレッジ ○ カバレッジが高いと安心してリファクタリングできる ● 自動テスト ○ 不安定（FLAKY）なテストはこまめに改修してCIコストを改善 21

Slide 22

Slide 22 text

チーム面の要素について補足 ● ワーキングアグリーメントを明文化 ○ 「尊敬・感謝・称賛」を大事にすることをWikiに書き起こした ○ レビューコメントにキャプションをつけ、「相手にどんなリアクションを求めているのか」を判別できるように ● タイムボックス確保 ○ デイリースクラムの後にモブワークをスケジューリングし、「意志の力に頼らない運用」にする（イフゼン・プランニング） 22

Slide 23

Slide 23 text

チーム面としてもっとも重要だと思ったこと 23 徹底して規約を定め、コストパフォーマンスの悪いコミュニケーションを撲滅する

Slide 24

Slide 24 text

今後やろうと思っているアイデア 24

Slide 25

Slide 25 text

課題：見積もりがボトルネックなので解消したい 25 要件定義見積もりタスク分解開発デプロイ見積もり精度を上げるためにタスクを分解する作業を入れたが、長時間かかる割に見積もり精度が上がらないためコストパフォーマンスが悪い

Slide 26

Slide 26 text

案：モブワークによる改善 26 要件定義見積もりタスク分解開発デプロイ Before After 要件定義見積もりモブワークデプロイ

Slide 27

Slide 27 text

27 要件定義見積もりタスク分解開発デプロイ Before After 要件定義見積もりモブワークデプロイ ● コードを見ずにタスク分解するのは困難。ざっくり見積もりしてすぐモブワークを始めたほうが確実 ● つねにモブワークすることで、タスクを分解しメンバーに割り当てるコストを削減

Slide 28

Slide 28 text

案：モブワークしやすい開発体制に変更する 28 PdM 開発 QA 設計からデプロイまで完遂できるチーム（メインチームと仮称） Before After

Slide 29

Slide 29 text

すばやいフィードバックを目指す開発スタイル 29 ● 動くものを作り、リアルタイムで改善を加える ● モブワークは口頭のやりとりが増えるため、暗黙知が多くなることがリスク。意思決定した内容の文書化を徹底する ● コミュニケーションコストが高い箇所はドメインを分割するチャンス。切り出したドメインに対応する別のチームを作る ※ 書籍『チームトポロジー』の図を一部変更して掲載

Slide 30

Slide 30 text

まとめ 30

Slide 31

Slide 31 text

長続きするハイパフォーマンスなプロダクトチームは、より効率的な共同作業の方法を見つけてデリバリーのボトルネックを取り除くことで、デリバリー頻度を着実に向上させることができる 31 『チームトポロジー』より引用

Slide 32

Slide 32 text

今回の話はこちらの4冊を参考にしました。興味ある方はぜひ読んでみてください！ 32

Slide 33

Slide 33 text

何か参考になれば嬉しいです。たのしいチーム開発ライフをお過ごしください！ 33

Slide 34

Slide 34 text

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