Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
チーム開発における様々なボトルネックの整理 / Organization of bottlen...
Search
すてにゃん
March 18, 2023
Technology
0
3.1k
チーム開発における様々なボトルネックの整理 / Organization of bottlenecks in Team Development
YAPC::Kyoto 2023 前日祭 - connpass
のReject Conにて発表した時の資料です。
すてにゃん
March 18, 2023
Tweet
Share
More Decks by すてにゃん
See All by すてにゃん
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
120
小田原でみんなで一句詠みたいな #phpcon_odawara
stefafafan
0
860
dotfiles について話したい #湘なんか
stefafafan
2
430
意義から考えるObservability入門 #srenext
stefafafan
2
1.3k
高橋メソッド風の発表を生成するCLIツールをPHPで作った #phpcon_odawara
stefafafan
1
1.1k
令和最新版 ソフトウェアエンジニアのためのDJ入門、あるいはDJに学ぶ仕事術 #ya8
stefafafan
2
630
一番やさしいDJ入門 2024
stefafafan
6
2.1k
『Goサブ会』によるチームを超えた知見展開、あるいは hatena.go に対する期待 #hatenago
stefafafan
0
2.1k
開発チーム横断タスクフォース 「Goサブ会」の 運用事例と今後の展望
stefafafan
0
870
Other Decks in Technology
See All in Technology
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
270
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
110
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
140
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.6k
プロダクトエンジニアリング組織への歩み、その現在地 / Our journey to becoming a product engineering organization
hiro_torii
0
130
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.1k
M3 Expressiveの思想に迫る
chnotchy
0
100
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
rubygem開発で鍛える設計力
joker1007
2
200
強化されたAmazon Location Serviceによる新機能と開発者体験
dayjournal
2
210
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
170
本が全く読めなかった過去の自分へ
genshun9
0
420
Featured
See All Featured
Music & Morning Musume
bryan
46
6.6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Into the Great Unknown - MozCon
thekraken
39
1.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
The Language of Interfaces
destraynor
158
25k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Why Our Code Smells
bkeepers
PRO
337
57k
Faster Mobile Websites
deanohume
307
31k
Transcript
チーム開発における様々な ボトルネックの整理 すてにゃん (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