パターンランゲージの適用例
「パターン、Wiki、XP」の本を読んでからパターン・ランゲージに興味をもつようになった。
パターン・ランゲージをプレゼンテーションや学習パターンに適用した事例を見つけたのでリンクしておく。
【元ネタ】
井庭崇のConcept Walk | 授業「パターンランゲージ」のグループワークで制作したパターンを冊子化
プレゼンテーション・パターン (Presentation Patterns)
創造的プレゼンの秘訣を言語化した「プレゼンテーション・パターン」 - GIGAZINE
「プレゼンテーション・パターン」の反響 - Togetter
パターン言語事例 - 慶應SFCの『学習パターン』 - @IT情報マネジメント
『パターン、Wiki、XP ? 時を超えた創造の原則』から感じた時を超えたソフトウェア開発の道 | daipresentsの世界
パターン・ランゲージの良い点は、現場の事例をボトムアップで抽象化し、他人に共有できる形式知へ変換できる点だと思う。
いわゆる経験知や暗黙知の内容を他人に説明する時に役立つと思う。
そして、パターンで表現されたベストプラクティスがどの問題に有効であり、他の問題で何故有効でないのか、という理由も明確に表現してくれる。
パターンは実例に基づくだけに大きな説得力がある利点もある。
上記の例では、プレゼンテーションや学習のパターンをピックアップしているが、MECEの観点から見れば、これだけでは不十分かもしれない。
でも、パターンを適用することでヒントや気づきが得られるだろう。
文章だけでなく、柔らかい絵も付いているので、想像力を働かせやすいし、年齢層を問わないだろう。
パターン・ランゲージは、単に経験知をパターン化するだけでなく、複数のパターンが有機的に作用する点も大きな特徴の一つ。
だから「生成的(generative)」というキーワードがよく出てくる。
- XPとパターン Ralph Johnson'sの見解にも下記のように書かれている。
(引用開始)
XP には「信頼性」や「理解容易性」に直 接関連するパターンが無いにも関わらず,「プラクティス」全体が結びついて, 信頼性が高く理解が容易なシステムを生成(generate)しています.
パターン同 様,一つ一つのプラクティスには名前があり,それ自身を学ぶこともできます.
パターン同様,プラクティス全体が結びつくことで,個々の単純な足し合 わせよりも大きな効果が得られるのです.そして,XP は極端にインタラクティブで,さらに,計画は可能な限り小さくなっています.
(中略)
Kent は,『デザインパターン』はパターンの創発的な特性を十分に強調していない,すなわち,生成的(generative)でないと考えました.
XP はこの点を より強く強調しています.
XP は1ダースのパターン(実際にはもっと多い)とし て知られるようになりましたが,「変更しやすさ」や「信頼性」に関して直接 の言及をしていないにも関わらず,パターンに従うことでこういった特性が生
成されるのです.
XP は長期のスケジュールをどちらかというと重視していな いにも関わらず,プロジェクトは進捗の予測可能性がより高く,予定通り出荷できる可能性もより高い,とXP支持者は言います.
(引用終了)
複数のパターンが組み合わさること(生成的(generative))で、より大きな目的が達成されることを示唆している。
実際、XPのプラクティス、Scrumのフレームワーク、アジャイル開発の多種のプラクティスを思い出せば、各プラクティスが相互作用して初めてアジャイルな特徴が出ている。
チケット駆動開発も同様だ。
「No Ticket, No Commit」「Ticket First」の基本プラクティスから「No Ticket, No Work」「Small Release」「No Ticket, No Release」のようなプラクティスが派生し、更にトレーサビリティやワークフロー管理、並行開発などの特徴も生まれて、個別プロジェクトの課題に適用できるような柔軟な仕組みが生まれている。
色々考えてみる。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント