【SQiP】アジャイル開発の生産性 / What is agile development productivity?

2022/09/09 ソフトウェア品質シンポジウム 2022 登壇資料

Transcript

1. アジャイル開発の生産性とは 〜リードタイムのメトリクスを 3階層に分けることで見えた生産性の指標〜 What is agile development productivity? ~ Productivity indicators seen when lead time metrics are divided into three layers ~ ソフトウェア品質シンポジウム 2022 合同会社 DMM.com 石垣 雅人（Masato Ishigaki）
2. About me 石垣 雅人 - Masato Ishigaki ・プラットフォーム事業本部 第1開発部 部長 ・VPoE室 略歴 ・DMM.com エンジニア 新卒入社 ・2020年より、総合トップ開発部 部長 / DMMポイントクラブ 事業責任者 ・2022年より、現職 著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版 ,2020） 著 : 『DMM PointClub TechBook』（技術書典, 2022） 連載中 : 『スモールチームが武器になる時代へ』（ ProductZine）
3. Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ : リードタイムを3階層にしたことで見えたもの - 結果と考察 - Target - アジャイル開発、プロダクト開発をしている方、事業責任者の方
4. Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ : リードタイムを3階層にしたことで見えたもの - 結果と考察
5. Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ : リードタイムを3階層にしたことで見えたもの - 結果と考察
6. 近年のソフトウェア開発の傾向 = コモディティー化 → XaaS - 新しい技術が登場し続ける、ソフトウェアの世界。 - Ex. コンテナ技術、k8s、Maschine Learning、NFT - 魅力的な技術であれば、沢山のプラクティスが出てくる。 - X as a Serviceやエコシステムとして、サービス提供される。 - 昔は苦労して皆が実装していたものが、平等に利用可能な「武器」になる - 技術は常に進化して、コモディティー化する - 代表的な例として、クラウドサービスがある - すると、開発速度はスピードアップする 技術競争 価格競争 価値 コモディティ化 技術発展のS字カーブ ユーザーニーズ 引用 : https://muchinare.com/archives/13693034.html 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
7. 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
8. 市場への投入タイミングの激化と開発組織の変化 - 市場に対して、追従スピードが求められる環境が加速 - XaaS / エコシステムよって開発は楽になっているはずがリードタイムはあまり変わっ ていないように思える - 組織全体でリードタイムを意識する必要がある - エンジニアチームだけが頑張っても駄目 - エコシステム x フルサイクルエンジニアリングが主流へ - とはいえ、規模が大きくなればステークホルダーは沢山いる 引用 : https://techlog.voyagegroup.com/entry/2019/02/04/171325 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮
9. Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ : リードタイムを3階層にしたことで見えたもの - 結果と考察
10. （ - - ）( ) { -- --- - - --- -- -- ; -- ------ --- ------ --- ------ --- ; Team ミクロ マクロ Layer 1.
 Pull Request, commitから生産性の健全性を可視化 
 
 Layer 2.
 Cumulative flow, Control Chart における チーム全体の生産性 
 Layer 3.
 All LeadTime
 仮説が出てからユーザー価値が届くまでの全体リードタイム 
 Stakeholder Member End-user アプローチ : リードタイムを3階層にしたことで見えたもの
11. （ - - ）( ) { -- --- - - --- -- -- ; -- ------ --- ------ --- ------ --- ; 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階層にしたことで見えたもの
12. Layer 1. ソースコードレベルでの可視化 メトリクス設計思想 - Ph.1 : GitHub → Google Data Studio - Ph.2 : Findy Teams（現在） Ex. • 平均プルリクエストのマージ時間 • 特定期間中のプルリクエストの作成数 • プルリクエスト作成からレビューまでの平均時間 • プルリクストへの平均コメント数 presented by @moriiimo
13. Layer 2.開発フレームワークに合わせたリードタイムの可視化 メトリクス設計思想 - 開発フレームワーク = アジャイル開発を行っていることを前提にした、スクラム やXPといった枠済み - イテレーション（スクラムでいうスプリント）といった一定の間隔で、メトリクスを 仕込み計測していく - 具体的に使うメトリクスは Cumulative flow、Control Chartの2つとした - Control Chart・・・特定の時系列のローリング平均と標準偏差を使った完了時 間の予測。サイクルタイムとリードタイムの 時間を提供します - Cumulative flow・・・累積フロー図。時間ごとのレーンの移動時間 引用 : https://help.zenhub.com/support/solutions/articles/43000300345
14. Layer 3.プロダクト開発全体のリードタイムの可視化 メトリクス設計思想 - ユーザーに価値を届けるには、成果物を開発すれば終わりというプロセスは 少ない - 成果物の合意を取るためにミーティングを行ったり、スクラム開発を 1週間で 行っていれば, 週1日は次のスプリント計画や振り返りなどで開発する時間は なくなる - 本研究では初手として開発している時間と開発以外の時間を有効稼働率とし て計測して可視化することを目指した - 「今日1日、何にどのぐらいの工数をかけたか」をタスクコードをもとに勤怠と工 数を紐付けて入力してもらっている （こちらは本研究ではなく、 DMM.comとして全体での取り組み） a. 有効稼働 (ア) 開発比率（%） ① 要件定義比率（%） ② 設計作業比率（%） ③ 開発作業比率（%） ④ テスト作業比率（%） (イ) 保守・運用比率（%） (ウ) プロジェクト管理比率（%） b. 開発外比率（%）（非有効稼働）
15. Outline - Outline - 課題 : ソフトウェア開発を取り巻く環境とリードタイム短縮 - アプローチ : リードタイムを3階層にしたことで見えたもの - 結果と考察
16. 結果と考察 : Layer 1. ソースコードレベルでの可視化 Ex.「平均マージ時間」 前提 : トランクベース開発などプルリクの単位を小さくしてブランチの生存時間を短くする方式であること 横軸で日付、縦軸でマージまでの時間 (Hour) 各技術領域でグルーピング - 縦軸の高さが全体的に低いこと - 縦軸の波が落ち着いていること
17. 結果と考察 : Layer 1. ソースコードレベルでの可視化 Ex.「平均マージ時間」 前提 : トランクベース開発などプルリクの単位を小さくしてブランチの生存時間を短くする方式であること 横軸で日付、縦軸でマージまでの時間 (Hour) 各技術領域でグルーピング - 縦軸の高さが全体的に低いこと - 縦軸の波が落ち着いていること - 「API」と「iOS」「Android」では、月平均のマージ時間が全体を通して 524時間の差があった - こうした課題に対して静的解析ツールを導入してソースコードのレビュー時間を短くしたり、チームとして優先的 にレビューを促進することで約 100時間マイナスされた例もある - そうなるとユーザーの価値提供が 100時間（約4日間）早くなるということである - 仮にその機能が1日100万円の売上を上げるものであれば、 400万円の収益増の効果があると想定される
18. Layer 1. ソースコードレベルでの可視化
19. 結果と考察 : Layer 2.開発フレームワークに合わせたリードタイムの可視化 前提 - 開発のフローとしてSprintBacklog→ Doing → Review/QA → Closedといっ たパイプラインのレーン設計があったときに、どのぐらいのサイクルで回ってい るかを可視化できる - 例えば,1週間のイテレーションで開発しているチームであれば ,SprintBacklog に置かれたIssue郡は1週間かけてClosedまで行くのが正しいため、ローリン グ平均は7.0 daysとなるはずである CycleTime : 1week（7.0days）
20. 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
21. 結果と考察 : Layer 3.プロダクト開発全体のリードタイムの可視化 プロジェクトA プロジェクトA 傾向 - 直近10ヶ月の有効稼働率を示したもの - 上段の部分を見ると ,大きく分けて開発比率が 61% - 開発街比率（非有効稼働率）は 19.2% - 一報、中段の雇用区分別に見ると社員は 55%〜67%の間 となっている - 約4割近くは開発以外の作業をしているため、ここは改善 できそうに思える - 下段は特定プロジェクトの開発工程別の時間である - プロジェクトの特性における傾向が分かれば良い - 例えば決済基盤といった冪等性が必要でセキュアな要件 では設計に大きな時間（ 760h）がかかるといった具合であ る - これを次に同じようなプロジェクトが来たときの参考にもな る.
22. まとめ 「Layerごとの関係性と当事者意識」 - 細かくトラッキングすればするほど、詳細なデータがでてくる - Layerが1→3と深くなればなるほど抽象度が上がってくるが、実は一本の線で繋がっている。それぞれが影響しあっている - どうしても組織の中で役割が違ったり職種が違うとセクショナリズムで階層化してくる。 - たとえば営業は「開発プロセスは自分には関係ない」といった思考になりがちだが、営業先のクライアントの要求吸い上げ →要求定義→要件定義→開発→リリー スと考えれば、点ではなく線で考えられる。 - 開発チームへの要求の伝え方、伝えるタイミングひとつでプロダクト開発のリードタイムは変わってくる。逆も然り 「発展」 - 最後に本研究のこれからの課題については、 Layer 3の部分をより細かく柔軟にビジュアライズしていきたい - エンジニアやデザイナーといった成果物を作るにあたって近くにいるメンバーについてはコミュニケーションを蜜に取りながら改善はしやすい - 一方、リードタイムの多くは、そこから外れたステークホルダーとの合意や調整で大きな時間をかけていることが多い - そのため、本研究では有効稼働率といった側面でしか可視化していないが、実際に VSM（Value Stream Mapping）などのソリューションを使いながらプロダクト 開発における仮説検証の開始と終わりをきちんと定量的 &自動化して可視化していきたいと考えている
23. ご清聴ありがとうございました