この国では犬が

本と芝居とソフトウェア

それくらい、欲張ってみてもいいだろう #RSGT2026

年末にきょんさんとお話ししたときに、「何を一番大事にしたいんですか?」といったことを問われて、よいプロダクト、よいチーム、よいプロセスや理論、それを広めること、自分自身の状態(がよいこと)、等々の中で何を一番大事にしたいのか、ということを考えたとき、「欲張りだから全部なんですよね」と答えたことをよく覚えている。欲張りだから、という言葉には、全部って答えるのが恥ずかしいというか、選ぶ覚悟がないことへの引け目みたいなものがあったのだと思う。

全部大事にしたい。そして今、全部大事にしていい、と思っている。というか、全部大事にすることこそが大事だ、とさえ思っている。僕自身にとっては、ということですね。

全部大事にしたい、ということが選べない弱さの表れであるというのは、実際そうではあると思う。でも同時に、どれも諦めたくないということが紛れもない本心なのだ。

いいプロダクトを作りたい、という人がいる。いいチームを作りたい、という人もいる。いいプロダクトを作るために、いいチームを作る必要がある、という人もいる。どれも大事な思いだし、正しいとも思う。

でも、僕の場合は、全部であることが特別大事なのだ。いやいや、誰だってそうだろ、と思っていたけれど、もしかして、僕が特にそうなのかもしれない、というか、どうやらそうみたいだ、ということに気づきつつある。

欲張りなのだ。これは引け目があるから言うのではなく、事実、そうなのだ。

そして、全部を求めることは、「無理」ではない、と思う。全部が満たされる場所というのは、容易ではないかもしれないが、確かにある。トレードオフではなく、妥協でもなく、調和。別に、それぞれの欲求に一次元の評価軸があって、それらの数値を全部最大化したい、ということを言っているわけではない。すべてが同時によくなっている、と誰もが感じられる、調和した状態というのがあるはずで、それを目指したい、ということを言っている。

これは、クリストファー・アレグザンダーが言う「全体性」の概念とかなり関係がある、と思っている。要は、全体性の高い状態、そしてそこから無名の質が感じられる状態を作り出したい(作り出し続けていきたい)、と思っているのだと思う。

2024年の暮れに、こう書いていた。

価値を生み出している、と思えることをやる。

これは、僕がずっと探しあぐねていた「やりたいこと」を、ついに言語化できた、と感じた瞬間だった。

ただ、これだけではうまくいかなかった。だから、去年の暮れには、こう書いた。

いずれにせよ、わからない、というところに戻ってきた、ということですね。

「全体性の高い状態、そしてそこから無名の質が感じられる状態を作り出したい」。わからない、というところから、ここまでは進んだ。

これは、「価値を生み出している、と思えることをやる」ということを別の言葉で言い換えただけだな、とも思う。別の言葉で言い換えることができたということは、解像度が上がったとは言えるのかな。でも、抽象度は変わっていない、つまり、具体的に何をするかという意味では一歩も進んでいないようにも思える。

それでも、力強い目標にはなった、のではないか。正直、難易度はとても高いと思う。だからこそ、目指す価値がある。そう思える。

RSGT2026では、「なかったものを作るんや」という思いを新たにした。きょんさんの、人=責任という古いやり方から、「手順」への着目へという革新。平鍋さんの、スクラムの根本原理を解き明かそうという試み。及部さんの、スクラムをコンフォートゾーンと言い切る覚悟と脱却への取り組み。それらから、勇気をもらった。

そして、色々なところで多く聞かれる「AIでアウトプットは増えたが、アウトカムは増えない」といった課題感への言及。RSGTのような、日本の最先端(に近いであろう)の人たちが集まる場でも、まだそこなんだな、と思うと、安心感(置いていかれてなくてよかった)よりは、危機感(こんなことじゃ、よりよい世の中はなかなか来ないぞ)がある。

15年間ソフトウェアエンジニアをやってきて、自分の中にもそれなりの暗黙知がある。それを最大限使って、周りの人たちの力も借りながら、なかったものを作る。プロダクト、チーム、プロセスや理論。そして、それを広めること。最後に、いやむしろ最初に、自分自身が充実していること。

それくらい、欲張ってみてもいいだろう。

2025年のふりかえり

今年も終わりますねえ。

やったこと

去年は、こう書いていた。

正直、一度「自由を手に入れてしまった」感覚がある。
一周目のゴール。あるいは第一部完、かな。
来年は、この自由を思い切り謳歌してみたい。
謳歌していたら、きっとまた課題が見つかるだろう。
人はあんまり自由でもいられないものだから。

これがどうして、驚いたことに、去年手に入れたと思った自由は自由1.0だったのだ。

そのあたりについては次の「わかったこと」で詳しく書こう。

やったこととしては、そうですね、全体として薄っすらとした停滞感に悩まされた一年だった、と言いたくなってしまうのだけれど、ところがどっこい、前半はなかなか精力的にやっていた様子が見受けられるのですよねえ。

それが証拠に、2月にはソース原理実践ワークショップに京都まで、

source.teal-lab.jp

そこからの縁で、自己組織化というワードに食いついて4月には美瑛でのホールシステム・リーダーシップ探求ワークショップにも行ったし、

teal-lab.jp

5月にスクフェス新潟にも行った。

www.scrumfestniigata.org

スクフェス新潟にはとうまさんに誘われて行ったので、お誘いいただきましてありがとうございました。
今にして思えば、ここできょんさんと知り合いになれたのがとても大きい。

そんなこんなで、はてなブログにも3記事書いたし、しずかなインターネットの方には、公開しているものだけで18記事も書いている。

たいへん精力的ではないですか。

そうですね、精力的、だったのですが、6月頃から、なんだかだんだんおかしなことになる。

そうですね、ちょっと詳しくは書きにくいし、書こうとも思わないけど、まあ、おしなべて言えば、停滞感のようなものに苛まれていったのでした。*1

だから後半ははてなブログ0。しずかなインターネット(先週まで)1。*2

わかったこと

だから、まとめてしまえば、奇妙な1年だったなあ、という感想になってしまいますね。

ただ、今は割とすっきりしていて、いや、すっきりしかけていて、かな。

まあこの記事に書いたようなことがおおむね関係あるんですけど、あるようで、ないようで。

sizu.me

あー、まだまとまってないんだな。
すっきりまとまった形でいま書くことは、かなり難しそうです。

ただ、書けることを書くなら。

まず、冒頭で触れた自由について。

昨年末に、「自由を手に入れてしまった」感覚を得たわけですが、その感覚自体が間違っていたとは思いません。今も「その自由」は持ち続けている。

ただ、それは「自由1.0」だった、と書いた。
どういうことかというと、昨年末の時点では、「制約が外れた」だけだったんですね。

今までは、もっと稼げるようにならなきゃ、とか、もっとできるようにならなきゃ、とか、何がしたいのか見つけなきゃ、とか、都度都度課題の方から来てくれたのです。
それが制約。

では、制約が外れると何が来るか。本当の自由がやってくる。自分自身が、本当に、何がしたいのかに向き合わなければならなくなったのです!

何がしたいのか、見つけたんじゃなかったっけ?

価値を生み出している、と思えることをやる。

それはそう。なんだけど、粗すぎましたね。いや、小さすぎた、のかな?
器として小さい。だから、導かれなかった。

いや、導かれたんですよ。だから、前半は調子よかったと思う。
でも、後半にかかる頃、ちょっとした揺らぎのようなものが来たときに、大きく揺さぶられてしまった。ということになるのかな。

器として小さかったから。

うまくまとまりませんね。まあ、実際まとまってないのだと思う。言語化以前の状態としても。

いずれにせよ、昨年末の状態が「安定」だったとすれば、今はまた「嵐」な感じです。(嵐が一時的に止んでいる、気もする?)

そういえば、4月のワークショップでは自分が人生の中で今「四季」のどこにいるか(※四季は巡るもの、という前提)というワークをやったのだけれど、僕の答えは「盛夏」だった。そこを少し回ったところ、だったかな?

そして今振り返ってみると、そこから実りの秋を経て、あっという間に冬に突入し、いま春の足音が聞こえ始めている、ようにも思える。

いや、わからない。そんなに早く巡ることはないようにも思えるし、あくまでメタファーなので、何重もの異なるタイムスパンで巡るもののような気もするし。

いずれにせよ、わからない、というところに戻ってきた、ということですね。

次にやること

さて、どうしようかな。

まさに、どうしようかな、ということをここ1ヶ月ほど考えていて。

うーん、やっぱり、まだ「冬」なんだろうな。

だったら、冬を大事にしよう。

しっかり、冬を味わおう。ありがたいことに、色々な人やものごとに恵まれているから、冬にすっかりやられてしまうことはないはず。

この先1年が丸ごと冬かどうかはわからないけれど、というか、春が近づいているような感じもしているけれど。

四季のメタファーを借りて、しっかり、「冬」の中にいる、この先しばらくはそれかな、と思う次第です。

*1:ちなみに、特定の誰かや何かが悪いとかそういうことではなく、気づいたらそうなってしまっていた、という類のことです

*2:ちなみにこの1はもともと公開してなくて、つい先日たまたま見返してたら別に公開してええやん、と思い立って公開したもの

XPの5つの価値は自己組織化を促進する

エクストリームプログラミング(XP)では、5つの価値が掲げられている。
シンプリシティ、コミュニケーション、フィードバック、リスペクト、勇気だ。

このXPの5つの価値を眺めていると、ほとんどそのままチームの自己組織化を促進する要素になっているな、ということにふと気づいた。

それぞれの人がXPに取り組む中でこのことを意識していれば、より高度に機能する自己組織化したチームになっていきやすくなるのではないかと思う。

この記事では、それぞれの価値(価値基準)がどのように自己組織化を促進しうるのかを解き明かしてみたい。

シンプリシティ

まず、シンプリシティ。シンプルなものは、組織化に開いている。

複雑なものはすでに組織化していて、新たな組織化には開いていないのと対照的だ。

どういうことか。

たとえば、「思い立ったらすぐ話す」というというシンプルな行動を考えてみる。

話すという行動は、あらゆる組織化に開いている。
まず、ただ話すことはいつでも起こりうるし、それ以外のあらゆる行動と組み合わせうる。

話していて、ちょっと一緒にコードを書いてみる。ホワイトボードを持ってきて図を描いてみる。関係者を呼んできて一緒に話す。などなど。
シンプルなものは、あらゆる構造(=組織)をそこから立ち上げていくことが可能だ。

他方、複雑なものを考えてみよう。「一日15分の定例ミーティングを設定する。関係者が多く調整がむずかしいため、その週のミーティングの時間調整をメンバーの持ち回りで担当する。ただし〇〇さんは非常に多忙なため担当から外す。また、定例ミーティングの議題は前日の18時までに収集することにして、投票で優先順位を決める。出席予定者は、欠席予定者の2倍の票数を持つ。棄権した場合は票を次回に持ち越すことができる。……」。

説明しやすいように恣意的に(無駄に)複雑にしてみたが、世の中を見渡してみると、これに似たような複雑な行動を作り出している例は案外すぐに見つかるだろう。

この行動(構造)に適合する構造を立ち上げるのは至難の業だ。すぐそばに似ているが少し違う(目的や、出席者が少しずつ違う)ミーティングがあったりなんかしたら、もう目も当てられない。
複雑なものの周りには、自己組織化が立ち上がる余地が非常に少ないことがわかるのではないだろうか。

「話すこと」を例として挙げたが、「チームの活動」というふうに広げてみても同じことが言える。

外から見てもよくわからない複雑・難解なルールに則って運営されているチームと関わることを想像してみるとわかるだろう。「このチームでは、Aさんが一括して要求を受け付けます。要求を伝えるには、こちらのフォームの必須項目を埋めてください。Aさんが休みの場合には、Bさんが代理を果たします。ただし一人ではその役割を負いきれないため、都度代理補佐を選出します。代理補佐は要求を受け付けません。代理の場合は、要求へのレスポンスが3日程度遅くなります。なお、……」。

このチームとの関わりは、極めて閉じている。ルールに則って行わないと機能しないし、そのルールも難しい。やはり、自己組織化の立ち上がる余地は非常に少ない。

まとめるなら、シンプルにすることで、自己組織化が起きやすくなる、と言えるだろう。

コミュニケーション

コミュニケーションはチームの自己組織化の契機だ。

チームの自己組織化は、それぞれの人が「感じ取る」ことによって始まると思う。

こういう課題があるのではないか。もっとこうした方がいいのではないか。次はこれをやるといいのではないか。
そういう動きがあるのなら、連携するといいのではないか。そういうAPIがあるのなら、こういう応用が考えられるのではないか。などなど。

このように、「感じ取る」ことから自己組織化が始まる。
コミュニケーションは、受信と発信を兼ねる。感じ取ることと、感じ取らせることを兼ねる、ということだ。

気軽に質問すれば、手軽に質問への答えが得られる。質問への直接の答えだけでなく、よりより問いの立て方や、関連する有益な情報が得られる可能性も高い。
質問を受けた側には、質問してきたその人が今何に取り組んでいるのか、関心を持っているのかが伝わる。将来、そのことで逆に話しかけに行く可能性も上がるだろう。

質問に限らず、相談や共有といった関わりでも同じだ。
コミュニケーションがあるところには、必ず受信と発信の双方が同時にある。

だから、同じ問題解決だとしても、「コミュニケーションによって解決すること」こそが自己組織化を促進する鍵となる。
仮に、「解決に至るまでの労力と解決の質がまったく同じ」だったとして、コミュニケーションせずに解決するのと、コミュニケーションして解決するのとだったら、後者の方が(自己組織化の観点からは)明確に望ましい、ということだ。

まとめるなら、コミュニケーションを増やすことで、自己組織化が起きやすくなる、と言えるだろう。

フィードバック

フィードバックを得ることを目指すことで、コミュニケーションが増える。

コミュニケーションが自己組織化の契機だとしたときに、その契機を増やすことにつながる、ということだ。

どういうことか。

ある機能の実現のために、うまい設計を思いついたとしよう。いいね、この設計でいけそうだ。
普通だったら、そのまま実装してしまうのではないだろうか。

しかし、フィードバックを大事にする考え方では、ここでコミュニケーションを取るという選択肢が浮かび上がる。
「よい設計を思いついたから、それが(思った通り)よい設計か、フィードバックを得てみよう」というわけだ。

その設計についてよいフィードバックをもらえそうな人に話しかけてみる。
「いいね、いいんじゃない」という反応かもしれない。「いいね、ただ……」という反応かもしれない。「いや、それだとうまくいかない。なぜならば……」という反応かもしれない。

実は、反応の内容はここでは問題ではない。
いずれも(「いいんじゃない」の一言でも)有益なフィードバックだし、フィードバック以前に、コミュニケーションの機会を作ることができているからだ。

フィードバックを増やすために、コミュニケーションを増やす。
チームの自己組織化の観点では、これがフィードバックという価値の最も大きな貢献だ。

補足的に。

ソフトウェアシステムもまた、チームという生態系(エコシステム)の一部である。
ソフトウェアシステムからのフィードバックもまた、チームというシステムへの入力となる。XPの規律であるTDDや継続的デリバリーといった、システムからフィードバックを得続けるための仕組みもまた、チームの自己組織化に一役を買う。

まとめるなら、フィードバックを増やすことで、自己組織化が起きやすくなる、と言えるだろう。

勇気

勇気とリスペクトの重要性は、「チームの自己組織化」を構成する単位が「人間」であることから来る、表裏一体のものだ。

まず、勇気について。

チームの自己組織化には、個人が非常に重要だ。そのことについては、以下の記事で詳しく書いた。

enk.hatenablog.com

記事の内容をここで繰り返すことはしないが、かいつまんで言うと、自己組織化のためには、それぞれの人が自分自身の価値観と、(そのときどきで)実現したいビジョンに忠実になることが大事だ、ということだ。

今の世の中では、まだまだ仕事の価値観と個人の価値観は切り離すもの、といった考え方が支配的だと思う。
「仕事の中でやりたいことをやる」というのは、なにか特別なことだと考えられているのではないだろうか。

実はそうでもない、というか、やりたいことをやることこそが、仕事で偉大な成果を上げる方法でもある、と思う。
ただ、それをここで論証するのはやや骨が折れるため、省略させてほしい。そういう世界観を前提としている話だ、ととりあえず受け取っていただければ幸いだ。

そういう世界観において、しかし、世の中の常識を鑑みると、「自分はこれがいいと思う」ということを素直に打ち出すのには勇気がいる。
人にもよると思うが、そういう人がほとんどではないだろうか。

ましてや、チームの中で(相対的に)スキルの低い領域が多い、比較的経験が浅い、といった立場だったらなおさらだろう。

それでも、自分の価値観とビジョンに忠実になること。
自分の思いを尊重していい。チームの自己組織化のためには、そう思える勇気が必要だ。

そして同時に、人のことは人に委ねること。
すべてをコントロールしようとしない。当たり前のようにも思えるが、案外難しい。誰かがすべてをコントロールするのは、当然ながら自己組織化ではない。

自分のことをする勇気を持つこと、そして人のことは人に委ねる勇気を持つことだ。

まとめるなら、勇気を持って行動することは、「人の集まり」が自己組織化するための「A面」と言えるだろう。

リスペクト

そして、B面がリスペクトだ。

リスペクトの方をA面とするか迷うところではあるが(両A面と言いたい気もする)、あえてこちらをB面とするのは、勇気があってこそ、このリスペクトが機能するからだ。
逆に、リスペクトだけがあって勇気がなくては、何も始まらない。

それでも、リスペクトは重要だ。勇気と同じくらい。

リスペクトについて言うべきことはそれほど多くない。
他の人の勇気を生かす。一言でいえばこれだけだ。

他の人が、その人の価値観とビジョンにもとづいて勇気を持って行動を起こしたとき、それを尊重し、支えるということだ。

自己組織化は勇気から始まる。こう言ってもいいだろう。
前に「コミュニケーションはチームの自己組織化の契機だ」と書いたが、より正確に言うと、自己組織化が力強く立ち上がるのは、そこに勇気がともなっているときだ。

リスペクトを欠くと、立ち上がってくる自己組織化を邪魔してしまう。

わかりやすい場面を想像してみよう。

経験の浅いエンジニアが、最近学んだ新しい設計手法を適用してみたい、と勇気を持って提案したとする。

リスペクトがない場合、経験豊富なエンジニアが、それはうまくいかない、とか、そんなことしなくても今のやり方で十分だ、と頭ごなしに否定し、何も起こらずに終わるかもしれない。

リスペクトがあれば、同じ経験豊富なエンジニアは、提案への感謝を伝えるとともに、その手法の利点を掘り下げるだろう。
結果的にそれが採用されるかもしれないし、されないかもしれない。いくつかの手法を統合した第三案にたどり着くかもしれない。

いずれにせよ、チームによってしか生まれなかったものが立ち上がってくる可能性が高くなる。これこそが自己組織化だ。

まとめるなら、リスペクトを持って行動することは、「人の集まり」が自己組織化するための「B面」と言えるだろう。

XPの5つの価値は自己組織化を促進する

全体をまとめよう。

エクストリームプログラミング(XP)では、5つの価値が掲げられている。
シンプリシティ、コミュニケーション、フィードバック、リスペクト、勇気だ。

シンプルなものは、組織化に開いている。
行動にせよ、要求や設計にせよ同様だ。あらゆるものをシンプルにすることで、自己組織化の可能性は広がる。

コミュニケーションは、自己組織化の契機だ。
コミュニケーションには双方向に「感じ取る」機会を作り出し、それが自己組織化のきっかけになる。コミュニケーションを増やすことで、自己組織化の機会は増える。

フィードバックを大事にすることは、コミュニケーションを増やすことにつながる。
すなわち、自己組織化の機会を増やすことにもつながる。また、人によるものかソフトウェアシステムによるものかを問わず、フィードバックそのものもまた、チームというシステムへの入力となり、やはり自己組織化のきっかけを作り出す。

勇気とリスペクトは、表裏一体となって「人の集まり」の自己組織化を支える。
それぞれの人が、勇気を持って価値観とビジョンの実現に踏み出すときが、自己組織化が本当に始まる瞬間だ。そして、踏み出した人を支えるために必要なのがリスペクトだ。
勇気とリスペクトがあってこそ、人の集まりが自己組織化することができる。

このようにして、XPの5つの価値は自己組織化を促進する。

チームの自己組織化が起こるように、ソース原理を活用する

今年のスクラムフェス新潟にこういうプロポーザルを出した。

confengine.com

が、残念ながら採択されず。

とはいえ我ながら面白いテーマだと思うので、いっちょブログにまとめてみようと思う。

ソース原理

ソース原理(Source Principle)とは、ピーター・カーニックという人が見出した、「人がビジョンを実現しようとするプロセス」を説明する原理・原則のことだ。

ソース原理では、すべての取り組み(用語として「イニシアチブ」と言う)には、「そのアイデアを実現するために、リスクを負って最初の一歩を踏み出した個人」がいる、とされている。

その個人のことを「ソース」と呼ぶのだが、それぞれのイニシアチブにおいて、ソースは必ず「一人」とされる。
「必ずしもそうではないのでは?」というケースとして、たとえば「共同創業」を思いつくが、そういったケースでも「リスクを負って最初に踏み出した人」は必ず(どちらか)一人で、その人がソースとなる、というのがソース原理の考え方だ。観察していると、必ずソースが特定の一人であることがわかる、とされている。

ソースが最初の一歩を踏み出したとき、「クリエイティブ・フィールド」(略してフィールドと呼ぶこともある)が生まれる。これは、ソース自身を含む関係者が活動できる「場」であり、協力者を惹きつける磁場のようなものでもある。
クリエイティブ・フィールドには、価値観とビジョンが備わっている。その価値観とビジョンを示すことは、ソースの重要な役割の一つである。

協力者は、フィールドの「中」で活動することになる。ソースの価値観に共感し、フィールドに入ってビジョンの実現の一端を担うとき、その人はサブソースになる、と表現される。

ただし、一緒に活動すれば誰でもサブソースというわけではなく、価値観に共感し、またソース(サブソースと区別する目的で、この文脈では「グローバルソース」という呼び方もされる)がその人を信頼してイニシアチブの一部を託すとき、初めてその人はそのイニシアチブのサブソースとなる。

サブソースは、グローバルソースに協力し、イニシアチブの一部を担う形で、ビジョンの実現に取り組む。

最後に重要なこととして、フィールドには、「クリエイティブ・ヒエラルキー」が存在する。グローバルソースには、サブソースに対する権威があるのだ。

少しわかりづらいところとして、この権威というのは、何かしらの外部的なもの(たとえば「組織の上司・部下の関係」など)とはまったく何の関係もない、ということに注意が必要だ。
あくまで、「アイデアを実現するために、リスクを負って最初の一歩を踏み出したこと」が、ソースをソースたらしめる要因だ。そして、そのソースには、そのイニシアチブのフィールドにおける権威がある。イニシアチブの価値観やビジョンを、ソース以外が変更することはできない。

ソース原理の概略はこんなところだ。
説明が不足していたり、そもそも説明していない(が、重要な)要素もいくらかあるが、議論を始めるのに十分な程度は記述できていると思う。

見ての通りとてもシンプルな原理・原則だが、人(の集まり)がビジョンを実現していく過程をとても正確に捉えているものの見方だな、と個人的には感じている。
現時点ではほぼピーター・カーニックさんの独自研究(と、彼の意思を継承したいくらかの人たちの実践や研究)にとどまっているものの、僕がこれまで色々と不思議に感じていたことがこの考え方でかなり説明できたり、発展の糸口を見出せている感覚があり、有用性が高いと思う。

そして、アジャイルソフトウェア開発もまさしく、「人(の集まり)がビジョンを実現していく過程」だ。
だとすれば、ソース原理を用いて考えてみることで、有用な何かが見出せるはずだ、と考え、この記事を書き始めた。

自己組織化

自己組織化は、アジャイルソフトウェア開発における重要なキーワードの一つだと思う。

アジャイルソフトウェア開発宣言にも示されているように、「プロセスよりも個人と対話を」、「計画に従うことよりも変化への対応を」価値とするアジャイルソフトウェア開発では、「最良のアーキテクチャ・要求・設計は、自己組織的なチーム(self-organizing teams)から生み出される」とされている。

しかし、「自己組織的なチーム」そしてそれを形づくる「自己組織化」とはいったい何なのだろうか?

これはとても深く探求できる問いだと思うが、今回はあえて簡潔な答えを提出するところから始めてみよう。

僕は、チームの自己組織化とは、

人それぞれが「いいと思うこと」をすることで、人それぞれではできないことをチームとして成し遂げること

だと思っている。

これではまだ掴みどころがないと思うので、逆に自己組織化「ではない」ことをいくつか挙げてみよう。

  • リーダーが「決まっている」のは、自己組織化ではない。人それぞれが「いいと思うこと」をするとき、個々の瞬間にそれぞれの人がリーダーになるはずだからだ。
  • 「決められたプロセスに従っている」のは、自己組織化ではない。人それぞれが「いいと思うこと」ではなく、「決められていること」を優先しているからだ。
  • 「みんながきっかり平等」なのは、自己組織化ではない。人はそれぞれが異なるため、本来平等ではあり得ず、過度な平等は何かしら作為的にもたらされていると考えられるからだ。
  • 「みんなが好き勝手に動いている」のは、広い意味で自己組織化である可能性もあるが、ここでは自己組織化としない。「人それぞれではできないことをチームとして成し遂げる」に至らないと思われるからだ。*1

他にも挙げられるが、いったんこれくらいにしておこう。だんだん輪郭が見えてきたと思う。
こういったものを除いたところにある、"人それぞれが「いいと思うこと」をすることで、人それぞれではできないことをチームとして成し遂げている"状態が、僕が考える「チームの自己組織化」だ。

もう少しだけ補足しておこう。

まず、前半の"人それぞれが「いいと思うこと」をする"というフレーズには、外部からのコントロールなく、また全体の詳細を把握することなくそれぞれの人が行動している、というニュアンスを含めている。
一部の人が「いいこと」を決めて、みんながそれを遂行するのではない。また、みんなが「すべて」を把握して行動するのでもない。それぞれが、それぞれなりに見えている範囲で「いいと思うこと」をしているだけ。それが、僕が考える自己組織化の第一条件だ。

後半の"人それぞれではできないことをチームとして成し遂げている"というフレーズは、「創発」を念頭に置いている。部分(個々の人)に還元できない性質が、全体(チーム)に現れる、ということだ。
だから、「明確な分業状態」は自己組織化とは言えない、ということにおそらくなるだろう。明確な分業状態では、個々の人が個々に持っているスキルを「足し合わせていった結果」が最終成果になるからだ。そうではなく(それだけではなく)、人と人との相互作用によって、予め定められた分業では(ほとんど)生まれ得なかった成果が生まれていること。それが、僕が考える自己組織化の第二条件だ。

自己組織化そのものの説明はこのあたりにして、そういった自己組織化は、どういった条件下で起こる(起こりうる)のかという問いに移ろう。

チームの自己組織化が起こるために

ここで、言葉を丁寧に扱いたい。
自己組織化は「起こす」のではなく「起こる」と書いたのには意図がある。

自己組織化を「起こす」ことはできない、と考えた方がよいと思っている。
そうではなく、自己組織化は「起こる」もので、私たちにできることは、自己組織化が「起こるのを邪魔しない」こと、そして「起こりやすい環境を作る」ことだ。

人はそれぞれが異なる。だから、人それぞれが「いいと思うこと」も異なる。もし、「誰が、何をいいと思うか」を厳密にコントロールしようとしたら、それはすでに自己組織化ではなくなっている。

チームにおいて、どのような「人それぞれではできないこと」が立ち上がってくるか(創発)もまた、厳密にコントロールすることはできない。
一人一人が複雑系である人間の総合作用によって生まれるものは、予期できない。できるとすれば、ある程度の方向づけだけだろう。

このようにして、自己組織化は「起こる」。
では、どうすればそれを邪魔せず、またそれが起こりやすい環境を作れるだろうか。

まず、邪魔をしないこと。

これはそのまま、前項で並べ立てた「自己組織化ではない状態」につながる取り決めや行動を控える、ということになる。
「チームのリーダー」を一人に決めない。プロセスを厳格に決めない。平等を過度に求めない。たとえばそういったことだ。

ほとんど何もしなくても、広義の自己組織化は自然と起こる。
雪の結晶、鳥の群れ、台風、神経細胞は、何者かの意図や作為によって作られているわけではない。

ただ、僕による定義の後半、「人それぞれではできないことをチームとして成し遂げている」状態をチームの自己組織化の理想とするならば、自然に任せているだけでは芸がない、とも言える。
ただただ自然状態において、何かしら(広義の)自己組織化が起こったとしても、それが「チームが(わざわざ)集まった理由」に叶うとは限らないからだ。

というわけで、チームの自己組織化が起こりやすい環境を作るにはどうすればよいか。
こちらも色々と考えられるが、この記事では特にソース原理を活用して考えてみたい。

ソース原理と自己組織化

はじめに、ソース原理とは、あらゆるイニシアチブ(取り組み)にはリスクを負って最初の一歩を踏み出した個人(=ソース)がいる、という考え方である、と説明した。

このイニシアチブというのがどういうものかを説明していなかったが、大小様々なものが該当する。
「事業」もイニシアチブだし、「プロジェクト」もイニシアチブだ。そういった大きな取り組みだけではない。「1時間のワークショップ」もイニシアチブだし、「一度立ち止まって、10分ほどリファクタリングに使おう」と声を上げることもそのリファクタリングというイニシアチブの第一歩だと言えるだろう。

これがチームの自己組織化とどう関わるか、だんだん見当がついてきただろうか?

またもう一つ説明していなかったこととして、ソースとなる人は、自身の(人としての)価値観を明らかにしていることが重要だ。
自身の価値観が明確だからこそ、どのようなイニシアチブに(リスクを負って)一歩踏み出すとよいかわかるからだ。価値観、言い換えるなら「実現していきたい世界のイメージ」のようなものがなければ、何もする必要はなく、何も起こらない。

材料は揃った。僕が考えるチームの自己組織化は、ソース原理の言葉を使って以下のように説明できる。

チームの中で、人それぞれが「いいと思うこと」をする。
それぞれの人は、自身の価値観を明らかにして生きている。チームにも、そういう状態で参加してきている。

集まったチーム全体として、どの方向に向かうかは、誰かが示すだろう。その人が、そのときの(イニシアチブの)ソースだ。
そして他の人たちは、(そのイニシアチブのビジョンに共感できる限りにおいて)そのクリエイティブ・フィールドに入り、サブソースを担うことになる。

サブソースとして、それぞれの人は自分なりの貢献を示す。
チームのメンバー同士は日々の関わりから、相互の信頼関係で結ばれていて、ソースとサブソースの関係はすみやかに結ばれる。

サブソースもまた、自分の価値観とつながっていて、そのときのソース(グローバルソース)の価値観・ビジョンに叶う範囲において、自分なりに「いいと思うこと」をする。
こうしてソースとサブソースの関係性が立ち上がり、それぞれの意思と意図とスキルを活用し、連携してビジョンの実現を推し進める。

前にも触れたように、イニシアチブの大きさはさまざまだ。毎月、毎週、毎日、毎時、大小さまざまなイニシアチブが立ち上がる。
メンバーそれぞれが、そのときどきでソースとなり、サブソースとなる。フラクタル的な入れ子構造の中で、役割を柔軟に入れ替えながら、チームの目的の実現へと向かっていく。

チームの目的そのものは、ころころ変わってはまずい。
そこには、おそらく(ある程度長い間変わらない)一人のソースがいることだろう。チームのメンバーの一人かもしれないし、チームを集めた人かもしれない。あるいは、チームに対しては(一見)協力者的な立ち位置にいる人かもしれない。「チームが集められた理由であるところのイニシアチブ」のソースが、いわゆる「チームの(大きな)目的」を知っているだろう。

とはいえ、目的は一つとは限らない。
一般的なアジャイル開発チームで考えてみても、目的はざっと3つは考えられる。たとえば、顧客価値を生み出すこと、アーキテクチャを進化させること、学習・成長すること、などだ。それぞれのソースが異なることもある(というより、その可能性が高い)だろう。

このように、チームの自己組織化は、ソース原理の言葉では「誰もがソース(となりうる人)としてその場に参加していて、ソースとサブソースの関係性を柔軟に交代しながらイニシアチブを連続的に立ち上げ、実現し続けていっている状態」と説明できる。

つまり、ソース原理が機能しやすい状態にすることが、ほとんどそのままチームの自己組織化が実現しやすい状態につながるということだ。

チームの自己組織化が起こるように、ソース原理を活用する

この記事のまとめに代えて、「チームの自己組織化が起こるように、ソース原理を活用する」というテーマについて綴って終わりとしたい。

ソース原理では、取り組みを実現していく具体的な活動としての「アウターワーク」だけでなく、個人の内面に向き合う「インナーワーク」の重要性を強調している。

価値観が明確だからこそ、「いいと思うこと」に踏み出せる、と書いた。
個人の価値観というものは、案外隠されている。世の中の人の言うことに影響されて、自分の本当の価値観が見えにくくなっているということも多い。

大事な価値観を持っていたとしても、素直に本当に実現したい世界へと素直に向かう行動を取るのではなく、その思いが何かしら歪んだ形で現れてしまうことも多い。

ソース原理ではこういった「個人の内面」に取り組むことを大事にしていて、その取り組みはそのまま、チームの自己組織化を起こりやすくすることにもつながるだろう。
ソースの役割をうまく担えるようになり、人それぞれがよりストレートに「いいと思うこと」の実現へと向かうことにつながるからだ。

また、自身の内面が整っている人は、他の人の価値観やビジョンをよりうまく尊重できるようにもなると思う。
他の人の邪魔をしてしまうときというのは、自身の価値観が歪んだ形で現れていることが多い。それがなくなれば(減れば)、人の取り組みを手助けするサブソースの役割もよりうまく担えるようになる。

最後に、クリエイティブ・ヒエラルキーの重要性に触れておく。

おさらいだが、クリエイティブ・ヒエラルキーとは、「グローバルソースには、サブソースに対する権威がある」ということだ。
そしてこれも繰り返しになるが、クリエイティブ・ヒエラルキーは、組織構造とは一切何の関係もない。あくまで、「何らかのアイデアを実現するため(イニシアチブ)に、リスクを取って一歩を踏み出した人」がソース(グローバルソース)になる。

逆に言うと、本来ソースではない人が、クリエイティブ・ヒエラルキーに従わずに無関係な権威やエゴを持ち出し始めると、うまくいかなくなり始めるということだ。
誰かが勇気を持って、何かを始めようと一歩を踏み出したとき(また繰り返すが、それは大げさな何かではなく、「立ち止まって10分ほどリファクタリングしましょう」といった程度のことかもしれない)、その意図、カッコよく言えばビジョンに耳を傾けてみる。

もちろん、共感できないイニシアチブに協力する必要はない。違うなら、違うと言う。それでも、そのイニシアチブの権威はソースにある。
違うと言われて、そうだな、と思えば、ビジョンを修正すればよい。ソースは独裁者ではない。むしろ、周囲からのフィードバックを得ながら、ビジョンをよりよくしていく意欲を持った方がよい。そして、そもそもやるべきではなかったなと思えば、イニシアチブを取りやめてもいいだろう。

それでも、ソースには権威があること、そしてそれは組織構造とは何の関係もないこと。
この2つを意識することは、チームの自己組織化が起こるための重要な要素だと思う。

この記事では、自己組織化とソース原理との関わりについてまとめた。
ややとりとめなくなってしまった気もするが、重要な点についてはおさえられたと思う。

これからも、こういった意識でチームでの実践に取り組んでいきたいと思っている。
また、発見や進展があったら報告します。

*1:本来の意味での自己組織化は別に「よいこと」とは限らない。よい悪いに関わらず、何らかの秩序が立ち上がってくることで、現れてくる秩序が何らかの意味で「悪い」こともありうる。だが、ここでは「チームの自己組織化」をポジティブな文脈で捉えたいので、「人それぞれではできない(よい)こと」が現れてくることを条件とした。

「ふりかえり」とは、チームという複雑系をよりよくするための実験にコミットする道のり

ソフトウェアエンジニアとして、チームでの「ふりかえり」に500回*1ばかり取り組んできた中で、「ふりかえり」とは、「チームという複雑系をよりよくするための実験にコミットする道のり」である、という理解に行き着いた。

これが真理である、というよりは、自分なりの整理の枠組みみたいなものなんだけど、ふりかえりという活動を見つめ直す役には立つんじゃないかなと思うので、解説してみたい。

「ふりかえり」とは、チームをよりよくするために立ち止まって話し合うこと

ふりかえりは、チームをよりよくするための活動だ。

いきなりこれに違和感を持つ人はあまりいないと思う。
素直に、まあそうだな、と思ってもらえれば幸いだ。チームとは何か、よりよくするとは何か、といったことを後に肉付けしていく。

また、ふりかえりは、立ち止まって話し合うことだ。

立ち止まること。

日々、仕事をする中でも、ふとした機会に内省をしたり、ちょっとしたふりかえりをすることはあるだろう。
それでも、「ふりかえり」と銘打って定期的に立ち止まり、話し合うことには特別な意味があると思う。

時間枠を先に用意しておいて話し合うことで、ふりかえりはダブルループ学習の格好の機会になる。
普段の思考の枠組みから一歩外に出て、自分たちが置かれている状況や目標、働き方など、前提を問い直すことができるということだ。

話し合うこと。

後に詳しく触れるが、話し合うことそれ自体にも重要な意味がある。
だから、ふりかえりとは話し合うことで、そのことも重要だ。

そういうわけで、「ふりかえり」とは、チームをよりよくするために立ち止まって話し合うことだ。

「ふりかえり」とは、実験を考案してその実施にコミットすること

「ふりかえりのゴール」をあえて一つだけ定めなさい、と言われたら、僕は「実験を考案してその実施にコミットすること」と答える。

前述の通り、しっかり立ち止まることや話し合うこと自体にも重要性があるので、一つと言われても困る、という気持ちもあるが、あえて一つだけ選ぶとすればこれなのではないかな。

ふりかえりのアウトプットを「SMART*2なアクション」みたいに言ったりすることがあるが、僕は「実験」と位置付ける方がより本質を突いているのではないか、と最近は考えるようになった。

後に詳しく述べるが、チームは複雑系だ。複雑系に対する介入は、実験でしかありえない。だから実験と呼ぶのが適切だ、とだけここでは触れておく。

その実験を、チームで考え出す。

そして、その実施にコミットするまでがふりかえりだ。
考案して終わりでは心もとない。チームとして、やるぞ、となっている状態、すなわちコミットしている状態になることがゴールだろう。

そういうわけで、「ふりかえり」とは、実験を考案してその実施にコミットすることだ。

「チーム」とは、目的を持つ複雑系(complex system)

チームは目的を持つ。

これはほとんど、チームの定義(の一部)のようなものなので、おおむね受け入れてもらえるのではないかと思う。それで十分だ。

強調したいのは後半の、チームは複雑系(complex system)である、というところだ。

複雑系では、入力と出力の関係が明らかではない。
「ああすれば、こうなる(はず)」という予測が成り立たない(少なくとも、成り立ちにくい)ということだ。

チームは複数の人間の相互作用でできている。
一人一人の人間自体も複雑系だし、チームは絶海の孤島のように存在しているわけではないので、チームの外側との相互作用もある。

そういうわけで、「チーム」とは、目的を持つ複雑系(complex system)だ。

「チーム」の目的の1つは、価値を生み出すこと

チームの目的というものを大きく分類するなら、2つある、と言える。

その1つは「価値を生み出すこと」だ。

これもほとんど自明と言ってよい気もするが、少し説明しておきたい。

チームの目的は何か、と聞かれたとき、「プロジェクトを成功させること」とか、「システムを新基盤に移行させること」、「利益目標を達成すること」みたいに答える(考える)人やチームもいると思う。
そして、それ自体はどれも、おそらく正しいのだろう。

ただ、そういったさまざまな「目的」を束ねる、やや抽象的で普遍的な目的(表現)として、「価値を生み出すこと」と言えるように思う。
まあ、そういう目的群を束ねるちょうどいい表現、くらいに思ってもらえたらいい。ある程度僕の価値観(何よりも価値を生み出すことを大事にしたい、という偏り)を反映してもいるだろう。その辺は多めに見てもらいたい。

さらに上位の目的を想定して「世界をよりよくすること」みたいに言うこともできる。
それもまた間違ってはいないだろう。

あくまで、ほとんどのチームに共通する目的の表現、かつ抽象的すぎないところを狙ったら、「価値を生み出すこと」と言えるのではないか、ということだ。

そういうわけで、「チーム」の目的の1つは、価値を生み出すことだ。

「チーム」の目的の1つは、学習・成長すること

そして、チームにはもう1つ重要な目的がある。それは「学習・成長すること」だ。

中長期的に価値を生み出し続けるためには、これが不可欠だと思う。

より大きな価値を生み出すために、という言い方もできるし、世の中の方が変わり続けているから、学習・成長しなければやがて価値をまったく生み出せなくなってしまうだろう、という言い方もできる。そのどちらもある。

成長至上主義みたいなことが言いたいわけではない。

ただ、ごく常識的というか、一般的にチームというものが集められたとき、単に価値を生み出すこと以外に、これも期待されているはずだ、ということだ。

価値を生み出していく中で自然と学習・成長できるということもあるだろうが、短期的な価値を生み出すことだけに集中しすぎると、学習・成長することがおそろかになってしまう場合も多いように思う。

また、ふりかえりという文脈においては特に、これを大事な目的の1つとしてはっきり認識することは重要だと思っている。

そういうわけで、「チーム」の目的の1つは、学習・成長することだ。

複雑系において、あらゆる介入は本質的に実験

さて、ここからがこの記事のサビだ。

ふりかえりで、いわゆるアクションを考えていく。

ただし、チームに対するいかなる介入も、実験である。本質的に、実験でしかありえない。
それを認識することが大事だと思う。

前述のように、チームは複雑系だ。複雑系において、因果は明らかでない。だから、介入の結果も事前には明らかでなく、介入は期待した(ものに近い)結果が得られるかどうかを調べる実験となる。

ここを間違えると、大事なことを見落としてしまう。

たとえば、何かミスがあったとする。ノーム・カースの最優先条項*3に従って、誰も責めず、冷静に原因を分析し、根本解決策を考えたとしよう。

それでも、それが根本解決になる保証は(ほとんどの場合)ない。ないのだ。
それをわきまえないと、ありもしない「完璧な解決策」を探し求める羽目になる。

もちろん、単純なミスの類であれば、比較的確実な対策が考えられる可能性もある。
しかし、ふりかえりで扱う課題はそういったものばかりではないだろう。

そういうわけで、複雑系において、あらゆる介入は本質的に実験だ。

課題は「見い出す」もの

「実験」を考える前に、何らかの「課題」を設定するだろう。

やや余談だが、課題といっても、「悪いものをなくす・減らす」ことばかりとは限らない。「よいものを生み出す、増やす」ような課題設定もありうる。
よいチームほど、「よいものを生み出す、増やす」ような課題設定の割合が増えていくようにも思う。

さて、課題はどこから来るのだろうか?

端的に言うなら、「現状」と「理想」の間にある、と言えるだろう。
だから、ふりかえりでは立ち止まって過去をふりかえり、現状を明らかにする。そして、理想との差を見るために、理想についても話し合うことが多いだろう。

KPTのような手法では、「Keepを続けること」や「Problemをなくす(減らす)こと」が課題だと考えられやすい。というか、手法自体がおおむねそういう建て付けになっていると思う。
もちろん、ふりかえりに取り組み始めたチームが、第一歩としてKPTを使い、KeepやProblemをそのまま課題として転用することが悪いわけではない。効果がないわけでもない。そこから一歩ずつ前に進み始められるのは、とても尊いことだ。

でも、思い出してほしい。チームは複雑系なのだ。

現状は、容易には明らかにならない。理想もまた、チームが置かれている文脈、時と場合に応じて様々だろう。
だとすれば、現状と理想の間のどこに課題を置くかも、決して自明ではありえない。

よりよい実験のために、よりよい課題を設定したければ、課題を「見い出す」必要がある。

経験上、はじめから(良質な)課題が明らかであることはほとんどない。
チームが、複雑系である自身の現状(と理想)に真摯に向き合い、忌憚なく話し合うことによって、初めて(仮説として)見い出されてくるものなのだ。

そういうわけで、課題は「見い出す」ものだ。

「ふりかえり」の道のりもまた、システムに影響を与える

ぼちぼちアウトロに入っていく。

チームという複雑系が、自身の現状と理想に向き合って、課題を見出し、実験を考案してその実施にコミットする。

チームが複雑系であることをもう一度思い出してみると、その道のりもまた、チーム(というシステム)に対する介入として機能することがわかる。

はじめに、「ふりかえり」とは、チームをよりよくするために立ち止まって話し合うことだと言った。

仕事の日々の流れの中で、立ち止まり、ふりかえりの場に集まって、チームは自分たちがチームであることを再確認する。よりよくしようという意思をともに抱く。

そして、話し合う。話し合いの中で、お互いの考えを理解する。見えているもの、感じていることを交換し合う。

その過程において、現状、理想、課題が共有される。チームにとっての現状、理想、課題になっていく。

実験も同じだ。現状と理想に照らして定めた課題に対して、どのような実験が有望か。どのように話し合うかによって、実験が本当に、チームにとっての実験になるかどうかが決まる。コミットできるかどうかが決まる。
コミットしてこそ、実験の結果が正しく検証できる。

改めて強調しておくと、結果的に実験にコミットすることだけが目的なのではない。
その過程そのものもまた、チームに対する影響を与える。ふりかえりの活動そのものが、チームをよりよくする(可能性が高い)。

そういうわけで、「ふりかえり」の道のりもまた、システムに影響を与える。

「ふりかえり」とは、チームという複雑系をよりよくするための実験にコミットする道のり

チームでのふりかえりという活動について、僕なりの理解を整理して解説してみた。

比較的抽象度が高い内容だったため、読んでくれた方によって、受け取るものは違うかもしれない。

ただ、まとめてみて改めて、『アジャイルレトロスペクティブズ』に代表されるふりかえりの手法をまとめた書籍やサイトの内容を本当に活用するには、こういうメタ認識が重要なのではないかな、ということは感じる。

うーん、これで『アジャイルレトロスペクティブズ』にほとんど同じような内容が書いてあったら笑えるな。
10年以上前に一度読んだきりで、その頃にはチームでのふりかえりなんてやったこともなかったので、普通に書いてある可能性もある。10年かけてたどり着いたのだ。そのときは、ご愛嬌ということで、ワハハ。

そういうわけで僕は、「ふりかえり」とは、チームという複雑系をよりよくするための実験にコミットする道のりだと思っている。

*1:参加が年間50回 * 9年 = 450回、ファシリテーションがだいたい通算50回くらい

*2:Specific / Measurable / Achievable / Relevant / Time-boundの略で、「よい目標」の目安

*3:ノーム・カースの最優先条項 - iki-iki