イベント登録数3,276

QCon Tokyo 2013 DDDをScrumで廻す。 あるいはScrumをDDDで廻す。

DDDが廻らない? スクラムが廻らない? それ2つ一緒にやれば廻るよ~QCon Tokyo 2013レポート
2013/6/12 TIS株式会社 前出祐吾  本稿では、アトラクタ代表の原田騎郎氏の講演「DDDをScrumで廻す、あるいは、ScrumをDDDで廻す」の模様をレポートする。原田氏というと、Scrumのイメージが強いが、ドメインモデラー、アジャイルコーチ、SCMコンサルタントという3つの顔を持っており、今回はドメインモデラーとしての講演であったが、DDD(Domain Driven Design)の話をするのは初めてとのこと。  最初に原田氏から会場(約30人程度)に対して、いくつか質問があった。「DDDをやっているか?」の質問に手を挙げたのは2人程度。やらない理由を訪ねられると「やった方が良さそうだと思っているんだけど(できていない)」という回答に多くの手が挙がった。思っているのとやっていないのとは、端から見れば同じという厳しい指摘があった。  続いて「Scrumやってますか?」の質問に、こちらも手が挙がったのは数人程度だった。「Scrumでプロジェクトが成功した人?」と訪ねられると手は挙がらなかった。「ScrumとDDDの細かい話は各自勉強を」ということで、この講演では、どうやったらDDD&Scrumをうまくやれるかが語られた。 DDDとは  そもそもDDDとはドメイン駆動設計のことで、ソフトウェアの設計手法である。原田氏は、DDDについて次のように言及した。 ソフトウェアプロジェクトで、まず注意を払うべきなのは、ドメインとドメインロジックである 複雑なドメインの設計はモデルに基づくべきである  続いて原田氏は、DDDをうまくやるには、以下の3つが必要だとした。 コアドメインに集中し、それ以外のところは簡単にやる方法を考える ドメインの実務家とソフトウェアの実務家による創造的な共同作業によって、モデルを探求する 明確に境界付けられ、他コンテキストの中で、ユビキタス言語により会話する  「発注を管理する機能を作ってほしい。言葉が通じず、人によって違うものを作るのはユビキタスではない。皆が同じ語彙を使って話せるようにしよう」(原田氏)  ここで原田氏は、Eric Evans氏の「Model Exploration Whirlpool」(モデル探索のうずまき)の図を引用。「モデルは作っただけではタダのモデルに過ぎない、コードを書いて確かめることがDDDでは一番大切だ」とした。 Eric Evans氏の「Model Exploration Whirlpool」(モデル探索のうずまき)の図(原田氏の講演資料より引用)  いつでも複数のモデルがあるので、正しいモデルを追究するのは無駄であり、モデルを使いつつ、さらに使えるモデルを捜し続けるのがDDDの目的であるという。 Scrumとは  続いて原田氏は、Scrumを「複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのもの」と説明。軽量で理解は容易だが、習得は非常に困難であるという。  原田氏は、「SCRUM BOOT CAMP THE BOOK」の挿絵を引用して、Scrumのフィードバックサイクルによりプロダクトの開発サイクルを廻し続けることを分かりやすく解説した。 「SCRUM BOOT CAMP THE BOOK」の挿絵(原田氏の講演資料より引用) クネビンフレームワーク  原田氏は、クネビンフレームワークについても言及。図を使い、問題の種類としてウォーターフォール型のプロセスで対応できるのは、「シンプル」「煩雑」までで「複雑」「カオス」は困難であると解説した。 クネビンフレームワーク(原田氏の講演資料より引用)  ここでいう「複雑」な問題とは、どういうものか? 原田氏は「自分大学の先生だと思ってほしい。そのうえで、学生が車で通学するのを抑制したいとしよう」という前置きの後、道にあるゲートをよけて車が走ったタイヤの跡が付いた絵を見せて、「やってみてどういう反応があるかを読まなければいけない。小さな問題でも複雑な問題がある」と、例を紹介した。  「ちょっとやってみて、どんな問題があるかを確かめる。結果が分かったらやる」これは、リーンスタートアップも同じ考え方である。  「カオス」は何が起こるか分からなく、反応速度が勝負。それにより、新しいプラクティスが出現するという。  「『複雑』系で生き残るためにはリズムが必要。例えば、スプリントを2週間として一定のペースで繰り返すというように、DDDにはリズムがないので、リズムを作らなければならない」(原田氏)  モデルは複数あっても良いので、そのモデルが正しいか確かめることが重要だ。原田氏は「モデルはシナリオがなければ扱えない。難しいモデルは書いても使えるかは分からない。モデルはチームが扱えないと意味がない。いきなり中小度の高い洗練されたモデルをわたしても失敗する」と注意点を述べた。  作るのを間違えたら作り直せば良いが、作る前に分かる間違いには気づきたいものだ。モデルで気づけば、はるかに速いフィードバックが得られる。原田氏は「フィードバックサイクルとして2週間より短くするときついだろう」と言及した。 ライブモデリングでScrumとDDDの実践  続いて「モデルをホワイトボードに書くのが一番。バックログを横に並べ、1人では書かず、2、3人で書くのがよい。『astah*』などのツールは清書用だ」ということで、「受注管理システムを作ってみる」ライブモデリングが行われた。  まず、バックログに以下の4つを挙げ、実際にホワイトボードにモデルが書かれた。 受注を登録したい 納品書を印刷したい 納期2日前になった注文を知りたい 納期を変更したい  次に、「納期2日前になったらどうするか」というシナリオを考えると、バックログに漏れが発覚。新たなバックログ「品目ごとに消費税率を適用したい」が来たら、どうするかという流れで実際にホワイトボード上のモデルの変更・拡張をすることでモデリングを実践された。  原田氏は「このモデルを使うかどうかは実験してから」ということで、実際に実装したJava(Scalaで書きたかったけど間に合わなかったそうだ)のソースコードを紹介。「難しいモデルの場合、実装してみると、できない個所が分かる。良いモデルかどうかは使わないと分からない」(原田氏)  コードレビューでは、ドメイン以外にビジネスロジックが埋もれていないかをチェックする。新しいバックログが来たときは「モデルの変更が必要か?」「拡張が必要か?」を確認し、バックログを見積もれば良いという。「新しいバックログが来たときもこわくない」(原田氏)。  原田氏は「実装に困ったときはホワイトボードにモデルを書く。モデリングツールではなく、頭から引っ張ってきて手で書くのが良い。モデリングツールは記録のために使うもの」とあらためて強調した。  また、複数のモデルを試すにはどうすればいいのだろうか? スプリントの期間を短くしてシリアルに繰り返すのではなく、単一のスプリント内で複数のオプションを同時に試した方が結果的に短い時間、少ないリソースで開発できるという。  さらに原田氏は、サイクルの中で拡張の方向が見えると強調。「パターン指向リファクタリングはパターンを使う十分な理由が分かって来ているときだけ使うように。あるか分からない拡張をリファクタリングしたり、リファクタリングのためのリファクタリングは無駄である」とのことだ。 DDDとScrumはうまく組み合わせられる  原田氏は最後に、まとめとして次のように語った。  「DDDとScrumはうまく組み合わせられ、どちらも変える必要がなく、お互いのメリットをうまく使えるものなので、メリットがあるかどうかはプロジェクト次第である。モデルを作ることを目標にし、『いつまでたってもモデルが完成しない』というDDDのハマりどころを『2週間のスプリントで出荷可能な製品を作らなければいけない』というScrumのプロセスで補う。あるいは、全体を見ないで開発してしまいがちなScrumのハマりどころを、ユビキタス言語であるDDDで全体理解を促進する。また、短いサイクルを軽量にまわすのが大事だ、まずは、小さく始めてみよう」  「DDDは難しいので、2年に1回しかやらないようでは、うまくなるわけがない。モデルを書いて失敗して、実装につながらなかった経験を積んでいくことが大切。ポンチ絵でいいので、さらっと書けるようになってほしい。この講演が、DDDとScrumをやる助けになれば幸いだ」(原田氏)という、ライブモデリング後の非常に説得力のある言葉だった。  Scrumにチャレンジして挫折した、あるいは、DDDに挫折したという方は、この2つを組み合わせたプロジェクトにチャレンジしてみてはどうだろうか。 QCon Tokyo 2013レポート プログラムは完璧でなければならないが、人は完璧ではない FabLabがもたらすソフトウェア+ものづくりの新たな価値 GitHubの中の人が使っているHubot、そしてChatOpsってなんだ? DDDが廻らない? スクラムが廻らない? それ2つ一緒にやれば廻るよ 大人気のログ収集ツールfluentdとは? そして、トレジャーデータやクックパッド、NHN Japanはどう使っているのか? HTML5と情報表現の最適化 WebRTCで変わるWebの未来 HTML5でできる多彩なビジュアライゼーション 「イベントカレンダー+ログ」レポート投稿募集中!このレポート記事が掲載されている本サービス「イベントカレンダー+ログ」では、イベント登録者がレポートを投稿したり、資料を一覧できるまとめページを作成できます。新着レポートは一覧に表示され、こちらのRSSにも配信されるので、ぜひご活用ください。