読者です 読者をやめる 読者になる 読者になる

"DDD & Scrum をぐるぐる廻すワークショップ #0"参加して来ました。

掲題のワークショップに参加してきました。

http://atnd.org/event/dddscrum

主催者は原田さんです。

https://twitter.com/haradakiro

使用していたスライドです。

http://www.slideshare.net/kiroh/dddscrum-scrumddd

会場はGREEさんに用意して頂きました。

http://gree.jp/

 

QConに参加していない僕のような方も考慮していただき、最初の1時間程は座学で「なぜDDDなのか」「なぜDDDとScrum」なのかとい話をして頂きました。

残りの時間はいくつドメインを決めそれをモデリングするワークショップを行いました。

モデリングを行ったドメインは次の4つですの通りです。

・図書館

 チュートリアル的に原田さんがモデリングしてくれました。

・ドラクエ

 参加者がドメインの情報を提供しながら原田さんがモデリングしてくれました。

・カードゲーム

 ブレイクタイムにドラクエとの比較という意味も込めて原田さんがモデリングしてくれました。

・コールセンター

 参加者がドメインの情報を提供しながら参加者がモデリングしてくれました。

 

以下、箇条書きになりますが印象に残ったところを記します。

◆モデリングの元になるシナリオはユースケースを使わなくてもよい。

ユースケースは優れたフレームワークなので使ったほうがよいが、ハードルが高い(ユーザー含め)と感じる場合はScrumのユーザーストーリーを用いてもよい。とのことです。ただし、モデルを描いたあとでユースケースを書くことがよくあるようなので、できれば最初からユースケースを書けるといいんだろうなと感じました。

 

◆DDDとScrumの相性はよい。補完し合う。

DDDをやり出すと実装されていない重厚なモデルが出来てしまい実装できないモデルが出来てしまうことが多いようです。これをモデリング地獄と呼びます。Scrumではsplint単位で動くソフトウェアをつくり上げる必要があるのでモデリング地獄に陥るのを避けられます。

また、Scrumは直近必要な機能は詳細化しますが、その先の機能については詳細化せずにプロジェクトを進めます。あまり先の機能を詳細化しても、その詳細化された機能は的外れで無駄になってしまうことが多いからです。ユーザーは動くソフトウェアを見ることで自分の希望するシステムを具体化していくわけです。

ただ、このように進めていくとソフトウェアの全体像が見えないという問題が出てくることがあります。そのため、モデリングの要素を入れて全体像を描いていきます。原田さんによると2週間splintの場合2,3splint先までモデリングするのが適当だそうです。もちもん、モデルもコードと同じようにsplintを進めていく中で改善していく必要があります。

 

◆ソフトウェア開発では抽象度のレベルが肝。

「そのソフトウェアは何を管理したいのか?」

モノはいろいろな捉え方をすることができます。本ワークショップでは"S.I.ハヤカワ"さんの"思考と行動における言語"の中に出てくる"抽象のハシゴ"(p173)を紹介していました。

f:id:jumperson:20130429120122g:plain

 

◆実装可能なモデルを教えなければいけない。

これは参加者の方からの質問で「現在のプロジェクトでは実装経験が少ない方がモデリングを行なっているため、実装可能なモデルにならない。」という相談への回答です。実装可能かどうかを教えるためには、その人達の前で実装してみて実装できないことを目の当たりにさせることが効果的とのことです。

 

◆"モデリング=クラス図を書く"ではない。

モデリングの目的はユーザーとエンジニアとの間にユビキタス言語(共通言語)を持ち、共通理解を持ってソフトウェアを作り上げていくことです。従って、クラス図にこだわる必要はありません。そういった意味ではモデリングは文書でも良いわけです。ただ、クラス図の多重度(1:N)の表現や汎化の表現等は非常に優れており、また、実装にもつながりやすいため、クラス図は良い選択肢の1つです。

 

◆ドメインエキスパートはいない。

ユーザーは自分の業務のエキスパートであっても、自分の仕事が経営にどう貢献し、社会にどう貢献し、どうお金を産んでいるのか理解してい人はほとんどいません。従って、エンジニアがユーザーや経営者の話を聞いてドメインを理解しドメインエキスパートになる必要があります。

 

 

◆実装は表になることは明らかでもモデルではクラスとして描いておいた方が良い。

※メモに残っていたので記載。詳細は忘れました。

 

最後に。

非常に刺激的で有意義な4時間を過ごさせて頂きました。今回は実際にモデルを書きませんでしがた、モデリングのスキルは実際に書かないと身につかないと感じたので、実際に書く機会を増やしていこうと思います。

 

 

イベントを開催してくださった原田さん。会場をお貸し頂いたGREEさん。

その他、協力していただいた多くの方々に感謝します。