チーム開発における様々な ボトルネックの整理 すてにゃん (id:stefafafan) 2023/03/18 YAPC::Kyoto 2023 Reject Con 1

自己紹介 ● すてにゃん (id:stefafafan / @stefafafan) ● 2015- 株式会社はてな ○ Webアプリケーションエンジニア ○ 最近はスクラムマスター、テックリードなど 2

今日話すこと ● チーム開発のサイクルを改善するにはどうす ればよいのか ○ 状況に応じて取れる手段を提示 ○ 読んだ本や記事、経験を元に分類分けしたものを共有 3

4 ケース1: 改善サイクルが 回っていない

ケース1: 改善サイクルが回っていない ● 状況 ○ 効率の悪い仕事の仕方を続けている ○ 改善される見込みがない ● 取れると良い手段 ○ アジャイルフレームワークを取り入れる 5

ケース1: 改善サイクルが回っていない ● 大事なのは Incremental で Iterative である こと ○ Incremental: 漸進的 ○ Iterative: 反復的 ● 課題の解消に向けて少しずつ着実に進めると 良い 6

ケース1: 改善サイクルが回っていない ● 漸進的で反復的に仕事を進めるには？ ○ アジャイルフレームワークを導入すると良い ■ Scrum とかはソフトウェア開発に限らず汎用的に使える 7

8 ケース2: ソフトウェア開発速度が 遅い

ケース2: ソフトウェア開発速度が遅い ● そもそも「遅い」とはどういうことなのか ● Four Keysの指標で会話すると良い ○ デプロイの頻度 ○ 変更のリードタイム ○ 変更障害率 ○ サービス復元時間 9

ケース2: ソフトウェア開発速度が遅い ● Four Keysはそれぞれの指標が満たされてい る必要がある ● 例えば「デプロイ頻度は高いけど毎回障害が 発生している」だとサービス復旧などに時間 がとられてしまっていることとなる 10

ケース2: ソフトウェア開発速度が遅い ● Four Keysの指標の改善にはどういうものが 効くのか ○ Extreme Programming (XP) のプラクティス ○ DevOps のプラクティス 11

ケース2: ソフトウェア開発速度が遅い ● Extreme Programming (XP) プラクティス （以下は一部の例の抜粋） ○ 計画 ■ 小さい単位でリリースする ○ コーディング ■ ペアプログラミングで進める ○ テスト 12

ケース2: ソフトウェア開発速度が遅い ● DevOpsのプラクティス ○ インフラ要件も一緒のプロジェクトで管理する ○ CI/CDを整える ○ Infrastructure as Code (IaC) する ○ 可観測性をあげる ○ アプリケーションエンジニアがインフラのオーナー シップを持つ 13

14 ケース3: チーム内の連携が イマイチ

ケース3:チーム内の連携がイマイチ ● 心理的安全性が足りない ○ HRT (謙虚・尊敬・信頼) の欠如 ○ コードレビューが辛い、気軽に発言できなくて課題が 隠されてしまう等 ● プロセスの改善の前に信頼関係を作るところ から 15

ケース3:チーム内の連携がイマイチ ● チームが自己組織化されていない ○ エラスティックリーダーシップ ■ サバイバルモード ■ 学習モード ■ 自己組織化モード ○ 現在のモードを自覚し、自己組織化へと導くにはどう すると良いかを考える 16

17 ケース4: チーム外との連携が イマイチ

ケース4:チーム外との連携がイマイチ ● Team Topologies ○ 現状の他チームとの関わりを図にする ○ リリースまでの流れで毎回他チームとコミュニケー ションが発生していると効率が悪そうなど ○ モノリシックなリポジトリのデプロイのたびに他チー ムに許可をとらないといけないなど 18

19 様々な話題があるが 上手く整理できないか

整理: スコープ別 ● いくつかのスコープで考えることができる ○ 職能チーム（エンジニアチーム、デザイナーチーム） ○ 機能開発チーム（企画からリリースまで） ○ チーム横断（同じ部署、会社レベルなど） 20

整理: カテゴリ別 ● スコープごとに以下のようなカテゴリがある ○ テクニカルな話題（コード設計、リファクタリング） ○ プロセス周り（Scrum、XP） ○ 人間関係（信頼、メンバーの成長） 21

スコープ✖カテゴリで考える ● チームごとにどこにボトルネックがあるかは バラバラなのでスコープ×カテゴリで考えると 良い 22

1. 職能チーム 2. 機能開発チーム 3. チーム横断 1. テクニカルな話題 2. プロセス 3. 人間関係 23 スコープ✖カテゴリで考える

スコープ✖カテゴリで考える ● エンジニア+デザイナー × テクニカル面 ○ コードベースがデザイナーにとっても開発体験の良い ものになっているか会話しながら見直すなど ● App Engineer+SRE × プロセス ○ DevOpsのプラクティスを導入すると良い ○ デプロイを依頼するのではなくIaCやCI/CDを整える 24

スコープ✖カテゴリで考える ● 会社のエンジニア組織 × メンバーの成長 ○ チーム間のエンジニアの交流が足りているか ○ 社内でのエンジニアの異動を促進していくと良いか 25

まとめ ● チーム開発には様々なボトルネックが存在す る ● スコープ×カテゴリ別に考えてどこから手をつ けていくかを考えると良さそう ○ 足りていないところはどこかというのを出すのにおす すめ 26

参考文献 ● 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

参考文献 ● 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