パターン言語

2016/12/05

AgileTourOsaka2016の感想

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

| | コメント (0)

2015/08/25

「ビヨンド ソフトウェア アーキテクチャ」は買い?

ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ(LukeHohmann 岡澤裕二 和智右桂) | 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか! これはとても良い本でした。 - t-wada のコメント / はてなブックマーク


(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス(マーキテクチャ)と技術(ターキテクチャ)をつなぐ架け橋として、情報システム部の方全員に読んでほしい本(情シス必読書)です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか?」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A:リリースチェックリスト
補遺B:戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな?

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

| | コメント (0)

2014/10/13

【告知】第7回redmine.tokyo勉強会を開催します~テーマはRedmine利用時のアンチパターン

2014/11/15土にredmine.tokyo第7回勉強会を開催します。

【元ネタ】
第7回勉強会 - redmine.tokyo

第7回redmine.tokyo勉強会 - PARTAKE

第7回redmine.tokyo勉強会 懇親会 (夜の部) - PARTAKE

(引用開始)
shinagawa.redmine あらため、redmine.tokyo の第7回勉強会を開催します。

Redmine利用時のアンチパターン、システム統合事例、新バージョン情報の他、LTを予定しています。

また今回、実験的にオープンディスカッション形式のセッションを行います。
申し込み時のアンケートで下記について意見を募集していますので、ぜひご回答ください。

1.Redmineをどのような用途で使っていますか。またはどのような用途で使えることを期待しますか?
2.Redmineを使ってみた上での問題点、または、これからの利用を考えるうえでの懸念点。

日時
2014/11/15(土) 13:00~

場所
東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー15F

Twitterハッシュタグ
#redmineT
(引用終了)

【1】私は、以下の内容で講演します。

タイトル:「RedmineのFAQとアンチパターン集【2014年度版】(仮)」

概要:
プログラマ上がりのプロジェクトリーダーは、チーム運営やプロジェクト運営の経験が不足しているため、Redmineのチケット駆動運営が上手くいかない状況が時々あります。
その原因の一つは、チームや案件の制約条件の違いによって、チケット管理を微妙に変えて運用することに気付かなかったこともあります。
今回は、自分の経験談を元に、チケット駆動開発のアンチパターンを説明します。

【2】講演の目的とねらい

おかげさまで、「Redmineによるタスクマネジメント実践技法」は4年経った今でも出版されています。

さかばさんはTwitterを使っています: "おかげさまで増刷(第7刷)が決定しました。累計部数は9,500部。ヒット作品まで、あと一息です。/ 小川 明彦 の Redmineによるタスクマネジメント実践技法 http://t.co/PxuwT2uFxQ"

私は、Redmineで初めてアジャイル開発を実践し、チケット駆動開発という開発プロセスを定義しようと色々模索していました。
そして、Redmineが今後発展する方向のアイデア: プログラマの思索にも書いたように、6個のテーマを今も思索しています。

【2-1】アジャイル開発への適用
【2-2】チケット駆動開発のプラクティス集 or パターン言語
【2-3】Redmine運用のアンチパターン集
【2-4】Redmineの運用パターン集
【2-5】開発基盤としてのRedmine
【2-6】メトリクス収集ツールとしてのRedmine

今回の勉強会の発表テーマは、【2-3】Redmine運用のアンチパターン集の続きです。
2011年に第1回RxTStudy勉強会で発表した時は、「空っぽのロードマップ」「停滞したチケット」「工程単位のバージョン」などのように、Redmineを入れたのにアジャイル開発の良さを発揮できないアンチパターンを紹介しました。

当時の発表資料「RedmineのFAQとアンチパターン集」はいつの間にか、5万ビューを超えるスライドになってました。
おそらく、紹介したアンチパターンは、皆さんの琴線に触れる場面があったのでしょう。

一方、2014年の第7回redmine.tokyo勉強会では、以前はアジャイル開発の観点を中心に据えたのに対し、今回はチームの規模や案件の種類の観点での失敗事例を集めてみました。
具体的には、以下の観点で、自分の経験談を含めて、アンチパターンを紹介したと思います。

・5人の小規模チーム x 20人の複数チーム
・自社開発 x オフショア開発
・大規模な受託開発案件 x 小規模な保守案件

| | コメント (0)

2014/10/11

現場の経験知をパターン言語にするコツが分かった #agileto2014

AgileTourOsaka2014に参加してきた。
テーマは「パタン特集」。
パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。
とても有意義な勉強会だった。
ラフなメモ書き。

【元ネタ】
10月11日 AgileTourOsaka2014

Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました

AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ

KenColle/AutomationPatternLanguage

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集: プログラマの思索

チケット駆動開発のナビゲーションマップ #Redmine: プログラマの思索

以下、勉強会のログを書いておく。

【1】パターン名は解決策である。
名前は体を表す。
パターン名が解決策とその問題を連想させるのが良いパターン。
パターン名からピンとこなければ、良いパターンとはいえない。
解決策をパターンの名前にする。
パターン名から、すぐに行動を起こせるかどうか。

懸田さんのワークショップでは、いかにダイエットして健康的な生活にするか、というテーマでパターン言語にする話。
各チームでパターンを作ってみると、「エクストリーム通勤」などメッセージ性はあるが、だからどう行動するのか、分かりにくいパターンが多かった。

【2】アンチパターンは状態を表す。
アンチパターン名は、問題を表す。
解決策ではないから、アンチパターンはパターンではない。

アンチパターンは、パターンの結果文脈に含まれるべきもの。
つまり、パターンを適用した結果、フォース(力の衝突、利害関係者からの圧力の衝突)は解決されたが、その結果が良い場合もあれば、予期しない副作用やリスクが出てくる時もある。
その時にアンチパターンが出てくるだろう。
例えば、パターン病の人のように、何でもかんでもパターンを適用してみたら失敗した、という時もアンチパターンに含まれるだろう。

例えば、テスト自動化パターン言語では、パターンとアンチパターンが関係付けられていたが、本来はアンチパターンは必要ない。
アンチパターンは、パターンの結果文脈の一つにすぎないから。

【3】フォースとは、力の衝突。
パターンは、利害関係者の力の衝突を解決するのではなく、「力の衝突をいなす」だけ。
パターンを適用した結果、良い結果になる時もあれば、副作用が起きて別のリスクや課題が出てくる時もある。

その時は、別のパターンを当てていく。
パターンは、現状をいきなり変えるのではなく、漸進的に変えていく。

【4】パターンはスケールしていく。
パターンはツリー構造ではない。
セミラティス構造、つまりネットワーク構造。
地形、建物、オブジェ等の場をネットワーク構造でパターンをつなげる。

スケールとは、パターンの一種のカテゴリ(?)

例えば、アレクサンダーの建築パターンは、大中小の3種類のスケール。
大:地形、環境、場所
中:出来事、行動、習慣
小:道具、ツール

例えば、デザインパターンのスケールは、生成・構造・振る舞いの3種類。

スケールには2種類ある。
時系列という横軸、利害関係者の人数という縦軸。

時系列にパターンを関連付けると、シーケンスのパターンになる。
例えば、テスト自動化のパターン言語がその例。
自動化開始→自動化導入→普及・終焉という時系列でパターンを関連付けているので、すごく理解しやすい。

では、テスト自動化パターンでは、スケールを成熟度別にできないか?
CMMIみたいに。
例えば、あるパターンを適用してアンチパターンが出たならば、それはレベル1。
そのアンチパターンを乗り越えたら、レベル2のように、成熟度別にできないか?

スケールは一つだけではうまくいかない。
幾つかのスケールを組合せると良くなる。
例えば、XPがまさにそう。
XPの12個のプラクティス単体では、品質や効率化について何も触れていないが、それらのプラクティスを全て実行すると、初めて、高品質で効率の良い開発が生まれる。(生成される)

例えば、スクラムパターンは組織パターンの一種。
スクラムパターンでは、スケールを時系列(リリース>スプリント>デイリー)でも分けるが、利害関係者の規模でも分けている。

EnterpriseArchitectureは、ツリー構造かつ階層化しているが、失敗した。
ビジネス向けシステムをアーキテクチャをビジネス・情報・アプリケーション・データに階層化したが、階層のつながりや組合せの方法が具体的に書かれていないので、苦労している。

【5】パターンは、最重要な基本的なパターンからスケールの単位で派生していく。
基本的なパターンは「センター」と呼ばれる。

例えば、組織パターンでは、「信頼された共同体」を起点として、他のパターンが派生していく。
例えば、「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」では、「エバンジェリスト」を起点として、他のパターンが派生する。

例えば、リーンスタートアップでは、MVPを中心に、プロダクトを洗練させていく。
途中で、ピボットで方針を変えたり、Build→Measure→Learnでプロダクトを進化させていく。

【6】パターン言語とは、関係者で紡ぎ合う物語。
基本的なパターンから派生したパターンを関連付けて、絵日記にしてストーリー化すると、パターン言語になる。

いつ、どこで、誰が、どんな問題を抱えていて、パターンを適用して、解決して、どんな結果になったのか。
絵日記というストーリーに、パターンが言語として自然に組み込まれる。

例えば、「ドメイン駆動設計」では「ユビキタス言語」パターンでは、「声に出してモデリングする」という解説がある。
ドメインをチームの言語とするには、モデリングした結果を声に出して、チーム全員で情報共有して理解できるまで、噛み砕く。

【7】プロジェクト・ランゲージは、場に適した実現可能な戦略。
パターン言語をあるドメインに適用した戦略。
具体的なプロジェクトに、パターン言語を適用し、パターンがドメイン特有の文脈やフォース、問題に適用できるか、検証し、その結果をパターン言語にフィードバックし、洗練させていく。

例えば、ソフトウェア開発のそれぞれの現場に対し、一つのストーリーであるパターン言語を適用してみて、その現場特有のドメインに適用できるようにパターン言語を改善していく。
その結果をパターン言語へフィードバックし、パターン言語を洗練させていく。

パターンは仮説。
パターンは実現したいイメージ。

パターン言語やプロジェクト・ランゲージを評価検証する時、その評価基準は、感情をモノサシにする。
パターンを適用した結果、楽しいですか?
パターンは、そのコンテキストやフォースにしっくりきますか?
パターンを適用した結果、なぜそう感じるのか?

最終的には、QWAN(無名の質)につながる。

【7-1】パターンは成長すべき。
アレクサンダーのパターン言語は「A Pattern Language」。
つまり、不変なパターン言語ではなく、アレクサンダー個人が見つけたパターン言語。
皆のパターン言語を集めて、洗練させて、一つの体系にできれば「The Pattern Language」になる。

俺のパターンが皆のパターンへ変わる。
だから、皆も自身でパターンを作ってみよう。

アレクサンダーの建築パターンは、「人の集まる場所」に注目している。
人が集まれば、コミュニケーションが生まれ、コミュニティが形成されていく。
コミュニティという場で、住民が自分たちの街を少しずつ漸進的に改善していく。

【7-2】小林さんの話。
伊丹市内を散策した時、鉄の柵と竹の柵があった。
どちらのほうが良いのか?
普通は、竹の柵は壊れやすく、鉄の柵の方が長持ちするから、鉄の柵の方が良い。

しかし、鉄の柵は、業者に頼まないと修理できない。
一方、竹の柵は住民が修理しやすい。
住民が竹を取ってきて、すぐに自身で改善できる。

良いパターンは当たり前な概念。
でも、言葉になっていない。
だから、パターンは暗黙知を見える化する。

【8】XPは場の設計を重視している。
「朝会(デイリースタンドアップ)」は組織パターンから出てきた。

XPは全体を重視している。
技術だけのプラクティスでは不足。
コミュニケーションだけのプラクティスでも不足。

XPは比較的広い観点で作られた、プロセスのパターン言語。
プラクティスを分離して、単体だけでは考えられない。

パターン指向リファクタリングは、パターン病という病気も生み出した。
リファクタリングにデザインパターンを適用しなければならない、というバイアスがかかった。

パターンはフォースをいなすだけ。
フォースを変えない。

アジャイルプラクティスはパターン言語か?
アジャイルコミュニティはパターンコミュニティの人達から生まれた経緯を考えれば、多分Yes。

【9】「パターンが生成的である」とはどういう意味か?

例えば、XPやアジャイルのプラクティスがそう。
技術的なプラクティスやコミュニケーション、チームビルディング、ファシリティに関するプラクティスを全て実践した結果、高品質で短納期の製品が作れる。
単体のプラクティスだけでは、品質や納期、効率化の効果は現れない。

XPのプラクティスはカッコイイ。
パターン名にメッセージ性がある。

例えば、「ドメイン駆動設計」の「ブレイクスルー」が、パターンが生成的になった結果のタイミングに相当するだろう。
つまり、モデルのあるべき姿は分からないが、モデルを綺麗にして分かりやすくしたい、という気持ちを持ってリファクタリングし続けると、ある時点で、急にモデルの見通しが良くなる。
それがブレイクスルー。

【10】自分の経験から、パターンにできるか?
パターンにするには、同じような状況で、3回パターンを適用して経験しているか?

繰返し性からパターンが生まれる。

パターンは難しい。
自分で、しょぼいパターンを書いて初めて分かった、と。

だから、シェパーディングで、ペアになってパターンを書いて評価してもらうと良い。
レビューアとレビューイの役割と同じ。
パターンのフィードバックをしてくれる。
構造的に見てくれる。
状況が分からない、フォースが分かりにくい、など、的確なアドバイスがもらえる。

【11】僕の感想:

たくさん刺激を受けた勉強会だった。
チケット駆動のパターンを未完成にしたからテスト自動化のパターン言語を見た時はやられたと思った笑。

テスト自動化のパターン言語は、ちゃんと時系列に関連付けられて、時系列の観点のスケールで区別されている。
また、一つのストーリーで、パターンやアンチパターンが語られている。

そういうストーリーを聞くと、そうそう、テスト自動化ではそんな落とし穴があるよね、せっかく自動化を頑張ったのにいつの間にか保守されなくなるよね、など、共感できる。
正直、すごいなーと思った。

KenColle/AutomationPatternLanguage

過去に僕が書いたチケット駆動のパターン言語は以下の通り。
テスト自動化パターン言語に比べれば、ナビゲーションマップまでストーリー化できておらず、中途半端だ。
まだアイデア段階にすぎない。

チケット駆動のプラクティスをナビゲーションマップに試しに書いてみたが、ストーリー化できておらず、パターン言語にはなっていない。

それが今後の課題。
チケット駆動のプラクティスもパターン言語で体系化して、広めたい。
アジャイルの現場、WF型開発の現場、大規模な受託案件の現場、小規模な保守案件の現場、など、色んなプロジェクトランゲージを作り、最終的なパターン言語としてストーリーを作り、皆が暗黙知として認識しているプラクティスを明示したいのだ。

【追記】
Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しましたの記事の一節をメモ。

(引用開始)
日本におけるパタン・ランゲージの第二次隆盛がきている?

私のワークショップ後に、@Posauneさんがテスト自動化のパターンランゲージの発表されていました。

この発表を聞いていて感じたのは、自分達でパタンをまとめ、Githubに置いてフィードバックをもらえるようにして、どんどんコラボレーションし改善していく、これこそまさに、数年前から構想していて(未だ心が折れてできていない)現場パタン構想(GembaPLoP)のひとつの現れなのかしれない、ということです。

他にもチケット駆動のパタン・ランゲージを@akipiiさんがまとめているという話も聞きました。
(引用終了)

懸田さんの別資料もリンクしておく。


| | コメント (0)

2014/08/24

第10回ドメイン駆動設計勉強会の感想 #dddosaka

第10回DDD勉強会で議論した内容をメモ。
自分が理解できたことだけを書いておく。

【参考】
第10回ドメイン駆動設計(DDD)読書会@大阪 - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

dddosaka/reading_ddd_report

第7回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第4回ドメイン駆動設計読書会の感想: プログラマの思索

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索

いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

【1】15章「汎用サブドメイン」「隔離されたコア」

コアドメインは、ソフトウェアプロダクトラインのコア資産とほぼ同じ。
蒸留は、コア資産抽出の作業と同じ。

コア資産こそがそのモデル、そのシステムの中核となるドメインの塊。

すると、そのコアドメイン(コア資産)から、補助的な役割を持つドメインを分離して、コア資産の凝集度を高めることが重要になってくる。

【1-1】補助的な役割を持つドメインはいくつかある。
一つは、汎用ドメイン。
たとえば、フレームワークなどの開発基盤、アナパタやリファレンスモデルのようなモデルテンプレート、自動テスト、共通関数など。
ドメイン駆動設計」の例では、タイムゾーンモジュールがあった。

他にも、会計や物理学は既にモデルとしてテンプレート化されているため、汎用サブドメインの範疇になる。

【1-2】他には、隔離されたコア。
ドメイン駆動設計」の例では、P.437にあるように、輸送パッケージから、配送<<コア>>と物流、顧客、金銭<<汎用>>のドメインに分離していている。
コアドメインが配送<<コア>>であり、隔離されたコアが物流、顧客、汎用サブドメインが金銭<<汎用>>に相当する。

責務駆動設計の観点では、以下の点で整理される、という話もあった。

・配送<<コア>>:コアドメイン。実績に相当。「業務」に相当。
・顧客、物流:隔離されたコア(補助的なサブドメイン)。計画に相当。「能力」「潜在能力」に相当。

【1-3】「ドメイン駆動設計」を読んで面白いのは、「汎用サブドメイン」「隔離されたコア」 の注意点やリスクが興味深いところ。

汎用サブドメインは共通関数やモデルテンプレートが該当するので、開発チームの中で優秀なメンバーが割り当てられやすい。
すると、技術系の人間ほど、タイムゾーン変換や物理学のような限定可能な問題を楽しむ傾向があり、そういう問題に時間をかけすぎてしまう。
本来ならば、コアドメインの開発に注力すべきなのに、2級レベルの開発者をアサインして、プログラムがあまりきれいでない状況になってしまいがち。

また、XPのようなアジャイル開発では、アーキテクチャスパイクやゼロリリースのように、初期のイテレーションで、技術的アーキテクチャの妥当性を証明するように、補助的な汎用サブドメインを扱う周辺システムを構築したがる。
しかし、これでは、本来のリスク管理にはならない。
コアドメインを少しずつ作っていき、ドメインモデリングのリスクを下げていく方向に進まないから。

それゆえ、初版のシステムは、単純であってもコアドメインの一部を作らなければならない、と主張している。
この点は同感。

【1-4】また、「隔離されたコアを切り出すタイミングは、システムにとって重要な、巨大な境界づけられたコンテキストがあり、モデルの本質的な部分が大量の補助機能のせいでわかりにくくなった時」と「ドメイン駆動設計」に書かれているが、そのタイミングでは手遅れではないか、という質問もあった。

確かに、コアドメインがどんどん巨大になっていた事実に気づいた時には、リファクタリングしようにも本番稼働中なので手を入れられず、最終的には、既存ドメインを捨てて、新規システムへリプレースするしかない経験が多い。
隔離されたコアを抽出して修正すべきタイミングを見つけるのは、実際にはとても難しい。

議論の中では、一つの解決法として、CIのメトリクスで凝集度や結合度などのメトリクスを常時測定しておき、メトリクスの兆候がある閾値を超えるとか、メトリクスの怪しげな傾向を見つけたら、隔離されたコアを抽出するタイミングと判断することもあるね、という話もあった。

【1-5】「<<コア>>」「<<汎用>>」はステレオタイプ。
パッケージ名やクラス名に、「~コアクラス」と書くのは良くない。
「<<コア>>」「<<汎用>>」はタグのようなものだから、ステレオタイプにした方がいい。

【2】16章「責務のレイヤ」

・ポリシー、業務、能力のレイヤは、パッケージを横断した構造ではないか?

・「業務」はイベント、トランザクションに相当。
・「能力」「潜在能力」はマスタ、リソースに相当。

・顧客が「能力」に相当する理由:
→輸送会社の例では、顧客はリピータ中心のため、顧客はビジネス上の資源であり、何度も活用する情報である。
 例:ダイレクトメールを客に送って、輸送の注文を促す

・逆に、一見の顧客の場合、顧客は「業務」でとらえられる。
 一見の顧客なら、顧客の情報をマスタとして持つ必要がない。
 トランザクションテーブル(例:輸送、配送、注文)に顧客の情報が含まれて、混在しているだろう。
 トランザクションテーブルに混じっている顧客データは、再利用される対象ではない。

・運送行程クラスは「能力」層なのに、「望ましい(isPreferred)」というメソッドがあり、唯一調和していない。
 そこで、「ドメイン駆動設計」では、運送行程クラスの「望ましい(isPreferred)」を「経路偏向ポリシー」クラスへ外出しして、「ポリシー」層に抽出している。

・新しい機能「特定の危険物に対しては、経路選択時に制限が適用される」をドメインモデルに反映する場合、従来のクラス設計では、「危険物経路サービス」を作ったとしても、呼び出しクラスになる「貨物」クラスにロジックが集中し過ぎて良くない。
 そこで、「ドメイン駆動設計」では、「経路選択サービス」に危険物の経路判断の呼び出しロジックを移動し、貨物クラスから切り離す。

・「ドメイン駆動設計」における「~サービス」クラスは、ユースケースに相当する。
 ユースケースに該当するサービスクラスが、業務ロジックのトリガーになっている。

| | コメント (0)

2014/08/15

ソフトウェアパターンの記事

ソフトウェアパターンの記事があったので、リンクをメモ。

【参考】
先人の知恵を集めた「ソフトウエア・パターン」 - 第1回 適用範囲が拡大する「ソフトウエア・パターン」:ITpro

先人の知恵を集めた「ソフトウエア・パターン」 - 第2回 アクティビティ配置のひな型「ワークフロー・パターン」:ITpro

先人の知恵を集めた「ソフトウエア・パターン」 - 第3回 成果物や組織の管理方法「マネジメント・パターン」:ITpro

(引用開始)
 パターンの目的はソフトウエア開発で直面する様々な問題とその解決策を明快に示すことだ。先人の経験に裏打ちされていることから,パターンは先人の知恵とみなすことができる。パターンで示されている問題に実際に直面したとき,そこに書かれている解決策は大いに参考になる。

 例えば,最も知名度の高いパターンにGoF(Gang of Fourの略)の「デザイン・パターン(Design Pattern)」がある。このパターンは,主に詳細設計で直面しがちな問題を23種類のパターンとして示している。その中のオブザーバー(Observer)パターンでは「あるオブジェクトの変化を他のオブジェクトに伝えたいが,通知したいオブジェクトを静的に決定できない」という問題を提起。その上で「通知するオブジェクトに対して共通のインタフェースを実装し,それらを変化するオブジェクトに登録する」という解決策を示している。

 これまでソフトウエア・パターンと言えば,ソフトウエア開発の分析,設計,実装の各フェーズを対象にしたものが中心だった。具体的には,クラス/データモデルの分析フェーズでは「アナリシス・パターン」や「データモデル・パターン」,基本設計フェーズでは「アーキテクチャ・パターン」や「エンタープライズ・インテグレーション・パターン」,詳細設計では「デザイン・パターン」,実装フェーズでは「イディオム」――といった具合である。

 ところが,ここに来てパターンの適用範囲が急速に拡大している(図1)。背景にあるのは何か。パターンに詳しいサイクスの宗雅彦社長は「分析/設計/実装といったエンジニリング・プロセスの知識だけでは,高品質なソフトウエアを素早くかつ確実に作れなくなったこと」と見る。言うまでもなく,開発すべきシステムは大規模化・複雑化し,短納期や高品質への要求も高まるばかり。そうした中では,ソフトウエア開発の「問題」も分析,設計,実装にとどまらない。これを受けて,適用範囲が広がりを見せているのだ。
(引用修了)

紹介されているパターンは以下の通り。

・デザイン・パターン
 →GoFの本「オブジェクト指向における再利用のためのデザインパターン

・アナリシス・パターン
 →ファウラーの本「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

・データモデル・パターン
 →「Data Model Patterns: Conventions of Thought (Dorset House eBooks)

・アーキテクチャ・パターン
・エンタープライズ・インテグレーション・パターン

・ワークフロー・パターン
 →「詳説 ビジネスプロセスモデリング ―SOAベストプラクティス (THEORY/IN/PRACTICE)

・構成管理(Software Configuration Management)パターン
 →「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

・導入パターン
 →「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

データモデルパターン以外は邦訳もある。
データモデルパターンとワークフローパターンだけは読み切れていないので、読んでみたい。

| | コメント (0)

2014/03/25

ソースコードからモデルの絵を自動生成する

ソースコードからモデルの絵を自動生成するツール(Graphviz、PlantUML)についてメモ。
アイデアをラフなメモ書き。

【元ネタ】
Graphvizの簡単なサンプル

Graphvizメモ(Hishidama's Graphviz Memo)

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)

PlantUML の使い方 | プログラマーズ雑記帳

PlantUML

【1】クラス図、あるいは単なるネットワーク図を手書きではなく、ツール上のGUIでもなく、ソースで書きたい時がある。
ちょうど僕は、「アイデアを組織に広めるための48のパターン」の本を読んでいて、その内容にすごく惹かれて、それらパターンの一覧であるナビゲーションマップが欲しくなった。
ナビゲーションマップがあれば、パターンの間でどのような関連があり、どのようにパターンが生成されていく(generative)のかを見ることができると考えたからだ。

アイデアを組織に広めるための48のパターン」には、48個のパターンと、それらパターンの関係は本文に書かれている。
「パターンA→パターンB」というデータを本文から抜粋すれば、ナビゲーションマップを作ることができる。

つまり、パターン一覧があり、パターンの関連も決定されているので、それらの仕様をソースコードに落とし込めばいい。
そこで、Graphviz の dot コマンドを使って、簡単な有向グラフを生成できるのではないか、と考えた。

アイデアはこんな感じ。
但し、作成途中なので中途半端な絵になっている。

「アイデアを組織に広めるための48のパターン」のナビゲーションマップ(作成中)

デザインパターン、ドメイン駆動設計、組織パターン、XPのプラクティスなどのナビゲーションマップは、Graphviz の dot コマンドで描けるソースコードに落とし込めば、すぐに生成できるはず。

【2】他にも、ソースコードで有向グラフを生成したい時がある。
例えば、バッチのジョブフロー図もそうだ。

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)によれば、Javaで書かれたオープンソースのHadoopのフレームワークであり、業務系バッチに特化しているものだが、バッチソースだけでなく、そのジョブフロー図も自動生成してくれるらしい。

バッチ処理は汎用機+Cobol時代からずっとあるけれど、その設計技法の中で、ジョブフロー図が一番重要な成果物だ。
ジョブフロー図がなければ、本番障害が起きた時に、どのジョブからリランして復旧すればよいか、などが分からなくなる。
しかし、お金のないSIや技術力のないSIでは、ジョブフロー図をExcelで書いているものの、その最新化を怠っている所も多い。
普通のお金のあるSIは、Visioでジョブフロー図を書いて都度更新しているが、バイナリファイルなのでバージョン管理もやりにくい。

しかし、バッチ処理のソースからジョブフロー図を自動生成できれば、ジョブフロー図を最新化する必要もない。
それができなくても、ジョブフロー図の元ネタをテキストファイルで書いておき、自動生成できるようにしておけば、そのテキストファイルをバージョン管理することで、変更管理の配下に置くこともできる。

ソースと設計書のトレーサビリティにもつながる。

【3】PlantUML の使い方 | プログラマーズ雑記帳によれば、UMLのクラス図やシーケンス図なども、テキストファイルから自動生成できるようだ。
JavaDoc上に書いておくようにしておけば、ソースコードに設計書が埋め込まれているので、ソースコードからUMLの各種ダイアグラムを自動生成する手法も選択できる。

【4】他にも、ガントチャートをRubyソースから自動生成するツールもある。

Rubyのガントチャート生成ツールTaskJuggler: プログラマの思索

【5】本来やりたいことは、ソースと設計書、報告書とのトレーサビリティだ。
ソースはバージョン管理にあり、チケットの作業履歴と紐づけている。
しかし、設計書や報告書はExcel、WordなどのOfficeファイルであり、バージョン管理したとしても、ソースの変更に追いつけていない。
本来なら、ソースコードを直せば、ソースコードから設計書を作り出すべき。

要件定義書、設計書、ソース、テストケース、障害などの間のトレーサビリティは、今後のソフトウェア開発で重要になってくる。
アジャイル開発でやっているとしても、その背後では、SCMやITSなどでトレーサビリティを確保できるようにしたいのだ。

時間に余裕ができたら、色々試してみたい。

| | コメント (0)

2014/03/22

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集

アジャイルに効く アイデアを組織に広めるための48のパターン」を読んだ感想をラフなメモ書き。

【参考】
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン一覧: プログラマの思索

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始 - Yasuo's Notebook

『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - delirious thoughts

Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中 - 未来のいつか/hyoshiokの日記


【1】背景、動機

自分が新しいツール、新しいプロセスを導入したい時、うまくいく場合とうまくいかない場合がある。
例えば、Redmineによるチケット駆動開発を導入したい時、あるいは、アジャイル開発を導入したい時、その結果は、やり方に応じて失敗する時もある。

僕はRedmineのエバンジェリストと思われる時が多く、Redmineの導入によってプロジェクト支援を期待される役割が多い。
僕は過去の経験から、アジャイル開発へ発展させるパターン・アンチパターンを貯めてきたので、どのプロジェクトもそれなりに成功してきたと思っている。
でも、他の人が同様に成功するとは限らないだろう。

2000年代前半、XPユーザグループでは、XPを通じたアジャイル開発をいかに現場に導入するか、という事例とノウハウの議論がたくさん行われた。
実情は、アジャイル開発は日本のSIに導入しづらい、という苦労話ばかりで、たくさんの失敗例ばかりだった。
でも、Scrumが世界で普及し始めた後を追うように、日本でもScrumをベースにしたアジャイル開発の成功事例が少しずつ増えてきているように思う。

アジャイルに効く アイデアを組織に広めるための48のパターン」は、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストが、そのアイデアを組織へ導入するためのノウハウ集だ。
この本の内容をもっと以前に知っていたら、僕もこのテクニックを使って、もっと容易にRedmineを導入できただろうと思った。

アジャイル開発を実際の現場に導入したいと思う人がいるなら、まずは「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んで、どのように組織へ展開すべきか、構想を巡らすと成功率が高まるだろう。

【2】「アジャイルに効く アイデアを組織に広めるための48のパターン」を適用できる状況

アジャイルに効く アイデアを組織に広めるための48のパターン」のアイデアは、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストだけでなく、次の人達にも使えると思う。

(1)PMOや品質管理部(SEPG)の立場で、個別プロジェクトや組織を支援する人達

PMOやSEPGは、普通は火消し役でプロジェクトを支援する立場が多い。
すると、火を噴いているプロジェクトで既に作業しているメンバーやリーダーが、実は抵抗勢力になってしまう場合もある。
現場の問題点を把握せずに、頭ごなしの命令や作業指示をいきなり実施すると、反発されてしまうのだ。

(2)プロジェクトリーダーとして、新しいツールや新しいプロセスを導入したいと考える人達

新しもの好きなアーリーアダプター、イノベーターの精神を持つプロジェクトリーダーは、新しい案件で新しいツールやプロセスを試したくなる場合がある。
新しい技術を試して、新しいノウハウを得たいのだ。
でも、メンバーが新しい技術に付いていけなかったり、上司が予算やコストを理由に圧力をかけてくる時もある。

(3)業務改善のためのシステム提案、要件定義を行う人達

SIがシステムを提案する場合、ユーザ企業にシステムを導入するだけでなく、ユーザ企業の業務プロセスも変わってしまうことも合わせて提案する時が多い。
業務のIT化とは本来、今まで労働集約的だった作業を自動化して、人減らしに使う一つの手法だから。
すると、ユーザ企業の組織構造も変わる事になり、従来の仕事を持つ人達は役割が変わるだけでなく、権限が廃止される場合もあるので、抵抗勢力になってしまう時がある。

【3】プラクティスをパターンとしてまとめる意義

アジャイルに効く アイデアを組織に広めるための48のパターン」が優れている点の一つは、エバンジェリストが使えるような道具として、パターン形式でまとめていることだ。
パターン形式なので、どんな状況でどんな問題に対してどんな解決策を実施すればよいか、が明確に理解しやすい。
また、パターンの概念はパターン名で名前付けられているので、会話の中でパターン名を呼ぶだけで、その背景や問題意識、パターンを適用した効果についても、他人と共有できる利点がある。

欧米人が日本人よりも優れている点は、PMBOKやCMMIのように、既に知られている経験知を知識体系として抽象的に普遍的な概念としてまとめる能力がある点だと思う。
関西IT勉強会でも、谷島さんが同じようにことを指摘されていた。

過去から今までの日本人も、プロジェクト管理や開発プロセスについて、たくさんの経験を持っているし、たくさんの書籍も出している。
しかし、それらの知識はバラバラであり、他人が使えるような知識や概念になっていない。
そもそも、それらの概念に名前が付けられていないので、他人との会話で流通できるような普遍性を持っていない時が多い。

パターンの良い点は、BOKのような知識体系よりも、帰納的であり、たくさんの経験を元に普遍化されているので、理解しやすい点にあるだろう。

僕は、パターン言語というアイデアが好きだ。
パターン形式で自分の体験に基づくプラクティスを作り出せるし、そのパターンを他人に広めやすくしてくれる。

パターン、Wiki、XPは良書: プログラマの思索

パターン言語のアイデア: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

アジャイルに効く アイデアを組織に広めるための48のパターン」でパターンに関する興味深い指摘がある。
P.16の「パターンの利用方法」に「初めてパターンを読んだ人は、情報が多すぎると感じるかもしれない」という指摘がある。
つまり、パターン形式には、状況・問題・解決策の3つで十分で、フォースや結果状況、使用例は不要ではないか、ということだ。

しかし、実際にグループでパターン化する議論をしていると、すぐに暗礁に乗りかかった。
ある解決策を用いた時に、副作用として発生する問題はどこに描くのか?
パターンの前提条件となる制約条件はどこに書くのか?
という質問がどんどん出てきた。

ほどなくして、結局、フォースや結果状況などの全てのパターン項目が追加された。
「問題解決に向けて議論していくと、いずれ全てのパターン項目が必要になることを、まさに目の当たりにした」という。

この逸話はとても重要な内容を示唆していると思う。
つまり、アレグザンダーのパターン項目は、単なる思いつきで作られたパラメータではなく、パターンを語る時に必然的に出てくるパラメータなのだ、ということだ。

そして、パターン項目のうち「フォース」がかなり重要であると、最近思うようになった。
以下にもその理由が書かれている。

パターンとフォースとぎゃー! - 反言子

(引用開始)
8. フォースが問題を定義する
形式上、問題がまず初めに来るので、作者は時折、解法を書く前に問題を記述する。
だが、これもまた問題を含んでいる。
解法をよく理解しないままに、問題を衝動的に記述する。
しかし、作者が解法について詳細に考え抜かない限り、そのような問題の記述はあいまいで、非常に大雑把なもになりがちだ。

問題と解決の結びつきが重要であることはわかっている。
僕はこの手の話が好きなので「問題こそ重要である」という考え方にはなじんでいる。
しかし問題を定義することは難しい。
なるほど、解法がわからない、衝動的に考えられた問題なのだ。

ゆえに問題を記述するためにフォース、そして問題とフォースの関係を考え抜くことが重要になる。
パターンが単なるマニュアルでない理由としてフォースの存在が語れることにも納得がいった。
(引用終了)

【4】各パターンのメモ

アジャイルに効く アイデアを組織に広めるための48のパターン」の各パターンを読むと、ああそういう意味だったのだな、と経験が整理される気がする。
以下、本の文章を踏まえて、自分の理解と体験を踏まえてメモしてみる。

◆全体に関わるパターン

(1)Evangelist : エバンジェリスト(1)
新しいアイデアを持ち、熱意を持って普及させたいと思う人。

(2)Small Successes : 小さな成功(2)
チームに小さな成功を植えつけて、意気を上げる。
チケット駆動開発なら、完了したチケットが必ず記録されるので、後から自分の実績をふりかえれば自信になる。

(3)Step by Step : ステップバイステップ(3)
トップダウンで一気にやらない。
ボトムアップで少しずつ広めていく。
お試し期間(47)や便乗(21)を使う。

Redmineによるチケット駆動開発は、ステップバイステップで実行しやすい。
運用しながら、ワークフローを修正したり、チケットの項目を追加したり、運用ルールを変えていくことは柔軟に可能。

(4)Test the Waters : 予備調査(4)
あなたは新しいアイデアに興奮して、エバンジェリストになりたいが、新しいアイデアが組織に合うかどうかまだ分からない時に使う。

(5)Time for Reflection : ふりかえりの時間(5)
定期的に評価し、フィードバックを得る。

「なぜ、ふりかえりが必須なのか、自明ではないかもしれない」。
しかし「走りながら考えればいい、経験からの学びは無意識のうちに積み重ねられていく」という考え方は、現実にはうまくいかない。
定期的に活動を評価し、学びの機会を作らなければ、同じような間違いを何度も繰り返す。

◆序盤の活動に関わるパターン

(6)Ask for Help : 協力を求める(6)

(7)Brown Bag : ブラウンバッグ・ミーティング(7)
ランチミーティングのこと。
日本なら、ノミニュケーションに相当するだろうか。

(8)Connector : コネクター(8)
(9)Do Food : 何か食べながら(9)
(10)e-Forum : 電子フォーラム(10)

(11)Early Adopter : アーリーアダプター(11)
新しいアイデアのオピニオンリーダーになりうる人々。

(12)External Validation : 外部のお墨付き(12)

(13)Group Identity : グループのアイデンティティ(13)
チームや活動に名前をつけること。
例えば、@daipresentsさんは自分のチームに「特攻野郎Aチーム」という名前をつけていたのを思い出す。
また、スティーブ・ジョブズも、Macチームに海賊の旗を掲げていた。

(14)Guru on Your Side : 達人を味方に(14)
組織のメンバーに尊敬されているシニアレベルの人々を味方にする。

(15)In Your Space : 空間を演出する(15)
「見える化」のこと。

(16)Innovator : イノベーター(16)
新しもの好きの同僚。
新しいというだけで好奇心をそそられ、興奮する人々。

(17)Just Do It : やってみる(17)
新しいアイデアの利点や限界は、自分自身の経験から情報を集める。
自分が今やっている仕事にそのアイデアを試して、評価してみる。

(18)Just Say Thanks : 感謝を伝える(18)
協力してくれた人々に感謝の気持を伝える。

僕が過去にKPTによるふりかえりを実施した時、女性SEや女性PGから、Keep欄に、他メンバーに感謝の気持を伝えるPostItが貼られた時がある。
感謝された人はさぞかし嬉しかっただろうと思う。
そんな表現だけでも、チームは和むし、一体感が高まる。

(19)Next Steps : 次のアクション(19)
アイデアをToDoリストに落とすこと。

(20)Personal Touch : 個人的な接触(20)
新しいアイデアの価値を伝えるために、技術的な利点よりも、個人や組織のニーズを理解する。

(21)Piggyback : 便乗(21)
自分のアイデアを既存の慣習に追加機能として載せることで、コストやリソースを減らす。
新しい取り組みよりも、改善として導入する。

Redmineによるチケット駆動開発では、普通、現場の作業ルールをそのままワークフローに当てはめて、運用を開始する。
つまり、AsIsのワークフローから開始して、少しずつ改修しながら、あるべき姿(ToBe)のワークフローへ変えていく。

(22)Plant the Seeds : 種をまく(22)
勝間和代氏が提唱している「Giveの5乗」と同じ。

(23)The Right Time : 適切な時期(23)
イベントの時期や助けを求める時は、タイミングを考慮する。

アジャイル開発では、イテレーションごとに、ふりかえりでフィードバックを得たり、次のアクションを考えるタイミングが取りやすい。
しかし、WF型開発は、実際は、ふりかえりや改善実施のタイミングが取りにくい。
なぜなら、工程単位に前工程のふりかえりやそれをうけた対策を考えたいが、普通は仕様変更や五月雨式のWF開発が多いので、メンバーが常に忙しく、まとまった時間を取るのが非常に難しいから。
結局、プロジェクト完了時の1回だけしか、ふりかえりが行われず、チームが解散するために、せっかく得られた知見や改善案も生かされない。

(24)Stay in Touch : 定期的な連絡(24)
(25)Study Group : 勉強会(25)


(26)Tailor Made : テイラーメイド(26)
新しいアイデアを採用する時、組織のプロセスとゴールを事前調査して、イノベーションが解決できるニーズや問題に適用する。

(27)Big Jolt : 著名人を招く(27)
今なら、アジャイル開発の有名人やアジャイルコーチを呼んで、組織変革を支援してもらうようにする。

◆中盤以降の活動に関わるパターン

(28)Corporate Angel : 経営層の支持者(28)

(29)Dedicated Champion : 正式な推進担当者(29)
組織で認められて、予算と権限を与えられたエバンジェリスト。
新しいアイデアの組織導入を効果的に進めたいなら、ボランティア活動だけでは身が重い。

(30)Early Majority : アーリーマジョリティ(30)
組織内に強力な足場を構築してくれる「より慎重なマジョリティ」。
門番(ゲートキーパー)であるイノベーターやアーリーアダプターだけでは、組織変革は不十分。

(31)Guru Review : 達人のレビュー(31)
組織のメンバーに尊敬されているシニアレベルの人々によるレビューチームを作り、新しいアイデアを評価してもらい、他の聴衆に影響させる。

(32)Hometown Story : 体験談の共有(32)
新しいアイデアの有用性を体験談で共有し、形式知として表出化する。
体験談という暗黙知の共有。
SECIモデルの一例。

僕の現場では、KPTによるふりかえりで、成功や失敗の体験談を共有する場合が多い。

(33)Involve Everyone : みんなを巻き込む(33)
イノベーションが一人の人や小さい集団のためだけではなく、組織全体のためにある。
より多くの人に新しいアイデアを「自分ごと」として認識してもらう。
それによって、心から取り組んでくれるだけでなく、貢献したいという力強い感情を生み出し、組織と個人のつながりも強化する。

(34)Just Enough : ちょうど十分(34)
新しいアイデアを学んでもらうには、学習曲線を考慮する。
段階を経て正しく理解してもらう。

Redmineによるチケット駆動開発では、運用ルールを1回説明すれば、その後は細かい説明は不要で運用できる利点がある。

(35)Local Sponsor : 身近な支援者(35)
現場のマネージャに協力を求める。
経営層や下々の人々よりも、中間層のマネジメント職の支援があってこそ、新しいアイデアは現場での仕事のやり方として正式に認められる。
パトロンに近い。
実は、プロジェクトリーダーやプロジェクトマネージャが、組織変革の抵抗勢力になってしまう場合が多い。

(36)Location, Location, Location : 場所重要(36)
半日以上かかるイベントは、仕事の現場を離れて、別の場所で開催する。

(37)Mentor : メンター(37)
新しいアイデアを理解して、チームを手助けできる人。
守護者、ファイアーウォールに近い。

(38)Royal Audience : 謁見(38)
(39)Shoulder to Cry On : 相談できる同志(39)

(40)Smell of Success : 成功の匂い(40)
新しいアイデアが成功し始めると、新参者がイノベーションについてエバンジェリストに尋ねてくるようになる。
そんなときは、教えるタイミングとして捉えよう。

(41)Sustained Momentum : 勢いの持続(41)

(42)Token : トークン(42)
名札のこと。
新しいアイデアを思い出させる小さな名札。
例えば、マグネット、ボタン、カップ、鉛筆、リングノート、クイックリファレンス、記事のコピーなど。
他にも、アバター、ツールのロゴ、ニコニコカレンダーなどが挙げられるだろう。

Redmineにもアバタープラグインがある。
担当者のアバターがあるだけでも、ツールへの関わり方は違ってくる。

◆抵抗と付き合うためのパターン

(43)Bridge-Builder : 橋渡し役(43)
新しいアイデアを受け入れた人を、まだ受け入れてない人に引きあわせて、イノベーションの有用性を受け入れてもらう。

(44)Champion Skeptic : 懐疑派代表(44)
エバンジェリストのアイデアに懐疑的なオピニオンリーダーに、公式な懐疑派の役割を演じさせる。
新しいアイデアの問題点を指摘するように促し、その問題に対処する。
但し、結果状況が悪くならないように注意が必要。

(45)Corridor Politics : 根回し(45)
重要な決議の前に、影響のある意思決定者に非公式に接触して、承認へのストーリーを作る。
文字通り、根回し、腹芸のこと。

(46)Fear Less : 怖れは無用(46)
抵抗勢力を新しいアイデアの強みに変える。

(47)Trial Run : お試し期間(47)
新しいアイデアのトライアル期間。
新しいアイデアを検証する。

(48)Whisper in the General’s Ear : 将軍の耳元でささやく(48)
集団の前でマネージャを説得できない時、非公式な場所でマネージャに懸念点を教えてもらう。

【5】「アジャイルに効く アイデアを組織に広めるための48のパターン」で面白いのは、エバンジェリストをサポートする人々の役割にたくさんのパターン名が付けられていること。

エバンジェリスト(1)、正式な推進担当者(29)がこのパターン言語の主役。
組織内には、コネクター(8)、アーリーアダプター(11)、達人、イノベーター(16)、経営層の支持者(28)、アーリーマジョリティ(30)がいて、彼らに働きかける。

エバンジェリストの味方には、著名人、身近な支援者(35)、メンター(37)、相談できる同志(39)、橋渡し役(43)がいる。
抵抗勢力には、懐疑派代表(44)がいる。

それら役割に相当する人は組織内の誰なのか、をマッピングしておけば、組織変革のどの時点ではキーマンは誰か、を考えるきっかけになりうる。

役割に相当するパターン名を調べてみると、非常によく考えられているなあ、と思う。
他にも色々考えてみる。

| | コメント (0)

2014/03/18

ドメイン駆動設計に出てくる概念モデルと分析モデルの違い

ドメイン駆動設計に出てくる概念モデルと分析モデルの違いについて、良い記事があったのでメモ。

【元ネタ】
ドメイン・フレームワークのススメ(第1回)

ドメイン・フレームワークのススメ(第2回)

【1】概念モデル、分析モデル、設計モデルを以下で定義している。
これは分かりやすい。

(引用開始)
概念モデル:問題領域に対する「理解のしやすさ」を重視したモデル。
実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。

分析モデル:概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。

設計モデル:分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。
(引用終了)

ドメイン・フレームワークのススメ(第1回)では、Greedというゲームを概念モデルで描いている。
Greedというゲームの概念をそのままクラス図に落とし込んだだけのものが概念モデル。

つまり、概念モデルはAsIsモデルであり、あるべきモデル(ToBe)ではない。
だから、概念モデルに出てくるドメインを再利用するのは難しい。

あるべきモデル(ToBe)こそが分析モデル。
すなわち、概念モデルからドメインを抽出(蒸留)し、より抽象度を高めることで、仕様変更しやすくし、再利用を高める。

(引用開始)
概念モデルは対象領域(問題領域)の本質的な構造や特性を捉えて理解を深めるために有効です。
この段階では、実現手段(HOW)の詳細にとらわれず、そもそも「どんなもの(WHAT)を相手にしなければならないのか」を整理しながら理解を深めることに注力します。システム開発の早い段階で問題領域に対する理解をしっかり深めておくことは、後のさまざまな工程に良い影響をもたらします。
そのため、概念モデルは「理解のしやすさ」を最も重視して作成されます。
一方で、概念モデルは現在対象となっている世界「そのままの姿」を素直に捉えたモデルであるため、基本的に抽象化/一般化や類似の問題領域に対する再利用性や拡張性の考慮などは薄くなります。
(中略)
ドメイン・フレームワーク化されていない概念モデルをベースに(概念モデルを「分析モデル」と呼んで)、設計、実装…といった詳細化の工程に進んで行ってしまう開発プロジェクトも多く見かけます。
この場合、大きな問題が無ければそれなりの期間/工数で正しく動作するシステムが出来上がってしまうので、一見するとその開発プロジェクトは成功したかのように思えてしまうのですが、そのようにして作られたモジュール群は後に類似の問題領域の別システムの開発のために流用(再利用)してみようとしてもあまり上手くいきません。
再利用性や拡張性が活かせないのであれば、オブジェクト指向で開発する意義の半分ほどを失うと言ってもオーバーではないでしょう。
オブジェクト指向は魔法ではないので、単に「クラス」という単位でモジュールをまとめれば自然に再利用性や拡張性が上がる…というわけではないのです。
(引用終了)


ドメイン・フレームワークのススメ(第2回)では、Greedゲームを抽象化したゲームの分析モデルを提示している。
ゲームの分析モデルでは、「ゲームフレームワーク」というパッケージにドメインモデルがパッケージングされて、再利用できるコンポーネントになっている。
そして、「ゲームフレームワーク」を継承することで、Greedゲームを実装できるように設計されている。

つまり、ドメインモデルという分析モデルへ蒸留させたことで、ドメインの再利用性が高まった利点がある。
しかし、分析モデルにも欠点はある。
分析モデルは抽象化しすぎるために、理解しにくいのだ。

(引用開始)
Greedゲームの分析モデルでは、Greedゲームに限らず他のゲームにも適用可能な部分(ドメイン・フレームワーク部分)とGreedゲーム固有の都合に左右される具象部分とが、モジュール(クラス)としても明確に分離/整理されています。
そのため、このようなモデルをベースに設計/実装されるソース・コードのうち、少なくともドメイン・フレームワーク部分については他のゲームを実装する場合にもそのまま再利用できる可能性が高くなります。
まとめ方(抽象化や一般化の方法)を工夫してなるべく多くの部分をドメイン・フレームワークとして抽出できれば、それだけ再利用率を上げることができるでしょう。
一方で、抽象化/一般化による変形/分離が施された分析モデルはある意味「素直な構造」ではなくなっているので、「問題領域の構造/特性を理解する」という目的にはあまり向いていない(理解するのが難しい)モデルになります。
たとえば、図 2 に示した分析モデルだけを見て、Greedゲームが「ゲーム」「ラウンド」「ターン」「ロール」の階層構造を持つということをパッと読み切るのは困難です。
ドメイン・フレームワーク化はドメイン・レベルでの再利用性/拡張性を確保するために必要なのですが、抽象化/一般化と理解のしやすさはトレードオフの関係にあります。
新たにモデルを見る人がそもそもの問題領域を素直に理解できるように、分析モデルの元になった概念モデルも対にして残しておく(抽象度の異なる目的別のモデルを作成する)のが良いでしょう。
(引用終了)

【2】上記のドメインフレームワークの考え方は、概念モデル(AsIs)→分析モデル(ToBe)へ蒸留させていくやり方だが、同じような経験がRedmineのワークフロー抽出にもある。

ある現場にRedmineを導入するとしよう。
すると、まず真っ先に行うのは、メンバー全員からヒヤリングして、その現場の現状のワークフローを抽出することだ。
抽出されたワークフローがRedmineのトラッカーの候補になる。
この作業は、あるべきワークフローではなく、現状運用されているワークフローなので、概念モデル(AsIs)と同等だ。

しかし、現状運用されているワークフロー(AsIs)があるべきワークフロー(ToBe)とは限らない。
無駄なステータスがあるかもしれないし、本来は別のワークフローで厳格に運用すべきかもしれない。

だから、あるべきワークフローのイメージを描いて、Redmineのワークフローを決定し、Redmineのトラッカーに登録する。
この作業は、現状のワークフローをモデルチェンジしてあるべきワークフローへ変えたので、分析モデル(ToBe)と同等になる。

【3】そんなことを考えると、設計という作業は、あるべき姿(ToBe)をイメージするのが重要であり、ドメイン駆動設計は進化的設計(反復的設計)によってAsIsからToBeを導き出そうとする手法であると思える。
最初から、正しいモデルを描くのではなく、リファクタリングしながら、より良いモデルへブラッシュアップしていく。
そのための技法やノウハウが「ドメイン駆動設計」にたくさん埋め込まれているわけだ。

色々考えてみる。

【追記】確かに、ドメイン駆動設計では、モデルとソースコードは一致するから、分析モデルと概念モデルの間に違いはない。

Twitter / j5ik2o: ドメインという言葉があるからといってすぐにDDDと紐づけて考えるのはよくない。DDDでは分析と概念のモデルは分けて考えないので。要注意。 / “ドメイン駆動設計に出てくる概念モデルと分析モデルの違い: プログラマの思索” http://htn.to/tXUEvR

でも、「ドメイン駆動設計」には、「浅いモデル」「深いモデル」という区別が出てくる。
おそらく、「浅いモデル」は「概念モデル」、「深いモデル」は「分析モデル」を示しているのだろうと思う。

プログラマが「モデルのあるべき姿」をいち早く理解できれば、単純に現状の業務を写しただけの概念モデルではなく、より汎用性の高い分析モデルをあまり苦労せずに作ることもできるだろう。
例えば、「ドメイン駆動設計」の貨物輸送モデルに出てくる船荷証券、利息計算モデルに出てくる発生主義会計(経過勘定科目)について業務知識をプログラマが持っていれば、業務の専門家と議論しているうちに、その存在に気づけるだろう。

| | コメント (0)

パターン指向リファクタリングのワークフローはドメイン駆動設計のアイデアに似ている

Martin Fowler氏によるリファクタリングのワークフローの記事が面白かったのでメモ。

【元ネタ】
Martin Fowler氏によるリファクタリングのワークフロー

TDDには黄金律(Red→Green→Refactoring)というワークフローがある。
つまり、テスト駆動開発とリファクタリングは密接に関連している。

テスト駆動開発・実践編01・黄金の回転 - Strategic Choice

実践テスト駆動開発第1回

テスト駆動開発の概要とメリット ? 実践テスト駆動開発一人読書会(1) ? mizoguche.info

リファクタリングは、反復的な設計手法でもある。
最初から完璧な設計ではなく、動くコードを徐々に洗練させながら、より良いコードへ変えていく。
つまり、進化的設計の手法の中にリファクタリングが組み込まれている。

パターン指向リファクタリング入門」は、GoFのデザインパターンとファラーのリファクタリングを結びつけた本だ。
アイデアとしては、パターンを、新しい設計の初期段階ではなく、既存の設計を改善するのに用いる。
さらに、パターンを使って設計を改善する時に、コードレベルの設計の変換、つまり、リファクタリングを使う。

(引用開始)
Joshua Kerievsky氏は著書「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」の中でこう提案した。

継続的にコードの設計を改善していくことで、どんどんそのコードを扱いやすくなる。
これは、ほとんどリファクタリングせず、便宜上新しい機能を追加する際に多大な注意を払う、というようなよくある状況とは雲泥の差だ。
もしあなたに継続的リファクタリングの衛生的習慣が身についたなら、いかに拡張や維持が容易になるかよく分かるだろう。
リファクタリングは今や周知の手法だとFowler氏は述べているが、多くのチームはリファクタリングの際に使用できる様々なワークフローをより良く理解する必要がある、と彼は示唆している。
そうすることで、それぞれの状況に一番合ったものを適応出来るからだ。
(引用終了)

リファクタリング」によれば、ファウラーは、パターンは目指そうとする所であり、リファクタリングは、どこか別のところからそこへ到達する方法、と言っている。
これは、リファクタリングの結果出てきた構造が実はパターンである、ということを意味していると思う。

この話はドメイン駆動設計の話に似ている。
ドメイン駆動設計において、浅いモデルを洗練させていくと、ある時、ブレイスクルーが起きて、深いモデルに変わる瞬間がある。
すると、深いモデルでは、ドメインエキスパートと開発者はユビキタス言語で会話できるようになる。

つまり、動くけれども汚いコードをリファクタリングしていくうちに、シンプルな構造になり、ブレイクスルーが起きた時、パターンが自然に現れてくることを意味しているのだろう。

パターン指向リファクタリング入門を突き詰めると、下記の3つのワークフローに集約されるらしい。

(1)新しいタスクを始める際に適応する"Preparatory(予備の)リファクタリング"
(2)広範囲において多大な注意を払う必要があるような問題のあるコードが存在する場合に適応する"Planned(計画的)リファクタリング"
(3)複数回の反復を通して大きなモジュールをリプレースする際に適応する"Long-Term(長期の)リファクタリング"

上記の3つのリファクタリングのワークフローは、ドメイン駆動設計の蒸留プロセスの連想させる。
パターン指向リファクタリング入門」は実際のコードを使って、リファクタリングとデザインパターンを絡めたパターン集になっているが、そのアイデアを突き詰めて抽象化させると、上記3種類のワークフローに収斂させるのだろうと思う。

他にも色々考えてみる。

| | コメント (0)

より以前の記事一覧