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