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
210
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
7
940
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
8
20k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.1k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
3
270
【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.8k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.5k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.6k
Other Decks in Technology
See All in Technology
スマートファクトリーの第一歩 〜AWSマネージドサービスで 実現する予知保全と生成AI活用まで
ganota
2
320
Apache Spark もくもく会
taka_aki
0
140
Snowflake×dbtを用いたテレシーのデータ基盤のこれまでとこれから
sagara
0
120
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
190
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.5k
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
260
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
120
S3アクセス制御の設計ポイント
tommy0124
3
200
DroidKaigi 2025 Androidエンジニアとしてのキャリア
mhidaka
2
380
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
1.1k
バイブスに「型」を!Kent Beckに学ぶ、AI時代のテスト駆動開発
amixedcolor
2
580
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
How to Ace a Technical Interview
jacobian
279
23k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Practical Orchestrator
shlominoach
190
11k
The Language of Interfaces
destraynor
161
25k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
KATA
mclloyd
32
14k
Speed Design
sergeychernyshev
32
1.1k
Site-Speed That Sticks
csswizardry
10
820
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)などのソリューションを使いながらプロダクト 開発における仮説検証の開始と終わりをきちんと定量的 &自動化して可視化していきたいと考えている
ご清聴ありがとうございました