Share
Embed
Cases of order based on cooperation and self-organization and the whole team approach
スクラムフェス大阪
kotatsu
July 19, 2025
Transcript
77 slides
-
1. はじめに a. 原体験、本セッションの⽬的、私を取り巻く状況、免責 2. 理論パート)相互扶助と⾃⼰組織化で成り⽴つ事例 a. 贈与と寄り合い b. 2つの事例からの学び
3. 実践パート)ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する a. プロダクト開発との関係性、実践しているアプローチとアウトカム 4. 導⼊と実践に向けたステップと考慮事項 5. まとめ アジェンダ -
相互扶助と⾃⼰組織化で成り⽴つ事例 ⽀配の⼒とは? 秩序を⽣み出す⼒と⼀⼝に⾔っても⾊々あり ます。 単純な「⽀配」だけでなく、構造的な⼒、誘 導する⼒、そして規範や⾔説の⼒として、 様々な形で社会に遍在しています。⽂化⼈類 学の視点から⾒ると、特に「国家なき社会」 や「寄り合い」のような共同体では、⽀配に よる⼒や構造による⼒(国家‧資本主義のそ
れ)が希薄な代わりに、⾏動による⼒や規範 的‧⾔説による⼒が、秩序を形成する上で極 めて重要な役割を担ってきました。 -
相互扶助と⾃⼰組織化で成り⽴つ事例 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 贈与論 モースは、ミクロネシアのクワキウトル族のポトラッチ(アメリカ合衆国およびカナダ‧ブリティッシュコ ロンビア州の太平洋岸北⻄部海岸に沿って居住する先住⺠族によって⾏われる祭りの儀式)や、ポリネシア のマオリ族の贈与の習慣といった事例を分析し、贈り物には、贈与者と受領者を結びつける、⽬に⾒えな いが強⼒な「精神的な拘束⼒」があることを⽰しました。贈り物は、単なる物質の移動ではなく、⼈間関 係、社会的地位、そして共同体の規範を織りなす「全体的給付」(total prestation)として機能します。 贈与の交換は、以下の三つの義務を伴います。 1.
与える義務 (to give) 2. 受領する義務 (to receive) 3. 返礼する義務 (to repay) -
相互扶助と⾃⼰組織化で成り⽴つ事例 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 贈与論 贈与論は、国家や貨幣、そして暴力による強制という近代的な前提がなくても、人間社会が複雑な秩序を形成し、 維持することが可能であるという洞察を得ることができます。 貨幣や市場が普及する以前の社会では、人間関係の多くが「負債( debt)」、すなわち相互に何かを借りている状 態によって成り立っていたという考察があります。これは金銭的な負債ではなく、 相互扶助や贈与によって生じる 「互恵的な義務感」としての負債です。 私たちが「借金」と聞くと連想するような、数字で明確に清算される金銭的負債とは異なり、精算がされない
「道徳 的な負債」や「人間関係の負債」が社会関係の根幹をなしていた ことを詳細に論じています。 引用元:『負債論 ─ 貨幣と暴力の 5000年史』(以文社、 2016年) -
相互扶助と⾃⼰組織化で成り⽴つ事例 1. 暴力や強制によらない規範遵守: 贈与の義務は法的な強制力ではなく、 「評判」「世間体」「名誉」といった社会的な価値によって維持 されま す。人々は共同体の一員として認められ、信頼されることを重視するため、自発的に贈与のルールに従い ます。 2. 非階層的な社会の流動性と柔軟性:
贈与のシステムは、特定の個人や集団に富や権力を固定化させるのではなく、 資源や義務の流動的な循 環を促します。ポトラッチのように、競って贈与し、消費することで富を「消尽」させる文化は、過度な富の集 中を防ぎ、社会的な均衡を保つ役割を果たしました。 3. 関係性の構築そのものが目的: 贈与は単なる経済活動ではなく、 「人間関係を築き、維持すること」そのものを目的 とします。贈り物のやり 取りは、友情、親族関係、政治的同盟といった社会的な絆を強化する儀礼的な行為です。 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 贈与論 引用元:『負債論 ─ 貨幣と暴力の 5000年史』(以文社、 2016年) -
相互扶助と⾃⼰組織化で成り⽴つ事例 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 寄り合い 寄り合いとは、古代から⽇本の社会に存在する、⾃律的な共同体運営のための⾃然発⽣的な慣習です。基 本的に地域や⾎縁、職業などで結びつき、互いの性格、家族構成、過去の⾏動、社会的⽴場などを⽇常的 に把握した「顔の⾒える」⼩規模な共同体で⾏われます。 • ⼀度きりの関係ではなく、⽣涯にわたる関係性を前提とするため、「貸し借り(恩義)」や「相互扶 助」といった⻑期的な互恵関係が重視されます。困った時は助け合い、何かを受け取れば返礼すると いうサイクルが、共同体を維持する基盤となります。 •
⽇々の交流や共同作業を通じて信頼が蓄積されます。信頼があるからこそ、明⽂化された契約なし に、⼝約束や⾮公式な合意で物事が進められます。 -
相互扶助と⾃⼰組織化で成り⽴つ事例 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 寄り合い 寄り合いにおける意思決定は、特定のリーダーによる指⽰や多数決ではなく、参加者全員の納得、すなわ ち「総意」や「合意(コンセンサス)」を⽬指す傾向が⾮常に強いです。 • 意⾒の対⽴があっても、感情的な議論を避け、時間をかけて「落としどころ」を探ります。それでも 全員が合意に⾄らない場合、無理に結論を出さず、問題を「棚上げ」したり、次回の寄り合いに「持 ち越し」たりすることがあります。これは、関係性を壊さずに問題を継続的に検討し、熟成させるた めの戦略です。 ‐
最終的な決定に対する全員のコミットメントを強化する効果がある • 明⽂化された法や規則が少ない⼀⽅で、「ムラ⼋分(村⼋分)」に代表されるような⾮公式な社会的 圧⼒が存在しました。共同体の規範から逸脱する⾏動は、評判の失墜や関係性の断絶に繋がり、個⼈ にとっては極めて重い制裁となります。秩序は、外からの強制ではなく、個々⼈の⾃律的な規範意識 と、共同体からの相互監視‧相互評価によって維持されます。 -
相互扶助と⾃⼰組織化で成り⽴つ事例 相互扶助と⾃⼰組織化で成り⽴つ秩序の事例 寄り合い 共同作業と儀礼を通じた連帯感の強化 寄り合いは、単なる話し合いの場だけでなく、共同体としての活動や儀礼を通じて、参加者間の絆を深 め、秩序を再⽣産する役割も担います。 • 「ハレ」と「ケ」の循環: 祭りや共同作業(例えば、⽥植えや稲刈り、⽔路の整備など)といった 「ハレ(⾮⽇常)」の共同活動は、⽇々の「ケ(⽇常)」における関係性の基盤となります。共に汗 を流し、共に⾷事をすることで、共同体の⼀員であるという意識が強化され、協⼒関係が再確認され
ます。 • 共同作業や儀礼の場は、⽇常的な不満や⼩さな対⽴を解消する機能も持ちます。共同体を優先する意 識が⾼まり、個々の争いを超えて、全体の調和を再構築する機会となります。 -
ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する 責務や情報の独占によって権⼒になってしまうので、それをしません。これは組織構造ではなくQAのタス クと責務をどのように定義するかの話です。責務の集中によってフェーズゲートが⽣まれ、フェーズゲート が⽣まれるとボトルネックとなり、機動⼒が損なわれるからです。 メリット • 全員が品質担保の責務があるので、バグは開発の早い段階で発⾒‧修正されやすくなる • 開発者もテストに参加することで、開発リソース全体の流動性が⾼まり効率的な開発が可能になる •
新しい技術や知識を取り⼊れる動きが加速する • 開発チーム全体のスキル向上に寄与 1.資源や労働の「共有性」と「必要に応じたアクセス」、そして「富の流動性」 →QA/QCの責務やタスクを独占しないでシェアする -
全員が品質保証の担い⼿である前提 のもと、QAはプロダクト開発のため の(品質に関するスキルや技能も含 めた)様々なケイパビリティを上げ る、というミッションにしています 重要なのはQAは品質保証をする⼈‧ 役割ではないということ ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する 1.資源や労働の「共有性」と「必要に応じたアクセス」、そして「富の流動性」 →QA/QCの責務やタスクを独占しないでシェアする
引用元:8/8(木)_Findy_ワンチームで勝つ :プロダクトチームの中 でのQAエンジニアのふるまい事例 -
ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する 2:意思決定と権⼒の「⾮集中性」 →QAとして横断組織をおかないで、チームの中に⼊る 組織設計として、QA横断組織を作らず、チームの中に⼊りチームの活動にコミットするという形を取って います。 品質保証がQAだけの責任ではなく開発チーム全体で⾏うことを組織設計としても⽰すことで、各メンバー が品質に対する強いオーナーシップを持ちます。権限が「⾮集中」されることで、⼀⼈ひとりが品質の「意 思決定者」としての意識を持ちます。 メリット •
意思決定が迅速化し、品質改善のサイクルが⾼速になる • 職種間の協⼒関係が促進され、より建設的なフィードバックと対話が⽣まれる ‐ 強制や命令、依頼、委託等はなく、ある程度は各々⾃分で考える必要があるから ‐ 特定の職種だけが品質基準やテスト戦略を独占しないため、チーム全体の透明性が⾼まるから -
ソフトウェアにおける品質は、単に技術 的な完成度やバグの少なさだけでなく、 ユーザーにとっての有⽤性、ビジネス⽬ 標への貢献、⻑期的な保守性や拡張性な ど、多様な「価値」を内包します。この ように広く存在する品質を⽀えるのはテ クノロジー、プロセス、そして組織で す。(cf: 品質富⼠⼭) 品質を広義で捉えた結果、明らかにQAの
みでは実現できないので全員でやってい く必要性が⾼まりました ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する 2:意思決定と権⼒の「⾮集中性」 →QAとして横断組織をおかないで、チームの中に⼊る -
ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する 3. 関係性の「持続性」 →常にスウォーミングをする なるべく、何でも⼀緒にやるようにしました。作業を⼀緒にやると、あるべきの話や今するべきではない けど思いついた話、私⽣活、⼈となり、⾊々⾒えてきます。この積み重ねにより、QAと開発者は、互いに 改善のためのフィードバックを与え合い、サポートし合うことで、より強固なチームや関係が築くことがで きます。単に「テストをパスした/しない」という⼀⾯的な関係で終わらず、品質向上という共通の⽬標に 向かって協⼒し続けられるようになりました。 メリット
• 品質保証の知識と経験がチーム全体に蓄積される • ⼀時的な課題やメンバーの⼊れ替わりがあっても品質⽔準が低下しにくい持続的な体制が構築される • 困ったときに助けてもらえる • リスクを拾いやすくなる • ベイビーステップができる -
ホールチームアプローチを相互扶助と⾃⼰組織化で成り⽴つ秩序の要素で再解釈する スウォーミングに持ち込むためのテクニックも ⾊々(cf: 過去登壇) スウォーミングの中の会話から転じ、そもそも の問題の提起をしたい‧なにかを変えたいと なったときは、そのために別途時間を取り⼀緒 に準備をするとか、MTGの準備やファクトの収 集、課題整理などを⼀緒にやったりもします。 3.
関係性の「持続性」 →常にスウォーミングをする 引用元:https://speakerdeck.com/kotatsu -
導⼊と実践に向けたステップと考慮事項 順番に登る、しっかりやる 思い返すと私は 1. 「QAとして横断組織をおかないで、チームに⼊る」 2. 「常にスウォーミングをする」 3. 「QA/QCの責務やタスクを独占しないでシェアする」 という順番で登りました。このような登り⽅になったのはたまたまですが、逆の順番、もしくは全部⼀気
にやろうとしてもうまく⾏かなかったような気がします。 チームの中に⼊っても、⾃分だけでテストをしていたら、この順番でやってもうまくいかなかったと思いま す。 -
導⼊と実践に向けたステップと考慮事項 コミュニティの運営 また、スウォーミングと同時に、品質に興味がある⼈たちの⼩さなコミュニティ的の運営することからは じめたことも添えておきます。 そのコミュニティの中では、コミュニティ‧オブ‧プラクティス(実践コミュニティ)のアプローチを参考 に、品質に関する関⼼や問題、熱意などを共有し、その分野の知識や技能を、持続的な相互交流を通じて 深めていきました。 — 実践コミュニティの構成モデル 1.
ドメイン: そのコミュニティで取り組む共通のテーマ 2. コミュニティ: メンバー間の相互作⽤と学習。どのようにコミュニティを運営していくか 3. 実践: 知識を⽣み出す活動 三要素を並⾏して発展させることが重要 引用元:コミュニティ・オブ・プラクティス ナレッジ社会の新たな知識形態の実践 -
実践コミュニティの構成モデル 1. ドメイン: そのコミュニティで取り組む共通のテーマ 2. コミュニティ: メンバー間の相互作⽤と学習。どのようにコミュニティを運営していくか 3. 実践: 知識を⽣み出す活動
上記3つともが流動的な状態だと存続が危ういとのことだが、品質に関する実践コミュニティは、ドメイン や実践を強固にするための題材には事⽋かない。安定した要素が⼀つでもあれば、それを元に他の要素の 安定にもつなげられて、メンバーの出⼊りは激しくてもコミュニティにあまり影響がないとも記載されてい て、今までの経緯を思い返すと合致する。 会社組織の中で品質コミュニティをやっていくにあたり、上記構成モデル3つを同時に発展させていくこと は他のドメインと⽐べると簡単なのでは?と思います 導⼊と実践に向けたステップと考慮事項 コミュニティの運営 引用元:コミュニティ・オブ・プラクティス ナレッジ社会の新たな知識形態の実践 -
寄り合いと国家の関係性からも学べる部分がありそうです • 階層型組織的体制の⽬標を理解するための時間は惜しまない。納得し⾃分の⾔葉で語れるまでになる • 階層型組織的体制の⽬的をネットワーク型組織の⽬標に⼀部取り⼊れる • 安定性や実⾏速度を出したいときは階層型組織的な組織設計を⾏う • 階層型組織的体制とネットワーク型組織の窓⼝‧インターフェースを⼀元化し、調整能⼒の成熟を図 る
ダンバー数からも分かる通り、巨⼤な組織の上から下までネットワーク型でやろうとするのは難しいの で、上記のような⼯夫を取り⼊れていく必要性があります。 階層型組織的な権⼒を⼀概に否定することは難しい 階層型組織体制とネットワーク型組織のいい感じの落とし所とは? 導⼊と実践に向けたステップと考慮事項