オープンセミナー広島2016の発表資料です。 http://osh-web.github.io/2016/

1. ぐるぐるDDDは何を目指して
いるのか？
Kiro Harada
Attractor Inc.

2. 原田 騎郎
Kiro HARADA
Agile Coach
Domain Moder
SCM Consultant
Twitter: @haradakiro
Attractor Inc.
ATL SD Ltd.
2

3. 3

4. 皆さんは、
何を作ってますか？

5. 何を見ればわかりますか？

6. お互い理解は
合っていますか？

7. ところで？
作っているものの品質は？
壊れずに安定していますか？
保守しやすいですか？
拡張しやすいですか？
設計は、美しいですか？

8. 今のシステムが良くないの
はなぜ？

9. これから
何をつくりますか？

10. ウォーターフォール
開発では？
要件定義書
要求仕様書
外部設計書
テスト仕様書

11. スクラムでは？
プロダクトバックログ

12. Blinds and

13. どうやって
理解を共有しましょう？

14. なぜモデルを使うのか？
Why do we use Models?

15. モデルとは？

16. 正しいモデルと
正しくないモデル？

17. 正確なモデルと
不正確なモデル？

23. 使えるモデル
使えないモデル？

24. なぜモデルを使う？

25. 私たちの製品は何か？
ソフトウェア
システム
サービス
インフラ

26. Modelss are useless, but modeling is indispensable.
モデルは役に立たない。でもモデリングは欠かせない
No models survive contact with the new context.
コンテキストが変わったら、モデルは必ず変わる。

27. Plans are useless, but planning is indispensable.
計画は役に立たない。でも計画作りは欠かせない。
No plans survive contact with the enemy.
敵に遭遇したら、計画は必ず変わる。

28. 状況によるね。

29. 作った状況と違う状況の中では、
モデルは役立たず

30. モデルと状況を
どうやったら理解できる？

31. 状況を共有するには？

32. 状況を共有するために:
一緒にモデリングしよう

34. モデリング
問題領域をいろいろな側面から見てみる
バリデーションとベリフィケーション
Validation and Verification

35. モデリングのうずまき

36. モデル探求のうずまき

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

38. シナリオ
ストーリー
モデルコード

39. ３つの人工物の整合性
少人数のグループで３つのものを一度に作ってみる。
シナリオ
モデル
実装・実現

41. ぐるぐるDDD/Scrum
ある対象のドメインを決めて、
シナリオ、モデル、コードの作成を45分のタイム
ボックス行う。
複数回繰り返す
イテレーションごとにふりかえり

42. 2013年から実施
開催場所
東京、大阪、仙台、名古屋、福岡、広島
シンガポール、バンコク、上海
ホーチミンシティ、ハノイ
ポルト

44. みんなコミュニケーションが
上手になってくる
ユビキタス言語
バウンダリの意識
同じものを３つの側面から見る

45. モデリング
他人が対象をどう見ているかを、お互いに理解しよ
うとする活動。

46. 知っているということ
知っていることを知っていること
知らないことを知っていること
知らないことを知らなかったこと
(知っていることを知っていると思っていたら、実
は知っていなかった)

47. アジャイルとモデリング
知らないことを知っているという境界を広げて続け
ていこうという試み。

48. それで？
モデリングのうずまきをまわすことは、本当は何の
ため？

49. 企業情報システムの現状

50. ところで？
作っているものの品質は？
壊れずに安定していますか？
保守しやすいですか？
拡張しやすいですか？
設計は、美しいですか？

51. 今のシステムが良くないの
はなぜ？

52. 美しいモデル？

53. なぜ？

54. 全体性と
修繕の原理

55. Alejandro Aravena
half-homes

58. モデルは、状況の変化によって、もっとも役に立つ
状態からは外れていく。
モデルが使える状態を保ったまま、よりよいモデル
へ修繕する。

59. 情報システムの修繕

60. 情報システムへの
変更コスト
新規＜＜追加＜＜変更＜削除

61. 機能の
必要・不要を知るコスト
不足機能
を見つける
＜
無駄な機能
を見つける

62. システムの機能の利用度
全く使わない
滅多に使わない
ときどき使う
よく使う
いつも使う
Standish Chaos Report 2002

64. 情報システムの
保守において
以下のようなことにコスト(リソース、時間)をさいて
ますか？
不要となった機能を探す
不要となったコードを削除

65. 情報システムを動かしたまま、
保守する方法を知らない。
動かし続けるだけが保守ではない。
システムをよりよい状態に改善しつづけること。
不要な機能、不要なコードの削除
本当に保守できていますか？

66. 情報システム
どれだけのコードが実際に使われていますか？
どれだけのデータが生きているデータですか？
重複しているコードはありませんか？
一時しのぎのコピーコードが残っていませんか？

67. 情報システムの開発を
どう評価しますか？
SLOC
機能数・画面数
ベロシティ
障害の数
品質
ユーザービリティ

68. Small is Beautiful

69. The Art of Repairing

70. 小さいシステムと小さく作り上げられないチームに、
大きなシステムを任せるわけにはいかない。

71. ありがとうございました
ご質問、ご意見などは、
- harada.kiro@attractor-inc.jp
- Facebook: haradakiro
- Twitter: @haradakiro

72. X
The Scrum Field Guide
(Mitch Lacey)
( )
…
( )
: 2
: 3,480