Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
650
【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 / 石垣雅人
【5分】始める前に失敗する ── fail fast(早く失敗)ではなくfail before(事前検死) ──
i35_267
1
26
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
4
1.8k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
26
19k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
8
2.6k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
68
25k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.5k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.5k
内製化で強化させる、事業のスケーラビリティーとエンジニアの成長戦略 / insourcing
i35_267
2
360
見積もりをしない。
i35_267
4
1.2k
Other Decks in Technology
See All in Technology
Microsoft Ignite 2024 Update 1 - AIとIoT関連の最新情報をどこよりも早く!
iotcomjpadmin
0
310
Nutanixにいらっしゃいませ。Moveと仮想マシン移行のポイント紹介
shadowhat
0
250
Oracle Cloud Infrastructure:2024年11月度サービス・アップデート
oracle4engineer
PRO
0
140
深層学習のリペア技術の最新動向と実際 / DNN Repair Techniques for AI Performance Alignment for Safety Requirements
ishikawafyu
0
140
Entra ID の多要素認証(Japan Microsoft 365 コミュニティ カンファレンス 2024 )
murachiakira
0
1.8k
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
230
AWS re:Invent 2024 予選落ちのBedrockアプデをまとめて解説!
minorun365
PRO
2
240
データ共有による新しい価値の創造
iotcomjpadmin
0
310
LY Accessibility Guidelines @fukuoka_a11yconf_前夜祭
lycorptech_jp
PRO
1
140
サービスの拡大に伴うオペレーション課題に立ち向かう / 20241128_cloudsign_pdm
bengo4com
0
770
Amazon ECSとCloud Runの相互理解で広げるクラウドネイティブの景色 / Mutually understanding Amazon ECS and Cloud Run
iselegant
18
2.3k
ONNX推論クレートの比較と実装奮闘記
emergent
0
270
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
28
2k
Teambox: Starting and Learning
jrom
133
8.8k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
It's Worth the Effort
3n
183
27k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Thoughts on Productivity
jonyablonski
67
4.3k
Automating Front-end Workflow
addyosmani
1366
200k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
1
220
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)などのソリューションを使いながらプロダクト 開発における仮説検証の開始と終わりをきちんと定量的 &自動化して可視化していきたいと考えている
ご清聴ありがとうございました