うちは特殊だから、と距離を取ってきた利用可能なインクリメントとちゃんと向き合ったら成長できたチームの話

うちは特殊だから、と距離を取ってきた 利用可能なインクリメントと ちゃんと向き合ったら成長できた チームの話 株式会社カオナビ 髙橋 朝人 © kaonavi, inc.

自己紹介 ● 名前：髙橋 朝人（asato） ● ロール：スクラムマスター || プロダクトオーナー ● 好き：アジャイル開発、プロダクト開発、温泉、謎解き・クイズ ● 苦手：はじめまして、大人数、あんこ、うなぎ @at_946 © kaonavi, inc. 2

• https://kaonavi.slack.com/archives/C03A3PK3SKD

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

チーム紹介 ● Feature：人材配置 ● Framework：LeSS（2 teams） ○ PO & SM：It’s me!! It’s anti-pattern!! ○ Designer：1 ○ Engineer：8 ○ QA Engineer：3 © kaonavi, inc. 4

今回のセッションのテーマは 「利用可能なインクリメント」です。 © kaonavi, inc. 5

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

• https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

でもうちは特殊だから距離を置いた ● ● でもうちは特殊だから、 ○ 頻繁なリリースが顧客の不利益になる場合もあるし（マニュアル、周知、問い合わせ、...） ○ 大きなリリースの方が顧客に伝えやすいしインパクトもあるし ○ コアなデータを扱う開発は元々規模が大きくなるし リリース時（Nスプリント後）に「利用可能なインクリメント」ならOK！ © kaonavi, inc. 7

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

• https://hatenanews.com/articles/2023/06/27/103000

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

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

利用可能は全顧客リリースだけじゃない もしかすると自分たちも 利用可能なインクリメントに 向き合うことで成長できるかも © kaonavi, inc. 11

ということで 約半年向き合ってきた課題や取り組みを 共有したいと思います！ © kaonavi, inc. 12

【課題】 今まで大きなリリース単位でしか 開発をしてきていないので 急に小さな利用可能を定義できない

【取り組み】ユーザーストーリーマッピングとエピック ● ユーザーストーリーマッピング ○ ユーザーの体験・物語をベースにユーザーストーリーを整理し、 全体像を可視化するアクティビティ、またはその成果物 バックボーン エピック１ （利用可能） ユーザーストーリーマッピング エピック２ （利用可能） リリース エピック３ （利用可能） © kaonavi, inc. 14

• https://www.amazon.co.jp/ユーザーストーリーマッピング-Jeff-Patton/dp/4873117321

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

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

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

• https://less.works/jp/less/framework/definition-of-done

【課題】 Undone work 多すぎ！

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

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

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

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

We are hiring!! https://corp.kaonavi.jp/recruit/list/ © kaonavi, inc. 23

• https://corp.kaonavi.jp/recruit/list/