1.
Modeling × TDD × DDD
Devlove甲子園2014 二階裏
～モデアジャ第2段～

2.
これは前に発表された続きものです
DevLove現場甲子園2013
2013年11月9日(土) 11:00～20:00
• 4つのテーマ 「創、考、守、団」
• 発表時間は 20分で4テーマ同時進行
参考：DevLOVE現場甲子園2013 http://devlove.doorkeeper.jp/events/5464

3.
モデリングもしないで
アジャイルとは何事だ？

4.
皆様に愛されて２万View
発表後、upから1日で1万View達成！
現在も少しずつViewとlike, Download
が伸びてます
http://www.slideshare.net/iwaoRd/ss-28075252
2014年8月15日現在
21,000 View突破！

5.
色々な人の支えがあってのView数
Facebookにて羽生田さん
からリンクシェア
はてなでブックマークが
310ユーザー達成
Twitterにて平鍋さんから
リンクTweet
感謝

6.
モデリングしないで
開発するとどんな感じ？
宣伝はさておき！

7.
イメージは
こんな感じ？
＊「おお アジャイラーよ！
しんでしまうとは なにごとだ！

8.
自己紹介
原田 巌
@iwaoRd
「人生、全速力で回り道」
モデモデ言ってるSIer勤務

9.
はじめに
• はっきり言って前回発表時から状況が好
転していない
• 何かをしては何かの問題が発生するモグ
ラたたき状態
納品する受託開発がダメと言われたらそう
かもしれないけど、まだ成功に向けての足
掻きが足らないと思うのです・・・

10.
Context
• いつもながら愛情溢れるSIerの話です
• いわゆる大規模請負案件です
• 複数チームいます
• 複数社います

11.
Problem
• Why can’t we all play nice?
Linda Rising
http://www.computer.org/csdl/mags/so/2012/05/mso2012050007.pdf
People naturally sort others into
in-groups and out-groups, just by
their appearances and actions

12.
複雑な関係・・・
現場にはForceが
沢山蠢いていて、
何かをするにも
何かのForceの影響をうける

13.
単純な解決策なんて無い！

14.
私の根底にある想い
Agileは自己組織化とフィードバック
• 壁（組織だったりチームだったり会社
だったり）を作りだすことで歪みが出来
てしまう
• 思想を理解するだけではダメ。実行して
気が付く事もある
• 要は「行動と学び」を繰り返していかな
いといけない

15.
さて本題

16.
今日話すこと
1. 開発現場の問題
（モデリングもしないでアジャイルとは何事だ!?の復習）
2. DDDから学んだ事
– 動くコードでモデルを検証！
3. それでも解決できない問題
– DDDとTDDでより良いモデリング！
4. 明日から実践する事

17.
1. 開発現場の問題
客「○○というのを作りたい」
私「はい」
客「・・・」
私「・・・」
客「作って」
私「えっ！？・・・」

18.
現場ではDDDを実践してます
• DDD流行ってますよね？（多分）
• 有名人が絶賛してますよね？（多分）
• かっこいいですよね？（多分）

19.
なぜ、DDDを採用したのか？
実はキッカケは
• お客様のOrderだから
• やらされDDD
です（笑
それが
DDD？
え？いや、その
多分ｗｗｗ

20.
でもやるからには
完璧に実行したい
• 積ん読されているEric EvansのDDDを読ま
ないと・・・
• オブジェクト指向の基礎を確認しておかない
と・・・
でも、その前に「考えないといけない」ことは

21.
わ け
なぜ、DDDが必要だったのか？

22.
DDD上手くやろうとして
見えた問題
• 前回の「モデリングもしないでアジャイ
ルとは何事だ！？」
http://www.slideshare.net/iwaoRd/ss-28075252

23.
現場での問題点
• モデリングの必要性
• デザインの理由の欠如
• アジャイルの文脈でのモデリング
– そこで作り出したかったもの
• 共通認識
• 目的を明らかにする
• 不確実性に対応する
そして、

24.
コードとモデリング
【バードビュー】
欲しいモノを叶える力を
私達は持っている！

25.
1. 開発現場の問題
まとめ
• 開発現場の問題への対応
– モデリングは重要である
• 共通認識を築くために地図としてモデル
• 誰もが学べる共通言語としてのモデル
• 一緒に作り上げて認識を合わせる場の形成
– モデリングと実装を合わせて成長させていく
• モデリングの目的を明確にしてコードに繋げる

26.
2. DDDから学んだ事
http://www.amazon.co.jp/dp/B00794TAUG/

27.
さて、まず何をしますか？

28.
そうモデリング！

29.
閑話休題
モデルはどこから生まれるか？
？

30.
システムとは何で出来ているか？
• 平鍋さんとの飲みでの話
平鍋さん
「システムは物語で出来ている」
この時に思ったこと
– モデル（やポンチ絵などの図）はお客様と交わされ
る物語を表している
– コードはコンピュータと交わされる物語を表してい
る

31.
つまり
• シナリオも無しにモデリングとは何事だ！
– その“言葉”はどこで拾ってきたの？
– その“モデル”は何の問題を解決しているの？
→ やりたいのは“コア”を見つけだす事
※シナリオと書きましたがユースケースでもユーザストーリーでもその
他どんな書式でも。要はお客様の語る物語ベースでないとそもそも何
作っているのか訳が分からないよね？

32.
ゆびきたす

33.
でも最近のシステム開発って

34.
現場にいるのは・・・
• 「これドーン！とやっちゃってよ！」
– 画面にボタンの追加（無意味）
– 裏の仕組みなんてどうでもいいじゃん！
– リリースは明日ね！
– 仕組み？動かすのはお前の仕事だろ！

35.
一方で、仕様はエンジニアの妄想
で生まれる
• 「そんなの仕様にない！仕様変更だ！」
（from 原田騎郎さんのDDD&Scrumワークショップより）
– とか言ってもその仕様はどこから？
– ○○って事は✕✕って
変更は“多分”あるよね？
– それデザインパターンだ！

36.
モデルの問題点
• 学びとしてモデル（もしくは図解）は良
い方向であるのは確か
• しかし、モデルには限界もある
– 図としての限界
– 伝えられる事の限界

37.
とは言え
• 熱意がある人（当事者）は食らいついて
くる印象
モデルが伝わらないのって、誰！？

38.
現場の一場面
私 「ということで、○○に着目するとA案、
B案のような設計が考えられますが、
✕✕からA案を取り、△△があっても
C案移行しやすくしま・・
人 「説明は分かった気がする。で、
ER図はいつ貰えるの？？」

39.
そもそもモデルに興味ない！？
興味ない人達が
やっている事 モデル距離感
モデルだけでは解決に繋がらない！！！
モデルわかんない！
無くても大丈夫！

40.
モデルを書けば
（すべて）上手くいく訳じゃない

41.
「正しいモデル」を書けばOK？
分析中毒に陥る悪魔の証明問題です。

42.
必要なもの
• ビジネスやユーザに立ち向かう
勇者の剣や盾
http://www.mpsnet.co.jp/hobbynet/products/doll/44501.html

43.
上手くモデリングしていくには

44.
DDD with Scrum
DDDをScrumで廻す あるいは ScrumをDDDで廻す
http://www.slideshare.net/kiroh/dddscrum-scrumddd

45.
DDDを通して気付く学びのループ

46.
小さく、そして速く
1. シナリオを探索する
2. モデルを小さく作る
3. モデルをコードにする
4. 動くコードからフィードバックを得て、
少しずつモデルを成長させていく
5. 回転を小さくイテレーティブに提供する
ことで少しずつ学んでいける

47.
みんなで賢く学んでいくこと

48.
2. DDDから学んだこと
まとめ
• 道具を理解して正しく使う
– UML＆ポンチ絵
– オブジェクト指向＆DDD
– Scrum
• 動くコードでモデルを検証する
• 実装で分かったことをモデルにフィードバッ
クする
• 小さく、そして速く！
動くコードでモデルを検証！

49.
3. それでも解決できない問題

50.
現場での話
私「シナリオが○○だからこのモデルの
認識です。次にあのケースですが、
客「あの・・・」
私「はい？」
客「そのモデルの確からしさってどのよう
に検証されるのですか？」

51.
質問！
あなたの設計や実装が正しいと何で判断し
ますか？

52.
モデルも書いた、ソースコードも書いたけど
• 依然残る問題
– モデルをソースで補完
– ソースは仕様通り動いている
– ユーザレビューもOK
でも、それって本当に「正しいの」？

53.
さぁ！テストをしようか！？

54.
TDDの私の持っている印象
• 実はTDDが嫌いです
– TDDはテスト手法？
– TDDは単体テスト？

55.
TDDは意味をなくしている
とある現場の会話。
* 「単体テスト完了！C0/C1 100%！」
私「了解です。で、なんでこのシグニチャ
なんですか？」
* 「・・・」
TDD界隈の人はそんな事ないだろう
でも、悲しいかな現場はそんなもんだ

56.
とあるTDDの会話
私 「どうしてこの設計にしたの？」
人 「テストしにくかったから変更しました」
多分、合ってる。
でも、間違っている。

57.
TDD is Dead
Cope says
“Most UT is Waste”
• UT tests methods, not the module/class
→ TDDは設計技法である

58.
テスト戦略
• C0/C1は政治問題
• どんなテストを何の目的で行うのかを先に決
めておかないといけない
→ “単体試験”とTDDを混同してはいけない！
でも、テスト戦略については今回のスライド範
囲外なのでまたの機会に・・・

59.
DDD × TDDで見えること
• テストでモデル（設計）の「確からし
さ」を検証する
• TDDの結果見えたものをモデルにフィー
ドバックする

60.
もう一度。
「システムは何で出来ているのか？」
≒「モデルはどこから生まれるのか？」

61.
実践テスト駆動開発(GOOS)読んだ by 平鍋さん
http://qiita.com/kenjihiranabe/items/b951b6d98672167347fd
受け入れテスト

62.
重要なのは？
１）全体感、目的、知識の共有
シナリオをベースにユーザ価値に着目したテス
トを実施すること。このテストは自動的に繰り
返して価値提供を保証すること。
２）実装のための設計をすること
モデリングとTDDで設計をスパイラルアップ
させていくこと。設計の確からしさを発見した
後はテストコードは捨てる覚悟であたる。

63.
モデリングとTDD
• モデリングとTDDは同時進行
– モデリングは重要であるが実装やテストと合わせて
設計を行う
– 検証したいのは「設計の確からしさ」である
– リファクタリングされれば単体レベルのテストコー
ドはゴミである
– モデルが検証されれば単体レベルのテストコードは
無用である
つまりTDDは設計で使用し、作成したテストコード
は捨ててしまった方がいい（ことが多い）。
1. UT is not automated test
2. heavy mocking hurts architecture
（from DHH says “TDD is Dead”）

64.
いつ実装を開始するか
• モデリングするのは「事前設計」レベル
– 「直前設計」と言う方が感覚に合う
– 大き過ぎるモデルは実装・テストサイクルが
遅くなる結果、学びが遅く間違える
– 小さくモデリングして実装（TDD）して、
コードや実行結果からフィードバックを得る
※勿論、全体性の認識は最初にとっておかないといけない
• 増田さん：パッケージ図
• かとじゅんさん：コンテキストマップ

65.
Kent Beck
“「学習－測定－ビルド」と呼ぶべきだと思
います。「ビルド－測定－学習」ではあり
ません”
from Startupプログラマの為の新アジャイルマニュフェスト
qiita.com/TsuyoshiUshio@github/items/28f4c127c911170cad49
モデリング
検証
実装とテスト(TDD)

66.
忘れちゃいけない！！！
How Do We Know When We Are Done?
Doneの定義
How Do We Know When We Are Done?
https://www.scrumalliance.org/community/articles/2008/september/how-do-we-know-when-we-are-done

67.
いつ終えるのか？
• やろうと思えばいくらでもこだわること
ができる
• 斧を研ぎすぎて、木を切る仕事を忘れ
ちゃいけない（目的重要）
– 三人のレンガ職人
「あなたは何をしていますか？」
モデルもコードも引き際大事

68.
最後にもう一つ質問
ユーザと話すときに“何”を伝えますか？

69.
とある会話
• 引出しを作る大工の話
From デザインパターンとともに学ぶオブジェクト指向のこころ
http://www.amazon.co.jp/dp/4894716844

70.
実装の話をするんじゃない！
• その話は伝わらない
• 伝えるのは「質」の話である

71.
パタンを見出すこと
http://blog-imgs-47-origin.fc2.com/i/t/o/itokaya/IMG_5160-horz.jpg

72.
［入口での転換（112）］より
<より大きなパタンとの結合>
…どんな建物や複合建物の場合でも、すでにそ
の主入口の大まかな位置は分かっている－［大
きな門口（53）］から敷地への門、［見分けやすい
入口の集まり（102）］から各建物への玄関、そし
て玄関。いずれにしろ、入口は「外部」－公的世
界－からさほど公的でない内部世界への転換を
つくり出す。
モデルは捨像
• この世の森羅万象は表せない
• でも、「パタン」を見出すことで「木を
見ながら森を見ることができる」
– Ex) 門
http://fashionjp.net/creatorsblog/fujita/2010/08/post-89.html

73.
パタン・ランゲージ重要
• パタン・ランゲージ
「あるコンテキストにおける問題の解決方法」
– パターンの名前
– パターンの目的、
すなわり解決する問題
– その達成方法
– 達成する上で考慮する必要
がある制約とフォース

74.
3. それでも解決できない問題
まとめ
• 設計技法としてTDDとDDDは親和性がよ
い
• モデリングと実装・テストは同時に進め
るべき
• そこから本質を発見していく
DDDとTDDで
より良いモデリング！

75.
持って帰って実践してみて！
より良い設計／コードの為に
明日から出来るモデリング

76.
コードから学ぶ／考える
• モデルだけでは見えない世界がコードか
ら見えることがある
• 時には実装パターンを使うことで、考え
られていない事が見えてくる

77.
増田さんのスライド
ドメインモデルの育て方
http://www.slideshare.net/masuda220/ss-36548248

78.
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
http://www.slideshare.net/yojik/ss-1033616

79.
オブジェクト指向とは
• 定義は本にお任せ
– そんなの手法の一つ
• でも、今までやってきた10年超の経験か
ら「正しいこと」にリーチできると思っ
ている
• 『必ずしもオブジェクト思考は銀の弾丸
じゃないが、武器は多いほうが絶対にい
い』（オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616 より）

80.
小さくモデリング
小さく実装＆テスト

81.
最後に

82.
忘れてはいけない
Context重要
モデルもモデリングも銀の弾丸ではない
戦術の一つとして用意しておいて欲しい

83.
何より大切なもの

84.
考え抜く事！
Think!!深く！深く！
深く！深く！

85.
以上、ご静聴ありがとうございました

86.
次回、予告

87.
アナリシスパターンが鍵となる!?
（現在、現場検証中！！！）
オブジェクトの広場 突撃インタビュー より
https://www.ogis-ri.co.jp/otc/hiroba/specials/MartinFowler/interview.html

88.
●おわり●