YAPC::Kyoto 2023 前日祭 - connpass のReject Conにて発表した時の資料です。
チーム開発における様々なボトルネックの整理すてにゃん (id:stefafafan)2023/03/18 YAPC::Kyoto 2023 Reject Con1
View Slide
自己紹介● すてにゃん (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): AGentle 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/09300028
stefafafan
nagauta
taka2noda
mii3king
microcms
shimap_sampo
nsakki55
hiroshinakagawa
washizaki
oracle4engineer
tsutaj
daihiraoka
ryomaru0825
lemiorhan
hatefulcrawdad
vanstee
zenorocha
stephaniewalter
brettharned
aleyda
chriscoyier
paulrobertlloyd
swwweet
akmur
mthomps