[#Agile] 自己組織化あるいは自律的組織 #UAS3

最近、チームはどうあるべきかを考えています。

アジャイル放談

考え始めたきっかけは、8月11日に頒布開始されるUAS3（Ultimate Agile Stories iteration 3）掲載に向けたアジャイル放談でした。今回も内容豊富な議論でした。編集を意識したり、ただ酔っぱらっていたり、と楽しいひとときをすごさせていただきました。

議論し尽くせなかった内容は、自転車の教え方 - トレーニングのあり方の考察 - や [#agileradio] アジャイルラジオはメディアミックスの力を持つ！ に書きました。そして、最後に残ったのが自己組織化あるいは自律的組織の議論です。

組織パターン

自己組織化に関しては、今夏に和智さんが訳されたJim Coplienらの「組織パターン」という本が出ます。しかし、よりUAS3を楽しんでいただくことと、読んだ際の気付きも明らかできる、と思いますので、この本を読み始める前、現時点での考え方をまとめておきます。

とはいうものの実は「XPやアジャイル開発の「価値」 -「価値観」でお願いします - #devsumi」で書いた様に和智さんの講演は聞かせていただいたので、講演資料の防火壁の事はすでに頭にあります。

自己組織化に境界は必要か？

アジャイル放談で議論になったのは、境界が必要かどうかです。「アジャイル開発とスクラム」にある様に、スクラムはオブジェクト指向化したプロセスですのでカプセル化は当然ですし、組織パターンのCoplienが関わっているので防火壁も意識されているでしょう。

実際、スクラムの価値である「集中」を実現するには外乱からチームを守る必要があり、サーバントリーダーシップを発揮して実現すべき事の一つでしょう。しかし、それは単純な境界で良いのか？というのが私の疑問です。

他の組織や関係者との情報共有

アジャイルのスクラムは良くできているものの、知識共有がチーム内で閉じている点がオリジナルのスクラムに劣っている点である事は、野中さんが「アジャイル開発とスクラム」で書かれているとおりです。

これに対して、現場ではタスクボードを見える場所に置いて、関連するチームや関係者で情報共有をされています。多くのチケット駆動開発プロジェクトが、社内に公開されているいたり、関係者をメンバーにしておくのと同じですね。

マルチロールな関わり方

アジャイル開発のワークショップでは「マルチロールは良くない」と言われます。しかし、実際問題として、プロジェクトは一つでも、事務作業や勉強会のような社内作業のほか、個人的な趣味や過程な事情など、人間が社会的な動物である限り、複数のロールを持つ事は当然です（関連「複数の組織に所属するユーザを支援するマルチロールコミュニケータと権限の委譲機構@SS2001」）。

欧米はどちらかというと個人主義・契約主義ですので、４０時間など契約の時間内の作業をこなせば後は自由であるとか、複数のロール間で何らかの取り決めをしておくのかもしれません。しかし日本の場合、あたり前の様にプロジェクト以外の色々な仕事が割り当てられてしまうとか、出産後の時短勤務であっても遠慮しながら帰るなど、なかなか難しいかもしれません。

マルチロールの場合も情報の共有が有効だと思います。どのような作業にコミットし、どのような計画で作業を実施する予定であるかを関係者に示す事が効果的です。しかし、チケット駆動開発であっても個人の状況は意識的に見ないとわかりません。朝会などの全体のコミュニケーションの場で、本人や事情を知る人が、チーム以外のロールを説明して、情報共有して個人の防火壁を築く必要があるでしょう。

自己組織化は同じ方向を向く事から始まる

このようにチームの運営を考えると単純な境界ではうまくいきません。バザール方式（リンク先はwikipedia）のオープンソースソフトウェア開発やコミュニティの活動でも自己組織化されているように、必要なのは方向性の共有だと思います。

チームに境界を定めるとその中だけで自己組織化されますが、多くのソフトウェアはリーマン先生の言われるE-Typeですので、単独で存在せずに外界のシステムに組み込まれて実行されます。そこでは、ユーザを含む全てのステークホルダーを巻き込んだ組織化必要です。

作って終わりではなく常に進化し続けるには、境界を作ってその中で自己組織化するだけではなく、関係者が重層的なロールを持ちつつ関わる状況が必要です。その様な状況も含めて、自己組織化を実現していくべきだと思います。

現場には多くの事情が存在する

スクラムは一つの有効な解を示している事は間違いないと思いますが、現実には色々と考慮しないといけない事情があります。それは受け入れて解決しないといけない問題です。

スクラムのアイデアの元になったオブジェクト指向は優れたモデリング技術の一つですが、言語によってはやりにくい事があります。そこで、アスペクト指向、多重継承やMixinのような改良が行われています。

これらは多くの問題を解決する反面、シンプルさを損なって新しい問題を生む場合もあるでしょう。しかし、単純にはいかない場合があるという現実を知っておく事は重要です。現実の問題点を踏まえた上でシンプルな実現を目指せば、より良いものにできるからです。

おわりに

以上、実際のチーム作りがどうあるべきかの考えをまとめました。境界を定める事は有効だとは思いますが、必須ではないし、それ意外の視点も大切ではないかと思っています。

自己組織化に必要と思われている境界が、書籍「組織パターン」でどのように語られているか、楽しみにしています。

＃この記事は、UAS3のアジャイル放談とあわせて読まれると、より楽しめると思いますw