2024年11月7日 プロダクト開発部　加藤 だいじなこと、に集中するチームでいるために

2 経歴 2020年3月コドモン入社のエンジニア。 今は保護者と先生のコミュニケーションに関わる機能を開発するチー ムに所属中。 写真は愛猫🐱 最近キーボードの▶キーを じり取られました(でも っつ られた) 自己紹介 加藤 尚子（かとう なおこ）

3 INDEX ● 今日のテーマ ● だいじなこと、に集中するチームでいるために ● 差し込みが優先され続けると起こること ● 私たちチームでの取り組み ● 「だいじなこと」と分けて扱う ● 日々チームで優先度判断できる場をつくる ● (長期的にやっていくこと) ● まとめ

今日のテーマ

5 だいじなこと、に集中するチームでいるために ● アジャイルに開発するためには変化へ対応 大事 ● 変化をうま 取り入れな ら常に「だいじな と」を見極めて集中で る 状態を目指している ● 変化にも色々な種類 ある 今回は「差し込み」の対応にフォーカス

6 差し込み 本発表では緊急だ ど重要ではない問題・緊急でも重要でもない問題、を指す 緊急 緊急でない 重要 重要でない 参考：アイゼンハワーマトリクス

7 差し込み 本発表では緊急だ ど重要ではない問題・緊急でも重要でもない問題、を指す 緊急 緊急でない 重要 重要でない す 終わりそうだ ら... やらな ゃい ない ら... と着手した なり ち 参考：アイゼンハワーマトリクス

8 「差し込み」が優先され続けると起こること ● 「だいじな と」に割 る時間 減る ○ ユーザーへの価値提供につな る と ○ 技術的な投資・開発環境の改善活動 ● 開発者 疲弊する → ユーザーにもプラスにならないし、開発者のモチベも下 る

9 そうならないために... チームで「差し込み」と上手く付き合うために工夫してます！ Not 誰 管理者として考える … … マダー? だいじ … だいじ じゃない

私たちチームでの取り組み

11 「だいじなこと」と分けて扱う ● 現時点で最重要なユーザーストーリーとそれ以外で種類分 する ● 差し込みにはイテレーションで対応する上限ptを決める

12 ● 現時点で最重要なユーザーストーリーとそれ以外で種類分 する ○ それ以外のチケットは「差し込み」と呼んで扱いを変えている 「だいじなこと」と分けて扱う ※画像はチームのBacklog管理に使っているMiro

13 「だいじなこと」と分けて扱う ● 差し込みにはイテレーションで対応する上限ptを決める ○ 1イテレーションで差し込みに使うのは3ptまで ○ 上限を超えないように、着手時期の期待値調整・よりミニマムな解決 策を考える・誰 の力を借りられない を考える...etc

14 日々チームで優先度判断できる場をつくる ● 優先度未判断ゾーン・デイリーリファインメント

15 ● 優先度未判断ゾーン・デイリーリファインメント ○ チームに依頼された と・やる必要 ありそうな とをまずは「優先 度未判断ゾーン」に置 運用 ○ 毎日のデイリーの後に見積もり・優先度判断をする(5分程度) 日々チームで優先度判断できる場をつくる

16 日々チームで優先度判断できる場をつくる ● 優先度未判断ゾーン・デイリーリファインメント ○ とりあえず来たものに着手、とならずにどの らい大事 ・いつやる べ をチーム全員の目を通して判断で る ○ 重要度 上 った場合も認識合わせ スムーズ

17 (長期的にやっていくこと) そもそも差し込み自体 減る・あっても対応コストを下 られるようにしたい ● 品質をあ る とで予想外の挙動を減らす ○ リファクタリング ● 回帰的な動作保証を低コストで行う ○ 自動テストの拡充 ● 仕様をシンプルにする ○ バグの温床になる不必要に複雑な仕様の見直し ● 潜在リスクに早めに づ ○ 監視 差し込みだけじゃなくて、重要な変化への柔軟な対応への備えでもある

まとめ

19 変化を適切にハンドリング、だいじなことに集中できるチームに🔥 「だいじなこと」 と分けて扱う 日々チームで優先 度判断できる場を つくる 長期的な改善活動

No content