Scrumの組織パターン

@kawagutiさんのBlogにScrumの組織パターンが載っていたのでメモ。

【元ネタ】
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti の日記　(id:wayaguchi)

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

【1】@haradakiroさんから、Scrumはパターンランゲージであるという意見を聞いて正直びっくりした。
XPこそがパターンランゲージであると思っていたから。
でも、上記の記事を読んでその意味を理解した。

上記の記事のパターンは構造がラフすぎて、正直理解しにくい。
原本を読むと、パターンの背景が詳しく書かれているだろうか？
とても興味がある。

僕はパターンという考え方が好き。
ソフトウェア工学や開発プロセスのように、人が関わる活動を支配する法則を説明するのに、経験則をパターンという言葉で表現できるのはとても分かりやすいと思う。
パターンはどんな背景や文脈で有効で、逆にどのような状況では有効でないのか、をはっきり示してくれるからだ。

パターンという考え方は性格学に似ているように思う。
性格学にはユングやフロイトなどたくさんの流派があるが、人の性格がどの分類に当てはまるのかが重要なのではなく、分類した結果現れた類型(タイプ)がどんな本質を持っているのか、を示しているのが重要、という話を読んだことがある。
その考え方をパターンに当てはめると、我々の現場の問題に対してパターンをそのまま当てはめるよりも、そのパターンの背景や本質を理解することによって、問題をよりシンプルな形で解きやすくしてくれるものだと思う。

パターンは経験則から生まれた社会科学に似た法則だ。
だから、パターンはある特定の時代や場所に依存する。
物理学や数学の法則のようにいつでもどこでも通用するわけではないが、パターンはその時代や場所から生じる制約条件を明らかにしてくれると思う。

【2】パターンの考え方で面白い特徴は、複数のパターンを組み合わせると意外な効果が現れることだ。
XPには10個以上のプラクティスがあるけれども、ソフトウェア開発の全体進捗や品質について何一つ語っていない。
でも、テスト駆動や継続的インテグレーションなどのプラクティスを組み合わせることによって、ソフトウェアの品質を従来のやり方よりも劇的に高めることができる。
同様に、計画ゲームやイテレーション単位の小規模リリースなどのプラクティスを行うことによって、開発の進捗をコントロールしやすくなり、そこからVelocity(開発速度)というアジャイル開発特有の概念も生まれてくる。

すなわち、ソフトウェアの品質や開発の進捗などの概念は、その概念自体を追いかけても掴みどころがなく、むしろ無関係と思われるプラクティスを徹底的に行うことによって逆にその概念に迫ることができるのだろうと思う。

この辺りは色々考えてみる。