属人化を防ぎ、スプリントゴールを達成するために開発者が始めた取り組み

スクラムガイドで開発者は次のように定義されています。

開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。

開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任を持つ。

スプリントの計画（スプリントバックログ）を作成する。
完成の定義を忠実に守ることにより品質を作り込む。
スプリントゴールに向けて毎⽇計画を適応させる。
専⾨家としてお互いに責任を持つ。
このことからも、開発者は専門性を持ちながらも自身が得意としない領域にも取り組むことが求められます。

それぞれの開発者が専門性を発揮して、得意な領域ばかりを着手するようになっていると、他の開発者からは何をしているか理解できなかったり、スプリントゴールが達成可能であるかの検査も個人依存で機能不全になってしまいます。

私達のチームでも、メンバーの入れ替わりを経験し、

「XXXさんがしているのでわからない」

「順調だったはずが直前でゴール達成が怪しくなる」

など、属人化のリスクを身を以て体験しました。

現在は、属人化を防ぐために行っているいくつかの取り組みが機能しているように感じています。

その取り組みについて共有し、持ち帰ってもらって明日からあなた達のチームで属人化を減らす手助けができればと思います。

Transcript

1. 属人化を防ぎ スプリントゴールを達成するために 開発者が始めた取り組み 2025/10/04 スクラム祭り2025 広島トラック JX 通信社 酒本伸也 @sakebook
2. 自己紹介 酒本伸也 @sakebook 所属 JX 通信社 スクラムマスター モバイルアプリの エンジニア 趣味 コーヒー（飲む方） ボードゲーム（やる方） 1
3. 会社紹介 2
4. 所属してるチームでやってること 気象庁などの情報を用いたtoB やtoC のWeb サービスの 開発・保守や機能追加 気象庁の情報を簡単に扱えるWeb API の開発 データソースの追加やエンドポイント・スキーマの整備 2023 年からのチーム このチームでの経験と変遷をもとにお話しします 3
5. チームについて メンバー 開発者 最大8 名いたときもあった 2025 年3 月から3 名体制 プロダクトオーナー 1 名 スクラムマスター 1 名←私です 環境 スプリントは1 週間 フルリモート プラットフォームチーム 社内のエンジニアが ステークホルダー 4
6. 私たちのチームで起こった 属人化について 5
7. 属人化 その人しかわからない 詳しい人がその人しかいない という状態を今回の発表では属人化と呼びます 6
8. ケース1: タスクの属人化 7
9. デイリースクラムにて スプリントゴールが達成できそうかをお天気マークで表現して サインを出してもらってます 分割しにくい大きめのタスクを1 人が抱えていた ずっと だったが スプリント最終日に になる 順調そうだったのに最後にいきなり終わらなさそうとなる 現在着手しているタスクの進捗を本人しかわからない状態 これを「タスクの属人化」と表現します ケース1: タスクの属人化 8
10. ケース2: ドメイン知識の属人化 9
11. デイリースクラムにて 困ってることがあれば各自共有して 詰まってしまわないようにしています お休みなどでメンバーが不在の時に 「そこはXXX さんじゃないとわからない」 「そのシステムは触ったことがないのでわからない」 ケース2: ドメイン知識の属人化 10
12. メンバーは入れ替わることがある 入れ替わりがあるということは 同じ経験をしていないメンバーがいるということになります 結果的にこの人しか知らないという状態に陥ることがあります これを「ドメイン知識の属人化」と表現します ケース2: ドメイン知識の属人化 11
13. ずっと同じメンバーという保証はない 入れ替わることは起こり得ることなので回避できないです 抜けたり入ったりした時に、属人化が起こらないように 仕組みでカバーできる体制にすることが重要です ケース2: ドメイン知識の属人化 12
14. ケース3: タスク・ドメイン知識の属人化 13
15. スプリントプランニングのトピック3 にて 選択した作業をどのように成し遂げるのか？ 「フロントエンドなのでXXX さんお願いします」 「XXX さんこのあたり得意なのでまたお願いします」 作業領域を閉じてしまってたり短期的な解決速度を優先することで 属人化が加速します これにより「タスク・ドメイン知識ともに属人化」していきます ケース3: タスク・ドメイン知識の属人化 14
16. 属人化が引き起こす諸問題 透明性が失われる 持続的な開発ができない チャレンジができなくなる などなど 透明性のない検査は、誤解を招き、ムダなものである “ “ 15
17. 属人化を防ぐための取り組み 16
18. 属人化を防ぐための取り組み 「計画者」と「実装者」をあえて分ける スプリントをまたいだタスクは別メンバーが引き継ぐ 「自分が作っていない機能」をスプリントレビューで発表する 17
19. 属人化を防ぐための取り組み 「計画者」と「実装者」をあえて分ける スプリントをまたいだタスクは別メンバーが引き継ぐ 「自分が作っていない機能」をスプリントレビューで発表する 18
20. 「計画者」と「実装者」をあえて分ける スプリントプランニングのトピック3 「選択した作業をどのように成し遂げるのか？」 私達はエンジニアで詳細見積もりという枠で行っています 19
21. 詳細見積もりのやり方 1. スプリントに積んだPBI に仮に個人をランダムにアサイン 2. どのように着手して進めるのか各自作業計画を立てる 3. その後、各自作業計画を発表して、疑問点や考慮漏れなどを 皆で洗い出す 4. 最後に仮のアサインを外し、アサインし直す すべてのアサインを決めることはせず、デイリースクラムで 調整する 詳細見積もりではコードも見つつ、関数や何行目という粒度まで 話し合います 「計画者」と「実装者」をあえて分ける 20
22. 詳細見積もりの効果 課題に対して皆が同じ理解で着手できる 思い違いや考慮漏れをお互い補完できる 人に説明する練習になる 課題の進め方についても考えられる この作業は他のリリースに影響するので 別途ブランチを切ったほうがいい 不確実性が高いのでペアで進めたほうがいい 依存関係があるのでいついつまでに終わってないと スプリントゴール達成に影響しそう 「計画者」と「実装者」をあえて分ける 21
23. 詳細見積もりをうまくやるコツ 時間をきちんと確保する トピック3 だけで2 時間確保してます 否定から入るコミュニケーションは避ける 違うとなる場合、前提が違ってたり考慮漏れがあると思うので その確認をしましょう チーム内に上下関係がなかったからうまく行った側面もある もしもテックリードなどがいる場合 他の人の出番を奪わないように意識してもらう 「計画者」と「実装者」をあえて分ける 22
24. 属人化を防ぐための取り組み 「計画者」と「実装者」をあえて分ける スプリントをまたいだタスクは別メンバーが引き継ぐ 「自分が作っていない機能」をスプリントレビューで発表する 23
25. スプリントをまたいだタスクは別メンバーが 引き継ぐ こちらも詳細見積もりでの取り組みです 前回のスプリントの残りがあったときには、着手していた人に 作業計画を共有してもらいます アサインを検討するときには、着手していた人以外が 行うようにしています 24
26. 効果 複数の視点で見れ、解決しなかった問題が解決する場合が あります 1 人で詰まっててスプリントをまたぐケースもあります 仕組みとして取り入れることで 引き継ぎは悪いものではないという共通認識にします 残りがあったときは、スプリント中におかわりして追加したもので あることが多い バトンタッチすることで、1 人しか知らない状況を防げます スプリントをまたいだタスクは別メンバーが引き継ぐ 25
27. 属人化を防ぐための取り組み 「計画者」と「実装者」をあえて分ける スプリントをまたいだタスクは別メンバーが引き継ぐ 「自分が作っていない機能」をスプリントレビューで発表する 26
28. 「自分が作っていない機能」をスプリント レビューで発表する スプリントレビューのための準備の時間を用意 スプリントレビュー準備という枠を設けて行なっています 27
29. スプリントレビュー準備 インクリメントの整理 スプリントゴールとスプリントプランニングのときに 話した内容を照らし合わせて相談します 共有する内容の大筋と発表者を決める その内容にあまり関わっていなかった人に発表してもらうように しています スプリントゴール達成に向けて取り組んでいるので 関わっていないことはないですが 提示するインクリメントに対してという意味合いです プロダクトゴールに近づくために必要なことを話す 「自分が作っていない機能」をスプリントレビューで発表する 28
30. 効果 スプリント内で何に取り組んでいたのかの理解を底上げする 作ったけどなんの課題解決につながってるのかわからない というのを防ぎます 皆でやってる意識が持てる ドメイン知識も身についていく コードレビューなどでも見てるはずの内容を 自身が共有する立場で再確認できるので深い理解につながります 「自分が作っていない機能」をスプリントレビューで発表する 29
31. 取り組みの始まり方 30
32. いきなり上手くいったわけではない やってみたけど定着しなかったこともある チームメンバーやタイミング、会社の状況などによっても 変わってきます これらの取り組みも改善を繰り返していって今の形に 落ち着いていきました 31
33. 取り組みの始まり方 メンバーの問題意識が重要 やらされるのではなく、自分たちがやる必要があると思って 取り組むことが大事です 問題について話す場はスプリントレトロスペクティブがある 私たちのチームでの取り組みも、スプリントレトロスペクティブ をやる中で生まれました。 スプリントレトロスペクティブの⽬的は、品質と効果を⾼め る⽅法を計画すること “ “ 32
34. 問題を表面化させるための工夫 手法を固定しない ファシリテーターを持ち回りにし、スプリント終盤で 手法を選択しています 手法によって話の出やすさや話の切り口は異なるので いつもと異なる手法を採用してみるというのは効果的です 1on1 での問いかけ 課題に思っていることや、やりたいけどできていないことなどを 掘り下げてスプリントレトロスペクティブの場に 出せるようにします 33
35. まとめ 34
36. まとめ 属人化には2 種類 現在着手しているタスクの進捗 ドメイン知識 私たちのチームで行なった取り組み 「計画者」と「実装者」をあえて分ける スプリントをまたいだタスクは別メンバーが引き継ぐ 「自分が作っていない機能」をスプリントレビューで発表する 35
37. まとめ 属人化を防ぐ取り組みはやらされるものではない 問題意識が重要 問題について話す場はスプリントレトロスペクティブ 問題意識の醸成には別の観点からのアプローチや 個別の掘り下げが有効 36
38. 以上
39. ご清聴ありがとうございました