社内用

1. 設計書からの卒業
～DDDへの誘い～

2. 設計書書きたくない
書く意味無いじゃん

3. なぜ？

4. ただの日本語プログラミングに
なっているから
なぜ？

5. ソースコードとの二重メンテになるから
(設計書はソースコードと乖離する)
なぜ？

6. ソースコードを追った方が
圧倒的に早いから
なぜ？

7. 設計書に縛られて
プログラミングが不自由になるから
なぜ？

8. •ロジックをゴリゴリ書いてしまっている
•設計書に何を書くべきかわかっていない
日本語プログラミングになっているから
原因

9. •製造工程で前工程の考慮漏れが発覚
•クライアントからの仕様変更依頼
•障害発生時にソースコードのみ修正
ソースコードとの二重メンテになるから
原因

10. ソースコードを追った方が
圧倒的に早いから
•プログラムはソースコードに記載の通り動いており、
設計書に記載の通り動いているわけではない
原因

11. 設計書に縛られて
プログラミングが不自由になるから
•設計書に書いて無いことは出来ない、やらない
•やろうとすると設計書の修正が必要になるので面倒
•設計書が間違っていたとしてもそれを正とするように
なる(クライアントの要望に応じなくなる)
•「それ設計書に書いてあるの？」
原因

12. 設計書に詳細なロジックを書いてはならない

13. コンテキストマップ
•http://d.hatena.ne.jp/asakichy/20110623/1308780754
•http://tsuyok.hatenablog.com/entry/2013/07/24/220841
ユーザーストーリー
•http://www.slideshare.net/Ryuzee/ss-8332120
•http://www.slideshare.net/papanda/ss-41638116
•http://hosukepoi.hatenablog.com/entry/2013/05/30/222338
ユビキタス言語
•チームで共有する言語
•プロジェクトにとって最善の用語
•http://d.hatena.ne.jp/asakichy/20110513/1305239515
クラス図
何を成果物とすべきか

14. クライアントが・・・
•システムを保守しているのは誰か
(クライアントはロジックを知ってどうするのか)
•クライアント(システム部含む)にとって設計書は意味のあるものか？
•クライアントは納品された設計書で何をするのか？
•ソースコードの読めないエンジニアは必要ない
•ソースコードの読めないエンジニアにはロジックは必要ない
•設計書修正の工数を減らせるので見積額減らせまーす(適当)

15. •重要なのはドメインであり、ユビキタス言語である
•設計書にはユーザーストーリーを書くだけに留める
•クラス図を書く
•ユーザーストーリーをクラス図に反映する
•システムを保守する人間がシステムの内部構造を理解していればそれでいい
•設計書に縛られてプログラムが歪になってはいけない
•シナリオ -> モデル -> コード ->
http://j5ik2o.me/blog/2013/05/11/sinario-model-code/
簡単に

16. どうすればいい？

17. ドメイン駆動設計(DDD)しよう

18. •組織として、ドメインに関する有用なモデルを獲得できる
•事業について、より洗練された正確な定義ができて、さらに深く理解できる
•ドメインエキスパートが、ソフトウェアの設計に貢献できる
•よりよいユーザー体験を提供できる
•モデルとモデルの間に、明確な境界を定められる
•エンタープライズアーキテクチャが、より整理されたものとなる
•アジャイルでイテレーティブなモデリングを、継続的に行える
•戦略的な面でも戦術的な面でも、新しいツールを使える
(実践ドメイン駆動設計 (Object Oriented Selection) p.24 より引用)
DDDを採用する事業価値

19. •クライアントを巻き込む
•ドメインエキスパートを巻き込む（情報システム部ではなく、業務部）
•クライアントが協力してくれないのならば案件を受けてはならない
•クライアントにシステムへの思いがなければ間違いなく炎上する
•我々はクライアントのビジネスにシステムで貢献するのであって御用聞きでもなけ
れば、クライアントの操り人形でもないし、ましてや奴隷でもない
•単なる技術屋になってはいけない
•「クライアントがこう言ってるから」ではなく、なぜそうするのか議論せよ
•ユビキタス言語を作る
•ユビキタス言語があれば本当のクライアントと話ができる
•業務にもシステムにも詳しくないクライアントの情報システム部は不要
•本当にそのシステムを必要としている人と会話が可能となる
•ドメインについて理解する
•ドメインをしっかり設計できていれば最適な技術を選べる
（フレームワークも言語も自由。最適なものを選べば良い。）
DDDのために

20. DDD(ドメイン駆動設計)は
Scalaがやりやすいらしいっすわー
ちなみに

21. •DDDは銀の弾丸ではない
•DDDを適用すべきでないところもある
•一度DDDが出来てしまえば生産性は今よりも向上するが、そこに辿り着くまでのコストは
掛かる(※どのくらいの数字かはやってみないとわからない)
注意

22. •組織的に挑戦していかなければならない(ビジネスモデルの改革)
•要件定義で失敗すればそのプロジェクトでの生産性向上は不可能
(もし生産性が高いように見えるのであればリスクを非常に多く積んでいるだけの可能性
があり、本当に生産性が高いのかは疑わしい)
•DDDワンチャン
小手先の生産性向上は限界を迎えている

23. •http://www.amazon.co.jp/%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%
82%A8%E3%83%B4%E3%82%A1%E3%83%B3%E3%82%B9%E3%81%AE%E3%83%89%E3%83%A1%E
3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88-IT-
Architects%E2%80%99Archive-
%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%
BA%E3%81%AE%E5%AE%9F%E8%B7%B5-
%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%82%A8%E3%83%B4%E3%82%
A1%E3%83%B3%E3%82%B9/dp/4798121967
エリック・エヴァンスのドメイン駆動設計
(IT Architects’Archive ソフトウェア開発の実践)

24. •http://www.amazon.co.jp/dp/479813161X/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=187205609&p
f_rd_s=lpo-top-
stripe&pf_rd_t=201&pf_rd_i=4798121967&pf_rd_m=AN1VRQENFRJN5&pf_rd_r=1T5HEH69P
YZB979FV278
実践ドメイン駆動設計
(Object Oriented Selection)