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
【SQiP】アジャイル開発の生産性 / What is agile development p...
Search
Masato Ishigaki / 石垣雅人
September 09, 2022
Technology
3
770
【SQiP】アジャイル開発の生産性 / What is agile development productivity?
2022/09/09 ソフトウェア品質シンポジウム 2022 登壇資料
Masato Ishigaki / 石垣雅人
September 09, 2022
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
4
170
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
7
880
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
8
19k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
3
260
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
630
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
1.7k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.4k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.6k
Other Decks in Technology
See All in Technology
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
6
700
知られざるprops命名の慣習 アクション編
uhyo
11
2.8k
モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる / Team-oriented Organization Design 20250825
mtx2s
6
43k
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
460
見てわかるテスト駆動開発
recruitengineers
PRO
6
2.1k
実運用で考える PGO
kworkdev
PRO
0
120
Product Management Conference -AI時代に進化するPdM-
kojima111
0
260
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
530
進捗
ydah
1
210
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
660
帳票Vibe Coding
terurou
0
150
ソフトウェア エンジニアとしての 姿勢と心構え
recruitengineers
PRO
22
11k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
11
1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.5k
Designing Experiences People Love
moore
142
24k
Typedesign – Prime Four
hannesfritz
42
2.8k
GitHub's CSS Performance
jonrohan
1032
460k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
How to Ace a Technical Interview
jacobian
279
23k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
570
Transcript
アジャイル開発の生産性とは 〜リードタイムのメトリクスを 3階層に分けることで見えた生産性の指標〜 What is agile development productivity? ~ Productivity
indicators seen when lead time metrics are divided into three layers ~ ソフトウェア品質シンポジウム 2022 合同会社 DMM.com 石垣 雅人(Masato Ishigaki)
About me 石垣 雅人 - Masato Ishigaki ・プラットフォーム事業本部 第1開発部 部長
・VPoE室 略歴 ・DMM.com エンジニア 新卒入社 ・2020年より、総合トップ開発部 部長 / DMMポイントクラブ 事業責任者 ・2022年より、現職 著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版 ,2020) 著 : 『DMM PointClub TechBook』(技術書典, 2022) 連載中 : 『スモールチームが武器になる時代へ』( ProductZine)
Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ :
リードタイムを3階層にしたことで見えたもの - 結果と考察 - Target - アジャイル開発、プロダクト開発をしている方、事業責任者の方
Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ :
リードタイムを3階層にしたことで見えたもの - 結果と考察
Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ :
リードタイムを3階層にしたことで見えたもの - 結果と考察
近年のソフトウェア開発の傾向 = コモディティー化 → XaaS - 新しい技術が登場し続ける、ソフトウェアの世界。 - Ex. コンテナ技術、k8s、Maschine
Learning、NFT - 魅力的な技術であれば、沢山のプラクティスが出てくる。 - X as a Serviceやエコシステムとして、サービス提供される。 - 昔は苦労して皆が実装していたものが、平等に利用可能な「武器」になる - 技術は常に進化して、コモディティー化する - 代表的な例として、クラウドサービスがある - すると、開発速度はスピードアップする 技術競争 価格競争 価値 コモディティ化 技術発展のS字カーブ ユーザーニーズ 引用 : https://muchinare.com/archives/13693034.html 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
市場への投入タイミングの激化と開発組織の変化 - 市場に対して、追従スピードが求められる環境が加速 - XaaS / エコシステムよって開発は楽になっているはずがリードタイムはあまり変わっ ていないように思える - 組織全体でリードタイムを意識する必要がある
- エンジニアチームだけが頑張っても駄目 - エコシステム x フルサイクルエンジニアリングが主流へ - とはいえ、規模が大きくなればステークホルダーは沢山いる 引用 : https://techlog.voyagegroup.com/entry/2019/02/04/171325 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ :
リードタイムを3階層にしたことで見えたもの - 結果と考察
( - - )( ) { -- --- - -
--- -- -- ; -- ------ --- ------ --- ------ --- ; Team ミクロ マクロ Layer 1. Pull Request, commitから生産性の健全性を可視化 Layer 2. Cumulative flow, Control Chart における チーム全体の生産性 Layer 3. All LeadTime 仮説が出てからユーザー価値が届くまでの全体リードタイム Stakeholder Member End-user アプローチ : リードタイムを3階層にしたことで見えたもの
( - - )( ) { -- --- - -
--- -- -- ; -- ------ --- ------ --- ------ --- ; Team Layer 1. pull request, commit, comment Layer 2. Velocity Tracking, Cumulative flow, Control Chart Layer 3. All LeadTime Stakeholde r Member End-user 既存ツールを利用することで、集計・運用コスト削減 アプローチ : リードタイムを3階層にしたことで見えたもの
Layer 1. ソースコードレベルでの可視化 メトリクス設計思想 - Ph.1 : GitHub → Google
Data Studio - Ph.2 : Findy Teams(現在) Ex. • 平均プルリクエストのマージ時間 • 特定期間中のプルリクエストの作成数 • プルリクエスト作成からレビューまでの平均時間 • プルリクストへの平均コメント数 presented by @moriiimo
Layer 2.開発フレームワークに合わせたリードタイムの可視化 メトリクス設計思想 - 開発フレームワーク = アジャイル開発を行っていることを前提にした、スクラム やXPといった枠済み - イテレーション(スクラムでいうスプリント)といった一定の間隔で、メトリクスを
仕込み計測していく - 具体的に使うメトリクスは Cumulative flow、Control Chartの2つとした - Control Chart・・・特定の時系列のローリング平均と標準偏差を使った完了時 間の予測。サイクルタイムとリードタイムの 時間を提供します - Cumulative flow・・・累積フロー図。時間ごとのレーンの移動時間 引用 : https://help.zenhub.com/support/solutions/articles/43000300345
Layer 3.プロダクト開発全体のリードタイムの可視化 メトリクス設計思想 - ユーザーに価値を届けるには、成果物を開発すれば終わりというプロセスは 少ない - 成果物の合意を取るためにミーティングを行ったり、スクラム開発を 1週間で 行っていれば,
週1日は次のスプリント計画や振り返りなどで開発する時間は なくなる - 本研究では初手として開発している時間と開発以外の時間を有効稼働率とし て計測して可視化することを目指した - 「今日1日、何にどのぐらいの工数をかけたか」をタスクコードをもとに勤怠と工 数を紐付けて入力してもらっている (こちらは本研究ではなく、 DMM.comとして全体での取り組み) a. 有効稼働 (ア) 開発比率(%) ① 要件定義比率(%) ② 設計作業比率(%) ③ 開発作業比率(%) ④ テスト作業比率(%) (イ) 保守・運用比率(%) (ウ) プロジェクト管理比率(%) b. 開発外比率(%)(非有効稼働)
Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ :
リードタイムを3階層にしたことで見えたもの - 結果と考察
結果と考察 : Layer 1. ソースコードレベルでの可視化 Ex.「平均マージ時間」 前提 : トランクベース開発などプルリクの単位を小さくしてブランチの生存時間を短くする方式であること 横軸で日付、縦軸でマージまでの時間
(Hour) 各技術領域でグルーピング - 縦軸の高さが全体的に低いこと - 縦軸の波が落ち着いていること
結果と考察 : Layer 1. ソースコードレベルでの可視化 Ex.「平均マージ時間」 前提 : トランクベース開発などプルリクの単位を小さくしてブランチの生存時間を短くする方式であること 横軸で日付、縦軸でマージまでの時間
(Hour) 各技術領域でグルーピング - 縦軸の高さが全体的に低いこと - 縦軸の波が落ち着いていること - 「API」と「iOS」「Android」では、月平均のマージ時間が全体を通して 524時間の差があった - こうした課題に対して静的解析ツールを導入してソースコードのレビュー時間を短くしたり、チームとして優先的 にレビューを促進することで約 100時間マイナスされた例もある - そうなるとユーザーの価値提供が 100時間(約4日間)早くなるということである - 仮にその機能が1日100万円の売上を上げるものであれば、 400万円の収益増の効果があると想定される
Layer 1. ソースコードレベルでの可視化
結果と考察 : Layer 2.開発フレームワークに合わせたリードタイムの可視化 前提 - 開発のフローとしてSprintBacklog→ Doing → Review/QA
→ Closedといっ たパイプラインのレーン設計があったときに、どのぐらいのサイクルで回ってい るかを可視化できる - 例えば,1週間のイテレーションで開発しているチームであれば ,SprintBacklog に置かれたIssue郡は1週間かけてClosedまで行くのが正しいため、ローリン グ平均は7.0 daysとなるはずである CycleTime : 1week(7.0days)
Sprint Backlog→ Doing → Review/QA → Closed - ローリング平均 :
8.2days - 所感 : 8.2daysでサイクルしていることを考えると 1週間を 過ぎているので何かしら課題を抱えていることがわかる . Doing → Review/QA - ローリング平均 : 2.5days - 所感 : 作業を開始 (Doing)してから2.5daysで実装が完 了し多くはコードレビューへ依頼が行われているため 開発速度自体に課題はなさそうに見える Review/QA → Closed - ローリング平均 : 3.6days - 所感 : いわゆるレビュー中になってから Closeするま でに3.6daysかかっている .チームの内情にもよるが、 ここの改善幅は大きそうと見る。 分解 結果と考察 : Layer 2.開発フレームワークに合わせたリードタイムの可視化 8.2days 2.5days 3.6days
結果と考察 : Layer 3.プロダクト開発全体のリードタイムの可視化 プロジェクトA プロジェクトA 傾向 - 直近10ヶ月の有効稼働率を示したもの -
上段の部分を見ると ,大きく分けて開発比率が 61% - 開発街比率(非有効稼働率)は 19.2% - 一報、中段の雇用区分別に見ると社員は 55%〜67%の間 となっている - 約4割近くは開発以外の作業をしているため、ここは改善 できそうに思える - 下段は特定プロジェクトの開発工程別の時間である - プロジェクトの特性における傾向が分かれば良い - 例えば決済基盤といった冪等性が必要でセキュアな要件 では設計に大きな時間( 760h)がかかるといった具合であ る - これを次に同じようなプロジェクトが来たときの参考にもな る.
まとめ 「Layerごとの関係性と当事者意識」 - 細かくトラッキングすればするほど、詳細なデータがでてくる - Layerが1→3と深くなればなるほど抽象度が上がってくるが、実は一本の線で繋がっている。それぞれが影響しあっている - どうしても組織の中で役割が違ったり職種が違うとセクショナリズムで階層化してくる。 - たとえば営業は「開発プロセスは自分には関係ない」といった思考になりがちだが、営業先のクライアントの要求吸い上げ
→要求定義→要件定義→開発→リリー スと考えれば、点ではなく線で考えられる。 - 開発チームへの要求の伝え方、伝えるタイミングひとつでプロダクト開発のリードタイムは変わってくる。逆も然り 「発展」 - 最後に本研究のこれからの課題については、 Layer 3の部分をより細かく柔軟にビジュアライズしていきたい - エンジニアやデザイナーといった成果物を作るにあたって近くにいるメンバーについてはコミュニケーションを蜜に取りながら改善はしやすい - 一方、リードタイムの多くは、そこから外れたステークホルダーとの合意や調整で大きな時間をかけていることが多い - そのため、本研究では有効稼働率といった側面でしか可視化していないが、実際に VSM(Value Stream Mapping)などのソリューションを使いながらプロダクト 開発における仮説検証の開始と終わりをきちんと定量的 &自動化して可視化していきたいと考えている
ご清聴ありがとうございました