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さんがまとめているという話も聞きました。
(引用終了)
懸田さんの別資料もリンクしておく。
最近のコメント