XPの5つの価値は自己組織化を促進する
エクストリームプログラミング（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つの価値は自己組織化を促進する。
チームの自己組織化が起こるように、ソース原理を活用する
今年のスクラムフェス新潟にこういうプロポーザルを出した。
が、残念ながら採択されず。
とはいえ我ながら面白いテーマだと思うので、いっちょブログにまとめてみようと思う。
ソース原理
ソース原理（Source Principle）とは、ピーター・カーニックという人が見出した、「人がビジョンを実現しようとするプロセス」を説明する原理・原則のことだ。
ソース原理では、すべての取り組み（用語として「イニシアチブ」と言う）には、「そのアイデアを実現するために、リスクを負って最初の一歩を踏み出した個人」がいる、とされている。
その個人のことを「ソース」と呼ぶのだが、それぞれのイニシアチブにおいて、ソースは必ず「一人」とされる。
「必ずしもそうではないのでは？」というケースとして、たとえば「共同創業」を思いつくが、そういったケースでも「リスクを負って最初に踏み出した人」は必ず（どちらか）一人で、その人がソースとなる、というのがソース原理の考え方だ。観察していると、必ずソースが特定の一人であることがわかる、とされている。
ソースが最初の一歩を踏み出したとき、「クリエイティブ・フィールド」（略してフィールドと呼ぶこともある）が生まれる。これは、ソース自身を含む関係者が活動できる「場」であり、協力者を惹きつける磁場のようなものでもある。
クリエイティブ・フィールドには、価値観とビジョンが備わっている。その価値観とビジョンを示すことは、ソースの重要な役割の一つである。
協力者は、フィールドの「中」で活動することになる。ソースの価値観に共感し、フィールドに入ってビジョンの実現の一端を担うとき、その人はサブソースになる、と表現される。
ただし、一緒に活動すれば誰でもサブソースというわけではなく、価値観に共感し、またソース（サブソースと区別する目的で、この文脈では「グローバルソース」という呼び方もされる）がその人を信頼してイニシアチブの一部を託すとき、初めてその人はそのイニシアチブのサブソースとなる。
サブソースは、グローバルソースに協力し、イニシアチブの一部を担う形で、ビジョンの実現に取り組む。
最後に重要なこととして、フィールドには、「クリエイティブ・ヒエラルキー」が存在する。グローバルソースには、サブソースに対する権威があるのだ。
少しわかりづらいところとして、この権威というのは、何かしらの外部的なもの（たとえば「組織の上司・部下の関係」など）とはまったく何の関係もない、ということに注意が必要だ。
あくまで、「アイデアを実現するために、リスクを負って最初の一歩を踏み出したこと」が、ソースをソースたらしめる要因だ。そして、そのソースには、そのイニシアチブのフィールドにおける権威がある。イニシアチブの価値観やビジョンを、ソース以外が変更することはできない。
ソース原理の概略はこんなところだ。
説明が不足していたり、そもそも説明していない（が、重要な）要素もいくらかあるが、議論を始めるのに十分な程度は記述できていると思う。
見ての通りとてもシンプルな原理・原則だが、人（の集まり）がビジョンを実現していく過程をとても正確に捉えているものの見方だな、と個人的には感じている。
現時点ではほぼピーター・カーニックさんの独自研究（と、彼の意思を継承したいくらかの人たちの実践や研究）にとどまっているものの、僕がこれまで色々と不思議に感じていたことがこの考え方でかなり説明できたり、発展の糸口を見出せている感覚があり、有用性が高いと思う。
そして、アジャイルソフトウェア開発もまさしく、「人（の集まり）がビジョンを実現していく過程」だ。
だとすれば、ソース原理を用いて考えてみることで、有用な何かが見出せるはずだ、と考え、この記事を書き始めた。
自己組織化
自己組織化は、アジャイルソフトウェア開発における重要なキーワードの一つだと思う。
アジャイルソフトウェア開発宣言にも示されているように、「プロセスよりも個人と対話を」、「計画に従うことよりも変化への対応を」価値とするアジャイルソフトウェア開発では、「最良のアーキテクチャ・要求・設計は、自己組織的なチーム（self-organizing teams）から生み出される」とされている。
しかし、「自己組織的なチーム」そしてそれを形づくる「自己組織化」とはいったい何なのだろうか？
これはとても深く探求できる問いだと思うが、今回はあえて簡潔な答えを提出するところから始めてみよう。
僕は、チームの自己組織化とは、
人それぞれが「いいと思うこと」をすることで、人それぞれではできないことをチームとして成し遂げること
だと思っている。
これではまだ掴みどころがないと思うので、逆に自己組織化「ではない」ことをいくつか挙げてみよう。
- リーダーが「決まっている」のは、自己組織化ではない。人それぞれが「いいと思うこと」をするとき、個々の瞬間にそれぞれの人がリーダーになるはずだからだ。
- 「決められたプロセスに従っている」のは、自己組織化ではない。人それぞれが「いいと思うこと」ではなく、「決められていること」を優先しているからだ。
- 「みんながきっかり平等」なのは、自己組織化ではない。人はそれぞれが異なるため、本来平等ではあり得ず、過度な平等は何かしら作為的にもたらされていると考えられるからだ。
- 「みんなが好き勝手に動いている」のは、広い意味で自己組織化である可能性もあるが、ここでは自己組織化としない。「人それぞれではできないことをチームとして成し遂げる」に至らないと思われるからだ。*1
他にも挙げられるが、いったんこれくらいにしておこう。だんだん輪郭が見えてきたと思う。
こういったものを除いたところにある、"人それぞれが「いいと思うこと」をすることで、人それぞれではできないことをチームとして成し遂げている"状態が、僕が考える「チームの自己組織化」だ。
もう少しだけ補足しておこう。
まず、前半の"人それぞれが「いいと思うこと」をする"というフレーズには、外部からのコントロールなく、また全体の詳細を把握することなくそれぞれの人が行動している、というニュアンスを含めている。
一部の人が「いいこと」を決めて、みんながそれを遂行するのではない。また、みんなが「すべて」を把握して行動するのでもない。それぞれが、それぞれなりに見えている範囲で「いいと思うこと」をしているだけ。それが、僕が考える自己組織化の第一条件だ。
後半の"人それぞれではできないことをチームとして成し遂げている"というフレーズは、「創発」を念頭に置いている。部分（個々の人）に還元できない性質が、全体（チーム）に現れる、ということだ。
だから、「明確な分業状態」は自己組織化とは言えない、ということにおそらくなるだろう。明確な分業状態では、個々の人が個々に持っているスキルを「足し合わせていった結果」が最終成果になるからだ。そうではなく（それだけではなく）、人と人との相互作用によって、予め定められた分業では（ほとんど）生まれ得なかった成果が生まれていること。それが、僕が考える自己組織化の第二条件だ。
自己組織化そのものの説明はこのあたりにして、そういった自己組織化は、どういった条件下で起こる（起こりうる）のかという問いに移ろう。
チームの自己組織化が起こるために
ここで、言葉を丁寧に扱いたい。
自己組織化は「起こす」のではなく「起こる」と書いたのには意図がある。
自己組織化を「起こす」ことはできない、と考えた方がよいと思っている。
そうではなく、自己組織化は「起こる」もので、私たちにできることは、自己組織化が「起こるのを邪魔しない」こと、そして「起こりやすい環境を作る」ことだ。
人はそれぞれが異なる。だから、人それぞれが「いいと思うこと」も異なる。もし、「誰が、何をいいと思うか」を厳密にコントロールしようとしたら、それはすでに自己組織化ではなくなっている。
チームにおいて、どのような「人それぞれではできないこと」が立ち上がってくるか（創発）もまた、厳密にコントロールすることはできない。
一人一人が複雑系である人間の総合作用によって生まれるものは、予期できない。できるとすれば、ある程度の方向づけだけだろう。
このようにして、自己組織化は「起こる」。
では、どうすればそれを邪魔せず、またそれが起こりやすい環境を作れるだろうか。
まず、邪魔をしないこと。
これはそのまま、前項で並べ立てた「自己組織化ではない状態」につながる取り決めや行動を控える、ということになる。
「チームのリーダー」を一人に決めない。プロセスを厳格に決めない。平等を過度に求めない。たとえばそういったことだ。
ほとんど何もしなくても、広義の自己組織化は自然と起こる。
雪の結晶、鳥の群れ、台風、神経細胞は、何者かの意図や作為によって作られているわけではない。
ただ、僕による定義の後半、「人それぞれではできないことをチームとして成し遂げている」状態をチームの自己組織化の理想とするならば、自然に任せているだけでは芸がない、とも言える。
ただただ自然状態において、何かしら（広義の）自己組織化が起こったとしても、それが「チームが（わざわざ）集まった理由」に叶うとは限らないからだ。
というわけで、チームの自己組織化が起こりやすい環境を作るにはどうすればよいか。
こちらも色々と考えられるが、この記事では特にソース原理を活用して考えてみたい。
ソース原理と自己組織化
はじめに、ソース原理とは、あらゆるイニシアチブ（取り組み）にはリスクを負って最初の一歩を踏み出した個人（=ソース）がいる、という考え方である、と説明した。
このイニシアチブというのがどういうものかを説明していなかったが、大小様々なものが該当する。
「事業」もイニシアチブだし、「プロジェクト」もイニシアチブだ。そういった大きな取り組みだけではない。「1時間のワークショップ」もイニシアチブだし、「一度立ち止まって、10分ほどリファクタリングに使おう」と声を上げることもそのリファクタリングというイニシアチブの第一歩だと言えるだろう。
これがチームの自己組織化とどう関わるか、だんだん見当がついてきただろうか？
またもう一つ説明していなかったこととして、ソースとなる人は、自身の（人としての）価値観を明らかにしていることが重要だ。
自身の価値観が明確だからこそ、どのようなイニシアチブに（リスクを負って）一歩踏み出すとよいかわかるからだ。価値観、言い換えるなら「実現していきたい世界のイメージ」のようなものがなければ、何もする必要はなく、何も起こらない。
材料は揃った。僕が考えるチームの自己組織化は、ソース原理の言葉を使って以下のように説明できる。
チームの中で、人それぞれが「いいと思うこと」をする。
それぞれの人は、自身の価値観を明らかにして生きている。チームにも、そういう状態で参加してきている。
集まったチーム全体として、どの方向に向かうかは、誰かが示すだろう。その人が、そのときの（イニシアチブの）ソースだ。
そして他の人たちは、（そのイニシアチブのビジョンに共感できる限りにおいて）そのクリエイティブ・フィールドに入り、サブソースを担うことになる。
サブソースとして、それぞれの人は自分なりの貢献を示す。
チームのメンバー同士は日々の関わりから、相互の信頼関係で結ばれていて、ソースとサブソースの関係はすみやかに結ばれる。
サブソースもまた、自分の価値観とつながっていて、そのときのソース（グローバルソース）の価値観・ビジョンに叶う範囲において、自分なりに「いいと思うこと」をする。
こうしてソースとサブソースの関係性が立ち上がり、それぞれの意思と意図とスキルを活用し、連携してビジョンの実現を推し進める。
前にも触れたように、イニシアチブの大きさはさまざまだ。毎月、毎週、毎日、毎時、大小さまざまなイニシアチブが立ち上がる。
メンバーそれぞれが、そのときどきでソースとなり、サブソースとなる。フラクタル的な入れ子構造の中で、役割を柔軟に入れ替えながら、チームの目的の実現へと向かっていく。
チームの目的そのものは、ころころ変わってはまずい。
そこには、おそらく（ある程度長い間変わらない）一人のソースがいることだろう。チームのメンバーの一人かもしれないし、チームを集めた人かもしれない。あるいは、チームに対しては（一見）協力者的な立ち位置にいる人かもしれない。「チームが集められた理由であるところのイニシアチブ」のソースが、いわゆる「チームの（大きな）目的」を知っているだろう。
とはいえ、目的は一つとは限らない。
一般的なアジャイル開発チームで考えてみても、目的はざっと3つは考えられる。たとえば、顧客価値を生み出すこと、アーキテクチャを進化させること、学習・成長すること、などだ。それぞれのソースが異なることもある（というより、その可能性が高い）だろう。
このように、チームの自己組織化は、ソース原理の言葉では「誰もがソース（となりうる人）としてその場に参加していて、ソースとサブソースの関係性を柔軟に交代しながらイニシアチブを連続的に立ち上げ、実現し続けていっている状態」と説明できる。
つまり、ソース原理が機能しやすい状態にすることが、ほとんどそのままチームの自己組織化が実現しやすい状態につながるということだ。
チームの自己組織化が起こるように、ソース原理を活用する
この記事のまとめに代えて、「チームの自己組織化が起こるように、ソース原理を活用する」というテーマについて綴って終わりとしたい。
ソース原理では、取り組みを実現していく具体的な活動としての「アウターワーク」だけでなく、個人の内面に向き合う「インナーワーク」の重要性を強調している。
価値観が明確だからこそ、「いいと思うこと」に踏み出せる、と書いた。
個人の価値観というものは、案外隠されている。世の中の人の言うことに影響されて、自分の本当の価値観が見えにくくなっているということも多い。
大事な価値観を持っていたとしても、素直に本当に実現したい世界へと素直に向かう行動を取るのではなく、その思いが何かしら歪んだ形で現れてしまうことも多い。
ソース原理ではこういった「個人の内面」に取り組むことを大事にしていて、その取り組みはそのまま、チームの自己組織化を起こりやすくすることにもつながるだろう。
ソースの役割をうまく担えるようになり、人それぞれがよりストレートに「いいと思うこと」の実現へと向かうことにつながるからだ。
また、自身の内面が整っている人は、他の人の価値観やビジョンをよりうまく尊重できるようにもなると思う。
他の人の邪魔をしてしまうときというのは、自身の価値観が歪んだ形で現れていることが多い。それがなくなれば（減れば）、人の取り組みを手助けするサブソースの役割もよりうまく担えるようになる。
最後に、クリエイティブ・ヒエラルキーの重要性に触れておく。
おさらいだが、クリエイティブ・ヒエラルキーとは、「グローバルソースには、サブソースに対する権威がある」ということだ。
そしてこれも繰り返しになるが、クリエイティブ・ヒエラルキーは、組織構造とは一切何の関係もない。あくまで、「何らかのアイデアを実現するため（イニシアチブ）に、リスクを取って一歩を踏み出した人」がソース（グローバルソース）になる。
逆に言うと、本来ソースではない人が、クリエイティブ・ヒエラルキーに従わずに無関係な権威やエゴを持ち出し始めると、うまくいかなくなり始めるということだ。
誰かが勇気を持って、何かを始めようと一歩を踏み出したとき（また繰り返すが、それは大げさな何かではなく、「立ち止まって10分ほどリファクタリングしましょう」といった程度のことかもしれない）、その意図、カッコよく言えばビジョンに耳を傾けてみる。
もちろん、共感できないイニシアチブに協力する必要はない。違うなら、違うと言う。それでも、そのイニシアチブの権威はソースにある。
違うと言われて、そうだな、と思えば、ビジョンを修正すればよい。ソースは独裁者ではない。むしろ、周囲からのフィードバックを得ながら、ビジョンをよりよくしていく意欲を持った方がよい。そして、そもそもやるべきではなかったなと思えば、イニシアチブを取りやめてもいいだろう。
それでも、ソースには権威があること、そしてそれは組織構造とは何の関係もないこと。
この2つを意識することは、チームの自己組織化が起こるための重要な要素だと思う。
この記事では、自己組織化とソース原理との関わりについてまとめた。
ややとりとめなくなってしまった気もするが、重要な点についてはおさえられたと思う。
これからも、こういった意識でチームでの実践に取り組んでいきたいと思っている。
また、発見や進展があったら報告します。
*1:本来の意味での自己組織化は別に「よいこと」とは限らない。よい悪いに関わらず、何らかの秩序が立ち上がってくることで、現れてくる秩序が何らかの意味で「悪い」こともありうる。だが、ここでは「チームの自己組織化」をポジティブな文脈で捉えたいので、「人それぞれではできない（よい）こと」が現れてくることを条件とした。
「ふりかえり」とは、チームという複雑系をよりよくするための実験にコミットする道のり
ソフトウェアエンジニアとして、チームでの「ふりかえり」に500回*1ばかり取り組んできた中で、「ふりかえり」とは、「チームという複雑系をよりよくするための実験にコミットする道のり」である、という理解に行き着いた。
これが真理である、というよりは、自分なりの整理の枠組みみたいなものなんだけど、ふりかえりという活動を見つめ直す役には立つんじゃないかなと思うので、解説してみたい。
- 「ふりかえり」とは、チームをよりよくするために立ち止まって話し合うこと
- 「ふりかえり」とは、実験を考案してその実施にコミットすること
- 「チーム」とは、目的を持つ複雑系（complex system）
- 「チーム」の目的の1つは、価値を生み出すこと
- 「チーム」の目的の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年かけてたどり着いたのだ。そのときは、ご愛嬌ということで、ワハハ。
そういうわけで僕は、「ふりかえり」とは、チームという複雑系をよりよくするための実験にコミットする道のりだと思っている。
2024年のふりかえり
年末なので、少し早いけれど今年をふりかえっておこう。
やったこと
昨年末には、こう書いていた。
幸い、「価値のあるものを生み出すこと」は、自分だけでなく、周りの人たちや社会にとっても利益こそあれ、不利益はあまりない。と思う。
であれば、素直にそれを楽しんだらいいのだろう。
この考えは、ここを経て、
- 僕は、世界に価値のあるプロダクトを届けたい。これが行動原理だ。
- また、自分が楽しく、幸福を感じていたい。これも重要で、譲れない。
- なお、どちらが第一原理かは明確になっていない。
ここまで進んだ。
今日は、価値を生み出している、と思えるようにする、という選択肢を手に入れた。
わかったこと
やっぱり、そうだったんだ。
価値を生み出したい。それだけは揺らいだことがない。
それを軸にしていれば、多分間違えない。
価値を生み出している、と思えることをやる。
という、暫定的な解。
森博嗣さんの「なにものにもこだわらない」という座右の銘がとてもいいなと思っていて、ひそかに裏・座右の銘にしている。（ちなみに表・座右の銘は「みんな死ぬ」。）
なので、これにもこだわるつもりはない。こだわるつもりはないけれど、一つ決めると他が自由になれる。逆説的に、（それ以外の）なにものにもこだわらなくなれる。
なので、一度そう決めてみようと思った。
次にやること
正直、一度「自由を手に入れてしまった」感覚がある。
一周目のゴール。あるいは第一部完、かな。
来年は、この自由を思い切り謳歌してみたい。
謳歌していたら、きっとまた課題が見つかるだろう。
人はあんまり自由でもいられないものだから。
追記
これ書いたあと、あれ、と思って。
この記事で「自由を手に入れた」みたいなこと書いて悦に入りつつ、得体の知れない不安感がどこかにあったんだけど、この考えだと価値を生み出せなくなったら終わりなんちゃん、ということに気づいてしまった……。
— enk (@enk_enk) 2024年12月25日
自分以外のものに対する価値観としては、「価値を生み出せなければ意味がない」とは思ってなくて（本当に思ってない）、でももし仮に自分に対してそう思ってるとすれば（※十中八九思ってないんだけど）えらいことなので、ちょっと再考が必要だなー。ふりかえりのふりかえりを書くしかないか……😂
— enk (@enk_enk) 2024年12月25日
考えてみたんだけど、結論は大丈夫そう。
ということを、一応追記しておく。
まず、「価値を生み出せなければ意味がない」（と思っているのではないか？）というのは「取り違え」。
「JavaScriptはブラウザで動くから、Javaも動くということ？」と言っているのと同じくらいナンセンス。*1
僕は「価値を生み出す（自分が生み出している状態）のが好き」なだけ。それ以上でも以下でもない。
他人が価値を生み出すのが好きかどうかは関係ないし、もちろん、価値を生み出さないなら意味がないとかもない（はじめからそんな話はしていない）。
それは自分に対しても同じで、好きなのは事実だけど、「価値を生み出さないなら意味がない」ということには論理的につながらない。似て非なる話。
一方で、「価値を生み出すのが好き」なのは疑いようのない事実なんですよね。
なので、自分が価値を生み出せなくなったら、「とてもつらい」と思う。好きなことできなくなるんだからね。
ここから得られる教訓は2つかなと思っていて、
- 価値を生み出し続けられるように、健康を大事にしよう。
- 価値を（今よりも）生み出せなくなっても楽しくいられるように、ゆっくりと違う価値観の軸も探していこう。
かな。
前者については割と大きな発見で、なぜか健康というものをなんとなく重視していない（かといって特別ないがしろにしているわけでもなく、「どうとも思っていない」）人生を送ってきたのだけれど、昨日これに気づいてから、ちゃんと大事にしよう、と思うようになりつつある。
後者については、別に今だって散歩が好きだったり、お酒が好きだったり、価値を生み出すこととは関係ない好きなことはあるから、そんなに悲観はしてない。
それでも、価値観の中心に「価値を生み出す」ことがあるとわかってしまった以上、いつか来るその喪失には備えておくに越したことはない。
まあ、こちらの優先順位は2番目でもいいかな。ゆっくり考えていく。
まずは、健康を大事にすることから。長く価値を生み出し続けられるように。
「健康を大事にする」っていう、多くの人がさっさと見つけるような目標を、こんなに大回りして見つけたのなんか面白いな。
でも、大回りしたからこそ、実感と納得感を持って取り組めると思う。やっていくぞ。
「アジャイルかどうかは、どうすればわかる？」
先日「アジャイル入門」的な内容でお話しする機会があったのだけど、その中で「アジャイルかどうかは、どうすればわかる？」ということに悩んでいる方が多く、「難しいな〜」と思いながら以下のリストを（一つの提案として）ひねり出した。
- 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
- 毎日、学んだことを計画に反映し、最善の計画に更新しているか？
- 計画変更のコストは、ゼロ（に限りなく近い）か？
- 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）
「これが正しい指標だ」と言うつもりはまったくなく*1、あくまで僕がこれまで学習や実践を重ねてきた中で、「このへんちゃうかな〜」と考えた提案であり、試案だ。
あくまで、「取り組んでみているけど、手応えがない」とか、「アジャイルできてる気はするけど、本当にそうなのか知りたい」といった悩みに対して、一つの手掛かりになれば、というレベルのアイデアだ。
とはいえ、案外いい線いってるんじゃないかな、というちょっとした自信のようなものもある。
この記事では、そのあたりを少ししっかり目に言語化してみようと思う。
1. 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
これは、アジャイル宣言の背後にある原則に示されている「価値のあるソフトウェアを早く継続的に提供」や「動くソフトウェアこそが進捗の最も重要な尺度」といった価値観を表現している。
ちなみに、原則の中には「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」というものもあるが、これは現代の（少なくともWebサービス開発の）環境では長すぎて、競争力にはつながらないと感じる。すでに世の中には「毎日、何度も」リリースできていて、そのことから利益を得ているチームが数多くあるのだから、そこを目指すのが妥当だろう。
また、これはアジャイルソフトウェア開発宣言に示されている「包括的なドキュメントよりも動くソフトウェアを」の直接的な表現でもあるし、「契約交渉よりも顧客との協調を」や「計画に従うことよりも変化への対応を」を実現するための方法でもある。
というのも、最終受益者（≒顧客）に価値を届け続けることによってこそ、顧客との協調は最大化される。そして、本番環境に動くソフトウェアをリリースすることこそが、「変化への対応」をも超えて、より積極的に「より高い価値への変化（≒フィードバック）」を生み出していく最良の手段でもあるからだ。
2. 毎日、学んだことを計画に反映し、最善の計画に更新しているか？
1つめの項目に「変化を生み出す」という意味があるとすれば、この2つめは「変化に適応する」ことを表現している。
アジャイルソフトウェア開発宣言で言えば、ずばり「計画に従うことよりも変化への対応」と直結しているし、「契約交渉よりも顧客との協調」という点でも、最初の契約（約束）を守る、守らないといったこと（交渉）よりも、常に最良の計画に更新し続けることで、顧客との協調を実現しようとしている。
原則で言えば、「変化を味方につけることによって、お客様の競争力を引き上げます」であったり、「シンプルさ（ムダなく作れる量を最大限にすること）が本質」といった価値観が表現されている。
最初に考えたすべてを作ることが、価値につながるとは限らない。というより、つながらない可能性が高い。それがアジャイルが前提としている世界観だ。
常に計画を見直し続ける。価値の高いものから作る。価値の低いものはあえて作らず、より価値の高いものを探し続ける。それこそが「シンプルさ（ムダなく作れる量を最大限にすること）が本質」を体現する行動だ。
3. 計画変更のコストは、ゼロ（に限りなく近い）か？
これは、2つめの項目を実現するための重要な前提だ。
2つ目のサブ要素なので、リストからは省いてもよかったかもしれないが、アジャイルから遠い状態のチームからするとやや想像しにくく、重要な前提であると気づきにくい要素でもあるのではないかと思い、あえてリストアップした。
アジャイル宣言の背後にある原則の中でも、「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」であったり、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します」、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」、そして「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」といった原則に忠実であれば、これが実現できる可能性が高い。
逆に言えば、計画変更のコストが高いとすれば、これらのいずれかがおろそかになっている可能性が高い、と考えると課題を発見しやすくなるのではないかと思う。
4. 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）
1〜3は（決して不可能ではないが）なかなか高い要求だと思う。
おそらく、1〜3のすべてが実現できているチームは、「アジャイルかどうかは、どうすればわかる？」というメタ的な疑問で悩むことはなく、よりアジャイルになることを目指しながらも、具体的な価値提供に集中しているだろう。
だからこそ、この4つめの項目もとても重要だ。
アジャイルソフトウェア開発宣言の冒頭では、「よりよい開発方法を見つけだそうとしている*2」と宣言されている。
また、アジャイル宣言の背後にある原則の最後には「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」という項目がある。
よりアジャイルになろうとする態度や行動それ自体が、アジャイルであるための条件の一つでもあるのだ。
技術の重要性
ここまで、4つの項目がどのようにアジャイルの価値基準や原則を表現しているかを説明してきた。
ここで一言、技術の重要性に触れておきたい。
というのも、ここまで説明してきて、技術の重要性に直接言及していないことに気づいたからだ。
これらの項目が実現されている状態の背景には、もちろん、「技術的卓越性と優れた設計に対する不断の注意」が必要になる。アジャイル宣言の背後にある原則の9つめだ。
特に僕が提案している項目の1つめである「毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？」は、自動テスト、リファクタリング、継続的デリバリーに投資し、また習熟していなければ、実現できるはずもない。逆に言えば、それらにしっかり投資し、習熟すれば、十分実現可能な目標でもある。
「アジャイルかどうかは、どうすればわかる？」
最後に改めて、「アジャイルかどうかは、どうすればわかる？」という質問への数多くありうる答えの一つとして、以下の4項目を提案したい。
- 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
- 毎日、学んだことを計画に反映し、最善の計画に更新しているか？
- 計画変更のコストは、ゼロ（に限りなく近い）か？
- 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）
これらは、「よりアジャイルになるために、どのような判断・意思決定をするとよいか」に迷ったときの一つの指針として使ってもらえると有用なのではないかと思っている。
これらから遠ざかる判断や決定なら、アジャイルからも遠ざかっている可能性が高い。
世の中のアジャイルなチームの多くは、これらを多く満たしている（はずだ。僕の知る限り）。
これらを満たしていなくても、アジャイルだと言えるチームもあるかもしれないし、アジャイルではなくても、うまくいっているチームもあるだろう。
それらを否定するものではない。
ただ、こういう状態はとてもいいものですよ、ということを言い添えて、この記事を終える。
