パターン言語の構造と事例集
「パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)」を読んでみたら、パターン言語はソフトウェア開発のベストプラクティス集を表現するのに有効ではないか、というアイデアについてメモ書き。
関係資料をスライドにまとめてみた。
【元ネタ】
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によるタスクマネジメント実践技法」にも書いている。
それらのプラクティスを一つのパターン言語として表現する事で、チケット駆動開発の構造をより明確にしてみたいと考えている。
| 固定リンク
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「パターン言語」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント
私ゃ最近、デザインパターンはアンチパターン駆動でなければならないんじゃないかって思ってる。そうなっていないからこそ、いわゆる「トンカチを持つと何でも釘に見える」って奴に陥りやすいんじゃないかって。
投稿: tarosuke | 2013/12/31 23:36