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
690
【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 / 石垣雅人
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1.1k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
4
2.2k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
28
20k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
9
2.7k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
68
26k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.5k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.6k
内製化で強化させる、事業のスケーラビリティーとエンジニアの成長戦略 / insourcing
i35_267
2
400
見積もりをしない。
i35_267
4
1.3k
Other Decks in Technology
See All in Technology
データの品質が低いと何が困るのか
kzykmyzw
6
1.1k
2025-02-21 ゆるSRE勉強会 Enhancing SRE Using AI
yoshiiryo1
1
180
なぜ私は自分が使わないサービスを作るのか? / Why would I create a service that I would not use?
aiandrox
0
700
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.1k
プロセス改善による品質向上事例
tomasagi
2
2.5k
Building Products in the LLM Era
ymatsuwitter
10
5.3k
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
730
MC906491 を見据えた Microsoft Entra Connect アップグレード対応
tamaiyutaro
1
540
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
330
Datadogとともにオブザーバビリティを布教しよう
mego2221
0
140
Developer Summit 2025 [14-D-1] Yuki Hattori
yuhattor
19
6.1k
君も受託系GISエンジニアにならないか
sudataka
2
420
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
133
9.1k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
The Invisible Side of Design
smashingmag
299
50k
Building Your Own Lightsaber
phodgson
104
6.2k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
Adopting Sorbet at Scale
ufuk
74
9.2k
Thoughts on Productivity
jonyablonski
69
4.5k
GraphQLとの向き合い方2022年版
quramy
44
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
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)などのソリューションを使いながらプロダクト 開発における仮説検証の開始と終わりをきちんと定量的 &自動化して可視化していきたいと考えている
ご清聴ありがとうございました