継続的改善フレームワークとしてのScrum

とあるところで記事として書こうかなと思っていることを、頭の整理＆下書き代わりに書きなぐっておきたいと思います。

Scrumはフレームワークである

Scrumって何？という話をする時に、あまり意識せずに、アジャイル開発の「プロセス」だとか「手法」だとか「方法論」だとか言ってしまうこともあるのですが、自分自身では「フレームワーク」という言い方が一番しっくりくるため、ここ数年はできるだけ「フレームワーク」と呼ぶようにしています。
そして、さらにどんなフレームワークかと言えば、Tobias Mayorが"Scrum doesn't do anything"(Agile Anarchy http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/)の中で述べているように、

Scrum is a framework for surfacing organizational dysfunction.

というのが、とても的を射ているように思います。

Scrumはアーキテクチャである

一方で、「Scrumはアーキテクチャである」という言い方もできるのではないかとも思っています。
ここで言う、「アーキテクチャ」は、ローレンス・レッシグが「CODE VERSION 2.0」の中で書いているような、人間の行動を規制する４要素（法・規範・市場・アーキテクチャ）の一つとしてのアーキテクチャです。まぁ、正しく言うとちょっと違うのですけれども、なんとなく、それに近いものがあるな、と。

Scrumは継続的改善のためのフレームワークでありアーキテクチャである

上記のように考えると、Scrumとは、

• 組織の機能不全を表面化させることで、それへの対処を促すフレームワークとしての特性だけでなく、
• またその実効性を担保するための、人間の行動・振る舞いを規制・規定するアーキテクチャとしての特性をも持っている

と言えるのではないでしょうか。

これによって何が生まれるかというと、（ここは長くなるので話を端折りますが）フレームワークやアーキテクチャに則った行動を習慣づけられることによる「意識」の変化です。

一般的には、「意識を変える」→「行動が変わる」という流れと思われがちですが、実際には、この逆のパターン、すなわち、行動を変えることによって意識が変わってくるということの方が多いように私は思っています。ただ、そこで難しいのが、いかにして行動を変えるか、というところ。そのための、フレームワークあるいはアーキテクチャとして機能するのが、私はScrumだと思っています。そしてそれが支えるものは、とりもなおさず、「継続的改善」なのです。

そういう視点から考えると、Scrumを組織に導入するにあたっていろんなことが考えられるわけです。そのあたりをきちんと整理していずれまとめてみたいと思います。