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
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
Search
Soh1121
February 20, 2025
Programming
1
190
PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜
Soh1121
February 20, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
1
230
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
260
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
170
SwiftUI Viewの責務分離
elmetal
PRO
1
230
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
110
技術を根付かせる / How to make technology take root
kubode
1
250
Amazon Bedrock Multi Agentsを試してきた
tm2
1
280
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
750
Amazon Q Developer Proで効率化するAPI開発入門
seike460
PRO
0
110
sappoRo.R #12 初心者セッション
kosugitti
0
250
2,500万ユーザーを支えるSREチームの6年間のスクラムのカイゼン
honmarkhunt
6
5.3k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Docker and Python
trallard
44
3.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
KATA
mclloyd
29
14k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Transcript
タスク分解の試行錯誤 〜レビュー負荷を下げるために〜 PHPカンファレンス名古屋 2025(2025/02/22)
2 アジェンダ はじめに レビュー負荷を下げるとは? 01 02 タスク分解の取り組みをご紹介 まとめ 03 04
はじめに 3
5 背景 • Four Keys(※1) を測定し、開発の高速化を目指す ◦ 現状を把握して改善のアクションを起こせるようにする ◦ 2022年12月から運用開始
• スモールスタート ◦ 「変更のリードタイム(※2)」に着目 ◦ 中でもレビューを迅速に行うことを目指してきた ▪ 取り組みやすく、効果があることが分かっているため ▪ 「レビューを迅速に行う」=「レビュー負荷を下げる」 ※1 ソフトウェア開発チームのパフォーマンスを測る4つの指標 ※2 commit から本番環境稼働までの所要時間 「エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ」より
レビュー負荷を 下げるとは? 6
開発スピードと品質の両立がしやすくなり チーム全体の士気と生産性を高めることができる! 7 なぜレビュー負荷を下げるのか? 1. チームの生産性向上 ◦ レビュー時間短縮により付加価値の高い作業へ集中 2. 品質向上につながる迅速なフィードバックループ
◦ 見落としが少なくなりレビュー精度が向上 3. コミュニケーションの活性化 ◦ 「早く終わらせたい」「まとまった時間がないとつらい」だと消極的になりやすい 4. モチベーションの維持 ◦ レビューがつらいとチーム全体のモチベーションが低下 レビュー負荷を 下げると
分解方法をいろいろ試行錯誤してみよう!! よく聞く方法から独自の方法まで! 8 どうすればレビュー負荷が下がるのか? • 1つの方法としてタスクの粒度を小さくするのが有効 どのように 小さくする...?
タスク分解の 取り組みをご紹介 9
10 試行錯誤したタスクの分け方 1. 機能単位 ◦ 1タスク=1機能として実装・レビュー 2. 処理単位 ◦ 1機能を処理ごとにタスク分解して実装・レビュー
3. レイヤー単位 ◦ ドメイン層・アプリケーション層・インフラ層などでタスク分解して実装・レビュー ◦ 今回は処理単位にタスク分解したものを更にレイヤー単位に分解した 4. 補完単位
11 補完単位とは? • 最初にミニマム実装で1タスク ◦ 本番用の正常系のみ ◦ プリミティブしか使わない • その後、不足部分を補完していくかのごとくタスク分解
◦ 例えば ▪ オブジェクトへの置き換え → 1タスク ▪ 本番環境・開発環境での処理の分岐 → 1タスク ▪ 異常系の実装 → 1タスク
12 タスク概要〜機能単位で分ける〜 タスクはすべて非同期処理基盤の構築プロジェクト • 4機能を実装・レビュー 機能概要 言語 実装難易度 設計 実装時期
非同期イベント登録 Go 中 なし 初期 非同期イベント検索(サーバー) Go 高 なし 初期 イベントのステータス更新② Go 低 なし 中期 ファイルアップロード Go 中 あり 後期
13 タスク概要〜処理単位で分ける〜 • 3機能を実装・レビュー(※ 部分的にレイヤー単位に分割 → 集計外) • 計測対象:13タスク 機能概要
タスク数 言語 実装難易度 設計 実装時期 非同期イベント発行(サーバー) 5 Go 中 あり 初期 イベントのステータス更新① 3 Go 中 なし 中期 非同期イベント リトライ※ 5 Go 高 あり 後期
14 タスク概要〜レイヤー単位で分ける〜 • 1機能の一部を実装・レビュー(他は処理単位) • 計測対象:7タスク 機能概要 言語 実装難易度 設計
実装時期 非同期イベントリトライ Go 高 あり 後期
15 タスク概要〜補完単位で分ける〜 • 3機能を実装・レビュー • 計測対象:14タスク 機能概要 タスク数 言語 実装難易度
設計 実装時期 非同期イベント発行(クライアント) 5 PHP 中 あり 中期 非同期イベント検索(クライアント) 5 PHP 中 あり 後期 ファイルアップロード 4 PHP 中 あり 後期
16 今回の計測対象メトリクス 1. 変更行数 ◦ 少ないほどレビュー負荷は低いはず 2. オープンからマージまでの時間 ◦ 短いほどレビュー負荷は低いはず
3. Conversation ◦ 少ないほどレビュー負荷は低いはず ※ 箱ひげ図でデータのばらつきを見える化
17 箱ひげ図とは? 外れ値 最大値・最小値 中央値 第3四分位 第1四分位
18 計測における前提 • レビューは実装者以外のメンバー全員で実施 • CI で静的解析を実施 • 各々レビュー負荷を下げるために事前に PR
にコメントを付与 ◦ Conversation に含まれている • 設計がないタスクはレビューで設計の議論が生じたものがある ◦ Conversation が膨らんでいる • PHP には慣れ親しんでいるが Go には不慣れ... ◦ 実装時期が後ろに行くほど慣れてきている
19 計測結果〜変更行数〜
20 計測結果から得られたこと〜変更行数〜 • 処理単位 ◦ 行数のブレ幅は大きいが、ものによっては「レイヤー単位」や「補完単位」と同程度 ◦ 外れ値が発生しているので、大きく上振れる可能性がある • 「レイヤー単位」と「補完単位」は同程度
◦ 「補完単位」の方が少しだけ大きな変更行数になった ◦ 「補完単位」の方が少ない変更行数になる割合が高い
21 計測結果〜オープンからマージまでの時間〜
22 計測結果から得られたこと〜オープンからマージまでの時間〜 • 処理単位 ◦ 上にも下にも外れ値が発生していて、ブレ幅が大きい ◦ 最小値は「機能単位」の最小値とあまり変わらなかった • 「レイヤー単位」と「補完単位」は同程度
◦ 「レイヤー単位」の方がブレ幅が少ない ◦ 「補完単位」の方が早くレビューが終わることがあった
23 計測結果〜Conversation〜
24 計測結果から得られたこと〜Conversation〜 • 処理単位 ◦ 上に外れ値が発生していて、議論が多いレビューが発生したことが見受けられる ◦ 最小値は「機能単位」の最小値とあまり変わらなかった • 「レイヤー単位」と「補完単位」は同程度
◦ 「レイヤー単位」の方がブレ幅が少ない
まとめ 25
26 ご紹介したこと • レビュー負荷を下げたいモチベーション • レビュー負荷を下げるためにタスク分解の方法 a. 機能単位 b. 処理単位
c. レイヤー単位 d. 補完単位 • タスク分解の方法ごとのレビュー負荷の計測結果 ◦ 変更行数・オープンからマージまでの時間・Conversation
27 試行錯誤の結果 • 分解しないとレビュー負荷はやはり高い!(機能単位) • 「処理単位」はさらなる分解が不要なケースもある ◦ が、多くは分解したほうがレビュー負荷は低くなりそう • 「レイヤー単位」と「補完単位」は同程度
◦ 変更行数は最大500行強程度までおさえられた ◦ タスクの特徴に応じて使い分けられそう
ご清聴 ありがとうございました 〜エンジニア募集中〜