DoorKeeper
https://redajp.doorkeeper.jp/events/20994
場所は新宿の日本総合システム株式会社 大会議室です。
参加者は５０人くらいでしょうか。
この日の登壇者は平鍋さんで、内容も私が興味ある「モデリング」ということで、期待大でした。
ちなみにこのイベントに対して平鍋さんがブログに書いてます。
要求開発アライアンスにて、「アジャイル時代のモデリング」お話しました。 （ブログ） http://t.co/Q2uo8nmO93 #redajp
— Kenji Hiranabe (@hiranabe) 2015, 3月 20当日から１周間以上経ってしまいましたが自分用復習メモ。
■ なぜモデルを使うのか？
- 人間はイメージの方が概要を上手くつかむことができる。
■ モデリングの本質
- コードと重なるモデルを全部書くのは意味がない。保守が大変になるだけ。
- そこで、モデルを２つに分ける。KeepsとTemps。
- 全体像をみんなに示して、すすめていくのが、Keeps。メンテする。軽く保ってコードと一緒にメンテしてください。
- その場限りのモデルが、Temps。終わったら捨てる。
- この２つを区別してスプリントの活動で使ってはどうか。
■Keep
- アーキテクチャ
- ドメインモデル
- キー ユースケース
■アーキテクチャ
- アーキテクチャは、全体の構造を示す見取り図。
- 私はココを担当してます、と指を指せることが重要。
- クラス図、パッケージ図が代表例。
- システム全体の構造的な表現。
- ポイントは、「よく知られたパターンが存在する」という点。
- アジャイルの人は「アーキテクチャは発現する」というが、それは怖いと思っているｗ
- 過去にやったことある例を必ず僕（平鍋さん）は見るようにしている。
- アーキテクチャは、システムの要求からはこない。
- 過去の人類の知見からも来るし、会社の老人の知見からも来る。
- アーキテクチャのカタログやパターンから持ってくる。
- 「これを使う」と決めたからといって、詳細化するとビッグデザインになってしまう。
- フレームワークもアーキテクチャの選択の１つ。
■ Pattern-Oriented Software Architecture
- この本にいろんなパターンが出てくる。
- ノー知識で乗り込むより、知見を勉強してからのほうがずっと良い。
 | Pattern-Oriented Software Architecture: On Patterns and Pattern Languages (Pattern-Oriented Software Architecture) (2007/04/13) Frank Buschmann、Kevin Henney 他 商品詳細を見る |
■ Architectureの例： Astah
- このパケッジ図はずっとメンテしている。
- 各パッケージに役割を書いておくのがポイント。
- 依存関係を書くのも超大事。
■ドメインモデル
- このシステムが扱うデータの構造を表す。
- 利用者がよく使う言葉群
- 最終的にはクラスの名前になったり、DBの名前になったりする。
- DDDを読んでください。
 | エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) (2011/04/09) エリック・エヴァンス 商品詳細を見る |
- 問題領域（ドメイン）の概念とそれらの繋がりがドメインモデル。
- 用語辞書をプロジェクト作ると思いますが、あれが一番大事。
- 用語辞書と、できれば、用語間の関係があったほうがいい。それがクラス図。
- 名前は、英語と日本語の両方つけたほうがいい。英語の方はプログラミングに落ちる。
- 人間のコミュニケーションレベル
- 全ステークホルダーで使う語彙。
- プログラミング・レベル
- コードを構成する要素の名前付けで出てくる。
- 普段見る名前は、概念モデルの言葉だけが出てくるようになる
- C言語でmalloc関数の呼び出しとかがロジックの途中に出てくるが、それはシステムの言葉。
- 業務のドメインの中に、急にシステムの言葉が出てくるのはおかしい。
- あと、for(i = 1, i <10; i++) とかも、10回ループを回したいだけなのに、呪文みたいな構文で意味がない。
- Rubyは、10.timesでいいじゃん、としている。その方がちゃんと意味を表している。
■ Key UseCase
- 「キー」がポイント。全部書かない。
- キーユースケースについては、発動してからシステムをどう通って実現されるかのメカニズムを書く。
- ユーザから見たシステムの代表的な使い方を書く。
- アーキテクチャを貫くメカニズムを書く。
- 開発者には教育的な例示となる。ただ、全部は書かない。
■ Kepps上にTempsを重ねる
- ホワイトボードにKeepsを投影して、その上にTempsを書く。
- Tempsはカジュアルモデリング。書いたら捨てる。
■ Scaling
- 100人のアジャイルチーム、どうしますか。
- Lessというのがある。
- 本の中の引用で、ケントベックが「ソフトウェアは分割統治できない。生命も一緒。」と書いてある。
- 「分割統括するよりも、conquer＆divedeだ！」
- まず動くものを1個作りなさい。その後に分けなさい。
- たくさんチームがあって大きかったとしても、Keepsとして動くトコまで作り、そのKeepsを持ってサブチームに行って、そのチームにしばくらいなさい。
- ドキュメントでなく、動くものと動かした人とモデルを持って、Tempsの話をしなさい。
- Keepsに修正が入ったら持って帰りなさい。
- 動かないものをバラ撒くな。
■ Model to have a conversion
- 本の中で、「会話するためにモデルを作りなさい」と言っている。
- モデルが偉いんじゃない。モデリングする活動が偉いんだ。
- スケールの問題を考えるとき、誰かが考えてバラ撒くのはダメ。動かしてconquerしてから。
■ Other to Keep
- Keepsの対象として、意思決定の理由をリストにしておく。
- なぜそうしたのかを書いておく。
- テストの戦略も、伝えるもの。
■ 式年遷宮
- 同じ神様の社を隣接した土地に作る。25年ごとに引っ越す。
- なぜこうするのか。
- ハードは劣化する。作り変える時になってしまっては、作れる人がいなくなる。
- 人間がいなくなるまえに、ペアプロならぬペア引っ越しする。
- 作った記憶を部族が持つ。人間から人間へ、経験をもって伝える。
■ ふりかえり
- Keepsするモデルは文脈依存する。やってみてチームで合意する。
- ふりかえりをやって、このモデルをKeepsにするかTempsにするかを決める。
■ まとめ
- 設計は大事。アジャイルでも大事。
- ただ、全部書こうとすると無理。なので最もシンプルなモデルセットを選ぶ。
- 動かしてから分ける。
- 最初の出だしは、アーキテクチャを作る目的でチームを作って、動くものを作る。
■ おまけ
■ FAQで出た話題
- 上手く言ったプロジェクトは、必ずぐちゃぐちゃになってる。
- Martin Fowler氏が提唱している「犠牲的アーキテクチャ」という考えがある。
- TempsとKeepsの分けるキッカケは無かった。人間の勘。
- ドキュメントはやりとりができない。なので人間の特性を上手く使うことが大事。
- 平鍋さんが紹介した、参加者である原田さんの講演スライド「モデリングもしないでアジャイルとは何事だ」
★感想：
モデルをKeepsとTempsという２種類に明確に分ける、という考えがすごくしっくりしました。
名前を与えたのはで、「それはKeepsだね」とか言えるようになるのはデカイですね。
あと、平鍋さんの話はすごく引きこまれます。
あーゆうふうにしゃべれるといいなぁ
皆様、ありがとーございました。
