パターン言語の構造と事例集
「パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)」を読んでみたら、パターン言語はソフトウェア開発のベストプラクティス集を表現するのに有効ではないか、というアイデアについてメモ書き。
関係資料をスライドにまとめてみた。
【元ネタ】
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti の日記 (id:wayaguchi)
デザインパターンをマインドマップで表現してみる:An Agile Way:ITmedia オルタナティブ・ブログ
パターンランゲージのカンファレンス AsianPLoP 論文投稿は1月6日まで!パターンを書いて投稿しよう! - kawaguti の日記 (id:wayaguchi)
【1】「パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)」を読んで、パターン言語がパターンの関係の全体像を表した図であり、パターンの関係そのものもパターンであるという記述を見つけて、パターン言語についてようやく分かったような気がした。
パターンとは何か?
それは、ある状況における問題に対する解決策を提示した一連の実践知を、パターンという形式で表現した形式知。
ある「状況」においてどんな「影響力」が働いて「問題」を引き起こすのか。
その「問題」を「解決」する具体策を提示し、どのような「結果」を引き起こすのか。
それを名前付けしたのが「パターン」である。
パターンの利点は、現場で頻繁に使われる暗黙知や実践知に対して、形式知として整理して体系化されているため、その知識を再利用しやすいこと。
パターンという形式を使わなくても、日本でも開発プロセスやプロジェクト管理などの経験談をまとめて、たくさんの著書が出版されていたが、僕はいつも腑に落ちない感触を持っていた。
それらの知識は、他の現場で再利用できる知識として整理されていなかったからだ。
知識と言うよりも、年をとった人の経験談でしか、受け止められない感覚を持っていた。
逆に、従来のソフトウェア工学は、ウォーターフォール型開発をベースとしていたために、開発プロセスやその管理手法が古い気がしていた。
知識体系にはなっているけれど、現場でその知識を使えるとはあまり思わなかった。
その理由は、Excelなどを駆使する手作業の部分が多すぎたり、抽象的すぎて実際の現場ではメンバーのスキルやコストの観点から導入しにくいこともあった。
でも、それぞれの現場で起きるソフトウェア開発の諸問題と解決策をパターンとして整理・体系化できれば、パターンを利用できるだけでなく、パターンが使える状況が明確になっているので、パターンで全ての問題が解決できるわけではないことが分かる。
懸田さんが公開されているパターン・キャンパスを使えば、実際のパターンを作り出すこともできるだろうと思う。
また、パターン言語という全体像を示すことで、各パターンの関連も見えてくる。
あるパターンで、ある問題を解決したとしよう。
すると、パターンを解決する前とは違った状況(結果文脈)に変化する。
パターンを適用して問題が解決されたポジティブな側面もあれば、逆に、パターンの適用によって状況が変化したために新たな副作用が発生して、別の問題が発生するというネガティブな側面もある。
問題解決は別の新しい問題を生み出す。
でも、普通は、その別の新しい問題は、以前よりもレベルが1段上の状況に置かれているので、さらに高度な解決法を要求する時も多い。
【2】スライドでは、パターン言語を各事例でまとめてみた。
GOFのデザインパターンは23個あるが、それらも関係づけることでパターン言語になる。
「オブジェクト指向における再利用のためのデザインパターン」には、パターン言語の全体図が蜘蛛の巣のように書かれているが、最初の頃は、それが何を意味しているのかよく分からなかった記憶がある。
各パターンがパターン言語で表現できるということは、パターンは有機的であるように思える。
「組織パターン」からScrumフレームワークに使われるパターンを抽出したパターン言語の全体像も公開されている。
その図を見ると、Scrumは非常に上手く作られたフレームワークであることがよく分かる。
また、XPも、別の観点におけるプロセスパターンでありパターン言語であることも分かる。
XPの12のプラクティスは、バラバラの概念ではなく、それぞれが関連し合っていて、一体化して初めて大きな効果が得られる仕組みになっているわけだ。
そして、ドメイン駆動設計のナビゲーションマップは、ドメイン駆動設計で使われるパターンのパターン言語だ。
以前からずっと考えているアイデアとしては、チケット駆動開発で頻繁に使われるプラクティスをパターン言語としてまとめて整理したいことだ。
既にアイデアは色々公開しているし、「Redmineによるタスクマネジメント実践技法」にも書いている。
それらのプラクティスを一つのパターン言語として表現する事で、チケット駆動開発の構造をより明確にしてみたいと考えている。
| 固定リンク
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- カンバンはステータス名が大事(2021.01.02)
「パターン言語」カテゴリの記事
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2(2020.12.31)
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1(2020.12.30)
- なぜユーザーストーリーによる要件定義にピンとこなかったのか(2020.12.29)
- AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想(2020.03.01)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
コメント
私ゃ最近、デザインパターンはアンチパターン駆動でなければならないんじゃないかって思ってる。そうなっていないからこそ、いわゆる「トンカチを持つと何でも釘に見える」って奴に陥りやすいんじゃないかって。
投稿: tarosuke | 2013/12/31 23:36