2015/03/18に開催された、要求開発アライアンス ３月定例会「アジャイル時代のモデリング」レポートです。
（3/18 19:00~）要求開発アライアンス ３月定例会「アジャイル時代のモデリング」 - 要求開発アライアンス | Doorkeeper
スライド資料に無い説明を中心にまとめています。ぜひスライド資料を併せてご覧ください。
【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
はじめに
今回の資料は海外（英語）のコンテキストで作られている。
海外では通常の開発であればアジャイルが当たり前となっている。
プレゼン資料の表紙はサグラダ・ファミリア。サグラダ・ファミリアは長期間にわたって破たんすることなく建造を続けている。
アジャイルであっても規律を持つことで大きな開発に適用出るのではないか？という思いがある。
Agile と Design
アジャイルの原則はシンプル。だが、詳細は書かれていない。
デザイン（設計）はどこで行うものなのか？
"While code is the truth, it is not the whole truth." - Grady Booch
コードは真実だが、コードが全てではない。
コードを保守し続けるために、コード以外の何かが必要ではないか。
BDUF(Big Design Upfront)のアプローチはこれまで失敗してきた。例えば、汎用性を持たせた設計をしても、使われなかったり、複雑になりすぎたりする。
WikipediaのBDUFの概説です。
Big Design Up Front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started.
Big Design Up Front - Wikipedia
BDUFとNDUF(No Design Upfront)の間にあるENUF(Enough Design Upfront)を目指す。
平鍋さんのインタビュー記事でもENUFについて触れられています。
先ほどの「よい按配」にあるのが、ENUF（ENough design Up Front）という考え方です。まずはシンプルに設計して、一回お客さんに見てもらいましょう。その方が、絶対に顧客満足度が上がるし、良いものができますよという信念です。過剰品質、過剰デザイン、過剰設計に陥らないようにする。前工程に時間を掛け過ぎないことが重要なんです。
開発者たちがアジャイル開発に抵抗感を示すワケ (1/3)：EnterpriseZine（エンタープライズジン）
"Let's keep the modeling baby but throw out the bureaucracy bathwater" - Scott Ambler
官僚主義（例えば無駄な承認フロー）を省き、モデリングの本質を考えよう。
モデリングによって可視化することで、テキストで起こりがちな誤解を回避できる。
百聞は一見にしかず(A picture is worth 1,000 words.)。
担当範囲だけ見ていても全体像は見えない。モデリングによって全体像を可視化する。
どんなモデルがコードの次に必要か
コードの全てをモデル化するのはアジャイルではない。だが、モデルが少なすぎると共通理解が成り立たない。
共通理解のために必要な資料を"Keeps"と呼び、一時的な資料を"Temps"と呼ぶ。"Keeps"の資料はメンテナンスし続け、"Temps"の資料はミーティングの間のみ用いる（ミーティングが終われば捨てる）。
"Keeps"に含めるもの。
- アーキテクチャ
- 全体像。自分の担当場所を指し示すことができる。
- クラス/パッケージ図
- ドメインモデル
- ユーザと開発者をつなぐもの。
- クラス図/ER図
- キーユースケース
- 代表例となるユースケース図
- シーケンス/コミュニケーション図の重要ポイント抜粋版
"Keeps/Temps"の考え方はastah*の開発でも適用している。
ミーティングではホワイトボードにKeepsをプロジェクタで投影しつつ、"Temps"を描くスタイルがよかった。
アーキテクチャはどこから来るのか。
⇒パターン、過去の事例、メンバーの経験など。
アーキテクチャの詳細を詰めすぎるとBDUFになるので注意。
アーキテクチャを刈り取る(Harvesting Architecture)。
『アーキテクチャを刈り取る』について、平鍋さんが「第9回UMTPモデリング技術ワークショップ」で発言された言葉を引用します。
平鍋
http://www.umtp-japan.org/modules/activity2/index.php?id=179#architecture
僕がアーキテクチャを刈り取るという意味で言ったのは、実はあまりリファクタリングと関連していないかもしれません。エクストリームプログラミングでは縦パスを1つend-to-endで通すということをまずやります。そのときにはまだ有効なアーキテクチャが何かは分かりませんが、たとえばUIからDBなど縦パスが動いてビジネス価値があるものを作りました、となる。そして、もう1本作り始めます、こうやったら動いた、というのを繰り返していくと、アーキテクチャがそこに現れるのではないか、ということです。つまり先読みをして、1本通す前に絵を描いても、あまりその絵は機能しなくて、そこに季節がめぐって皆で作っていくと、秋にはそれができているでしょうと。
スライドで『"Architecture"の例』として挙げたのはAstah*の実例。
パッケージの責務（役割）をラベルに記載している。
パッケージ間の依存関係を描くことはとても大切。
ドメインモデルを学ぶにはDDD本を読む。
ドメインモデルにおいて用語辞書が一番大切。
ステークホルダーが話す共通語となり、要素の名前となる。
用語辞書は日本語と英語で書く。英語表記の揺れを防ぐため。
コードはCPUに命令するためのものではない。やりたいことを表現する。
『"Domain Model"の例』はAstah*の実例。
外国の方向けに『「寿司」のドメインモデル』を用意した。
余談だが、"Shiromi"（白身）と"Akami"（赤身）のレイヤーが違うことにツッコミを受けたことがある。でも、やっぱり"Akami"は"Maguro"（鮪）のサブクラスだと思う。
『"Key UseCases"の例』で黄色の要素は代表例として挙げていることを表している。
メカニズムはコミュニケーション図で描くのが好み。シーケンス図でもよい。
"Keeps"上に"Temps"を重ねる、とは"Keeps"の要素を使って"Temps"のモデルを作るという事。
Scaling
LeSSとはLarge-Scale Scrumの省略形。
"Rather than divide and conquer, an XP team conquers and divides" - Kent Beck
分割統治だけではうまくいかない。XPでは動くものをまず作り、それから分割する。
まずはモデルと動くものを作る（スライドではTIGER TEAMが担当）。動くものができてからサブチームに分割する。最初のチーム（TIGER TEAM）メンバーはサブチームに分かれ、知見を共有する。サブチームでの成果を"Keeps"にフィードバックする。
"Model to have a conversation." - Craig Larman and Bas Vodde
会話をするためにモデルを作る。
モデルは会話のためにある。会話が大切。
他にKeepすべきもの
アジャイルの中心は「人」である。設計書ではない。
"A lot of design information lives in tribal memory." - Grady Booch
設計情報の多くは種族記憶(trinbal memory)の中にある。
チームメンバーの記憶の中で共有されているが、明文化はされていない。
式年遷宮はペアプログラミングのようなもの。ノウハウと暗黙知の共有。
ソフトウェア開発でも暗黙知の共有で成り立っている。暗黙知を排除しようとしたのがソフトウェア工学だが、その揺り戻しとしてアジャイルが生まれた。
式年遷宮の意義についての解説です。
式年遷宮では、約800種1600点の御装束神宝を古式により新しく作り殿内に納められます。古代のままに、その時代時代の最高の刀工、金工、漆工、織工など美術工芸家によって調製されています。
http://www.sengu.info/qanda02.html
しかし、太刀（たち）の原料の玉鋼（たまはがね）、染色料、国産絹糸等御料の入手が難しく、砂鉄をタタラで操作する和鉄精錬の技法の継承者も少なく、草木などを用いる染色家、錦織や組紐などの技術者も後継者が実に困難状況になってきています。このような中で、20年毎に繰り返す仕来りによりこれらの技術も受け継がれて来ました。また、わたしたち日本人の生活や社会を支える文化も同時に育くまれて来ました。ここにも遷宮祭の意義があると思います。
Tips
keepするモデルは振り返りながら取捨選択する。
人の強みは"Question and Answer"できること。ドキュメントは"Answer"しかできない。
idobata(Idobata)はチーム開発にフォーカスしたグループチャット。
開発ツールとの相性が良い。JenkinsやGitHubとも連携できる。
以下、永和システムマネジメントでの活用例。
・BOTで朝会の時間を告知する
・毎朝、カンバンの写真を撮って送る
Q&A
Q.
アジャイルな開発を実践した結果、グチャグチャになったコードに対し、モデリングからやり直したい。どこから着手すればよいか？
A.
やり直すことを目的とするなら、パッケージ間の依存関係を整理できるかがポイント。依存関係を整理できなかったり複雑すぎるなら、一から作り直した方が良いかもしれない。依存関係が整理されていればサブパッケージ単位での改善が可能。
Q.
銀行システムを担当しているが、膨大なドキュメントをスリム化させたい。どうしたら良いか？
A.
ドキュメントを捨てることは怖い。責任問題になるから。
ドキュメントのスリム化を進めるのであれば、強いリーダーシップをとるしかない。重複するものや他のドキュメントから導けるドキュメントを整理するところから始めるとよいかもしれない。
Q.
メンバーの離任で失われる"trinbal memory"をどう保持すればよいか？
（平鍋さんとの名刺交換の際に質問させていただきました）
A.
メンバー離任による"trinbal memory"の喪失はアジャイルでもウォーターフォールでも変わらない。ノウハウの共有を普段から行うことが大切。例えば、ペアプロ、レビュー、チャット、GitHubの活用など。
idobataならログを無限にさかのぼれるので便利。
参考
平鍋さんご自身で今回の講演について書かれたエントリです。講演中に紹介された資料リンクがそろっています。
An Agile Way — 要求開発アライアンスの定例で、「アジャイル時代のモデリング」を講演しました。集まって頂いたみなさん、あ...
所感
無駄なドキュメントは作りたくない。でも、何をどこまで作ればよいのか、という悩みに対して、今回の講演では"Keeps/Temps"というキーワードで一つの方向性を示していました。このキーワードは実践と振り返りを繰り返すことで、各現場に合ったやり方を見つけるためのフレームワークとなりそうです。
また、参加者の中にはアジャイル開発で"Keeps/Temps"に近いことを既に実践しています、という方がいました。アジャイル開発という枠組みの中で異なる場所で同じ考えに到達したという事に"Keeps/Temps"というアイディアの有用性を感じました。
参加者には証券や銀行のシステム開発に携わる方がちらほらいました。この分野でアジャイル開発が一気に広まることの想像は難しいですが、将来に向けた動きとなるかもしれません。
講演者の平鍋さんとは名刺交換させていただきました。平鍋さんのエントリで感謝の言葉をいただきましたが、こちらこそありがとうございました。
