エクストリームプログラミング(XP)では、5つの価値が掲げられている。
シンプリシティ、コミュニケーション、フィードバック、リスペクト、勇気だ。
このXPの5つの価値を眺めていると、ほとんどそのままチームの自己組織化を促進する要素になっているな、ということにふと気づいた。
それぞれの人がXPに取り組む中でこのことを意識していれば、より高度に機能する自己組織化したチームになっていきやすくなるのではないかと思う。
この記事では、それぞれの価値(価値基準)がどのように自己組織化を促進しうるのかを解き明かしてみたい。
シンプリシティ
まず、シンプリシティ。シンプルなものは、組織化に開いている。
複雑なものはすでに組織化していて、新たな組織化には開いていないのと対照的だ。
どういうことか。
たとえば、「思い立ったらすぐ話す」というというシンプルな行動を考えてみる。
話すという行動は、あらゆる組織化に開いている。
まず、ただ話すことはいつでも起こりうるし、それ以外のあらゆる行動と組み合わせうる。
話していて、ちょっと一緒にコードを書いてみる。ホワイトボードを持ってきて図を描いてみる。関係者を呼んできて一緒に話す。などなど。
シンプルなものは、あらゆる構造(=組織)をそこから立ち上げていくことが可能だ。
他方、複雑なものを考えてみよう。「一日15分の定例ミーティングを設定する。関係者が多く調整がむずかしいため、その週のミーティングの時間調整をメンバーの持ち回りで担当する。ただし〇〇さんは非常に多忙なため担当から外す。また、定例ミーティングの議題は前日の18時までに収集することにして、投票で優先順位を決める。出席予定者は、欠席予定者の2倍の票数を持つ。棄権した場合は票を次回に持ち越すことができる。……」。
説明しやすいように恣意的に(無駄に)複雑にしてみたが、世の中を見渡してみると、これに似たような複雑な行動を作り出している例は案外すぐに見つかるだろう。
この行動(構造)に適合する構造を立ち上げるのは至難の業だ。すぐそばに似ているが少し違う(目的や、出席者が少しずつ違う)ミーティングがあったりなんかしたら、もう目も当てられない。
複雑なものの周りには、自己組織化が立ち上がる余地が非常に少ないことがわかるのではないだろうか。
「話すこと」を例として挙げたが、「チームの活動」というふうに広げてみても同じことが言える。
外から見てもよくわからない複雑・難解なルールに則って運営されているチームと関わることを想像してみるとわかるだろう。「このチームでは、Aさんが一括して要求を受け付けます。要求を伝えるには、こちらのフォームの必須項目を埋めてください。Aさんが休みの場合には、Bさんが代理を果たします。ただし一人ではその役割を負いきれないため、都度代理補佐を選出します。代理補佐は要求を受け付けません。代理の場合は、要求へのレスポンスが3日程度遅くなります。なお、……」。
このチームとの関わりは、極めて閉じている。ルールに則って行わないと機能しないし、そのルールも難しい。やはり、自己組織化の立ち上がる余地は非常に少ない。
まとめるなら、シンプルにすることで、自己組織化が起きやすくなる、と言えるだろう。
コミュニケーション
コミュニケーションはチームの自己組織化の契機だ。
チームの自己組織化は、それぞれの人が「感じ取る」ことによって始まると思う。
こういう課題があるのではないか。もっとこうした方がいいのではないか。次はこれをやるといいのではないか。
そういう動きがあるのなら、連携するといいのではないか。そういうAPIがあるのなら、こういう応用が考えられるのではないか。などなど。
このように、「感じ取る」ことから自己組織化が始まる。
コミュニケーションは、受信と発信を兼ねる。感じ取ることと、感じ取らせることを兼ねる、ということだ。
気軽に質問すれば、手軽に質問への答えが得られる。質問への直接の答えだけでなく、よりより問いの立て方や、関連する有益な情報が得られる可能性も高い。
質問を受けた側には、質問してきたその人が今何に取り組んでいるのか、関心を持っているのかが伝わる。将来、そのことで逆に話しかけに行く可能性も上がるだろう。
質問に限らず、相談や共有といった関わりでも同じだ。
コミュニケーションがあるところには、必ず受信と発信の双方が同時にある。
だから、同じ問題解決だとしても、「コミュニケーションによって解決すること」こそが自己組織化を促進する鍵となる。
仮に、「解決に至るまでの労力と解決の質がまったく同じ」だったとして、コミュニケーションせずに解決するのと、コミュニケーションして解決するのとだったら、後者の方が(自己組織化の観点からは)明確に望ましい、ということだ。
まとめるなら、コミュニケーションを増やすことで、自己組織化が起きやすくなる、と言えるだろう。
フィードバック
フィードバックを得ることを目指すことで、コミュニケーションが増える。
コミュニケーションが自己組織化の契機だとしたときに、その契機を増やすことにつながる、ということだ。
どういうことか。
ある機能の実現のために、うまい設計を思いついたとしよう。いいね、この設計でいけそうだ。
普通だったら、そのまま実装してしまうのではないだろうか。
しかし、フィードバックを大事にする考え方では、ここでコミュニケーションを取るという選択肢が浮かび上がる。
「よい設計を思いついたから、それが(思った通り)よい設計か、フィードバックを得てみよう」というわけだ。
その設計についてよいフィードバックをもらえそうな人に話しかけてみる。
「いいね、いいんじゃない」という反応かもしれない。「いいね、ただ……」という反応かもしれない。「いや、それだとうまくいかない。なぜならば……」という反応かもしれない。
実は、反応の内容はここでは問題ではない。
いずれも(「いいんじゃない」の一言でも)有益なフィードバックだし、フィードバック以前に、コミュニケーションの機会を作ることができているからだ。
フィードバックを増やすために、コミュニケーションを増やす。
チームの自己組織化の観点では、これがフィードバックという価値の最も大きな貢献だ。
補足的に。
ソフトウェアシステムもまた、チームという生態系(エコシステム)の一部である。
ソフトウェアシステムからのフィードバックもまた、チームというシステムへの入力となる。XPの規律であるTDDや継続的デリバリーといった、システムからフィードバックを得続けるための仕組みもまた、チームの自己組織化に一役を買う。
まとめるなら、フィードバックを増やすことで、自己組織化が起きやすくなる、と言えるだろう。
勇気
勇気とリスペクトの重要性は、「チームの自己組織化」を構成する単位が「人間」であることから来る、表裏一体のものだ。
まず、勇気について。
チームの自己組織化には、個人が非常に重要だ。そのことについては、以下の記事で詳しく書いた。
記事の内容をここで繰り返すことはしないが、かいつまんで言うと、自己組織化のためには、それぞれの人が自分自身の価値観と、(そのときどきで)実現したいビジョンに忠実になることが大事だ、ということだ。
今の世の中では、まだまだ仕事の価値観と個人の価値観は切り離すもの、といった考え方が支配的だと思う。
「仕事の中でやりたいことをやる」というのは、なにか特別なことだと考えられているのではないだろうか。
実はそうでもない、というか、やりたいことをやることこそが、仕事で偉大な成果を上げる方法でもある、と思う。
ただ、それをここで論証するのはやや骨が折れるため、省略させてほしい。そういう世界観を前提としている話だ、ととりあえず受け取っていただければ幸いだ。
そういう世界観において、しかし、世の中の常識を鑑みると、「自分はこれがいいと思う」ということを素直に打ち出すのには勇気がいる。
人にもよると思うが、そういう人がほとんどではないだろうか。
ましてや、チームの中で(相対的に)スキルの低い領域が多い、比較的経験が浅い、といった立場だったらなおさらだろう。
それでも、自分の価値観とビジョンに忠実になること。
自分の思いを尊重していい。チームの自己組織化のためには、そう思える勇気が必要だ。
そして同時に、人のことは人に委ねること。
すべてをコントロールしようとしない。当たり前のようにも思えるが、案外難しい。誰かがすべてをコントロールするのは、当然ながら自己組織化ではない。
自分のことをする勇気を持つこと、そして人のことは人に委ねる勇気を持つことだ。
まとめるなら、勇気を持って行動することは、「人の集まり」が自己組織化するための「A面」と言えるだろう。
リスペクト
そして、B面がリスペクトだ。
リスペクトの方をA面とするか迷うところではあるが(両A面と言いたい気もする)、あえてこちらをB面とするのは、勇気があってこそ、このリスペクトが機能するからだ。
逆に、リスペクトだけがあって勇気がなくては、何も始まらない。
それでも、リスペクトは重要だ。勇気と同じくらい。
リスペクトについて言うべきことはそれほど多くない。
他の人の勇気を生かす。一言でいえばこれだけだ。
他の人が、その人の価値観とビジョンにもとづいて勇気を持って行動を起こしたとき、それを尊重し、支えるということだ。
自己組織化は勇気から始まる。こう言ってもいいだろう。
前に「コミュニケーションはチームの自己組織化の契機だ」と書いたが、より正確に言うと、自己組織化が力強く立ち上がるのは、そこに勇気がともなっているときだ。
リスペクトを欠くと、立ち上がってくる自己組織化を邪魔してしまう。
わかりやすい場面を想像してみよう。
経験の浅いエンジニアが、最近学んだ新しい設計手法を適用してみたい、と勇気を持って提案したとする。
リスペクトがない場合、経験豊富なエンジニアが、それはうまくいかない、とか、そんなことしなくても今のやり方で十分だ、と頭ごなしに否定し、何も起こらずに終わるかもしれない。
リスペクトがあれば、同じ経験豊富なエンジニアは、提案への感謝を伝えるとともに、その手法の利点を掘り下げるだろう。
結果的にそれが採用されるかもしれないし、されないかもしれない。いくつかの手法を統合した第三案にたどり着くかもしれない。
いずれにせよ、チームによってしか生まれなかったものが立ち上がってくる可能性が高くなる。これこそが自己組織化だ。
まとめるなら、リスペクトを持って行動することは、「人の集まり」が自己組織化するための「B面」と言えるだろう。
XPの5つの価値は自己組織化を促進する
全体をまとめよう。
エクストリームプログラミング(XP)では、5つの価値が掲げられている。
シンプリシティ、コミュニケーション、フィードバック、リスペクト、勇気だ。
シンプルなものは、組織化に開いている。
行動にせよ、要求や設計にせよ同様だ。あらゆるものをシンプルにすることで、自己組織化の可能性は広がる。
コミュニケーションは、自己組織化の契機だ。
コミュニケーションには双方向に「感じ取る」機会を作り出し、それが自己組織化のきっかけになる。コミュニケーションを増やすことで、自己組織化の機会は増える。
フィードバックを大事にすることは、コミュニケーションを増やすことにつながる。
すなわち、自己組織化の機会を増やすことにもつながる。また、人によるものかソフトウェアシステムによるものかを問わず、フィードバックそのものもまた、チームというシステムへの入力となり、やはり自己組織化のきっかけを作り出す。
勇気とリスペクトは、表裏一体となって「人の集まり」の自己組織化を支える。
それぞれの人が、勇気を持って価値観とビジョンの実現に踏み出すときが、自己組織化が本当に始まる瞬間だ。そして、踏み出した人を支えるために必要なのがリスペクトだ。
勇気とリスペクトがあってこそ、人の集まりが自己組織化することができる。
このようにして、XPの5つの価値は自己組織化を促進する。