アジャイル開発へのミーム学的アプローチ

アジャイル開発における知識やルールの伝播などについて、利己的遺伝子で有名なリチャード・ドーキンスの「ミーム」に例えることは、それほど新しい話ではありません。

私自身はまだちゃんと読んでいないのですけれども、古くは、2002年（原書は2001年）のアリスター・コーバーンの「アジャイルソフトウェア開発」にミームに関する記述が出てきているようです。原書のドラフト版などがネットにPDFでありましたので、興味のある方はどうぞ。
http://zsiie.icis.pcz.pl/ksiazki/Agile Software Development.pdf

さらにその後、Philippe Kruchten氏がMemeplex（ミーム複合体）にも言及して、よりコンテキストに着目した記事を書いたりもしています。
Voyage in the Agile Memeplex - ACM Queue

このような、アジャイルにおけるミーム学的なアプローチというのは特にアジャイルな組織のマネジメントや組織改革を考えていく上では非常に面白い考え方だと思います。そんな中で、このブログでもよく取り上げているJurgen Appelo氏のManagement 3.0でも、第10章でミームやミーム複合体の話が出てくるので簡単に紹介したいと思います。

アジャイルソフトウェア開発はミーム複合体である

互いに依存するミームの集合体をミーム複合体（memeplex）と呼びます。ダーウィン進化論的に言えば、ミームが寄り集まってミーム複合体を形成するのは、その方が自身を複製する成功確率が高くなるからです。
ここで、アジャイル開発における個々のプラクティスをミーム、そしてそれらをパッケージングしたScrumだとかXPだとかKanbanだとかをミーム複合体と考えてみましょう。ご存知の通り、個々のプラクティス自体はアジャイル開発云々以前から存在していたものも多いと思います。しかしながら、それらのプラクティス自体がミームとして世の中に伝播していくのはかなり限定的であり、現在これだけアジャイル開発が世の中に広まっているのは、やはりそれがアジャイル開発としてScrumだとかXPだとかKanbanだとかといったブランド（？）名のもと、ミーム複合体を形成したことによるものが大きいと言えます。

そう考えるとどんなことが見えてくるか

Jurgen Appelo氏はこのあたりの話を本にまとめるまえに自身のブログでその草稿に近いものを書いています。
The Success of the Agile Memeplex - Agile Management | NOOP.NL
そこから、アジャイル開発をミーム複合体としてみた場合に見えてくる５つのポイントをそのまま引用したいと思います。

It can be easier to get people to adopt multiple ideas, concepts or practices simultaneously, then it is to have them adopt just one. (For example: teaching them to apply Extreme Programming instead of only unit testing);

In a memeplex not all ideas, concepts and practices need to be beneficial. In fact, some of them can be harmful. But because they are all part of the same memeplex, the bad ideas help the good ideas to be copied around as well, which neutralizes the bad effects. (An example which might be on dangerous ground: I have seen no conclusive evidence of the value of collective code ownership, but this practice seems to reinforce the other agile practices, so it won’t hurt copying it along as well);

Removal of individual memes from the memeplex may weaken, or even destroy, the strength of the memeplex. (Example: removal of collective code ownership might lead to an agile adoption breaking down completely);

There may exist multiple competing memeplexes that reinforce and need each other because their competition draws attention away from alternatives. (Example: competition between XP, Scrum, and Kanban within the Agile world draws attention to the agile brands in general);

Memes may have different origins, and can even be exchanged and shared across multiple memeplexes. (Example: user stories started as a meme within XP, but are now firmly locked into the Scrum paradigm as well).

http://www.noop.nl/2010/02/the-success-of-the-agile-memeplex.html

まとめ：組織へのアジャイル導入における示唆

アジャイルな開発を組織に導入する際によく議論になるポイントとして、「Scrumでやるよ」みたいな感じで始めた方がいいのか、とりあえずいくつかのプラクティスからできる範囲で少しずつ導入していくのがいいのか、というのがあります。また、Scrumを導入するとして、最初からフルセットでやらなきゃいけない（いいとこ取りのいわゆるCherry Pickingはよくない？）のか、それもできるところから…でよいのかという話もよく出てきます。
上で紹介した、ミームとミーム複合体の話から考えると、ミーム単体（個々のプラクティス）よりもミーム複合体（たとえばScrum）の方が強力であり導入の成功確率も高いと考えた方がよいでしょう。
但し、JurgenもManagement 3.0の中で語っていますが、これは必ずしも「トップダウンでビッグバン的に導入する」ことを意味するわけではありません。ミーム複合体としてのScrumを導入するからといって、それが「全てのミーム（プラクティス）を同時に」導入しなくてはならないというわけではないということです。概念として大きな固まりで捉えること、そしてそれを伝えていくことは重要ですが、個々のプラクティスの導入時期や順序などは、それこそその組織のコンテキストに応じて、というのが正しいアプローチではないかと思います。