168 Views
February 28, 25
スライド概要
ツクリンクで実践しているチケット分割についてになります!こちらで開発生産性を上げれるよう取り組んでます!
ウチのタスク分割術! 〜 チケット粒度の細分化で実現する開発効率向上〜 #つくてくトーク ツクリンク株式会社 ⼋尾 (@Tomoki____Y)
⾃⼰紹介 ● 名前 ○ ⼋尾(@Tomoki____Y) ● ● ツクリンク株式会社 アソシエイトエンジニアリングマネージャー 経歴 ○ 2018年 異業種からエンジニアへ転⾝ ○ 2022年 ツクリンク⼊社 ○ エンジニアとして転⾝してから、ずっとメインはRailsを使⽤している ○ EMとして役割を変更してからはまだ1年⽣ 🐣
アジェンダ 1. タスク分割とは? 2. なぜタスク分割に着⽬したか 3. チケット粒度を細かくする理由と効果 4. タスク分割の具体的⼿法 5. 気を付けなければいけないポイント 6. (参考)弊社での改善事例 7. まとめ
タスク分割とは 本スライドでお話する「タスク分割」は、 1つの開発機能を 「複数の⼩さなチケット」に分割する作業としお話します ▼ 弊社では 弊社ではJiraを利⽤しており、スプリント前のバックログリファインメント時に 「この機能 を具体的にどんな作業に分解できるか」を検討し、 「1つの意図や⽬的」ごとの細かいチ ケットを作成しています。
なぜタスク分割に着⽬したか ▼ 弊社の課題 ‧Four Keysを定量的な数値を確認すると変更のリードタイムが⻑かった ‧1つのPRの変更⾏数が多く、1回のレビューでは⾒逃す場⾯が多々あった ‧PRが作成された段階での軌道修正が発⽣してしまう事があった ▶ 分割を始めたきっかけ → 上記の課題解決を⾏う為にタスク分割に⽬をつけ取り組み始めた ▶ 期待効果 ‧実装範囲を狭める事による、実装‧レビューのスピード向上 ‧レビューに対する⼼理的負担低減 ‧早期の軌道修正
チケット粒度を細かくする理由と効果 1. 複雑度の低減 チケットを⼩さくすることで、開発‧レビューで注⽬する範囲が狭くなり分かりやすい 2. レビューコストの削減 ⼩規模な変更なら、レビューの⼼理的ハードルが下がりスピードも向上 3. 品質向上 ⼩さい単位の変更は抜け漏れを防ぎやすくバグ検知もしやすい 4. 早期軌道修正 万が⼀⽅向性が合わなくても、⼩さなうちに修正可能
タスク分割の具体的⼿法 ▼ 基準1: 「1つの意図(⽬的)ごとに分割を⾏う」 例)ユーザー登録機能 - 登録フォームのUI実装 ⼊⼒内容のバリデーション実装 データベースへの保存処理実装 ...など ▼ 基準2: 「1⽇で実装‧レビューが終わる範囲」 意図ごとに分割するのが難しい場合や意図ごとに分割しても⼤きくなりすぎるという場合は、 もう1つの分割基準として考えてます。 ▼ 補⾜ 必要以上に分割しすぎないことに注意も必要!
気を付けなければいけないポイント 1. 分割に時間がかかりすぎるリスク チケットを分割するという作業はノーコストで⾏えるものではなく、時間はかかります。 「チケット分割」そのものが⽬的化してしまい、本来のゴールである「機能をユーザーに届 けること」が後回しになってしまわないよう注意が必要です。 2. 過度なチケット化で管理が煩雑に 過度にチケット分割を⾏うと単純にチケット量が増えるので、チケット管理オーバーヘッド が増える可能性があります。チームの規模‧実装内容に応じて適切な粒度を⾒極めることが 重要です。
(参考)弊社における改善事例 ▼ リードタイムの短縮 チケット分割を意識する前の1年半程度前と直近を⽐較するPRマージまでは80%削減 ▼ 1年半前 ▼ 直近 参考: 開発⽣産性改善についてまとめた記事
(参考)弊社における改善事例2 ▼ レビュー負荷の軽減 以前はPRが溜まっているという様な状況が頻繁に⾒えておりましたが、 それが⼩さい単位になることでレビュワーの腰も軽くなり、テンポよくマージされていき 直近はPRが溜まるという状況はあまり⾒受けられないです。 ▼ 社内の声 「レビューをする事への⼼理的なハードルが少なくなった」 「レビュー対象が局所的なので修正への対応が⾏いやすくなった」 「テンポよく実装が⾏えている」
まとめ ⬛ チケット粒度を細かくすることで - 開発/レビューの⼼理的ハードルを下げ 複雑度を軽減しつつ リードタイム短縮と品質向上を⽬指すことができる! ⬛ ただし、分割しすぎにはコストがかかるので注意が必要 - 弊社では、「1つの意図ごと」、「1⽇で実装‧レビューが終わる」を基準に分割をし ている 開発プロジェクトやチームの規模に応じて適切な分割を意識する ⬛ ご意⾒‧ご質問⼤歓迎です!!
ご清聴ありがとうございました! #つくてくトーク