1. 原田騎郎
株式会社アトラクタ
1

2. 原田 騎郎Kiro HARADA
ドメインモデラー
アジャイルコーチ
SCMコンサルタント
Twitter: @haradakiro
認定スクラムプロフェッショナル
認定スクラムマスター
認定スクラムプロダクトオーナー
株式会社アトラクタ 代表
2

3. DDD やってますか？
3

4. ¡ 難しいから、もうちょっと勉強してから
¡ 小さいシステムにはいらないでしょ
¡ やったほうがよさそうだと思っているん
だけれど。
4

5. Scrumやってますか？
5

6. ¡ 「どうせ、Scrum はやるもんじゃな
い！」って言うでしょ。
¡ やってみたら問題ばっかりでてくるし。
¡ 「いきあたりばったりやっているだけ
じゃないの？」と突っ込まれるし。
6

7. どうやったら
DDD & Scrum
をうまくやれる？
使える？
7

8. ¡ ソフトウェアプロジェクトで、まず注意
を払うべきなのは、ドメインとドメイン
ロジックである。
¡ 複雑なドメインの設計はモデルに基づく
べきである。
8

9. ¡ コアドメインに集中する
¡ ドメインの実務家とソフトウェアの実務
家による創造的な共同作業によって、モ
デルと探求する
¡ 明確に境界づけられたコンテキストの中
で、ユビキタス言語により会話する
9

10. モデル探索の
うずまき
モデルを新しいシナリオで
揺さぶる
シナリオ
モデル
モデルを提示
状態ウォークスルー
解決策ウォークスルー
言語の探求
間違う
ストーリーを語る
肉付けする
難しいところに再フォーカス
コアドメインに再フォーカス
コードによる探査
シナリオを テスト としてコードする
厳密さを加える
言語を洗練する
解決策を探求
間違う
収穫＆文書化
参照シナリオ
まともなモデルの一部
ほとんどのアイデアは書かない
10

11. ¡ 正しいモデルを探求するのが目的ではな
い。
¡ モデルを使いつつ、さらに使えるモデル
を探し続けるのが目的。
¡ うずまきを廻し続ける。
11

12. ¡ 複雑で変化の激しい問題に対応するため
のフレームワークであり、可能な限り価
値の高いプロダクトを生産的かつ創造的
に届けるためのものである。
§ 軽量
§ 理解が容易
§ 習得は非常に困難
12

13. 13http://www.scrumprimer.org/anime

14. 14
SCRUM
BOOT
CAMP
THE
BOOK
翔泳社より
https://www.facebook.com/ScrumBootCampTheBook

15. 15http://www.ryuzee.com/

16. ¡ Product Backlog ‒ プロダクトバックログ
§ Sprint Backlog ‒ スプリントバックログ
▪ Backlog Refinement ‒ バックログ洗練
§ Sprint Review ‒ スプリントレビュー
§ Retrospective ‒ 振り返り
¡ Potentially Shippable Increments ‒ 出荷可能な増分
¡ プロジェクトじゃなくて、プロダクトの開発サイクルを廻し
続ける。
16

17. 17
By
Dave
Snowden
http://cognitive-­‐edge.com/
http://en.wikipedia.org/wiki/File:Cynefin_framework_Feb_2011.jpeg
を
CC-­‐BY
3.0
ライセンスに基づき翻訳。

18. ¡ 境界
¡ フィードバック
¡ リズム
18

19. ¡ プロダクトビジョン
¡ ユーザーストーリー
§ ユースケースシナリオ
¡ モデル
§ モデルとシナリオのうずまきをまわす
19

20. ¡ ストーリーの順位付けをする
¡ モデルを書いてみる
§ (モデルは常に複数ある)
§ モデルはストーリーを記述できるか？
▪ モデルは役に立つか？
§ モデルをストーリーが十分説明できるか。
▪ 足りていないストーリーはないか？
20

21. ¡ 難しいモデルは実装して確かめる
§ ドメインモデルのみ
▪ 永続化層
/
UI
はとりあえず考えなくてよい
▪ 複数のモデルを確かめる
▪ 記述力
▪ 実装のしやすさ
▪ テストのしやすさ
▪ 拡張のしやすさ
21

22. ¡ 「検査と適応によって、間違っても、それ
から学べば良い」
けれど
¡ わかる間違いには、気づきたい。
¡ ２週間は短い。それ以上、短くするとき
つい。
22

23. ¡ ホワイトボード
§ 関心ごとのある部分だけホワイトボードに
¡ 適宜清書してリポジトリに
§ astah*
使ってます
23

24. ¡ ドメイン以外にビジネスロジッックが埋
もれていないか？
§ ドメインモデルに書いたテストを、そのまま
使えるか？
§ 実装しにくいところはどこか？
▪ ドメインの使い方を間違えやすいところはどこか
24

25. ¡ バックログを見積もる
§ モデルの変更が不要
§ モデルの拡張が必要
§ モデルの変更が必要
25

26. ¡ スプリント期間を短くするだけでは成功
は難しい。
¡ 単一のスプリント内で複数のオプション
を試す。
¡ モデルを利用した並行開発
26

27. ¡ パターン指向リファクタリング
¡ 次のバックログが見えないうちにリファ
クタリングするのはアンチパターン
§ リファクタリングのためのリファクタリング
は悪
27

28. ¡ バックログが Ready になる前に実装モ
デルを拡張するな
§ 概念モデル、仕様モデルをシナリオでテスト
してから。
¡ リファレンスモデル、パターンの適用を検
討する
28

29. ¡ 富
¡ 資産
¡ 農業資産
¡ 家畜
¡ 牝牛
¡ ベッシー
29S.I.Hayakawa
“Language
in
Thoughts
and
Action”
1939

30. ¡ リファレンスモデルは抽象度が高く、再利
用性が高い。
§ 時間をかけて確かめられている。
けれど
¡ プロジェクトに役に立つかは、確かめな
いとわからない。
30

31. ¡ 小規模プロジェクトは、要件変更に弱い
§ 使えるリソース、期間が限られている
¡ 小規模プロジェクトの範囲を DDD によ
るモデルで定義する。
§ モデルの拡張範囲を合意する
§ モデルの変更をともなうバックログは混入し
ない
31

32. ¡ パターンランゲージとしての Scrum
¡ パターンランゲージとしての
Domain
Driven
Design
32

33. 33
http://domainlanguage.com/ddd/patterns/
CC-­‐BY
3.0
Unported

34. 34
http://jeffsutherland.org/scrum/scrum_plop.pdf

35. 35
Coplien,
James
and
Neil
Harrison.
Patterns
of
Agile
Software
Development.
Addison-­‐
Wesley,
©2004.

36. ありがちなハマりどころ 対応策
モデリング地獄(DDD)
• モデルを作ることを目標にしてし
まう
• いつまでたってもモデルが完成し
ない
スプリント(Scrum)
• 出荷可能な製品を２週間ごとに！
• モデリングも含めて使えるフィー
チャーを２週間で作らなければな
らない。
全体を見ないで開発(Scrum)
• システムの全体像を考えない
• 全体計画を立てない
ユビキタス言語(DDD)
• みなが使える共通言語をつくる
• 共通言語による全体理解を促進
• 全体計画のガイドとしてのモデル
36

37. ユーザー
ビジネス
プロダクト
オーナー
開発者
フィード
バック
プロダクト
バックログ
出荷可能な
増分
DDD で Scrumを
廻してみる

38. ¡ DDDとScrumは、うまく組合せられる
§ DDDもScrumも変える必要がない
§ お互いのメリットをうまく使える
¡ 短いサイクルを軽量にまわすのが大事
¡ まずは、小さく始めてみましょう。
38

39. ¡ DDD+Scrumのワークショップをやりま
す。
¡ 次回開催は未定です
§ (たぶん７月には一回)。
§ Twitter @haradakiro でアナウンスします。
39