$30 off During Our Annual Pro Sale. View Details »

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

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

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

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

面川泰明

March 05, 2022
Tweet

More Decks by 面川泰明

Other Decks in Programming

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. 効果1:アイドルタイムの削減
    13
    レビュイー
    レビュアー
    プルリクエスト
    レビュー
    修正
    マージ
    プルリクエスト レビュー 修正 マージ
    モブワーク
    Before
    After

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  18. 効果6:参加メンバー全員のモチベーション向上
    ● リアルタイムにコードがデプロイされるとテンションが上がる
    ● ライブコーディングは基本的に楽しい(人にもよるけど)
    ● 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