ぐるぐるDDDは何を目指しているのか？

Kiro Harada Attractor Inc.

原田 騎郎Kiro HARADA Agile Coach Domain Moder SCM Consultant Twitter: @haradakiro

Attractor Inc. ATL SD Ltd.

2

3

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

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

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

ところで？作っているものの品質は？

壊れずに安定していますか？

保守しやすいですか？

拡張しやすいですか？

設計は、美しいですか？

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

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

ウォーターフォール 開発では？要件定義書

要求仕様書

外部設計書

テスト仕様書

スクラムでは？

プロダクトバックログ

Blinds and

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

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

モデルとは？

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

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

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

なぜモデルを使う？

私たちの製品は何か？

ソフトウェア

システム

サービス

インフラ

Modelss are useless, but modeling is indispensable.

モデルは役に立たない。でもモデリングは欠かせない

No models survive contact with the new context.

コンテキストが変わったら、モデルは必ず変わる。

Plans are useless, but planning is indispensable.

計画は役に立たない。でも計画作りは欠かせない。

No plans survive contact with the enemy.

敵に遭遇したら、計画は必ず変わる。

状況によるね。

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

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

状況を共有するには？

状況を共有するために:

一緒にモデリングしよう

モデリング

問題領域をいろいろな側面から見てみる

バリデーションとベリフィケーション

Validation and Verification

モデリングのうずまき

モデル探求のうずまき

モデル探索の

うずまき

モデルを新しいシナリオで

揺さぶる

シナリオ

モデルモデルを提示

状態ウォークスルー

解決策ウォークスルー

言語の探求

間違う

ストーリーを語る

肉付けする

難しいところに再フォーカス

コアドメインに再フォーカス

コードによる探査シナリオを“テスト”としてコードする

厳密さを加える

言語を洗練する

解決策を探求

間違う

収穫＆文書化　参照シナリオ

　まともなモデルの一部

　ほとんどのアイデアは書かない

37

シナリオ ストーリー

モデルコード

３つの人工物の整合性

少人数のグループで３つのものを一度に作ってみる。

シナリオ

モデル

実装・実現

ぐるぐるDDD/Scrum

ある対象のドメインを決めて、

シナリオ、モデル、コードの作成を45分のタイムボックス行う。

複数回繰り返す

イテレーションごとにふりかえり

2013年から実施開催場所

東京、大阪、仙台、名古屋、福岡、広島

シンガポール、バンコク、上海

ホーチミンシティ、ハノイ

ポルト

みんなコミュニケーションが 上手になってくる

ユビキタス言語

バウンダリの意識

同じものを３つの側面から見る

モデリング

他人が対象をどう見ているかを、お互いに理解しようとする活動。

知っているということ

知っていることを知っていること

知らないことを知っていること

知らないことを知らなかったこと

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

アジャイルとモデリング

知らないことを知っているという境界を広げて続けていこうという試み。

それで？

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

企業情報システムの現状

ところで？作っているものの品質は？

壊れずに安定していますか？

保守しやすいですか？

拡張しやすいですか？

設計は、美しいですか？

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

美しいモデル？

なぜ？

全体性と 修繕の原理

Alejandro Aravena

　　half-homes

モデルは、状況の変化によって、もっとも役に立つ状態からは外れていく。

モデルが使える状態を保ったまま、よりよいモデルへ修繕する。

情報システムの修繕

情報システムへの 変更コスト

新規＜＜追加＜＜変更＜削除

機能の 必要・不要を知るコスト

不足機能

を見つける ＜ 無駄な機能

を見つける

システムの機能の利用度

全く使わない滅多に使わないときどき使うよく使ういつも使う

Standish Chaos Report 2002

情報システムの 保守において

以下のようなことにコスト(リソース、時間)をさいてますか？

不要となった機能を探す

不要となったコードを削除

情報システムを動かしたまま、保守する方法を知らない。動かし続けるだけが保守ではない。

システムをよりよい状態に改善しつづけること。

不要な機能、不要なコードの削除

本当に保守できていますか？

情報システム

どれだけのコードが実際に使われていますか？

どれだけのデータが生きているデータですか？

重複しているコードはありませんか？

一時しのぎのコピーコードが残っていませんか？

情報システムの開発を どう評価しますか？

SLOC

機能数・画面数

ベロシティ

障害の数

品質

ユーザービリティ

Small is Beautiful

The Art of Repairing

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

ありがとうございました

ご質問、ご意見などは、

- harada.kiro@attractor-inc.jp

- Facebook: haradakiro

- Twitter: @haradakiro

�X

The Scrum Field Guide (Mitch Lacey)

( )

…

( )

: 2: 3,480