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

『LeanとDevOpsの科学』という書籍では、ハイパフォーマーである組織の特徴として「デプロイの頻度が多いこと」を挙げています。しかしデプロイの頻度を多くするには具体的にどうすればいいのでしょうか？この疑問に対し、モブワークと呼ばれる開発手法を通して解決を試みた結果をお話します。試行錯誤を重ねる中でチームが文字通り一心同体となり、リソース効率からフロー効率へ発想を転換していく過程をお楽しみいただけます。ハイパフォーマーを目指したい方、良いチームを育てたい方、開発で充実感を味わいたい方におすすめです。

↓動画で確認いただきたい方はこちらからご覧ください。
https://youtu.be/gT_GJXJVuU0

Transcript

1. フロー効率の向上から始める 開発生産性の高め方 YAPC::Japan::Online 2022 #yapcjapan | 2022/3/5 track B | @omokawa_yasu モブワークを沿えて 1
2. 自己紹介 2
3. 3 副業：占い師 おもかわ やすあき
4. モブワーク フロー効率 高めたよ 4 トークテーマで一句
5. 概要 5 1. モブワークでフロー効率を上げることができた 2. モブワークでフロー効率が上がった理由をふりかえる 3. 今後、さらにフロー効率を高めるには？
6. 当時の開発体制 6 PdMチーム プロダクトオー ナー 開発チーム QAチーム QA担当 一般メンバー テックリード スクラムマスター デザイナー
7. スプリント バックログ 当時の開発手法 7 デイリー スクラム 1週間の スプリント スプリント レトロスペクティ ブ スプリント プランニング スプリント レビュー インクリメント プロダクト バックログ
8. 発生した課題：コードレビューがボトルネックに 8 PdMチーム 開発チーム QAチーム QA担当 一般メンバー テックリード スクラムマスター レビュー依頼 多すぎて キャパオーバー プロダクトオー ナー デザイナー
9. 解決策：コードレビューをモブワークにした 9 レビュイー レビュアー ①　オンライン or オフラインで開発メンバーが 全員集まる。レビュイーが担当タスクの背景と実 装意図を説明 ②　軽く質疑応答した後、モブプログラミング。 そ の場でマージ・デプロイまで行う
10. 結果：デプロイまでの時間が短縮され、 　　　フロー効率が向上した • タスク着手からデプロイまでの時間（リードタイム） ◦ 185%向上 • 1スプリントあたりのベロシティ ◦ 115%向上 10
11. 185% リードタイムの向上率はかなりよかった ベロシティはむしろ下がると思ってた（稼働率が下がったので） 11
12. モブワークの効果をふりかえってみた 12
13. 効果１：アイドルタイムの削減 13 レビュイー レビュアー プルリクエスト レビュー 修正 マージ プルリクエスト レビュー 修正 マージ モブワーク Before After
14. 効果２：マルチタスク防止 リアルタイムにフィードバックが得られるため、レビュイーがマルチタスクを防止 できる 14
15. 効果３：レビュアーの負担を軽減 • モブワークで初めて分かったが、最もレビュアーが時間を掛けるのは実装 意図や背景の理解だった • レビュイーに口頭で説明してもらえるため、レビュアーの理解が進む 15
16. 効果４：チーム全体の学習を促進 • 網羅的にコードレビューするとドメイン知識が深まる • 1人だと実装パターンのアイデアは2~3個だが、モブワークすると5~6個く らい出る • メンバーの集合知がテックリードに勇気を与える ◦ テックリードに集中したプレッシャーを全員で分担 ◦ メンバーの多角的な視点は最高の学習機会 16
17. 効果５：テックリードがレビューするときの 　　　　思考過程が全員に伝わる • 特に印象深かったチェック観点 ◦ エッジケースが足りてるか、かなり時間を掛けて見てた ◦ プルリクエスト作成者にもしものことがあったら、レビューしているコー ドを引き継ぐ責任を取れるかどうか見てた ◦ コード規約・フォーマットは、Rubocopなどのリンターに任せているの でレビューしてなかった 17
18. 効果６：参加メンバー全員のモチベーション向上 • リアルタイムにコードがデプロイされるとテンションが上がる • ライブコーディングは基本的に楽しい（人にもよるけど） • 1人で詰まると地獄だが、みんなで詰まると心が折れない 18
19. モブワークの成功をサポートした要素 19
20. ウチの組織では、技術面とチーム面の2つの要素がモブワークをサポートしてくれました 20 モブワークの成功 • 継続的デリバリーの整備 ◦ 自動テスト ◦ トランクベース開発 ◦ 監視 ◦ 高いテストカバレッジ • 心理的安全性の確保 ◦ ワーキングアグリーメント明 文化 ◦ タイムボックス確保 ◦ コラボレーションスペース確 保
21. 技術面の要素について補足 • トランクベース開発でビッグバンリリースを防ぐ ◦ ブランチは1日でマージできるくらいのサイズに調整する ◦ フラグで表示制限して段階的にリリースできるようにする • 高いテストカバレッジ ◦ カバレッジが高いと安心してリファクタリングできる • 自動テスト ◦ 不安定（FLAKY）なテストはこまめに改修してCIコストを改善 21
22. チーム面の要素について補足 • ワーキングアグリーメントを明文化 ◦ 「尊敬・感謝・称賛」を大事にすることをWikiに書き起こした ◦ レビューコメントにキャプションをつけ、「相手にどんなリアクションを求 めているのか」を判別できるように • タイムボックス確保 ◦ デイリースクラムの後にモブワークをスケジューリングし、「意志の力 に頼らない運用」にする（イフゼン・プランニング） 22
23. チーム面としてもっとも重要だと思ったこと 23 徹底して規約を定め、コス トパフォーマンスの悪いコ ミュニケーションを撲滅す る
24. 今後やろうと思っているアイデア 24
25. 課題：見積もりがボトルネックなので解消したい 25 要件定義 見積もり タスク分解 開発 デプロイ 見積もり精度を上げるためにタスクを分 解する作業を入れたが、 長時間かかる割 に見積もり精度が上がらないためコスト パフォーマンスが悪い
26. 案：モブワークによる改善 26 要件定義 見積もり タスク分解 開発 デプロイ Before After 要件定義 見積もり モブワーク デプロイ
27. 27 要件定義 見積もり タスク分解 開発 デプロイ Before After 要件定義 見積もり モブワーク デプロイ • コードを見ずにタスク分解するのは困難 。ざっく り見積もりしてすぐモブワークを始めたほうが 確実 • つねにモブワークすることで、 タスクを分解しメ ンバーに割り当てるコストを削減
28. 案：モブワークしやすい開発体制に変更する 28 PdM 開発 QA 設計からデプロイまで完遂できるチーム （メインチームと仮称） Before After
29. すばやいフィードバックを目指す開発スタイル 29 • 動くものを作り、リアルタイムで改善を 加える • モブワークは口頭のやりとりが増える ため、暗黙知が多くなることがリスク。 意思決定した内容の文書化を徹底す る • コミュニケーションコストが高い箇所は ドメインを分割するチャンス。 切り出し たドメインに対応する別のチームを作 る ※ 書籍『チームトポロジー』の図を一部変更して掲載
30. まとめ 30
31. 長続きするハイパフォーマンスなプロダクト チームは、より効率的な共同作業の方法を見 つけてデリバリーのボトルネックを取り除くこと で、デリバリー頻度を着実に向上させることが できる 31 『チームトポロジー』より引用
32. 今回の話はこちらの4冊を参考にしました。 興味ある方はぜひ読んでみてください！ 32
33. 何か参考になれば嬉しいです。 たのしいチーム開発ライフをお過ごしくださ い！ 33
34. ご清聴ありがとうございました！ 34