ソフトウェア開発のスクラムにおけるストーリー分割のコツについて。

1. チームの目標への柔軟な対応
吉村総一郎 (@sifue)

2. 1つのプロダクトをチームで
開発するって本当に難しい

3. 個人でやる開発って本当に楽
(例:趣味開発、一人プロダクト、カーボーイ開発)

4. なんで？

5. 全員が同じ目的、目標に
向かわなくてはいけない。
これがすっごくコストが高い。
(アジャイルサムライという本の中ではみんなをバスに載せると言ったりします)

6. チーム開発をしっかりやるならちゃんとコ
ミュニケーションコストをかける覚悟が必要

7. ここで質問

8. 今作っている機能を何のためにつくってい
て、どういう目標を持っているか話せる人？

9. 実はこれができないってのは、チーム開発に
おいて致命的にマズイことだったりします
(無駄な機能開発や、無駄に汎化された設計をとかしちゃったりすることも...)

10. そもそも目的、目標ってなんだっけ？

11. 目的・目標の例１
• 目的: コミケでより沢山の同人誌を売って有名になる
• 目標: 今回のコミケで500冊完売

12. 目的・目標の例２
• 目的: 日本における電子書籍市場の拡大とシェアの獲得
• 目標: 下半期電子書籍売り上げ10億円

13. 目的・目標の概念
• 目的 (Purpose, Mission,Aim, etc)
• 目標 (Goal,Target, Milestone, etc)
目的
目標１ 目標２
目的は方向性、目標は期限と数値目標が設定
される

14. ソフトウエアのチーム開発において、
この目標ってすごく決めづらい

15. 例えば
目標: 9/9にとある機能をリリース
と仮に目標設定したとしても、よくあるのが

16. • ソフトウエアの手順書等ドキュメントが一切ない
• 名目上不具合ゼロだが、そもそも不具合発生収束
していない
• 不具合を発生させずに不具合を直すことができな
いほどの技術的負債がある
• リリース日にメイン開発者がほとんど退職する
リリース日に、
こういうことが記憶にある方？

17. •リリースはされたが、毎日障害が起こる
•直す人がいないので不具合が放置される
•そして最初は怒り狂ってたユーザーも、
初期担当開発者も誰もいなくなった
結果、
目標は達成されたが、果たしてこれが目指した姿なのか？

18. 私が望んだのはこんな未来じゃない！

19. なんでこうなった？
リリース日だけを目標するといけないの？

20. 別にそういうことではない

21. ちょっとここで説明、
ソウトウェア開発にはトレードオフな４つの要素がある
(アジャイルサムライという本の中では荒ぶる四天王と呼ばれてる)
時間 予算 品質 スコープ

22. このような問題の場合、
目標設定で軽視されたのはどれだったかというと
品質

23. ソフトウエアは品質を徹底的に下げることで、時間や
予算、スコープを維持することが可能であるが、品質
は一見表面上に出にくい

24. 1. プロセス品質 (開発体制の品質)
2. 内部品質 (ソースコードの品質)
3. 外部品質 (ソフトウェアの機能の品質)
品質には
ことさら１と２は見えにくく、ガタガタになっている場
合がある。特に今回は1と2を完全に見落としている。

25. ではどうすればこうならなかったのか？

26. そこでアジャイルプロジェクトの導入

27. アジャイルプロジェクトは、時間も予算も品質も固
定化して考えて、スコープだけを変更しようとしよ
うとする考えるやり方
時間 予算 品質 スコープ

28. • 品質 :
1. プロセス品質 (開発体制の品質) → チームが満足できる品質
2. 内部品質 (ソースコードの品質) → チームが満足できる品質
3. 外部品質 (機能の品質) → チームが満足できる品質
• 時間 : きっちりスケジュールを守る
• 予算 : 予定した人数と工数を守る
• スコープ : 優先順位の高い要件の本当に本当に必須なものだけを
優先的に、できるところまでやる

29. こうやって解決しよう

30. こういうやり方の有名な方法がスクラム！

31. スクラムでは全ての機能をストーリーとして必ずひとつ
ひとつリリースして、ユーザーに届く価値にしていきます
（無論、本番環境ではなくて裏投入やショーケース環境にリリースするのもあり。
ユーザーも自分以外のステークホルダーを許可するとやりやすくなります。）

32. 普通のやり方だと
管理ツールにおける管理ツールユーザーの権限機能 20人日

33. スクラムだと
1 管理ツールユーザーが、所有する権限で機能の利用が承認されるようになる 5pt
2 管理ツールユーザーが、Web上でユーザーの権限を確認することができる 3pt
3 管理ツールユーザーが、Web上で権限をユーザーに割り当てることができる 5pt
4 管理ツールユーザーが、Web上で権限をユーザーに追加することができる 5pt
5 管理ツールユーザーが、Web上で権限をユーザーに削除することができる 3pt
6 管理ツールユーザーが、Web上で権限をユーザーに編集することができる 5pt
こんな風に分割します

34. 1 管理ツールユーザーが、所有する権限で機能の利用が承認されるようになる 5pt
2 管理ツールユーザーが、Web上でユーザーの権限を確認することができる 3pt
3 管理ツールユーザーが、Web上で権限をユーザーに割り当てることができる 5pt
4 管理ツールユーザーが、Web上で権限をユーザーに追加することができる 5pt
5 管理ツールユーザーが、Web上で権限をユーザーに削除することができる 3pt
6 管理ツールユーザーが、Web上で権限をユーザーに編集することができる 5pt
5PTと書いてあるのは、ストーリーポイント。スクラムに
おける、仕事を相対的に見積もるためのリスクやタスク
交換のコミュニケーションコストを含んだ値(初期は理想
人日)。プランニングポーカーでチームで見積もります。

35. 1 管理ツールユーザーが、所有する権限で機能の利用が承認されるようになる 5pt
2 管理ツールユーザーが、Web上でユーザーの権限を確認することができる 3pt
3 管理ツールユーザーが、Web上で権限をユーザーに割り当てることができる 5pt
4 管理ツールユーザーが、Web上で権限をユーザーに追加することができる 5pt
5 管理ツールユーザーが、Web上で権限をユーザーに削除することができる 3pt
6 管理ツールユーザーが、Web上で権限をユーザーに編集することができる 5pt
こう分割してリリースしておくと、いざリリース日までに5
番目までしかできなかったとしても、最悪利用できるように
できる。しかもストーリー分割しておけば、いざとなったら
担当開発者以外の人でも開発できるので、他の部分を開発し
てた人でも手伝える。

36. 1 管理ツールユーザーが、所有する権限で機能の利用が承認されるようになる 5pt
2 管理ツールユーザーが、Web上でユーザーの権限を確認することができる 3pt
3 管理ツールユーザーが、Web上で権限をユーザーに割り当てることができる 5pt
4 管理ツールユーザーが、Web上で権限をユーザーに追加することができる 5pt
5 管理ツールユーザーが、Web上で権限をユーザーに削除することができる 3pt
6 管理ツールユーザーが、Web上で権限をユーザーに編集することができる 5pt
こういうふうに細かい機能で優先順位をたてると、意外とこ
の機能つかわれないんじゃね？というのが見つかったりする
こともあります。実際に、すごく苦労して作った機能なのに
ほとんど使われてない機能って結構ありますよね…。

37. このようにスコープ（要件）の方を柔軟にし
て、品質と時間と予算を固定化することが可能

38. でもストーリー分割の方法って難しいよね

39. 難しい
(アジャイルな見積もりという本の中でもひとつの章が設けられているぐらい)

40. • 基本的にはストーリーは、リリースできたり、成果物
として何か残せる、人と交換しやすいぐらいにまとめ
るのが良い。
• 規模も１スプリントに収まりやすいように2∼5ptぐら
いに分割するほうが良い。分割し過ぎるとストーリー
ポイントの肥大化や管理コストの増大をまねく。
原則として

41. 1. データで分割
2. 機能で分割
3. 設計、実装、リリースで分割
4. 横断テーマで分割
5. 大きなリファクタリングをストーリーとして分割
これだけ覚えておけば良い割り方

42. 1. データで分割
•先ほどの管理ツールの例で言うと、ユー
ザー、権限等の操作すべきデータ対象で
ストーリーを分割する
•例: ユーザー割当機能と権限割当でス
トーリーを分割する

43. 2. 機能で分割
•追加、削除、更新、集計等のデータに対
する操作や機能で分割する
•例: ユーザー追加機能とユーザー削除機
能、ユーザー一覧機能で分割

44. 3. 設計、実装、リリースで分割
• その名の通り、設計、実装、リリースで分
割する。設計は、レビュー済み設計資料を
他の開発者が利用できるようになること
を、実装は、そのレビュー済みのコードが
共有リポジトリに入って他の開発者が利用
できるようになることをゴールにする

45. 4. 横断テーマで分割
•フレームワークの用意、ロギングの実装
など横断機能で分割
•例: 開発者が、全エンティティの編集ロ
グを利用できるようになる、等

46. 5. 大きなリファクタリングを
ストーリーとして分割
•リファクタリングも規模が大きい場合
は、ストーリーにしてしまいます。
•例: 開発者が、モジュールBに依存せず
にモジュールAを利用できるようにな
る、等

47. 1. データで分割
2. 機能で分割
3. 設計、実装、リリースで分割
4. 横断テーマで分割
5. 大きなリファクタリングをストーリーとし
て分割
基本的に1, 2が基本戦略で、困ったときにそれ以外を使う方法が
良い。これで、柔軟にスコープを柔軟にすることができます。

48. この方法があれば、肥大化する要求と対峙しな
がらもスコープを柔軟にして、開発していける

49. •リリースはされたが、毎日障害が起こる
•直す人がいないので不具合が放置される
•そして最初は怒り狂ってたユーザーも、
初期担当開発者も誰もいなくなった
こういうのがない未来にしていきましょう！

50. 以上
ご清聴ありがとうございました

51. 最後に（時間が余っていれば...)

52. ジャンプ漫画で考える
理想のアジャイルチーム像

53. エンジニアが目指すべき
理想のアジャイルチーム像
• リーダーがその場にいなくても目的のために柔軟に
動けるチーム
• リーダー含めたメンバーが一人ぐらい欠けても目標
を達成する
• 密なフィードバックをし合っている
• お互いの能力を活かし合う

54. ジャンプ漫画で例えると

55. 目指すべきチームの例
• リーダーがその場にいなくても目的のために柔軟に動けるチーム
• リーダー含めたメンバーが一人ぐらい欠けても目標を達成する
• 密なフィードバックをし合っている
• お互いの能力を活かし合う
ブチャラティチーム 幻影旅団 湘北チーム

56. 目指すべきでないチーム像
• リーダーがその場にいなくても目的のために柔軟に動けるチーム
• リーダーを含めたメンバーが一人ぐらい欠けても目標を達成する
• 密なフィードバックをし合っている
• お互いの能力を活かし合う
Z戦士 ルフィ海賊団
これらのチームは、リーダーの役割比重が重すぎ、下位打線を活かしきれていない
護廷十三隊の各隊

57. こんなチームが理想のアジャイルチーム
なのではと考えています
• リーダーがその場にいなくても目的のために柔軟に動けるチーム
• リーダー含めたメンバーが一人ぐらい欠けても目標を達成する
• 密なフィードバックをし合っている
• お互いの能力を活かし合う
ブチャラティチーム 幻影旅団 湘北チーム

58. 以上、本当に
ご清聴ありがとうございました