利用可能なインクリメントとちゃんと向き合ったら成長できた / The story that a team was confronted with the available increment

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

タレントマネジメントシステム「カオナビ」社員の個性・才能を発掘し戦略人事を加速させるタレントマネジメントシステム © kaonavi, inc. 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© kaonavi, inc. ● “ 開発者はスクラムチームの一員である。各スプリントにおいて、利用可能なインクリメントのあらゆる側面を作成することを確約する。 ”   ● “ 価値を提供するには、インクリメントを利用可能にしなければならない。 ”   by スクラムガイド    ● 「利用可能とは何か」については言及されていない     ● チームの解釈  ○ 利用可能 = 全顧客にリリースできる状態   利用可能なインクリメントとは   6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© kaonavi, inc. 【転機】FeatureToggles がやってきた   8 ● (Feature|Release)(Toggles|Flags)   ○ 顧客に機能解放するかどうかを制御する仕組み   ○ カオナビでは顧客単位で制御可能     ● 導入目的：ビッグバンリリースの回避   ○ リリースとデプロイを分離しデプロイ頻度を増やす   ○ 祈りのリリース回避（影響範囲が大きくなりやすい）   ○ 不具合の対応範囲の特定しやすく   ○ 大量のコンフリクトの回避   https://hatenanews.com/articles/2023/06/27/103000

Slide 9

Slide 9 text

© kaonavi, inc. 9 FeatureTogglesを活用すれば、新しいフィードバックループをつくれるのでは！？   ● ドッグフーディング 🐶  ○ 自社の人事メンバーに通常業務で使ってもらう   ○ 人事メンバーからのフィードバックをGet !!     ● Salesデモ 🤝  ○ Salesメンバーに提案時のデモで使ってもらう   ○ Salesメンバー & 見込み顧客からのフィードバックをGet !!     ● CSデモ ❤  ○ Successメンバーに既存顧客への新規機能紹介で使ってもらう   ○ Successメンバー & 既存顧客からフィードバックをGet !!    

Slide 10

Slide 10 text

© kaonavi, inc. 10 【気づき】利用可能の利用シーンはひとつじゃない   ● ドッグフーディング 🐶  ○ 自社の人事メンバーに通常業務で使ってもらう  ○ 人事メンバーからのフィードバックをGet !!     ● Salesデモ 🤝  ○ Salesメンバーに提案時のデモで使ってもらう  ○ Salesメンバー & 見込み顧客からのフィードバックをGet !!     ● CSデモ ❤  ○ Successメンバーに既存顧客への新規機能紹介で使ってもらう  ○ Successメンバー & 既存顧客からフィードバックをGet !!    

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

【課題】  今まで大きなリリース単位でしか  開発をしてきていないので  小さなデプロイ単位を定義できない 

Slide 14

Slide 14 text

Slide 15

Slide 15 text

【課題】  顧客リリースでないリリースは  何が終わっていればリリースできるか  わかってない 

Slide 16

Slide 16 text

【方針】  誰かが突然Toggle ONにしても  大丈夫って言える状態 

Slide 17

Slide 17 text

© kaonavi, inc. 17 【取り組み】エピック単位のUndone workの可視化   ● Undone work とは？   ○ “ Doneの定義と潜在的に出荷可能の間にある差分 ” by Done の定義 - Large Scale Scrum (LeSS)  ○ 完成の定義には含まれないが、リリースまでには完了させる必要のあるタスク     ● やったこと  ○ Undone workリストを作成   ○ エピック単位でUndone workリストから取り組むものをリファインメント   ○ Undone workをエピックの計画づくりに組み込み  

Slide 18

Slide 18 text

【課題】  Undone work 多すぎ！ 

Slide 19

Slide 19 text

© kaonavi, inc. 19 Undone workが多すぎる…   ● 状況  ○ Undone workを可視化した結果、undone workだけで2, 3スプリント必要なことが判明     ● 例えば  ○ i18n対応  ○ ストーリーのE2Eテスト   ○ リグレッションテスト  ○ パフォーマンステスト   ○ 補助ドキュメントの作成   ○ リリース手順・切り戻し手順の作成   ○ … 

Slide 20

Slide 20 text

© kaonavi, inc. 20 【取り組み】Undone workの完成の定義化 or 早期着手化   ● i18n対応 👍  ○ スプリント内で対応したい＆できるものだったので完成の定義へ  ● ストーリーのE2Eテスト 👍  ○ 開発プロセスの見直しと職能にこだわらない行動でスプリント内で対応できるように改善し完成の定義へ  ● リグレッションテスト  ○ playwrightの活用などを検討中   ● パフォーマンステスト   ○ スプリント中から大量データで動作をさせてみるなどし予兆を検知するように   ● 補助ドキュメントの作成 👍  ○ 一部スプリント内で対応したい＆できるものだったので完成の定義へ  ● リリース手順・切り戻し手順の作成   ○ リリース直前の実施が効果的・効率的なのでUndone workのまま  

Slide 21

Slide 21 text

こうしてぼくたちは  エピック単位に  利用可能なインクリメントを  つくれるようになった    新しいフィードバックが生まれた  チームは成長した 

Slide 22

Slide 22 text

© kaonavi, inc. 22 まとめ  ● 利用可能なインクリメントに向き合うことでチームとしてもう1段階成長できた   ○ ユーザーストーリーマッピングとエピック   ○ Undone workの可視化   ○ Undone workの完成の定義化 & 早期着手   ○ （エピック見積もりで早くより遠くを見通す）   ○ （LeSSのブランチ戦略）   ○ （スプリントゴールでスプリントに集中）   ○ （スプリントゴールでデイリースクラムが活性化）   ○ （チーム合同モブプログラミング）   ○ （防災訓練（障害対応の練習））   今回の発表内容以外にも色々な変化がありました！ 🎉