チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development

YAPC::Kyoto 2023 前日祭 - connpass のReject Conにて発表した時の資料です。

Transcript

1. チーム開発における様々な ボトルネックの整理 すてにゃん (id:stefafafan) 2023/03/18 YAPC::Kyoto 2023 Reject Con 1
2. 自己紹介 • すてにゃん (id:stefafafan / @stefafafan) • 2015- 株式会社はてな ◦ Webアプリケーションエンジニア ◦ 最近はスクラムマスター、テックリードなど 2
3. 今日話すこと • チーム開発のサイクルを改善するにはどうす ればよいのか ◦ 状況に応じて取れる手段を提示 ◦ 読んだ本や記事、経験を元に分類分けしたものを共有 3
4. 4 ケース1: 改善サイクルが 回っていない
5. ケース1: 改善サイクルが回っていない • 状況 ◦ 効率の悪い仕事の仕方を続けている ◦ 改善される見込みがない • 取れると良い手段 ◦ アジャイルフレームワークを取り入れる 5
6. ケース1: 改善サイクルが回っていない • 大事なのは Incremental で Iterative である こと ◦ Incremental: 漸進的 ◦ Iterative: 反復的 • 課題の解消に向けて少しずつ着実に進めると 良い 6
7. ケース1: 改善サイクルが回っていない • 漸進的で反復的に仕事を進めるには？ ◦ アジャイルフレームワークを導入すると良い ▪ Scrum とかはソフトウェア開発に限らず汎用的に使える 7
8. 8 ケース2: ソフトウェア開発速度が 遅い
9. ケース2: ソフトウェア開発速度が遅い • そもそも「遅い」とはどういうことなのか • Four Keysの指標で会話すると良い ◦ デプロイの頻度 ◦ 変更のリードタイム ◦ 変更障害率 ◦ サービス復元時間 9
10. ケース2: ソフトウェア開発速度が遅い • Four Keysはそれぞれの指標が満たされてい る必要がある • 例えば「デプロイ頻度は高いけど毎回障害が 発生している」だとサービス復旧などに時間 がとられてしまっていることとなる 10
11. ケース2: ソフトウェア開発速度が遅い • Four Keysの指標の改善にはどういうものが 効くのか ◦ Extreme Programming (XP) のプラクティス ◦ DevOps のプラクティス 11
12. ケース2: ソフトウェア開発速度が遅い • Extreme Programming (XP) プラクティス （以下は一部の例の抜粋） ◦ 計画 ▪ 小さい単位でリリースする ◦ コーディング ▪ ペアプログラミングで進める ◦ テスト 12
13. ケース2: ソフトウェア開発速度が遅い • DevOpsのプラクティス ◦ インフラ要件も一緒のプロジェクトで管理する ◦ CI/CDを整える ◦ Infrastructure as Code (IaC) する ◦ 可観測性をあげる ◦ アプリケーションエンジニアがインフラのオーナー シップを持つ 13
14. 14 ケース3: チーム内の連携が イマイチ
15. ケース3:チーム内の連携がイマイチ • 心理的安全性が足りない ◦ HRT (謙虚・尊敬・信頼) の欠如 ◦ コードレビューが辛い、気軽に発言できなくて課題が 隠されてしまう等 • プロセスの改善の前に信頼関係を作るところ から 15
16. ケース3:チーム内の連携がイマイチ • チームが自己組織化されていない ◦ エラスティックリーダーシップ ▪ サバイバルモード ▪ 学習モード ▪ 自己組織化モード ◦ 現在のモードを自覚し、自己組織化へと導くにはどう すると良いかを考える 16
17. 17 ケース4: チーム外との連携が イマイチ
18. ケース4:チーム外との連携がイマイチ • Team Topologies ◦ 現状の他チームとの関わりを図にする ◦ リリースまでの流れで毎回他チームとコミュニケー ションが発生していると効率が悪そうなど ◦ モノリシックなリポジトリのデプロイのたびに他チー ムに許可をとらないといけないなど 18
19. 19 様々な話題があるが 上手く整理できないか
20. 整理: スコープ別 • いくつかのスコープで考えることができる ◦ 職能チーム（エンジニアチーム、デザイナーチーム） ◦ 機能開発チーム（企画からリリースまで） ◦ チーム横断（同じ部署、会社レベルなど） 20
21. 整理: カテゴリ別 • スコープごとに以下のようなカテゴリがある ◦ テクニカルな話題（コード設計、リファクタリング） ◦ プロセス周り（Scrum、XP） ◦ 人間関係（信頼、メンバーの成長） 21
22. スコープ✖カテゴリで考える • チームごとにどこにボトルネックがあるかは バラバラなのでスコープ×カテゴリで考えると 良い 22
23. 1. 職能チーム 2. 機能開発チーム 3. チーム横断 1. テクニカルな話題 2. プロセス 3. 人間関係 23 スコープ✖カテゴリで考える
24. スコープ✖カテゴリで考える • エンジニア+デザイナー × テクニカル面 ◦ コードベースがデザイナーにとっても開発体験の良い ものになっているか会話しながら見直すなど • App Engineer+SRE × プロセス ◦ DevOpsのプラクティスを導入すると良い ◦ デプロイを依頼するのではなくIaCやCI/CDを整える 24
25. スコープ✖カテゴリで考える • 会社のエンジニア組織 × メンバーの成長 ◦ チーム間のエンジニアの交流が足りているか ◦ 社内でのエンジニアの異動を促進していくと良いか 25
26. まとめ • チーム開発には様々なボトルネックが存在す る • スコープ×カテゴリ別に考えてどこから手をつ けていくかを考えると良さそう ◦ 足りていないところはどこかというのを出すのにおす すめ 26
27. 参考文献 • Brian W. Fitzpatrick, Ben Collins-Sussman. Team Geek ―Googleのギークた ちはいかにしてチームを作るのか. オライリージャパン. 2013. • Matthew Skelton, Manuel Pais. チームトポロジー 価値あるソフトウェアをす ばやく届ける適応型組織設計. 日本能率協会マネジメントセンター. 2021. • Nicole Forsgren Ph.D., Jez Humble, Gene Kim. LeanとDevOpsの科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する. インプレス. 2018. • Roy Osherove. エラスティックリーダーシップ ―自己組織化チームの育て方. オ ライリージャパン. 2017. 27
28. 参考文献 • Don Wells. “The Rules of Extreme Programming”. Extreme Programming (xp): A Gentle Introduction. 1999. http://www.extremeprogramming.org/rules.html • hirokidaichi. “エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読 書ガイド”. Qiita. 2021. https://qiita.com/hirokidaichi/items/95678bb1cef32629c317 • Tom Hall. “DevOps のベスト プラクティス”. Atlassian. 2023. https://www.atlassian.com/ja/devops/what-is-devops/devops-best-practices • Toshimaru. “『Team Geek』読んだ ~HRT(謙虚/尊敬/信頼)の精神を知り会社でサバイブし ていく方法~”. Hack Your Design!. 2019. https://blog.toshimaru.net/team-geek/ • yigarashi. “Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法に ついて”. yigarashiのブログ. 2022. https://yigarashi.hatenablog.com/entry/2022/05/30/093000 28