fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DDD Alliance! 3週連続DDD 第3週」に参加しました

2015/09/16(水) 「DDD Alliance! 3週連続DDD 第3週」に参加してきました。

connpass
http://ddd-alliance.connpass.com/event/18962/

Togetter
http://togetter.com/li/876882

先々週行われた第1週と、先週行われた第2週も参加しました。そんとき書いたブログはこちら。
今回はその第3週(最終回)なのでした。
会場が銀座の歌舞伎座タワーにあるドワンゴさんということで、隣りにある歌舞伎座の写真を1枚パシャリ。
20150916_ddd1.jpg



第3週(14章~17章)戦略的に取り組む
3週連続DDDその3_ドメイン駆動設計_戦略的設計 from 増田 亨


以下、口頭説明部分を中心に当日取ったメモ。
---

■ 3社での取り組みの事例 (P.5)
(1) HRソリューションズ
  • 人事採用のドメイン。仕事があって求人があって応募する、というドメインは単純。
  • 採用雇用は経営戦略に関わる。
  • あと採用担当者の独自性が強い。こーやりたい、という思いがストレートに出る。
  • 社長がエネルギッシュで営業しまくるので、システムが追いつかないという状態だった。

(2) SBヒューマンキャピタル
  • こちらも人材系サービス。
  • 人材系サービスは、応募者情報を流通出来ている業界。
  • 似たようなサービスが違うモデルで実装されてるサービスをどう連携させるか、とても勉強になる。

(3) ビッグローブ
  • 契約、課金、キャリア連携とか業務的にヘビーなシステムに取り組んでいる。
  • レガシーが今のままではどうにもいかないので、将来に向けて自分たちの戦略で取り組んでいる。

■ 取り組みの現実 (P.9)
(1) HRソリューションズ
  • 経営のスピードがシステムより早いので、スピード重視。

(2) SBヒューマンキャピタル
  • 若手メイン。短期的問題で忙殺されがち。現場レベルでの戦略的な意識向上から始めている

(3) ビッグローブ
  • 壮大な取り組みなので、結果を出すまでに相当時間かかるだろうけど、一歩一歩進めている。

■ 戦略的に取り組む (P.10)
  • 「すぐには見えない効果」 ・・・ 予算取りでうまく説明できないのはそうとう障害。
  • 「それでも取り組む動機」 ・・・ これはシステム屋の本能。いいものを作りたい。
  • 「一歩一歩進む」 ・・・ 一歩一歩を同じ方向に向かわせるか。

■ 誰がやるのか (P.10)
  • これは第4部の大きなテーマ。
  • アーキテクチャチームとかPMOとかがマスタープラン作る、という思想とは真逆。
  • そうじゃなく、現場の人が視野を持って、コードに反映する。
  • コードを書く人が戦略的に取り組むのが一番効果的、というのがDDDの思想。ここがポイント。
  • 綺麗な図とかマスタープランじゃない。大事なのは「言葉」なんです。
  • 戦略をコードに反映してはじめて効果が出るんだ。ドキュメントにいくら書いたってダメ。

■ 戦略的に取り組む場合こそ基本が大切 (P.12)
  • これが一番いいたいこと。戦略的だからといって基本から離れたらダメ。
  • 第1部~第3部の内容を基にして第4部に取り組む。DDD本もそういうストーリーになってるし、やっぱりそうなんだな。
  • 第4部だけやっても意味はない。第1部~第3部とXPとOOを抑えながら長い時間取り組むのがDDDの戦略的設計。

■ 戦略的 (P.14)
  • 選抜された人がやるんじゃなくて、多くの関係者で。その一番の道具が「言葉」。
  • 時間をかけて、お客様のシステムを良くしていく機会はあまりないが、そうしていければ幸せ。

■ オブジェクト指向と「変更容易性」 (P.16)
  • オブジェクト指向は変更容易性を相当重視している。
  • 「抽象データ型/段階的抽象化」、モジュール化はこれまでもずっと言われてた。
  • 「メッセージング」はオブジェクト指向に独自かも。モジュールに分離したとき、どういうふうにしておくと変更やりやすくなるんだっけ、と考える際、アラン・ケイはメッセージングを重視している。
  • 最近はリアクティブプログラミングとかが登場して、この辺は少し変わってきた。
  • 手続き型だろうが関数型だろうが、ドメイン層を人間に近い考え方で部品化して人間の関心事をコード化した場合、それほど変わらないだろうな、と思う。

■ 抽象データ型/段階的な抽象化 コードを人間の発想に近づける (P.17)
  • 自分で型を宣言することで、ドメインオブジェクトの型でプログラミングしていこう。

■ 「モジュール化」と「メッセージング」 (P.18)
  • 独立性の高い部品同士を「メッセージ」で繋ぐことで、構造の組み換えとかがやりやすくなる。
  • 完全同期ではなく、非同期でメッセージをやりとりする。

■ ソフトウェアの開発スタイル (P.20)
  • 変更のコストとリスクをどう下げるか。これまでは「変更」との戦いの歴史。どう安全に変更するか。

(1) 変更を管理する (予測型)
  • もともとは、「変更は管理する」という予測型の思想だった。
  • きちんと最初に決めて、ゴールに行けるのがいい。でもそれは無理だから、変更を管理していきましょう。

(2) 変更を受入れる (反復・漸進型)
  • 1990年代くらいから「変更を受け入れよう」というRUPに代表されるような考え方が出てきた。
  • まず作ってみて、それで目標を設定しなおす。

(3) 変化を目指す (適応型)
  • XPはもっと違うことを言っている。変化に対応するよりも、変更を目指そう。
  • ソフトウェアを作るってことは、変更していくこと。変化が常に頭の中心課題であるべきという哲学。

---
  • 「予測型→反復・漸進型→適応型」という推移は、発展というより、それぞれ違う世界のような気がする。

■ 変化を目指す開発チーム (P.21)
  • 変化を目指す開発チームには何が起きるか。

(1) コミュニケーション
  • 変化を目指していこうよ、となると、「何が変わった?」、「今度は何を変える?」とコミュニケーションするようになる。

(2)シンプリシティ
  • 単純な方が変化させやすい。できるだけシンプルに保つことで次々変化させる。

(3) フィードバック
  • 変化するためには、フィードバックに基づき次の道を探っていく。

(4) 勇気
  • 行動する勇気というだけではない。
  • 変化の必要性に気がついているんだけど、今はそのタイミングではない、とぐっと思いとどまるような忍耐力、耐える力も「勇気」。

(5) リスペクト
  • 相手に感心を持つことなんだ。相手のことに興味を持たないのは、リスペクトではない。

■ 3つの原則を戦略的に (P.27)
  • 第1章の「ドメインの知識を噛み砕く」というのを、長期的に大勢で、広い範囲でやること。
  • 戦略的であっても、抽象論だけでなく、コードで表現しないとダメ。これが第4部のキーポイント。
  • 規模が小さければ「削る力」はあまりいらないかも。
  • でも戦略的に長期的にやるときには、削る力、実験する勇気は、高いレベルが求められる。
  • モデルと実装を結びつけること。戦略もコードに落とし込んで、変えていくんだ。

■ 第2部を拾い範囲で長期的に (P.31)
  • 「システム間連携」となると、システム的な話になりがち。
  • でもそうじゃなくて、各システムのドメイン層の中核をどうマッピングしていくかが重要。
  • それは「システムインタフェース」間の話ではない。

■ 第3部を戦略的に実践する (P.32)
  • 相当焦点を絞らないと、コスパが悪い。
  • 「深いモデルの探求」と「しなやかな設計」は、焦点絞って、そこでやるべき。
  • その波及効果があれば、他がボロボロ、ということにはならない。
  • そういうスキルがあれば、絞った箇所以外も良くなる。どんどん波及していき、ドメイン層全体が綺麗になり、ドメイン層を使う他3層も軸がはっきりする。
  • ドメイン層の中核を的確に捉えるチームが活動することで、どんどん周りに波及していく。
  • その波及を、世代やチームを超えて如何に伝えていくか。
  • 第1部~第3部のことを地道に一歩ずつコードに落としていく。


ここまでが主に前回の復習。第4部からがこの日の本題。


■第4部 戦略的な設計 (P.36)
  • 14章以降は、経験あるエンジニアは、あーそうだよね、と思い当たる内容が多いのではないか。
  • そいうことを言語化したい、並べてみた、という意味で価値が高い。現場で経験してきたことが言葉になっている。

■ 14章 モデルの整合性を維持する (P.38)
  • 7つの見出しのうち、赤字の4つを中心に説明する。

■ 境界づけられたコンテキスト - 大きな部品を特定する (P.40)
  • キーワードはモデル。どういうモデルを元にアプリが組み立てられているのか。境界はどこで切れるか。
  • 開発チームが分かれているのにモデルは1つを共有している、というのはありえないので、開発チームが「境界づけられたコンテキスト」の候補となる。
  • 1つのチーム=1モデル、は候補なのであって、必ずそうあるべき、というわけではない。
  • 1つのモデルが追求できる範囲がコンテキスト。
  • 1つの範囲ではあるけど、モデルはどんどん登場していく。人が増えたり時間が経過したり。同じ人でも違うモデルになったり。
  • そのリスクをキャッチしながら、徹底的に1つのモデルにしようね、と努力をする。
  • そうすることで、それぞれのモデルは明確になるから、マッピングできるようになる。
  • 「境界付けられたコンテキスト」内で純度を保とう。

■ ひとつのコンテキスト内で継続的な統合をする (P.41)
  • 「概念」は、別々の人の頭の中でばらばらに進化をはじめることに、いつも注意する。
  • 人が集まって仕事をしている以上、ある日、みんなが共通認識をもった、というのは素晴らしいが、それがずっと続くかというと違う。放っておくと徐々にバラバラになる。それを1個に保つかが重要。
  • ここで言う「継続的な統合」は、コードを毎日自動でビルドしてCIで統合している、というのとは違う。
  • 「概念」は言葉にできないと意味がない。そうじゃないと、みんなが同じ概念を共有していることにはならない。
  • 相手が何を考えているかに感心を持って、ドメインの一貫性を維持する。
  • 単独のコンテキストの純度を如何に保つがが前提。それが前提で連携がある。

■ コンテキストマップ (P.42)
  • そんなに綺麗に境界の線が引けるわけではないので、この図は境界をぼかしている。
  • ドメイン層の中の重要な部分に絞ったモデルについてマッピングを考えるのがコンテキストマップ。
  • ビッグローブで30人のリーダーが集まってコンテキストマップを作った。すごい興奮する出来事だった。みんなの頭に埋もれていたものが明らかになってきた。季節代わりくらいのタイミングでもう一度やるのが効果あるんじゃないか。
  • 理想論じゃなくて、現実を関係者で共有するということが大事。

■ コンテキスト間の関係 (P.43)
  • 最近出た70ページくらいのDDD資料(Domain-Driven Design Reference)にも出てくる。
  • これはエヴァンスの書籍の図。
  • 横軸が「チームのコミュニケーションの意欲と能力」。それが高くなることが前提で、縦軸の「関連するシステムに対する制御」は、それによってどのくらいでコントロールできるようになるか、自由にできるようになるか。
  • 横軸も縦軸も両方共0なら、「別々の道」を進むしかない。

■ 第14章の要点 (P.44)
  • 前述したビッグローブさんがコンテキストマップを書いてて、美しいと思った。人間臭い。
  • でも、妥協しながらここに辿り着いて、それが事業を支えている。

■ 密接な関係を実現する (P.45)
  • 「共同経営」は、相手の経営にも相当口を出すし、相手の設計にも口を出す。
  • それが枠組みとして保証されているのが「共同経営」。
  • 明らかに共通部分があるので互いに共通開発しましょう、というのが「共有カーネル」。
  • 本当に取り組むべきかの意思決定を、開発チームが、つまりコードをいじる人たちが考えて戦略としていく。

■ 明確な関係を打ち立てる (P.46)
  • 1チームになるのはなかなかできない現実的な解として、「顧客/供給者のチーム」がある。
  • 「顧客/供給者のチーム」、」「公開ホストサービス」、「公表された言語」は、誰かのものに誰かが合わせる、という点で共通。
  • 「公開ホストサービス」を作る側と使う側でコミュニケーションできるなら、とってもいい解になる。
  • そうじゃなく、作る側が使う側に一方的に「使え」というのはダメ。
  • 「公表された言語」の例としては、ERPで人事データを交換するのに使う「HRXML」というものが公開されている。
  • そーゆうものを使って統合していくのが1つの解。でもあまり使われていない。汎用的になりすぎてて、使いにくい。
  • 総論は合意できても、具体案までは合意できないので、具体案は自分たちでビジネスにしたほうが上手くいくので、人材系ではあまり使われてない。でもそーゆうXMLの標準とかがあれば、勉強すれば役に立つ。

■ 独立した別のチーム (P.47)
(1) 別々の道
  • デフォルトは、開発チームは別々。自分たちのことでめいいっぱい。
  • でもチームが分かれてたら、別チームに関与するの難しい。

(2) 順応者
  • 別のチームが作ったものをベースにしてしまうと、連携が楽だよね。
  • でもチーム同士が対等じゃなくて、そっちで決めてください、的な思考停止モデルになりがち。
  • でも現実はけっこう多い。

(3) 腐敗防止層
  • お互いがどーゆうモデルを持ってるかの知識を持ち合うが、調整ごとを一切せずに、間をコンバートしてしまえ。
  • そうすると、自分たちの責任でできるようになる。
  • 別のチームで行動してしまおう、というのが思想の根底にある。

■ コンテキスト間の関係の意思決定 (P.48)
  • 「意思決定」とは、どうコードにどう反映するか、ということ。

■ 戦略を選択する時の考えどころ (P.49)
  • 391~398ページは、ドメイン駆動設計らしい現場の体験談が書かれている。
  • 厳しい現実に対して、どう実践的に判断したかの話が書かれているので、この8ページは徹底的に熟読してほしい。
  • 実際的なエヴァンスの体験談が濃厚に書かれている。
  • コードに影響しそうな人たちに共有しにいくのが、コンテキストマップをひろげていくことになる。

■ 変換(関係を変えていく) (P.50)
  • 今の関係はこうなんだけど、こーゆう関係にもっていきたいよね、という話。
  • 実践的な話が書いてあるので熟読してほしい。コンテキストマップを広げていくために共有してほしい。
  • 現場の体験談。

■ 第14章まとめ (P.51)
  • 「意思決定」を必ず「コード」で表現すること。

■第15章 蒸留 (P.52)
  • コアドメイン、ドメインビジョン声明文、協調されたコア、凝集されたメカニズム、が段階的な話になっているので、そーゆうストーリーとして今日は話します。

■選択と集中 コアドメイン (P.54)
  • 選択と集中。中核中の中核を見極める。見つけに行くことですごく得るものがある。
  • 規模が大きくなると、一発で見つかるわけがない。
  • そのためには要約力を磨くとか、実験してフィードバックを得ながらコアドメインを識別していく。
  • 商売をやって稼ぎに行ける場所には複雑なドメインモデルがある。

■ 中核の探し方 (p.56)
  • DDD本に具体的に書いてある。
  • 顧客クラスから住所を抽出するのと同じ考え方。

■ かたまりを「抽出」する (P.57)
(1) 汎用サブドメイン
  • いわゆる、注文とか、認証とか、アプリによくでてくる概念で切り分けていこう。
  • その段階で中核はどこかわからない。でも、ざくっとその単位で分けてしまうのが核を見つけに行く準備作業。

(2) 凝集されたメカニズム
  • コードが複雑になるところを隠蔽すると、そこを取り出すとシンプルになる。
  • 塊を分けることで、じゃあコアはなんだんだ、とチームで議論する準備ができる。

■ 「かたまり」の「意図」を明確に (P.58)
  • 塊間の依存関係が重要。
  • 関係を言葉として表現することで、意図が明確になっていく。

■ 「コアドメイン」の具体化 4つの段階 (P.59)
  • 「コアドメイン」の具体化には4つの段階がある。
  1. ドメインビジョン声明文
  2. 強調されたコア
  3. 隔離されたコア
  4. 抽象化されたコア

■ ドメインビジョン声明文 (P.60)
  • ドメインの中心的な関心事を言葉を使って書く。これは費用対効果が高い。
  • ワークショップでもやる。チームによい影響を与える。
  • 語尾をあいまいにしない。「~なんだけど。」とかはダメ。癌になる。
  • ふつうの会話としては形式がおかしいくらいにきっちり正しく表現するようにしてください。
  • 文を切らない。
  • 「あれ」、「これ」、「それ」を使わない。ラフスケッチを書いた瞬間、あれがこうなって、と言い出すが、アンチパターン。
  • カタカナ言葉はみんなの理解がばらつくので、同音異義語が少ない大和言葉にまでする。

■ 協調されたコア (P.61)
  • 重要な要素をマーキングしにいく。マーカーで色をつける。ゲーム感覚でやるだけでも相当価値がある。
  • 何が重要か、何を捨てるべきか、という議論をする。
  • 絵にしてみて、マーキングできたよね、で終わっちゃダメ。大切なのは、言葉で表現してみること。

■ 隔離されたコア (P.62)
  • 重要と思われたものを1つのパッケージにまとめてみる。
  • コードとして重要なものが明確になってくる。レベルの高い蒸留。

■ 抽象化されたコア (P.63)
  • 抽象化の最終形。
  • これができた!という経験はあんまりない。部分的には経験してる。

■ 第16章大規模な構造 (P.65)
  • テーマは、「森を見る力」。

■ 「森」を少しずつ成長させていく (P.68)
  • バサッと構造を綺麗にするのではなく、徐々に改善していく。そうすると全体が少しづつ成長していく。
  • 機械的な秩序ではなく、有機的な秩序。これはアレグザンサーの本にも出てくる。


■ メタファー
  • 個人的に好きじゃない。カタカナ用語だし。イメージが沸かない。

■ 責務のレイヤ (P.70)
  • 候補は、一番下の「潜在能力」から一番上の「意思決定」。
  • 複雑になったら5層に分けろ!ではなく、考えていくと5層に分かれる、という話。最初は2層くらいに分けるところから。
  • 一方向のオブジェクト構造にするとやりにくいことがある。でもそうする実験をすることで、より良い設計の気づきが得られたりする。
  • うまくいかない、というところがブレークスルーの手がかりになる。

■ 知識レベル (P.72)
  • アナリシスパターンにも出てくる。

■ 第17章 戦略をまとめ上げる (P.76)
  • 戦略設計上の意思決定に欠かせない箇条書き6条は読み直してください。


★感想:
3週に渡って徹底的にDDD本の話を聞けて、すごく頭の中が整理された感じだ。
ここまで徹底的にDDDを語り尽くす勉強会というのは初ではなかろうか。

増田さんは講演の中で、自分の会社の宣伝とかに時間を割くことは一切されなかった。
3週連続、合計6時間、休憩無し。その時間をフルに使って、聴講者が求めるDDDについて語り尽くしてくださった。
これは凄いことだと思うのです。
完全に損得勘定なんか抜きで、数百ページのスライドを作成して、参加者の期待に応じてくださったのだから。
しかも無料。ホント感謝です。

今回のDDD3週連続の内容を噛み砕くためにも、是非もう一度、書籍を読み直したいと思うのでした。
あ、それもいいけど、実践的な新しい本も出たことだし、そっちの読書会とかあると更に嬉しいな~
誰か主催してくれないかな~ (チラッ

実践ドメイン駆動設計 (Object Oriented Selection)
ヴァーン・ヴァーノン
翔泳社
売り上げランキング: 38,983


増田さん、関係者の皆様、ありがとーございました。

「DDD Alliance! 3週連続DDD 第2週」に参加しました

2015/09/10(木) 「DDD Alliance! 3週連続DDD 第2週」に参加してきました。

DoorKeeper
http://ddd-alliance.connpass.com/event/18961/

Togetter
http://togetter.com/li/873126

先週行われた第1週も参加しました。そんとき書いたブログはこちら。
2015/9/2(水) 「DDD Alliance! 3週連続DDD 第1週」に参加しました

今回は台風の影響でどうなることやら、と思いましたが、無事開催されてよかったです。
でも、大雨で日本あちこち大変だったようですね・・・

というわけで、今回も自分の復習のため、口頭説明部分を中心に当日取ったメモを書き起こしてみる。


第2週(8章~13章)深いモデルの探求
3週連続ddd その2 深いモデルの探求 from 増田 亨


第1週のおさらい

■ 抽象データ型/段階的な抽象化人間の発想に近づける (P.7)
  • 人間の発想に近づけるというのは、今日の第3部でもポイントになる。 
  • 汎用的なLocalDateクラスじゃなくて、誕生日に限定した独自定義クラス(DateOfBirth)まで持っていく。

■ 俯瞰 (P.9)
  • 第1部 ドメインモデルを機能させる 
    • ドメインは大切だね、じゃなくて、エヴァンスはもっと極端なことを言っている。
    • ドメインモデルを中心にすべてを組み立てる。
  • 第2部 モデル駆動設計の構成要素
    • 第2部は基本スキル。必要最低限。でも、いくら第2部を実践してもDDDのメリットや効果は出てこない。
    • 3週連続でしゃべろうと思ったのは、この辺を話そうかな、と思ったから。第2部に時間をとられて話せない部分を話したかった。
  • 第3部 より深い洞察へ向かうリファクタリング
    • ドメインモデルが現場に役立つのは、第3部を頑張った結果として出てくる。
    • 第2部でリポジトリとか実践しても、ぜんぜん恩恵はない。

■ 主題:モデルを活用する (P.11)
  • この図がDDDのキモ。
  • 膨大な技術を噛み砕く、自分から集めていく。集めるだけでなく、鋭く説明するにはどうすればいいんだ、に切り込む。

■ ドメイン (P.12)
  • ドメインモデルは、要約したもの。本当に重要な語彙に絞ったものがドメインモデル。
  • ドメインモデルがコードになってるのは、ドメイン層の5%とかのコア。ちゃんと要約しにいかなければならない。
  • ドメイン層全体がドメインモデルというわけではない。
  • 狭い範囲を深堀する、という考えは前提知識として持っていたほうがいい。

■ ドメインとソフトウェア (P.13)
  • 自分たちは右下の「ソフトウェア」に関心がいく。
  • 「ソフトウェア」の左上の境界に現れる画面設計書とかにドメインの言葉が出てくる。
  • でも、それ以外の活動でどう関心事が出てくるか、自分から外に出て、取りに行かなければならない。
  • なぜその人が活動しているか、その目的とか経緯とかまで思いを馳せることが重要。
  • 外に広げれば広げるほど楽になる。
  • ここまで知れば楽になる、じゃなくて、どんどん外に行って、動機とか背景まで知りに行ったほうがわかりやすくなるかなと思っている。

■ モデル (P.14)
  • 大変なのは本質的でないものを削る力。判断できるようになるには、相当知識がないとできない。
  • どちらかを選ばないといけないのに選べない、という状況は、自分の知識不足なだけ。
  • 何が重要かを追い求めるが大事。
  • 厳密に組み立てる力は、ソフトウェアは厳密にしないと破綻するので、ほっといてもフィードバックがかかるはず。それよりも削る力の方が難しい。

■ 第2章 コミュニケーションと言葉の使用 (P.17)
  • ドキュメントを書くくらいなら、聞けばいいじゃん。
  • ただ、残しておいたほうがいい情報はドキュメントにすることはある。
  • ただ、それは厳選する。大事な情報はソースコードに表現されているはず。
  • ユビキタス言語は、「いつでも、どこでも、だれとでも」。エンジニア同士の会話でさえも、お客さんと使うような共通言語を使うべき。

■ 第3章 モデルと実装を結びつける (P.19)
  • DDDでは、モデルはコードに落とす前の作業、ではない。モデルを書いてても、常にコードを考えろ。
  • 具体的に論理的に常に考えてないから、すぐにコードに落とせないんだ。
  • コードを書く人がドメインを深く理解することが最も効果的。
  • ドメインの言葉を使ってるエンジニアのほうが、スキル優れているエンジニアよりいいものを作る。一緒にやってて安心感がある。
  • 1~3章を実践することがドメイン駆動設計。それができれば、第2部以降はHow Toに過ぎない。やりかたは他にたくさんある。

■ 【広告】DDDの3原則を体験的に学ぶ (P.21)
  • 実践のワークショップをやる。 http://ddd-alliance0002.peatix.com
  • 本の実践ではない。
  • 要約力を体験する。
  • 苦労せず楽しくドメインを学ぶにはどういうアプローチがあるか体験してみる
  • UMLとかではなく、言葉とラフスケッチを使ってモデリングする。クラス設計に練り上げる。

■ 第2部のおさらい モデル駆動設計の構成要素 (P.22~)
  • 主題は、モデルと実装の一致なんです。
  • モデルを熟知していても、コードと乖離することはよくある。非常に難しい。
  • そこが不一致になると的外れで構造がねじれたソフトウェアになる可能性が高くなる。変化に適応できなくなる。
  • とにかくモデル(主要な概念)がコード上にあらわれているようにする。それがDDD。
  • そこに切り込むのが今日の第3部のテーマ。

■ 第4章 ドメインを隔離する (P.25)
  • プレゼンテーション層とかアプリケーション層とかデータソース層に、ちょっと修正でIF文とかが入りやすい。
  • そうじゃなく、ドメイン層に集めること。
  • 大切なのは、その3層に紛れ込んでくるドメイン知識をドメイン層に徹底的に移していくこと。

■ 第5章 ソフトウェアで表現されたモデル (P.27)
  • 書籍の図5.6にValueオブジェクトのクラス図が出てくる。5章はこれが理解できるかどうかがすべて。
  • 住所という概念をクラスとして切り出す。ただし、2つで1つだよ、という集約を意識しなければならなくなる。
  • そのトレードオフを相当DDDは振り切っている。関心事ならば、クラスとして分離しろ。
  • 左のクラス図の発想でいる限り、第3部の話は理解できない。
  • 左と右のクラス図の差は非常に大きい。狙ってるのは右のクラス図なんだ。

■ 第6章 ドメインオブジェクトのライフサイクル (P.29)
  • オブジェクトをDBに入れて取り出す、というライフサイクル管理は、別のクラスに担当させることによって、ユーザの関心事をシャープに表現しやすくなる。
  • それらは外出にしましょう。
  • 本質は、ドメイン層をピュアに保つための考えの一つ、ということ。

■ 第7章 より実戦に近い練習 (P.30)
  • 第2部の理解度チェックとして、人と語り合ってみるのが有効。
  • 最初のステップで、ドメイン層を隔離するためにアプリケーション層を導入している。この1ページがキモ。
  • 「ドメイン層」の議論を「機能」視点から隔離し、注目しなければならない情報はなんだっけと考える。
  • ドメイン層にHTMLやSQLのコードが入ると汚染される。
  • そうじゃなく、アプリケーション層を導入して、こーゆう機能を実現します、という「機能」の視点から隔離する。
  • ドメイン層の視点でものを見に行こう。
  • この発想の転換は最初すごく苦労した。
  • 機能分割とか、そういう議論ではない。ドメイン層の議論は、機能の議論でもI/Fの議論でもない。
  • チームがこれを当たり前にできるようになれば、相当変わる。

■ 第2部は基礎練習 (P.31)
  • ここまでの第2部は、当たり前の内容。でも相当ハードルが高い。
  • 私はサッカーが好きなので、スライドの例もサッカーで表現している。
  • 練習の時からヘラヘラやってるのはムカつくんですよ。
  • 練習の時から、試合で90分が経過したヘロヘロの時間まで、徹底的に確実にやること。
  • 第2部わからなかったら先に第3部へいってもいいが、行ったり来たりすることを常に意識してほしい。
  • 常に行ったり来たりすることで、より良いものができていくんだ。


ここから今日の本題

■第3部 より深い洞察に向かうリファクタリング (P.32~)
  • 第1部がきっちり理解できて実践できていれば、第3部はどうでもいいかも。
  • ここまでやると本当に役立つよ、というのをチームで共有できると、もっとわかってくる。

■ 主題:実際に役にたつモデルを探す (P.33)
  • なぜこの章構成なのか、疑問があって、つかみどころがないところがある。
  • 読み直したけど、ちょっとよくわからないな、というところがある。

■ 第3部 導入 (P.34~)
  • ドメイン層の話。
  • 設計技法の話とか技術用語とか出てきても、ぜんぶ疑って欲しい。
  • エヴァンスが第3部で書こうとしてこととズレてるんじゃないか、と疑って欲しい。

■ 役に立つモデル (P.36)
  • 主要な関心事は何? それをわかりやすく表現するのはどういうこと? というのが第3部。
  • コードを相当しなやかにしておかないと、追随できなくなる。

■ コードのいやな臭い (P.38)
  • いやな臭いのTOP4を書いている。
  • コードが悪い、というのはエンジニアならすぐ分かるはずだが、それだけでなく、DDDとして一歩踏み込むこと。
  • 例えば、ドメインの概念を見つけ出して、それをメソッドとして抽出するとか。

■ 「分割」ではなく「抽出」 (P.39)
  • 「分割」ではなく「抽出」ということに気づくまで、すごく時間がかかった。
  • ウォーターフォールなら、大きい物は分割しろ、となる。抽出が分割であると誤解してた。
  • 大きいから分けるんじゃなくて、大きいなら、価値があるものが埋まってるから、それを取り出せ。
  • 小さくするんじゃなくて、大事なものを抽出するんだ。
  • 大きかったら分ければいいや、という考えでは、第3部は理解できない。
  • 隠された大切なものを発見して、それを抜き出す、という考え方は非常に重要。

■ 深いモデル (P.40)
  • ドメインの表面的な側面を捨て去る、とあるが、こーゆうものを捨て去れ、とパターンされてない。なので自分で意識してください。
  • 1章で「トポロジーを外した」みたいな話。でも第3部で具体例が出てこない。
  • でもモデリングのキモ。いかに捨て去るか。
  • 第3部に書かれているパターンをソースコードにすべて適用しようとしても、得られるものはほとんどない。
  • 深いモデルを探求するために焦点を絞っていくのが第3部。
  • どこにフォーカスして第3部の内容を徹底的にやってみるかのフォーカス決めも第3部の重要なテーマ。

■ 深いモデル/しなやかな設計 (P.41)
  • こっちよりあっちのほうが重要だよね、と一言いうのは簡単。でもコードを組み替えるのは難しい。
  • なのでコードのしなやかさが必要。そうしないとコードがついてこなくなる。

■ 「モデル」の発見のプロセス (P.42)
  • 「モデル」という言葉から、コードを書く前にする作業、という考えになるが、そうじゃない。
  • モデルは開発プロセス中で発見していくんだ。

■ 8章 ブレークスルー (P.43)
  • 「なんだ、そういうことか」、「目から鱗」といった経験。
  • 問題意識を持ち続けていれば、「あ、こうすればいいのか」と気づくことができる。
  • 凄い気づきが見つかったからハッピーだよね、じゃない。
  • 凄い気づきを元に実験して実装しなおす判断は、インパクトが大きくてリスクになる。それをどうやってチームで制御しながら取り組むかがブレイクスルーのキモ。

■ シェアとシェアパイ (P.45)
  • 協調融資によるリスク分散。そのドメインの話。
  • 最初の設計は、一回ごとに貸出するシェアと、限度額のシェア、の両方が入り組んでいた。
  • それが、「シェア」と「シェアパイ」にクラス分けることでブレークスルーが起こった。

■ 兆候と結末 (P.46)
  • 兆候に気づいたのが、ブレークスルーに至る重要な感覚。
  • おかしいな、という違和感を持ち続けて、常に疑うことが大事。

■ 第9章 暗黙的な概念を明示的にする (P.48)
  • ドメイン駆動設計のキモ。探求したかったら概念を掘り出しに行きなさい。
  • でも、現実は相当難しい。受託で納期もあるし無理な仕様変更も降ってくるなかでやるのは難しい。
  • 概念を掘り出す5箇条に取り組むこと。

■ 2.ぎこちなさを精査する (P.52)
  • ドメインの言葉で語ってみる。
  • ifとかelseとかが自分の言葉から出てきたら、ドメインの言葉で語れていない証拠。

■ 3.矛盾について熟考する (P.53)
  • 矛盾を感じたら、記憶にとどめておくこと。書き留めなくても良い。
  • 後々、「あぁ、こーゆうことだったのか!」と気づけた時に、それは矛盾じゃなくなる。その時に学習成果になる。
  • 「あー、そうなんだ」と、新しい理解として認識してしまうと、すんなり通りすぎて、学びとして残らない。

■ 4.文献を読む (P.54)
  • 新人教育のテキストがあれば、ぜひ読んでください。そいう人向けに理解させようとする何かが得られる。
  • 全部を自分で理解する必要はない。聞ける人を人脈として育てておく。自分の仕事も楽になる。
  • 文献は、全部を精読しない。
  • 目次や「はじめに」や第1章などで使われている全体図とか比較表、用語集をうまくピックアップして、それなりの感覚をつかむ。

■ 5.何度でも挑戦する (P.55)
  • 回数を繰り返すことが「概念」を発見する基本。

■ 9章の補足 (P.57)
  • 制約、プロセス、仕様、の3つ。これをオブジェクト指向で表現しようとすると大変。

■ 9章の補足:制約 (P.58)
  • 概念を掘り出すためには、なんでもString型でいいじゃん、という考えではできない。
  • 制約のなさに気持ち悪さを感じよう。

■ 9章の補足:「プロセス」 (P.59)
  • 構造はオブジェクトとして表現できるが、プロセスはオブジェクト指向で表現しにくい。
  • プロセスを表現する武器として、イベントストリームやリアクティブは非常に役立つ。
  • ただ最近の流行りとして受け止めるのではなく、ドメインとして認識する。

■ 9章の補足:「仕様」 (P.60)
  • オブジェクト指向では、やめたほうがいい・・・

■ 10章 しなやかな設計 (P.61)
  • この章を10章として独立させてるのは、開発者がドメイン層に集中するためには、こーゆう設計にしておけば楽になるよ、実験がやりやすくなるよ、というメッセージ。
  • メソッドの引数とかはValueオブジェクトにするのが望ましい。型として表現する。intとかだと、ドメインの関心事が表現できない。
  • Valueオブジェクトは5章に出てくるが、10章の実践ネタとしても非常に有効。

■ その他のテクニック (p.64)
  • 「制約」は表明を使ってコードとして表現すればソフトウェアが安定して、実験がやりやすくなる。
  • コードにどんどん制約を埋め込む。

■ 攻める角度 (P.65)
  • 「しなやかな設計」と「概念の掘り出し」は、同じ箇所に両方ないといけない。

■ 第10章のまとめ (P.66)
  • ポイントは2つ。
  • 1.技術者が「利用する人たちの関心事」に集中すための工夫
  • 2.「しやなか」なほど、実験がやりやすい
  • 10章は技術的なことなので、チームでまずここからやってもいいかも。

■ 第11章 分析パターンを適用する (P.67)
  • 11章は、語りたいことが山ほどある。
  • 今日は語り尽くせないので、DDDAllianceの別イベントでやろうと思っている。

■ 第12章 デザインパターンをモデルに関係づける (P.70)
  • デザインパターンは技術的な観点で説明されている。なのでドメインに直接役立つものが多くない。 by エリック・エヴァンス
  • ドメイン層の設計でデザインパターンを取り込むなら、ドメインの言葉でそのパターンがどういう意味を持つのか、チームで話し合って、意味があったら使おう、とするのがよい。

■ 第13章 より深い洞察に向かうリファクタリング (P.71)
  • ブレイクスルーの瞬間は大発見だし、すっきり感がある。だからといってすぐにコードを変更しよう、というのは危険。

■ リファクタリングの方向とタイミングを間違えないために (P.73)
  • どこまでリファクタリングするんだ、いつやるんだ、という方向を間違えないように。
  • ひとりでやるのでなく、選抜チームで取り組もう。
  • 偏った方向に行くのを防ごう。
  • ドメインエキスパートがピンとこないような「深いモデル」、というのはありえない。それはブレークスルーではない。
  • ドメインエキスパートから最悪、ほとんど話をきけなくても、自分たちの考えたことがドメインエキスパートの考えから突拍子なことになってないか、だけは絶対にチェックしろ。
  • ドメインエキスパートからのフィードバックは大切にしなさい。
  • いつでも会話できる、ということよりも、そちらのほうが大事。

■ 第3部まとめ (P.75)
  • 9章を地道にやり続けること。これがDDDのメッセージ。
  • 第2部だけではダメで、第3部の内容を実践してこそ、ブレークスルーとか起こる。


★感想:
自分で本を読んでいたときは、今読んでる章に特化して視野が狭くなってしまいがちです。
でも、こーゆう風に全体を俯瞰して説明してもらえると、「あぁ、あの話は全体のここに位置していて、あの話と繋がるのか」といったような気付きが非常に多い。
自分の考えが整理されて一歩進む感じですね。これがまさしく、8章のブレークするーなのかも。
第3週のイベントも楽しみです。

増田さん、関係者の皆様、ありがとーございました。

「XP祭り2015 “俺も!!”」に参加しました

2015/9/12(土) 「XP祭り2015 “俺も!!”」に参加してきました。

公式サイト
http://xpjug.com/xp2015/

こくちーず
http://kokucheese.com/event/index/324682/

Togetter
http://togetter.com/li/872910

場所は早稲田大学 西早稲田キャンパスです。
参加者は200人弱くらいでしょうか。
今年で私、初参加から4年連続の参加になります。過去に書いたブログはこちら。


というわけで私にとって、毎年恒例の楽しみなイベントになりつつあります。

今年も会場に着くと、協賛の出版各社様からの献本がズラリ。
20150912_xujug1.jpg
毎年、最後のクロージングで参加者にプレゼントされるので、楽しみの1つなのです。

この日、私が参加したセッションは以下のとおり。


今回は講演系ばかりの選択になりました。でも、ワークショップの方も魅力的だったので、両方とも参加したかったなぁ・・・


ということで、自分の復習も兼ねてブログにメモを書くのである。


A-1 オープニング (Agile仙人) – 10:00~10:30
毎年恒例、オープニングを務めるのはAgile仙人お二人による漫才。
このセッションはゆる~く、メモとかは取らずにのんびり楽しみます。
今年は、これまでのXP祭りを振り返る、という内容でした。
私がXP祭りに参加するようになったのはここ4年くらいですが、XP祭りはもう15年くらいの歴史になるようで・・・
でも、長いようであっという間だったのかもしれません。


A-3 XP lives, XP dies, XP lives again!! (角征典さん) – 10:30~11:30
XP matsuri 2015 keynote from Masanori Kado


素晴らしい講演でした。大事なことはスライドに書いてあるので、口頭説明の部分のみ、メモ。

■ XP lives (past) (P.2)
  • XP白本の第2版が出た2004年くらいまでは、XPは生きていた。2008年まではXPは辛うじて生きていた。
  • でも、この後の時期くらいからXPは死んでるんじゃないか。

■ XP dies ... and Scrum lives (P.4)
  • XPがなんで死んだか?原因は無い。ただ、Scrumが台頭してきた。
  • XPの分かりにくかった部分をシンプルに書いて、フレームワーク化したのがスクラムガイドだった。

■ Scrum lives ... (P.5)
  • 認定スクラムマスター(CSM)の取得者が2006年で30000人だったのが、2年くらい経って2009年に60000人と倍になった。
  • この時期がXPが死んだ時期と重なっている。
  • スクラムガイドの著者が「CSMは金儲けの道具ではない」と主張したら、自分が作ったScrum Allianceから、自分もスクラムガイドもscrum.orgに追い出された・・・

■ Agile is Dead (P.8)
  • 書籍「達人プログラマー」で有名なデイブ・トーマスが、アジャイルカンファレンスに向かうバスの中で、二人のアジャイルコンサルタントの会話を聞いて激怒した。
  • そのイベントの基調講演のタイトルを急遽「Agile is Dead」に変更し、帰ってからも怒り心頭でブログを書いた。
  • http://www.infoq.com/jp/news/2014/11/pragmatic-dave-agility

■ GROWS (P.12)
■ デイブ様からのご提案 (P.15~P.22)
  • これらの提案はNo!
  • なぜなら、「一方的に与えるモデル」ではダメだから。自分で掴んでいくモデルじゃないといけない。

■ プリクエル (P.31)
  • (「プリクエル」という単語の意味を知らなかったのでググってみたら、「文学・映画作品などの)前編」とあった。)
  • アジャイルの歴史、つまり以前に何があったかのを知らないと、理解が進まない。

■ Q.「アジャイル」を提案したのは誰?
  • 角さんからの質問に対し、聴講者の1人「マイク・ビードル」 ⇒ 角さん「No」
  • A.「マーティン・ファウラー」です。なぜなら、「アジャイル」の発音がイギリス式だから。
  • アメリカ英語だと「アジル」。最初、みんなが「アジャイル」と発音できるか不安だった。
  • 「アジャイルマニフェストの歴史」のページにちゃんとそう書いてある。(まこぴも読んでみたら第2節に書いてあった!)

■ ぶりきじゃ( Martin Fowler's Blikiの日本語翻訳サイト)
■ Conversational (対話) (P.39~)
  • マーティン・ファウラー 「Conversational が最近のアジャイルでは失われているのが嫌だ」
  • Conversational がなぜ大事なのか、XP白本には書いてない。
  • ケント・ベックのうまく表現できないことを、マーチン・ファウラーがいつもうまく表現してくれる。
  • マーティン・ファウラーは、まとめ職人としてすごい。
  • 有名な「トヨタウェイ」も、マーチン・ファウラーのまとめとほぼ一緒だった。凄い。

■ 科学的管理法
  • XP白本の18章に「テイラー」が出てくる。
  • 科学的管理法により、人間性が失われていった。科学的管理法は人間を歯車的な使い方をする。
  • 生産性を上げようと考える人を立てて、それ以外の人が何も考えずに働く。
  • ただ、人は怠ける可能性があるので、後工程で品質をチェックする人を配置する。
  • このような管理が、科学的管理法である。でも、我々はモノではない。

■ モノの証明(認定) (P.54)
  • XP白本の21章に「認定とか認証は良くない。金儲けしてるだけだ。」と書かれている。
  • XPは、認定とかは作らない。「XP dies」、XPは死んだ、と言われても、認定を作っていない。
  • (認定を行っているScrumとの対比)

■ バートランド・ラッセル
  • 数学者はお爺さんになると、哲学者になるw
  • ラッセルの言っている「個人の独創性」と「社会的結合」の組み合わせる話と、XPは同じことをやろうとしている。
  • クリエイティブなことも必要だし、一緒に働かないといけない。
  • ラッセルの言いたいことが1章冒頭の一文「XPはソーシャルチェンジである」と、簡潔に表現しているw

■ 新しいソーシャルチェンジ (P.59)
  • 誰とでも上手くいくわけではないので、まず最初にTeam Geekを読んでもらう。
  • Team Geakには、個性が強い人たちをどうチームとしてまとめるかの話が書いてある。

■ 三本柱(HRT) (P.60)
  • まず「HRTの文化」を作る。HRTは好き嫌いに関わらず、まず最低限は守ってもらうようにする。
  • (ちなみに私、Team Geekに関する角さんの以前の講演でこの絵を見せられて、HRTと聞くといつもコレ思い出す・・・)

(「北斗の拳」のハート様)


■シンプリシティ (P.68)
  • こんまり先生は、片付けの先生として有名。
人生がときめく片づけの魔法
近藤麻理恵
サンマーク出版
売り上げランキング: 153


■ こんまり流片付け術 (P.71)
  • 「捨てるモノ」ではなく「残すモノ」を選ぶ。
  • それまでは断捨離が流行っていた。ものを捨てていくと生活が荒んでいく実感があった。なので方針転換した。
  • こんまり先生いわく、「それはときめくか?」
  • 方法論としては革新的だった。それは、教えることができないから。
  • ときめきは個人的。教えるものではない。最強のツール。

■ なんか聞いたことがある! (P.73)
  • クリストファー・アレグザンダーは、デザインの美しさとか心地よさとかをデザインに反映しようと考えていた人。
  • 結局はこんまり先生と同じことを言っている。

■ ときめく♥プラクティスを選ぶ (P.78~)
  • XP白本の23章「時を超えたプログラミングの道」は、ときめきの道なんだ。
  • XPをやる時は、ときめく必要がある。ときめくプラクティスを選ぶんだ。
  • XPは「価値」とか言ってるけど、そんなの届けた後にしかわからないじゃないか。
  • 「無駄」とか「価値」じゃなくて、「ときめき」なんだ。
  • ときめき駆動開発。TDD!

■ XPが目指している(いた?)もの (P.82)
  • このグラフは、時間が進むにつれて変更工数は指数的にに増えることを表してる。
  • 時間が経っても変更コストは一定にできる、という下側のグラフがXP白本の第2版にあった。

■ できることを増やすプラクティス (P.83~)
  • ケント・ベックが本に書いたこの例について、マーティン・ファウラーがまとめ職人として上手く表現している。
  • 変更工数推移のグラフを平らにするにはこの3つをやってればいいんだ。
  1. テスト(自動テスト)
  2. 継続的インテグレーション
  3. リファクタリング

■ バリー・ベームからの反論 (P.85)
  • いや、それだけでもダメ。小さいプロジェクトならいけるかもだけど、大規模プロジェクトだとダメ。

■ アーキテクティングは前もって行う必要があるのか? (P.86)
  • 良い設計と悪い設計があって、ちゃんと設計してないと時間が経つについれて機能追加する速度が落ちていく。
  • スタミナ仮説のグラフで、「No Design」と「Good Design」の線の交差点よりも期間が短いPJは設計しなくてもいいかもだけど、そうじゃないなら設計しましょう。
  • そうしないと、技術的負債に落ちていく。
  • 交差点までの期間は、数週間くらい。

■ 技術的負債の四象限 (P.90)
  • マーティン・ファウラーが提唱している。(ぶりきじゃ: http://bliki-ja.github.io/TechnicalDebtQuadrant/
  • 4象限の左半分は無鉄砲で救いようが無いので、捨てても大丈夫w
  • 考えないといけないのは4象限の右下。容易周到にやってるのに不注意。ここをどうするかがソフトウェア開発の関心事。
  • XP白本の14章で扱っている。
  • 経験をベースにした設計が大事。熟考でも、早すぎてもダメ。経験してから設計する。

■ 「経験」してから設計する (P.92)
  • セットベース開発が現実的。
  • 複数案を実装してそこから選ぶとあるが、ブランチ1個で開発したりとか、現実ではやられていない。
  • でも、やってみたらいいんじゃないかな。

■ 可逆性を確保せよ (P.93)
■ モブプログラミング (P.116)
  • モニターとキーボードは1つ。ドライバー1人に対して、他の人はみんながナビゲーターとして見ている。
  • ただ、WIP制限が1なので効率的じゃないよ、とKanban in ACTIONが書いてるけど・・・・

■ ラズベリージャムの法則 (P.132)
  • 「広げれば広げるほど薄くなる」という法則。
  • いろんな人に伝わった結果、よくわからないものが広まっている。それを飲み込むのじゃなく、自分で考えることが大事。

■ イチゴジャムの法則 (P.133)
  • 「粒があれば、どこまでも薄くはならない」という法則。
  • ここで言う「粒」は、人間性と適応性。


■ 昼休み (11:30~13:00)
お昼休みは1時間半と長く、外に出て食事するには十分です。ですが私は・・・


あと、昼休みに出版社さん提供の書籍を手にとって読んでみたり、配布資料に目を通したり、知り合いのスタッフさんと会話したり。
先週買った角さん翻訳の白本をまだ読みきってなかったので、それを読んだり。

そんなこんなで、今年もゲリラLT(野良LT)が始まります。


野良LTお馴染み @take3000 さん、今年はクラスメソッドでの採用活動がLTのテーマでした。
他にもLT司会進行役の侍レッドさんのXP祭り音頭(?)の生演奏があったり。
重音楽戦士特攻隊長の戯言(公開版)~XP祭り2015~ from Samurai Red

今年は聴衆も多くて盛況。のんびり楽しいヒトトキを過ごしました。


A-4 “俺も” XP入門 (木下史彦さん) – 13:00〜13:45
俺も エクストリームプログラミング入門 from Fumihiko Kinoshita


アジャイルで名高い永和システムマネジメントの、アジャイル事業部の事業部長をされているとのこと。
事業部長というと年寄りのイメージがありますが、木下さんはとても若く見えました。何歳なんだろう・・・

■ XPシリーズの書籍
  • ピンクの「導入編」: 具体的なやりかたが書いてある。白本は書いてない。
  • 黄色の「アドベンチャー」編: ピンクのと同様、具体的な進め方が書いてある。
  • 緑の「実行計画」編: 計画づくりのフォーカスしている。
  • 紫の「適用」編: XPを実践した人のコラムがある。
  • オレンジの「実践」編と赤の「ウェブ開発」編: 1つのプロジェクトにフォーカスして説明している。
  • 黒の懐疑編: XPを批判的な視点で解説している
  • 全部絶版なので書店で買えないAmazonで中古が売っていて、8刷全部買っても、合計111円!

■ XPとは
  1. 恐れに対処する
  2. 変更コスト曲線を平らにする

上記をテーマに、書籍で紹介されていることをベースにした解説でした。
私、白本しか読んだこと無い(しかもまだ半分くらい)なので、白本以外の書籍に関する情報はとてもありがたかったです。


A-5 アジャイルとアンラーニング (渋川よしきさん) – 14:00〜14:45
アンラーニング from Yoshiki Shibukawa


角さんと木下さんのスライドが約130枚なのに対し、渋川さんのスライドは全部で20枚!
社内SEとしての取り組みについて、XPを交えてシンプルに纏めらています。

「社内専用のライブラリやフレームワークは誰も使いたがらない。自分のキャリアに役立たないので。」という言葉は刺さりますね・・・
私も自社で技術開発支援的な部門にいるのですが、この辺はきちんと意識してツール開発とか支援をする必要があると思います。

あと、「アンラーニング」という言葉。既存のやり方を捨てて、新しいやりかたを学ぶ。
この辺は、天野さんのLTのテーマだった「老害」にも少し関連しそうだな、と思いました。
新しいフィードバックを得て、自分で経験をして、やりかたを変えていくの大事。


■ C-6 ユーザーストーリーマッピング入門 Agile2015版 (川口恭伸さん) – 15:00~15:45
(スライドが公開されたらココに貼る)



2009年のアジャイルカンファレンスでJeff Patton に合って感銘を受けたのが、以下の本の翻訳にも繋がったそうです
ユーザーストーリーマッピング
Jeff Patton
オライリージャパン
売り上げランキング: 98,666


セッションでは、ユーザーストーリーマッピングのポイントや利点などを紹介されてました。
あと、セッションの中で協調ワークショップについて紹介されてました。
ステークホルダーとか予算出す人を入れて、共通理解を作っていく話や、現在ユーザはどういう問題をかかえていて、どういうところを辛いと思っているか、をワークショップで明らかにするという話がありました。
事前に調査をやっておき、知っている人がいる状態でやることがポイントだそうな。

スライドがまだ公開されてないので、纏めは後で追記予定。


C-7 ユーザーストーリー ネクストジェネレーション (懸田剛さん) – 16:00〜17:00

(スライドが公開されたらココに貼る)

ユーザーストーリの話に始まって、会話の重要性、テンプレートゾンビ、ゴールデンサークル、デザイン思考、NVC、M♡P、狩野モデル、Happy Startuup Cambus、沢田マンション、輝ける大地、etc・・・

非常に多岐に渡る壮大な講演でした。結論的なものはたぶんこれに集約される、でいいのだろうか・・・w





・・・スライドが公開されたらメモを起こす予定。


A-8 LT祭り – 17:15~18:30

毎年恒例、XP祭りの最後を飾るのはLT大会。今年もレベルの高いLTが繰り広げられました。
20150912_xujug2.jpg

LT大会の打順。


現時点で公開されているスライドを貼っておく。

エンドツーエンドテストを自動化したらチームがすごく良くなった@XPまつり2015LT from Taichi Watanabe




俺も!「老害」 公開版 from ESM SEC


"総務も!!"アジャイルプラクティス! from pupupopo88


Xpとシステム思考のシナジー 「8の字を見つけよう」 from Ieda Ryo


いやー、今年のLTも大変楽しめました。


★感想:
純粋に楽しかったし、気づきも多く得られたし、来年もまた行きたいな~と思うのでした。

奮闘してくださる当日スタッフさんが講演をほとんど聞けないのはなんか申し訳ないので、Ustremeの録画&配信とか来年からやってみるといいんじゃないかな~と思うのでした。
そうするとスタッフさんも、後でUstと公開済スライドを見ながら、講演を聞けるようになるので。
同時セッション数も多いので、参加者も自分が参加できなかった裏番組を後で聞けたりする恩恵もあるでしょうし。
もちろんUst配信はそれなりに大変だと思うのですが・・・

登壇者さん、運営のスタッフさん、会場提供の早稲田さん、関係者の皆様ありがとーございました。

「DDD Alliance! 3週連続DDD 第1週」に参加しました

2015/9/2(水) 「DDD Alliance! 3週連続DDD 第1週」に参加してきました。

connpass
http://ddd-alliance.connpass.com/event/18959/

Togetter
http://togetter.com/li/869354

場所は銀座の歌舞伎座タワーあるドワンゴさんです。
参加申込は満員御礼、90人くらいかな。

DDDと言えばこの本。まさしく鈍器!



DDDに関する講演はこれまで、5~6回くらいは参加したでしょうか。
増田さんのDDDに関する講演も3~4回は聞いた覚えがあります。いくつかはブログにも書きました。

あと、@naopi さん主催のDDD本読書会(羊)にも参加してました。
初回に参加したときのブログはこちら ⇒ 2013/6/8(土) 「DDD本 読書会(羊) #0」に参加しました
この読書会は基本毎月開催で2年くらいかかったんですが、全17回+α、無事読み終えましたw

あと長期休暇とかにも1日1章ずつ読んだりと、それなりにDDD本は読んだ気がします。
ただ、やっぱ難しいトコが多くて、とてもじゃないけど「DDDは理解した」という状態には至っていません・・・

そんなわけで今回のイベントにも参加することにしたのです。
ちなみに申込者は130人以上いたと思いますが、私が一番早かった!


第1週(1章~7章)DDDの基本を理解する
  • 第1部 ドメイン駆動設計の3原則 (1章、2章、3章)
  • 第2部 ドメイン駆動設計のグッドパーツ (4章~7章)
3週連続DDDその1 from 増田 亨

大事なことはスライドに書いてあるので、口頭で補足説明があった部分を中心に個人メモ。
---

■ 増田さんのDDDに関する取り組み (P.6)
  • 最初はDDDがよく分からなかったが、分からないながらも現場でやりはじめた。
  • 一番最初のころは読み落としていた、勘違いしていたことがいっぱいあった。
  • 自分の経験から思っていたこととエヴァンスの考えが違っていた。
  • そういう気付きがだいぶあった。
  • 8年やってきて成長できたかな。

■ エヴァンスの取り組み (P.10)
  • エヴァンスはケント・ベックやマーチン・ファウラーと一緒に仕事してきたので、オブジェクト指向やエクストリームプログラミングを組み合わせてやってきた。
  • 本を読んで吸収しようと思った時に、この2つなんだ、というのはキーになる。この文脈で読むと理解できることがあった。

■ 勉強になった本 (P.15)
  • 「リファクタリング」に勝るものはない。「実装パターン」もコードの話ばかり。この2冊はとにかくやった。




実装パターン
実装パターン
posted with amazlet at 15.09.06
ケント・ベック Kent Beck
ピアソンエデュケーション
売り上げランキング: 93,585

  • 「オブジェクトデザイン」がオブジェクト指向の本の中で一番印象に残った。

オブジェクトデザイン (Object Oriented SELECTION)
レベッカ・ワーフスブラック アラン・マクキーン
翔泳社
売り上げランキング: 232,350

  • XPは勉強しなおしている真っ最中。新訳で読んでる。

エクストリームプログラミング
ケント ベック シンシア アンドレス
オーム社
売り上げランキング: 23,663

  • XP本の参考文献に上がってる「わびさびを読み解く」という本は、ウォーターフォール的な物事の計画の立て方と、XPの人間の活動に合わせたソフトウェア開発のやりかたが書いてあって、すごく参考になる。
  • 哲学的なことをが書いてあるわけではない。ぜひ読んでください。

Wabi-Sabi  わびさびを読み解く for Artists, Designers, Poets & Philosophers
レナード・コーレン
ビー・エヌ・エヌ新社
売り上げランキング: 28,712


■ 「適応型」のソフトウェア開発 (P.17)
  • オブジェクト指向とエクストリームプログラミング、2つは車の両輪。
  • オブジェクト指向の変更容易性、エクストリームプログラミングの変化適応性。
  • 前者が後者を支えている。同じ哲学からでてきてるんだろうな、と思う。
  • 相互に補強しあう関係。

■ 「適応型」のソフトウェア開発 (P.21)
(1) 予測型
  • ソフトウェアの最終形を早い段階で早い段階に厳密に定義して、そこへの近づき方を重視するスタイルが予測型。
  • ビル開発なんかもこんな感じ。ただ最近のソフトウェア開発では「それって、どうなの?」ってのはある。

(2) 反復・漸進型
  • 予測型の改善策として出てきたのが反復漸進型。代表はRUP。
  • 遂行フェーズでリスクを潰す。
  • これも大きくみれば計画型。計画して、着地点に到達する。リスク駆動で精緻化していく。
  • これとアジャイルはまったく違っている、と個人的に思っている。この理解がDDDのキーだと思っている。

(3) 適応型
  • XPは変化に適応しながら育てていく、という点が重要で、DDDのポイント。適応型に相当重きが置かれている。
  • 適応型も、最終形はざっくり考える。でも最初から全部わかるわけがない。
  • ドライブのメタファ。目的地は決まっている。ルールやスピードは走りながら調整していく。
  • 天候が変わったり、ドライブ中に見つけた場所に寄り道したり。
  • 「関係者が納得すればそれでいいじゃない?」という考え方。
  • みんなで合意してれば、当初の予定と全然違うところに到着したっていいじゃない。
  • 人間のリズムを重要視している。そういうふうにしたほうが人間的なエネルギーが出るよね。

■ YAXP(もう一つのXP) (P.23)
  • YAXP(Yet Another XP)というのは「もうひとつのXP」。自分が名付けた言葉。
  • とにかく動くソフトウェアを作り続ける、という、究極のXP。曖昧な要求、口約束、なるはや、追加と修正の嵐・・・
  • 自分のこまでの経験で、口頭で依頼を受けた開発の最高額は6000万円だった。
  • 適用型のソフトウェア開発では当たり前。DDDの良い実践の場。

■ 抽象データ型/段階的な抽象化 人間の発想に近づける (P.27)
  • Javaにはintとかshortとか、言語仕様レベルのレイヤがある。それを使って日付を表現しようとすればできる。
  • そうじゃなく、人間の日付という概念に、コンピュータの要素をラップする形で近づけたのがLocalDateクラス。
  • 言語仕様レベルのレイヤから、人間のやりたいことに近づけていくのが段階的な抽象化。
  • DDDは徹底的にこれをやる。関心があるものだけ記述する。

■ OO + XP = ドメイン駆動設計? (P.28)
  • 半分はYESかな。
  • DDDは、OOの最終形。OOのコミュニティで評価が高い。
  • エリック・エヴァンスは、「OOとXPの、それぞれの設計で強調しているところに名前をつけたのがDDDである」と言っている。
  • OOが忘れたものを思い出させてくれる。

■ 「ドメイン駆動設計」の理解の鍵 (P.30)
  • ドキュメントより会話、は精神論として知られているが、ドキュメントは「過去のもの」という点も重要。
  • チームで合意をとって進むのに大事なのは「言葉」なんだよね。
  • 毎日言葉を使って会話していくことで理解を共有していく。
  • OOとXPが鍵なんだ、と気づいてから、DDD本の「まえがき」に納得感が生まれた。

■ 「ドメイン駆動設計」の3原則 (P.32)
  • 1~3章の理解と実践がDDDのすべて。
  • 1~3章にもでてくる話を自分なりに実践するだけでも価値は出てくる。

■ ドメイン (P.33)
  • ドメインとは、ソフトウェアを利用する人たちの「活動」と「関心事」。
  • ソフトウェアを実際に使う側の人たちはコンピュータに興味があるわけではなく、ビジネスや業務上の成果が関心事。
  • それを理解したうえでソフトウェアを作りに行くんだ。
  • 技術者にとってドメインは画面仕様書とか機能一覧とか。そこにドメインの言葉は確かに出てくる。でも、そこの言葉と利用者側にすごくギャップがあるから、ユーザ側にもっと切り込んでいかないといけない。

■ ドメインのモデリング (P.36)
  • 利用する人たちの「活動」と「関心事」を要約する。
  • 軸となる関心事をいかに見つけに行って、「これが嬉しいんですよね」と、いかに要約して説明するか。
  • 「要約」がモデリングのキモ。
  • 「要点」はなんだんだ、骨格はなんなんだ、と探しに行くことがモデリング。
  • 本質的でないものを削る力は、発見する力よりも難しい。理解できるようになるには、相当ドメインの知識を増やさないといけない。
  • ドメインエキスパートは、何か重要かをわかりやすく説明はしてくれない。
  • わかっていても、言語化できるかは別能力。だけど、間違っていたら正すことはできる。
  • なのでドメインエキスパートに話しかけて、フィードバックを得ることが重要。
  • 耳を傾ければしゃべってくれるのではない、我々が探しにいかなければならない。
  • ユーザの企画書は怪しい。綺麗事や官僚的な作文が多い。そこを確認しにいくのもエンジニアの仕事の1つ。
  • ユーザが何に感心を持って活動しているのか、を要約できる力がDDDを実践していくうえでの一番のスキル。
  • 言葉とかスケットとかコードとか、目や耳で感知できる形にして、チームで共有する。

■ 第1章 (ドメインの)知識を噛み砕く (P.42)
  • いろんなメディアを使いながら知識を噛み砕く、と本には書いてある。
  • まず知識を噛み砕く。出発点ですぐにソフトウェアを作り始めてはいけない。
  • P.49のまとめスライドに書いてあることができていれば、DDDができているということ。

■ 第2章 言葉を使った意思の伝達 (P.51)
  • UMLでなく言葉でチームに浸透させる。設計ドキュメントやレビューの代わりに言葉で伝える。

■ ユビキタス言語 (P.52)
  • いつでも、どこでも、誰とでも。
  • 「同じ言葉で語れ」ということよりも「いつでも話すこと」が大事。技術者同士での会話でもユビキタス言語を使う。
  • ある単語が出てきたとしても、同じ意味とは限らない。これを発見して、1つの言葉を同じ意味に揃えることが大事。
  • 「おまえのいってる○○って、こーゆうこと?」と突っ込む。
  • なんかおまえのいってること違うな、と思ったら突っ込んで確認することが大事。
  • ドメインモデルはユビキタス言語の全部じゃない。
  • ユビキタス言語は500とかに最終的にはなる。ユビキタス言語のコアを抜き出したものがドメインモデルになる。

■ 声に出してモデリングする (P.53)
  • しゃべる、聞く、がコスト低いし、感覚的に「おかしい」と気づくのに一番よい。読んだり書くよりも格段に感度が高い。なのでそれを使いましょう。

■ 一つのチームに一つの言語 (P.54)
  • 第4部の「境界づけられたコンテキスト」の基本原理となっている。
  • 第4部の「継続的な統合」、も、CIという意味ではなく、言葉の不一致を継続的に統一していきなさい、ということ。どう見つけて統合していくかに言及している。
  • このあたりにDDDの言葉のわかりにくさがあるかもしれない。

■ 言葉たいせつ (P.56)
  • 開発者が、利用者の「重要な関心事」をよどみなく語り始める。こうなれば安心。プロジェクトに大きな問題は起こらない。
  • 開発者が技術用語しか使わない恐怖感。開発者が何を作ってるかわからない恐怖感。大外ししている可能性が0ではない恐怖感。

■ 第3章 モデルと実装を結びつける (P.57~」
  • モデルは分析に使えるだけでなく、設計に使えないといけない。

■ 第2部 モデル駆動設計の構成要素 (P.66)
2部は基礎練習。どんな状況でもできるようにしなければならない。

■ レイヤー化アーキテクチャ (P.68)
  • ドメイン層を分離し、すべての層がドメイン層に依存するようにする。
  • これを表面的に実装するのは難しくない。問題なのは表面的な分離でなく、ドメインロジックがコントローラー層やページ記述に染み出したりした場合。
  • 状態の判断がビューに染み出してたら、ドメイン層に持っていかなければならない。
  • そいういう作業をすることによってはじめてドメイン層に知識が集まる。
  • いかに検知してドメイン層に持ち込むか、リファクタリングを緊密に実施するか、が重要。
  • SQLのSELECT文で、WHERE句でイコール条件を使って区分を判定していたりしてたら、ドメイン層からドメインが抜け落ちているシグナル。

■ 2ステップビュー (P.72)
  • エンタープライズアーキテクチャパターンに登場する。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)
マーチン・ファウラー
翔泳社
売り上げランキング: 97,624

  • STEP1はドメインオブジェクトが論理構造を返す。
  • <tr>といったHTMLタグは見栄えのビューなので、STEP1とは分ける。
  • STEP1で論理構造をマップとしてまず持たせて、STEP2で、マップから物理構造に変換するための変換クラスを作る。
  • 全部ビューで組み立てるのではなく、可能な限りドメインオブジェクトに持たせる。

■ 第4章まとめ (P.75)
  • ポイントは、ドメイン層からの漏れ出しにいかに気づいて、いかに防ぐか。

■ 第5章 「モデル」をプログラムで表現する
  • モデルとコードの一致は難しい。
  • 5章は表面的なことで、出発点。DDDなら誰でもやっている。

■ 何が違うのか? (P.80)
  • 左のクラス図のままだと、モデルとコードを一致させにくくなる。
  • クラス図には、顧客と住所はいつも一緒に考えないといけないんだ、という「集約」を表現したい。
  • 左のクラス図のほうがシンプル。
  • でも右のクラス図のほうが、「住所」という関心事があるのならクラスとして分離し、面倒な「関連」と「集約」を背負い込んででも、モデルとコードを一致させよう、という意思が読み取れる。
  • この違いが、5章のすべて。
  • 左のクラス図ほうが楽。でも、右のクラス図はめんどくさくなるけど、モデルとコードが一致させられれるようになる。
  • 左のクラス図は、下3つのフィールドが「住所」だ、という情報がどこにも入ってない。
  • 右のクラス図は、その3つが「住所」だと明確に表現されている。
  • こーゆう感覚をチームで自然に共有できるようになるかがDDD実践の鍵。
  • 住所をクラスとして分離することで、「住所が無い時はどうするんだっけ?」、「住所が複数ある時はどうするんだっけ?」という議論が出てくる。
  • この思想と設計は、どんなにめんどくさくても、ロスタイムのへろへろな状態でもやるんだ。

■ 値オブジェクト(Value Objects) (P.83)
  • 関心事を表現する独自の型を作り、メソッドの引数や型に指定することで、メソッドを知識豊かに表現する。

■ エンティティ(Entity) (P.84)
  • エンティティ=データベース、という考えが染み付いてるので、エンティティは太りがち。
  • エンティティは、「識別」という利用者の関心事に集中する。
  • とことんスリムにする。
  • Valueオブジェクトは、関心事の抽出を繰り返すことによって見えてくる。ここでは一意識別の話は忘れてください。
  • 人間が同姓同名にぶつかった時にどう判断するかを掘り下げていくことによってドメインの理解が深まる。

■ ドメイン層のサービス (P.85)
  • 「サービス」を覚えたばかりのエンジニアは、なんでも「~Policy」というクラスに分離したがるが、これは危険。手続き型になっちゃう。
  • 回避策としては、メソッドの引数と戻り値の型を「ドメインオブジェクト」にすること。そこにlongとかStringとか使わない。

■ ファーストクラスコレクション (P.88)
  • コレクションをラッピングしたドメインオブジェクトを定義することで、「一覧」から関心事を取り出すようにする。
  • ユーザの関心事と一致させられる。

■ モジュール(Packages) (P.90)
  • モジュールは本当に重要なモデリング要素なので、名前や構造を変える作業は積極的にやってください。
  • コードを、利用する人たちの構造に沿って整理すること。

■ 第6章 ドメインオブジェクトのライフサイクル (P.94)
  • 「集約」、「ファクトリ」、「リポジトリ」の3つは、ライフサイクルや整合性が強調されている。
  • なぜそれらを問題視しているかというと、モデルに余計な心配が入ってきてモデルとコードの整合が崩れやすいから、「集約」、「ファクトリ」、「リポジトリ」の3つを使うといいんだよ、と言っている。
  • ドメインの関心事から生まれる設計でなく、関心を守るために必要なものが「集約」、「ファクトリ」、「リポジトリ」の3つである。

■ 第7章 言語を使用する:応用例
  • 7章は実践例。ぜひ読み直して欲しい。
  • 流れが12ステップある。この流れを意識するとだいぶ楽になる。
  • 各ステップで何をやってるかがわかると、モデルを育てる、歩調を合わせる、というのがだいぶわかってくる。
  • まず、アプリケーション層を導入する、というのを一番最初(ステップ2)でやっている。ここでドメイン層の議論を機能の視点から隔離している。
  • アプリケーション層は、機能からドメインを分離する。ここは勉強する価値が非常に高い。
  • 入出力項目の定義はほとんど登場しない。それらを固めるアプローチはDDDではない。ソフトウェア開発では入出力項目の定義はぜんぜんアリだけど、DDDではない。
  • 関連・集約・リポジトリは、7章の具体例をよく読んでください。6章より7章の例のほうがわかりやすい。


★感想:
この勉強会に参加することが決まってから、じゃあ1~7章をもう一度読みなおしてから勉強会に参加しよう!という気持ちになりました。
もちろん7章をじっくり読むには時間が足りなかったのですが、それでも太字の部分を中心に拾い読みしつつ、一通り目を通してから参加しました。
そいういう意味で、この勉強会は再度勉強しなおすチャンスを与えてくれました。
その副産物の効果がとても大きく、復習のモチベーションに繋がったのはとてもありがたかったです。

あと、増田さんの説明も大変わかりやすく、新しい気づきもたくさん得ることができました。




第2週も当選したので参加する予定です。
増田さん始め関係者の皆様、ありがとうございました。

-->