フロー効率の向上から始める開発生産性の高め方 ~ モブワークを沿えて ~ / 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
   

   View Slide

2. 自己紹介
   2
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

30. まとめ
    30
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide