【イベントレポート】「離れて、共に 市場経済を超えたニーズへの対応」
はじめに
2020年7月25日に開催された、ミキ・カシュタンによる、特別オンラインWS「離れて、共に 市場経済を超えたニーズへの対応」のイベントレポートです。
スピーカーはミキ・カシュタン。
名前だけは知っていたけど、オーガナイザーの安納献さんによれば、日本にNVCを広めることになった源流の一人、そして世界で最も影響力のあるNVCトレーナーの一人とのこと。
今回はミキがコロナ禍で感じた市場経済主義の限界と、それを乗り越える方法を一緒に考えるという趣旨のワークショップでした。
スピーチ
質疑応答
Q. (地域コミュニティで交換する経済は)みんなが交換できるリソース(資源)を持っていることが前提となっているが、個人が細分化され、そのようなリソースを持っていないことが問題では?
全くもって同意します。
最初に政府を頼らなければならないのは、みんなが遠いところにある、大きな組織に頼っているから。
ただ、みんながどこにいようと、それを始めて欲しい。
たとえば、車から始められるかもしれない(→カーシェアリング)。
一つのストーリーをシェアさせて欲しい。
ソ連崩壊時、キューバへの贅沢品ではなく、日用必需品の輸入も途絶えた。
当時、急に自給自足にならないといけなかった。
今でもキューバの食料品の半分は、首都ハバナで生産されている。
環境が制限されると、私たちはよりクリエイティブになる。
今のこの時期は、創造性を引き出すのに良い時期。
Q. ミキさんの話の背景には、社会契約があるのでは? 日本は天皇制で2000年いったので、オルタナティブを探しづらい。ミキさんの社会契約という考え方が、簡単にしてるのでは?
私は日本の歴史にほとんど詳しくないので、想像で答えます。
天皇制の遥か前に、何かがあって、いのちから離れていった。
全ての文化の太古の知恵は、日本でも同じだと思う。
どこかの時点で、いのちを信頼するところから離れていった。
いのちから離れていたら、恐れに入った。
恐れに入ったら、どれだけ必要かどうかがわからなくなる。
恐れの中では、実際に必要な分量が分からなくなる。
自然の豊かさの代わりに、そこに生まれるのは2つの悪。
1. 製造された欠乏
2. 恐れ
恐れが起ると、争いが起こる
そこでは国家を作るのがとても魅力的になる
国家の機能は、暴力をコントロールすること。
1. これは正当化された暴力、正当化されてない暴力と区分ける
2. 国家は市場を生み出す。税金を生み出すためのお金を産むのに役に立つから
みなさんが乗り越えなきゃいけない権力への恐れは2層ある。
1. 天皇、もしくはてっぺんにいる強い男性への恐れ
2. グループ全体が持つ、同調圧力、グループが持っている権威
日本文化の強みは、全体を考えること、それは有利にも使える。
Q. 私たちは結局、プラスチック産業などは必要なのではないか?
エネルギー、石油、はそう長く持たない。
私たちはあまりにも利便性に慣れ親しんでいて、それ抜きでどう生活したら良いかのイマジネーションを失っている。
私たちは死と向き合う必要がある。
私たちを殺そうとするものをコントロールしようとするとそこには、より多くの死が集まります。
近代の文化は死を失敗と捉えている。
私は自然の命の一環として見ている。
この惑星の資源の範囲内で暮らし、消費を減らし、もう二度と合わない人の面倒を見る。
Q. ミキがこのワークショップで一番伝えたかったことは何か?
交換(exchange)は、利己主義に基づいている。
流れ(flow)は、寛大さに基づいている
私は、人間のみならず、全ての命を大切にするあり方がみたい。
人間のみならず。
(もう一問とても興味深い問いがあったのですが、ちょうど飲み物を取りにいってて聞けなかったので割愛)
感想
オーガナイザーの安納献さんがこのワークショップを開催した理由の一つとして、「ミキみたいな人がこの星にいて、こんなすごいことを言っている人がいるよと伝えたい」と言っていましたが、まず私が強く感じたのもミキの圧倒的な存在感でした。
ミキは、自分の人生すべてを目的のために捧げよう。と思い、目的に添わないことはやらない人で、このワークショップもミキに断られ続け、数年掛かりでようやく実現したとのこと。
まずはそんなミキ・カシュタンの存在と生き方に衝撃を受けました。
そして、衝撃を受けたのはミキ自身だけではなく話の内容にもです。
話は国家誕生前の数万年の規模に及び、資本主義など既存のイデオロギーに染まっている自分にはまだ消化に時間がかかると感じました。正直最初は「お花畑」ではないかと感じていましたが、質疑応答やミキのブログを読むと、これはお花畑ではなく、地に足がついた思想に支えられた社会変革運動だと思い直していきました。
それに......市場に委ねるのではなく、政府に頼るのでもなく、地域コミュニティで必要な分だけを与え合う社会。それは決して夢物語ではなく、すでに、社会のあちこちで芽吹き、このコロナ禍で加速しているようにも感じています。
今回、ミキは理想という種をみんなに植えたかったのだと思います。
もちろん理想を実現するのには多くの障害がありますが、種を植えられた私たちは、明日から少しだけ行動が変わるような気がしています。そしてその小さな行動の積み重ねが、大きく社会を変えていくのではないでしょうか。
私も今日からできることを探そうと思ったワークショップでした。
さいごに
今回はミキ・カシュタンの特別WS「離れて、共に 市場経済を超えたニーズへの対応」のイベントレポートを書きました。
イベントに参加できなかった方が少しでもイベントの雰囲気が感じる助けになれば嬉しく思います!
そして、想像より遥かに大変なイベントを企画、実現してくださった運営チームの安納 献、鈴木 重子、石川 咲子、石川 世太の皆様、ありがとうございました!
新人スクラムマスターやアジャイルコーチ必読!?『アジャイルコーチヒッチハイク・ガイド』【現在無料】
はじめに
今回は、アジャイルコーチに限らず、スクラムマスターやエンジニアリングマネージャーにも是非オススメしたい『The Hitchhiker's Guide to Agile Coaching(アジャイルコーチヒッチハイク・ガイド)』という本をご紹介します。*1
現在(2020年07月23日)、今なら無料で以下よりダウンロードできます。
私は様々なエンタープライズ企業でアジャイル導入支援をしています。
この一年、様々なアジャイル関連書籍を読んだ中で、どの本も素晴らしいと感じる一方、仕事で感じているモヤモヤや困り事に対応していない、というもどかしさを感じていました。
今、ようやく探していた一冊に辿り着けたような気がしています。
てわけで前置きが長くなりましたが、なぜ本書をオススメしたいのかと、本書で紹介されているテクニックの一部をご紹介していきます。
本書をオススメする理由
本書をオススメするのは、あまり語られることがない、アジャイルを定着させるためのコーチングスキルについて実践的なテクニックやフレームワークが豊富に紹介されているためです。
Agile thinking and agile practices are easier to learn than coaching skills. There are agile books, Scrum training, workshops, conferences, communities and a lot more available, however for many people the main problem is, in fact, the unlearning of old thinking patterns.
アジャイル思考やプラクティスはコーチングスキルよりも簡単に学べます。アジャイル関連書籍、スクラムトレーニング、ワークショップ、カンファレンス、コミュニティ、その他多くのものがあります。
前書きに、アジャイル関連書籍は「仕事で感じているモヤモヤや困り事に答えていない」と書きましたが、それもそのはず。
1と2は異なるスキルなのにも関わらず、私が1の本に2の情報に求めていたからなのです。
そして、1に関する情報はあふれていますが、2に関する情報はまだまだ多くありません。*2
They have started out as new agile coaches with reasonably good agile knowledge, but do not know enough about coaching. If you belong to this group, this book is for you.
彼らは、合理的で優れたアジャイルナレッジを持ちながらも、コーチングについて十分な知識を持っていない新人アジャイルコーチとしてスタートしました。
もしあなたがこのグループに属しているなら、この本はあなたのためのものです。
まさに私がそうでした。
全くコーチングスキルがないままこの世界に飛び込んだ私が取れた唯一の選択肢は、「狂信者」になることでした。つまり、現場で、アジャイルマニフェストとスクラムガイドを掲げて「スクラムではこうしてください！」「それはアジャイルマニフェストと違います！」と叫んでいたのです。
結果、変わらないどころか、悪化する現実......
なぜなら、
however for many people the main problem is, in fact, the unlearning of old thinking patterns.
しかし多くの人にとっての主な問題は、結局のところ、古い思考のアンラーニングです。
多くの企業にとってアジャイル導入時の主要な問題は「古い思考のアンラーニング」だからです。
経験的にも、古い思考をアンラーニングしながら新しい思考をインストールするためには、アジャイルに関するスキルと同じ位、優れたコーチングスキルが必要になります。本書は、そのための本なのです。
個人やチームにどう問いかけるべきか?
ここからは本書で紹介されているテクニックのごく一部をご紹介します。
ナラティブ・クエッショニング
どのように個人やチームに質問を投げかけるか? は、私のようなコーチング初心者にとってとりわけ難しいテーマの一つです。
そんな中、本書で紹介されている北欧の家族療法の理論家カール・トム（Tomm, K.）のナラティヴ・クエッショニングが参考になりました。トムは4つの質問を意識して質問することが重要だと言います。
1. リニア・クエッション(刑事の質問)
直線的因果律の構え・探索的意図
(いつ、何処で、誰が、何を)
2. サーキュラー・クエッション(探検隊の質問)
円環的因果律の構え・探索的意図
(一体全体どうなってるんだろう)
3. ストラテジック・クエッション(教師の質問)
直線的因果律の構え・戦略的意図
(正しく導くための質問)
4. リフレクシブ・クエッション(ファシリテーターの質問)
円環的因果律の構え・戦略的意図
(新しい物語へのきっかけを作る質問)
たとえば、プロダクトオーナーが複数いる現場を、一人のプロダクトオーナーに導きたいとします。
以前の自分は以下のようなストラテジック・クエッションをふりかざし、教師のように振舞うのが精一杯でした。
- スクラムガイド にはプロダクトオーナーが何人と書かれていますか?
- 本来は何人が望ましいですか?
しかし、ストラテジック・クエッションだけでは現実は動きません。
現実を動かすためには、以下のようなリニア・クエッションで刑事のように、事実を確認する必要があり、
- いつからプロダクトオーナーが複数人になりましたか?
- 複数人のプロダクトオーナーは具体的に何をしてますか?
以下のようなサーキュラー・クエスチョンで文化人類学者のように、組織や人がどのような世界観と構造を持っているかを確認する必要があり、
- なぜプロダクトオーナーが複数人になったのでしょうか?
- プロダクトオーナーが複数人いることで何か課題はありますか?
そして、以下のようなリフレクシブ・クエッションでファシリテーターとして、相手の世界観を尊重しながら、アジャイルとしても適切な地点に着地させる必要があります。
- プロダクトに一番詳しいあなたが、開発チームとモブでプロダクトバックログアイテムを作ることで知識をシェアしていくのはどうでしょうか?
経験豊富なコーチやコンサルタントを観察すると、この質問の使い分けを上手にしていることに驚かされます。
ブリッジクエスチョン
アジャイルコーチは個人だけではなく、チームに対しても質問しなければなりません。
本書が素晴らしいのは個人に対してだけではなく、チームに対する問いかけのテクニックやフレームワークも豊富に紹介されていることです。
たとえば、メンバーの態度、経験、意見、提案の間の架け橋となり、チームの共通理解を築くためのブリッジクエスチョン(bridging questions)は、発言するメンバーの意見が偏っている場合や、形成期のチームに有効だと感じています。
- ブリッジクエスチョンの例
“What similarities do you see in what different people are saying here?”
“In what way do the things Paul is speaking about link to your interest in the subject? What can you add to this?”
“In what way are you inspired when you hear the others discuss the subject?”
“Is there something you feel that the others have forgotten in their discussion?”
“In which way can you see that your thoughts are aligned with other people’s opinions? In which way do your thoughts differ from the others’ opinions?”
"異なる人々がここで述べていることにどのような類似点がありますか？"
"パウロが話していることは、どのようにしてあなたの興味と結びついているのでしょうか？ あなたはこれに何を加えることができますか？
"他の人たちがこのテーマについて話しているのを聞いて、あなたはどのような点で感銘を受けましたか？"
"他の人たちが議論する中で、何か忘れていると感じることはありますか？"
"自分の考えが他の人の意見とどのように一致していると思いますか？自分の考えと相手の意見はどのように違いますか？"
おわりに
今回は、『The Hitchhiker's Guide to Agile Coaching』をご紹介しました。
もちろん本書では「ナラティブ・クエッショニング」や「ブリッジクエスチョン」などの質問についてだけではなく、傾聴やシステムコーチやスポーツコーチとアジャイルコーチの違い、各スクラムイベントでのチェックポイント、5Dモデル、チームの成長モデル等、明日から役に立ちそうな様々なテクニックやモデルが取り上げられています。
Agile coaching is not magical handwaving. It is a soft but very very structured skill.
本書は、アジャイル推進者のための本に見えて、実はアジャイルではなくても有用な本です。
私のようにアジャイル推進で苦戦している方だけではなく、組織に新しいことをもたらそうと苦戦している方が一人でも多く本書を知るきっかけになればと思います。
最後までお読みいただき、ありがとうございました!
アジャイルコーチが見た、上司を説得するための5つのポイント
昨日、「ほめる」ことについてウダウダ書いてた挙句次第に気に入らなくなりボツにしてしまったので、今回は連続Tweetみたいなノリで、これまでのスクラムマスターやアジャイルコーチの経験を通じて、組織を変えるためのポイントを書いてみたい。
今回は、組織を変えるために避けて通れない「上司(や他部門やステークホルダー)」を説得する際に普段心掛けている極私的ポイントをまとめました。
1. 相手の言葉を使う
あるUXデザイナーが、エンジニアとの合同ミーティングを開催した際の経験をシェアします。
私を含むエンジニアはUXデザイナーの提案に懐疑的で、会議も重苦しい雰囲気に包まれていましたが、そのUXデザイナーが、
「それってドメイン駆動設計におけるユビキタス言語みたいなものですよね」
と普段エンジニアが会話している用語を使ったことから、「お、この人分かってんじゃん」という空気が流れ、一気に場の雰囲気が打ち解けてエンジニア全員が彼に耳を傾けていきました。
その時分かったことは、相手に提案を聞いてもらうためには、「この人は自分のことをわかっている」と思わせる必要があり、「相手の言葉を使う」ことはそのための有効な手段だということ。
アジャイルやスクラムを推進する際、私たちはついスクラム用語で話しがちになりますが、それは「私たちが所属する言語圏の言語」です。まずは「相手が所属する言語圏」を見極めましょう。事業責任者をプロダクトオーナーなどと勝手に翻訳することには注意です。
- 相手の言語を観察/傾聴する
- その言語をそのままコピーする
- 書籍などを読み、相手の言語をより理解する(対セールス部門だったらセールスの、対マネージメント部門だったらマネージメントの)
2. 行動の背後にある"意図"に注目する
私たちは、上司やマネージャーの提案を見て、しばしば「間違っている、ついていけない」と思う。
ただ現在、様々な組織を経験して思うのは、上司やマネージャーが間違うのは、意図ではなく、意図を実現するための戦略(手段)であることがほとんどだということ。そして従来型組織の上司やマネージャーは意図を伝えることが苦手な方が多いことがこの悲劇に拍車を掛けます。
多くの組織で悲劇は、以下のように起こります。
- メンバーに自律的に働いて欲しい → 「よし、そうできるように精一杯アドバイスをしよう」
- もっと効率を上げたい → 「よし、全員に仕事を詰め込もう」
- もっと規律を高めたい → 「よし、チャラチャラしている付箋は禁止しよう」
なので私たちは、上記のような提案を聞いても、即座に否定するのではなく、その背後にある意図を汲むことが重要となります。大変なのは、表面に現れるものから暗号のように意図を読み解く必要があることです(上司に限らず私たちだって「愛している」と伝えたくて、相手を「なんて自分勝手な人なんだ!」と怒鳴ったりする)。
経験上、抵抗派の上司もアジャイル開発の推進メンバーも、「メンバーに自律的に働いて欲しい」「もっと効率を上げたい」「もっと規律を高めたい」というような共通の意図を持っている事が多いのです。もちろん従来型開発とアジャイル開発では、たとえば効率という観点でも、リソース効率やフロー効率というように採用する戦略は正反対になりますが。
即座に相手を否定せず、相手の意図を理解し、それを満たすような手段という形で提案すれば、上司やマネージャーに受け入れられる可能性が高まります。もしかした苦手な相手とも、意外と自分と重なる意図を持っているかもしれません。
3. 小さくはじめて信頼貯金を貯める
これも多くの方が言っている事ですが、結局の所、上司や他部門に、自分の提案を通すためには「実績を上げて信頼を勝ち取る」しかありません。これは社内のスクラムマスターでも社外のアジャイルコーチでも同じです。そして初めから大きな実績を上げることは困難なので、なるべく小さな成功体験を積み重ねて信頼貯金を貯めることが重要になります。
ただし、小さな成功体験にもリスクがあります。それは周囲が「もう十分達成した」と思い込んでカイゼンをやめてしまうこと。なので、小さな成功体験をある程度重ねたら、どこかでギアチェンジをして変化を加速させると良いと思います。
焦ることはありません。
私が見る所、信頼貯金には複利がつきます。
ただし、失うのも一瞬ですが......
4. あなたの力を意識する
さて、これまで上司や他部門に説得することをテーマに話していましたが、そもそも自分は提案できる立場ではない、役職上の権力がないから組織なんか変えられっこない、という人もいるかと思います。
というか、ぶっちゃけ、それは私です。
私は10年間以上、ある孫請けSIerで平社員としてWebエンジニアをしていました。会社は上意下達のカルチャーであり、そこでは上司が絶対でした。
意思決定とは絶対的な権力を持った上司するもので、部下はそれに従うものだとずっと思ってきました。
私は、役職的な権力だけを力と勘違いし、「孫会社だから、平社員だから、派遣だから何もできない」と無力感をずっと抱えて生きてきました。しかし、心理学者のJ.R.P.FrenchとB.Ravenは「人々がリーダーの要求に応え、命令や指示に従う根拠は、①強制的パワー、②報酬的パワー、③合法的（地位・役職）パワー、④人間的（好感）パワー、⑤情報的パワー、⑥専門的パワー」と言っているそうです。
つまり、人を説得し、組織を変えるのに必ずしも地位や役職は必須ではないのです。
さらに言えば、あなたはあなたの影響力で、既に組織を変化させ続けています。
組織においては全ての関係性は連続的につながっています、
先程のバタフライエフェクトの例のように、あなたが隣人に小さくとも影響を与えることで組織は少しづつ変化しています。
普段は意識出来ていないかもしれませんが、貴方は毎日組織で何かアクションをするたびに関係性に影響を与え変化させているのです。
先輩アジャイルコーチは「上司を変えることはできないが、上司に働きかけることはいつでもできる」とよく現場で伝えています。
あなたの力を意識し、信じて、遠慮なく上司に働きかけていきましょう。
5. 説得しない(人は変えられないことを知る)
大学時代、授業中に「告白は必ず失敗する」と言った教授がいました。
理由を訊ねると、「本当にお互いが好きだったらわざわざ告白という不自然な儀式をしなくても自然に付き合っているはずだ、相手が好きではないから告白をするのだ」との答えが返ってきて、なぜだか不思議と記憶に残っています。
人を説得することは告白と似ています。
これまで人を説得することについて語ってきましたが、不思議なもので、頑張って人を説得しようとすればするほど、相手はそこにコントロールの意図を感じ取り、拒絶を強めます。逆説的ですが、他人は変えられないことを認識してはじめて、他人が変わる可能性が開けるのです。
人に説得する前に、まずはあなた自身が変わりましょう。
そのためには「XPを広めるためにはどうしていけばいいか」という質問に対するケント・ベックの回答が参考になります。
「XPを広めるにはどうしていけばいいか」という質問に対しては，Beck氏は「まずは努力して自分を変える」ことだと答えた。「自分が変わることによって，立ち居振る舞いや行動がどう変わったかを人に見せる。その変化がどれだけプラスの方向に働いているかを証明する。自分がよい方向に変われば，対人関係もよくなる。そこから信頼が生まれる。そこまでいけば，まわりは『自分も変わってみようか』と思う」（同氏）。「相手を説得しよう，相手が言うことを覆して自分が言うことを納得させよう」という態度では決して伝わらないのである。「まわりの人間のどこが悪い，ここが悪いという点に注目するのではなく，ポジティブな方向性でよりよくものごとを変えていく」という心構えが必要だという。
おわりに
今回は、組織を変えるために避けて通れない「上司(や他部門やステークホルダー)」を説得する際の普段心掛けている極私的ポイントをまとめてみました。
はじめは連続Tweetのノリで書こうと思いましたが、意外と分量が多くなって反省しています。
上司や組織との関係は以下のようにまだまだ語りたいトピックが多いため、また機会を見つけて話したいと思います。
- "事実"と"意見"を分けて話す
- それでもダメだったらとっとと逃げ出す
もちろん、これは私の経験によるもので、あなたの組織に適用できるかどうかはわかりません。
ですが、一つでも使えそうなアイディアがあればとても嬉しく思います!
最後までお読みいただきありがとうございました!
軽い気持ちや冗談で相手を批判する時、自分の中で起こっていること
つい先日、本人としては軽い冗談のつもりで他人のブログを批判してしまい、大切な人を傷つけてしまったことがある。
もう二度とこんなことを起こしたくない、という欲求がある。
人とのつながりをもう一度取り戻したい、という欲求がある。
そのため、軽い気持ちで相手を批判する時、自分の中で起こっていたことを最近探究しているNVC(非暴力コミュニケーション)の助けを借りて考えてみたい。
批判する時に湧き上がっている感情
判断する、批判する、評価する、解釈を加えるということはどれも、自分が必要としていることが満たされていないという遠回しの訴えだ。
僕が人に批判的になってしまうのは、うらやましさや妬ましさがある場合だ。
- その人は、いつか辿り着きたい場所にいる。それは、自分が辿り着きたい場所からいかに遠いかを痛感させる。その痛みをぶつけたくなってしまう
- その人は、注目を浴びている。それは、自分が注目を浴びていないことを痛感させる。その痛みをぶつけたくなってしまう
- その人は、輝かしく見えるキャリアを歩んでいる。それは、自分のキャリアがいかに不安定かということを痛感させる。その痛みをぶつけたくなってしまう
- その人は、楽しそうに仕事をしている。それは、自分の仕事の苦しさを痛感させる。その痛みをぶつけたくなってしまう
自分はその湧き上がった痛みや感情をどこかで恥ずかしいと感じている。だからなるべく他人に悟られないよう、冗談や軽口の形でなるべくわからせないようにするのだ。
感情の大元にあるニーズ
けれどNVCが自分にとって大きな助けになったのは、それら一見醜くて目を背けたくなるような感情の大元にも、人間としての普遍的なニーズがあり、そしてニーズは全て美しいと主張しているところだ。
もともと感情に美しさや醜さはない、醜くみえる感情は、美しいニーズが満たされていないという現れなのだ。
わたしたちの言葉（言動）はすべて、そのひとのニーズを表しています。
ニーズとは、（ひとのもっとも深いところにある）行動の源となる動機です。言葉を口にしたときに、そのひとのなかで本当に大切にしているものです。わたしたちには、いつでも「『人生の普遍的で美しい質』を満たしたい」という思いがあります。
最初に湧き上がった感情の背後にあるニーズをNVCの感情とニーズリストにあるニーズの言葉で現してみたい。
1. のニーズは、"成長"や"所属、帰属意識"
2. のニーズは、"理解してもらうこと"や、"共鳴・共振"
3. のニーズは、"安心"
4. のニーズは、"気楽さ"や、"楽しみ"
おわりに
今まで言ってきたことは、決して自己正当化ではない。全ての言動や行動が普遍的な美しいニーズに基づくからといって、もちろん何を言っていいわけではない。自分の言動や行動の背後には美しいニーズがあるのと同様に、相手の言語や行動の背後にも美しいニーズがある。今回、自分の痛みと向き合うことを恐れて、軽口の形で相手を非難することは、相手の大切なニーズを損うことを学んだ。
これからは相手に批判的なフィードバックをしたくなったら、自分の中に湧き上がるネガティブな感情に向き合い、その大元にあるニーズに目を向けたい。そして、相手の中にあるニーズをできるだけ推測したい。その上で、言葉を紡いでいきたいと強く考えている。
新しいふりかえりのアクティビティ: Requestについて
最近クライアント先で実験しているふりかえりのアクティビティが、チームや全体に良い効果をもたらしつつあると感じるため、アクティビティを「Request」と「KPTR(=Request)」とそれぞれ名づけてシェアしたいと思います。
「Request」のコンセプトです。
チームのカイゼンと同じくらいのエネルギーを、他者へのリクエストに向けることで、チームのみならず「チームを含むシステム全体」のカイゼンと調和をはかるためのアクティビティ
また、Requestが効果的なチームは以下を想定しています。
- 関係者が多いプロジェクトの大企業等のスクラムチーム
- 開発チームだけでふりかえりを実施しているチーム
作成した背景
これまで、様々な企業でのスクラムマスターやアジャイルコーチの経験を通して、チームでカイゼンをするというアジャイルにおけるふりかえりのコンセプトは素晴らしいですが、実際の運用では以下のような問題があると感じてきました。*1
そして、上記の結果、以下状態になったチームも少なからず経験してきました。
- チーム自身に対して無力感を抱くようになる
- チーム以外に対して批判的感情を抱くようになる
無力感や批判的感情を抱いたチームは、チーム内では楽しく活動できるもの、マネージャーやステークホルダーなど他者との健全な関係性を抱けないまま、その偉大なパワーを次第に弱めていきます。
上記を解決するため、チームのProblemに対してチーム自身で解決策を図ると同時に、チーム以外の他者に対して積極的にリクエスト(=お願い)することを要素として追加したのが「Request」です。
Requestのやり方
- チームメンバーで課題の原因分析する
- チームのTryと他者へのリクエストを決める
1. チームメンバーで課題の原因分析する
まずは、チームメンバーで話し合いたい課題の原因分析をします。なるべくチーム内で閉じない、組織全体に関連しそうな課題を選択すると効果的です。*2
まずホワイトボード中央に課題のふせんを配置し、あとは「なぜなぜ分析」や「マインドマップ」やシステム思考の「因果ループ図」などで原因分析していきます。
この時、チームだけで解決可能な原因と、他者の力を借りる必要がある原因のふせんを色分けするのがポイントです。
2. チームのTryと他者へのリクエストを決める
上記分析の結果から、チームのTryと他者へのリクエストを決めます。
上記での「チームだけで解決可能な原因と、他者の力を借りる必要がある原因」の境界線がチームの限界点です。
なので境界線付近の原因について、チームのTryと他者へのリクエストを決めます。
ここでは、自身へのTryのみならず他者へのリクエストを「SMART Goals」の考え方を活かしてなるべく具体的にすることがポイントです。*3具体的なリクエストであればあるほど、リクエストが受け入れられる可能性が高まるからです。*4
(リクエストの例)
- 悪い例: 開発チームのことを考えてもっと早めに動いて欲しい
- 良い例: スプリント開始前までに、スプリントで必要なPBIのリソースを用意して欲しい
KPTRのやり方
「KPTR」は「Request」の簡易版です。
KPTや類似するYWTなどのアクティビティでの「何をすべきか決定する」フェーズで、上記を参考に、チーム自身のTryに加えて、具体的に他者にリクエストしたいことを決定します。
想定される疑問
「Request」や「KPTR」はこのブログで公開するのでもちろんまだ具体的なリアクションはありませんが、これらのアクティビティに対する想定される疑問についてお応えします。
どうせリクエストが通らないのでは?
このアクティビティを聞いて「リクエストしても、どうせ上司や顧客は聞いてくれないよ......」という疑問が浮かぶかもしれません。
しかし経験的には、他者が拒絶するのは思いつきのような雑な提案や批判です。
このアクティビティでは以下のような工夫を重ねることで、リクエストが実行される可能性をできる限り高めています。
チームの甘えにつながるのでは?
また、このアクティビティを聞いて「チームの甘えにつながるのでは?」という疑問が浮かぶかもしれません。
ですが、このアクティビティはチーム自身をカイゼンさせるよりも、勇気が必要になる場合があると感じます。
個人的な経験からも、それくらい他者へのお願いというのは難しいものです。
お願いは常に、断られたらどうしようという恐怖がつきまといます。なので現実はお願いする代わりに、遠慮や、我慢や、命令や、批判であふれています。「Request」 はチームを甘えさせるものではなく、チームに勇気を持って正々堂々と他者にお願いをすることで、チームの成長と周囲との健全な関係づくりを促すためのアクティビティなのです。
さいごに
今回は顧客先で実験中のふりかえりのアクティビティである「Request」をご紹介しました。
これからはもっともっとふりかえりのアクティビティを作っていきたいと思います!
もしご興味があれば、フィードバックや、自分のチームでも実験していただければ泣いて喜びます!😭
最後までお読みいただき、ありがとうございました!
*1:他のエントリでより詳しく考察しているため、もし良ければお読みください。 norihiko-saito-1219.hatenablog.com
*2:「Request」はLeSS(大規模スクラム)のオーバーオールレトロスペクティブに影響されていますが、1. オーバーオールレトロスペクティブよりも手軽にできること、2. 他者へのリクエストの有無が異なります。 less.works
*3:「SMART Goals」については以下の記事が参考になります。 qiita.com
*4:具体的なリクエスト程実行可能性が高いことについては、NVC(非暴力コミュニケーション)が参考になります。「相手から受け取りたいものがはっきりすればするほど、必要としていることが叶う可能性は高くなる」 www.amazon.co.jp
チームはいつルールを破るべきか? あるいはスクフェス大阪のキーノートを聞いて #scrumosaka
今回はこれまでのスクラムマスターやアジャイルコーチとしての経験から、「チームはいつルールを破るべきか?」について考察していきます。
経験上、チームがルールを破るタイミングは以下3点です。
- ルールの背景にあるコンテキストが、現実と一致しなくなった時
- 破るメリットが、デメリットを上回る時
- ルール遂行が高い負荷を伴う時
- 1. ルールの背景にあるコンテキストが、現実と一致しなくなった時
- 2. 破るメリットが、デメリットを上回る時
- とここまで書いてきて、スクラムフェス大阪の永瀬美穂さんの基調講演を聞きました
- ↑しみったれたこと書いてるなーー自分!! って感じました
- 結局、チームはいつルールを破るべきか?
- おわりに
1. ルールの背景にあるコンテキストが、現実と一致しなくなった時
ルールには、目的や機能する状況などのコンテキストが存在します。
チームがルールを破るべき最初のタイミングは、そのコンテキストが、現実のコンテキストと一致しなくなった時です。
たとえば、「新入社員は出社次第デスクを拭く」という社内ルール。
ルールが制定された際は「新入社員に順応性や規律性を身につけてほしい」という目的があったのかもしれませんが、現在、その企業が新入社員に順応性ではなく自律性や創造性を身につけてほしいと考えているならば、そのルールを遵守することは無意味どころか有害です。
経験上、こうした状況は企業の社内ルールに多く見られます。
企業では問題が発生すると、問題解決のための一時しのぎ的なルールが制定され、その後コンテキストが変わっても盲目的に遵守されることが多いからです。*1
注意: ルールではなく現実が問題だと指摘するルールもある
この時注意すべきなのは、ルールではなく現実の方が問題だと指摘するルールもあること。
たとえば、スクラム。
多くの方がスクラムガイドを読んでまず感じるのは、「ウチには当てはまらない、ウチには無理」ではないでしょうか？
- ビジネス部門と技術部門の協調
- チームだけで出荷可能なソフトウェアを短期間で開発する
などのスクラムのルールを、組織構造や、受託開発という仕事形態などの現実のコンテキスト下で適用するのは難しいとスクラムの全面実施を諦める組織を多く経験してきました。
しかし、自分の解釈では、スクラムとは「そのルールが成り立たない現実こそ変容せよ」と我々に迫るためのフレームワークです。*2
そして現実を変容させる旗振り役は、スクラムマスターと呼ばれます。*3
ですので、現実のコンテキストとそぐわないからとルールを破るのは、時に現状追認やルールの価値を損なう結果もあるので注意が必要です。経験上、スクラムなどの客観的に一定の実績があるルールを、現実では不可能だと投げ捨てる場合はただ単に現状を追認していたり、妥協しているだけという場合が多く見られます。
2. 破るメリットが、デメリットを上回る時
チームがルールを破るべき2つ目のタイミングは「破るメリットが、デメリットを上回る時」です。
注意: ルールを破りたい場合、メリットは明白だが、デメリットは見えていないことが多い
ここでの問題は、ルールを破る場合(作る場合も同じですが)、破りたいメリットが本人にとっては明白でも、デメリットは往々にして全部見えていないことが多いことです。*4
なぜなら、すべてのデメリットを見るためには全体像が見えている必要がありますが、たいていの場合私たちは全体像が見えていないからです。*5
たとえば、自分のスクラムマスター時代の話。
自分は前職でのスクラムマスター時代、チームが成り立てだったということもあり、チームとして仲良くなることを優先し、デイリースクラム(朝会)を60分とって毎朝雑談していました。本来は15分以内で終えなければならないことを漠然と覚えていましたが、「チームが仲良くなる/楽しむ」というメリットのために、深く考えずにそのルールを破っていました。
また、迅速なリリースとチームに与えられた高いKPIを達成するために本来社内でしなければならなかったテストコードやコードレビューを簡略化していきました。
当時、自分が見えていた世界はこんな感じでした。
狙い通り、チームは仲良くなり、チームに与えられた高いKPIを達成しましたが、問題はその後、自分が見えていなかった領域から様々なデメリットが噴出したことです。チームは次第に規律を失い、低品質なコードを量産し、知らず知らずの内に他チームやマネージャーからの信頼を失っていきました。
結果、自分は会社を去りました。
全体像が見えないまま深く考えずに目先のメリットを優先させると、こんな結果が待っているという例です。
↑しみったれたこと書いてるなーー自分!! って感じました
永瀬さんのキーノートで印象に残ったのは、以下。
- スクラムは非秩序系への対応が得意
- ふりかえり等でこれこれのプロブレムがあるのでこういうトライをするとか、そんな単純に分析可能？、そんなに相関関係ってはっきりしてる?
だから、もっと複雑系の世界で、何が影響するとか、予見できないところを目がけて実験を繰り返していこうという話でした。
なぜなら、すべてのデメリットを見るためには全体像が見えている必要がありますが、たいていの場合私たちは全体像が見えていないからです。
と前項で偉そうに書きましたが、全体像とは、無限の属性があり、属性同士が複雑に関連しあい、絶えず変化し続けるシステムです。私たちに見えるわけありません。
パワポで気をつけるべきは「イシューツリー」とか「MECE」的お作法が広がりすぎて、その形で問題を整理して資料化すると、みんなが「分かった気になる」ことかなと。実際は、要素間の依存関係や因果関係はもっと複雑かつ不透明だし、構造もどんどん変化するので、図式化で理解した気になるのが怖い。
— とくさん (@nori76) 2020年6月28日
結局、チームはいつルールを破るべきか?
というわけで最初の問いに戻ると、チームはいつルールを破るべきか? と聞かれたら、「破りたくなったらいつでも!」と答えます。
ルールを破りたいという時は破りたいという理由があるからですし、どんどんやってみましょう。ただし、その際は「実験」として行うのが重要です。つまり、
- 最初に仮説を立てましょう
- 注意深くどんな影響があるかを観察しましょう
- 悪影響(とりわけ他人)が出たら早めに撤退しましょう
「失敗したらどうするか」 だって?
大丈夫、およべさんの口癖を借りればそれは「失敗に成功した」だけのこと。
そもそも長い目で見れば、あれは成功だとか、失敗だったとか言えるわけがないのですよね。
おわりに
今回はチームはいつルールを破るべきか? について考察してきました。
スクラムフェス大阪のキーノートを経て、最初に書きたかったこととまるで違う結論になり、訳のわからないブログになりましたが後悔していません。
永瀬さんのキーノートを聞いて、自分も知らずにいつの間にか守りに入っていたのではないかと考えてしまいました。アラフォーになり、先日娘が誕生し、「盗んだバイクで走り出す」と聞くと盗まれた方にとってはとんだ迷惑だなぁ「夜の校舎 窓ガラスを壊して回った」と聞くと窓ガラスは税金で修理するのだろうかと考えてしまう年齢になりました。けど、尾崎豊がルールを破ったおかげで、当時は誰かが被害に合ったかもしれないけどその何百万倍以上の方を感動させる結果になったのです。ルールを破って良かったかどうかなんて最後まで誰にもわかりません。
フェス、フェス!!
最後までお読みいただき、ありがとうございます!!
*1:ルールではありませんが、LeSS(大規模スクラム)では、問題発生時にその問題に対応するためのマネージャーを増やすことを、ほにゃららマネージャーと揶揄されています。 www.amazon.co.jp
*2:スクラムとは「そのルールが成り立たない現実こそ変容せよ」と我々に問いかけるフレームワークです。ということに関して、こちらのブログが大変参考になります。*2bbbbashiko.hatenadiary.com
*3:長年の組織構造や契約という現実に立ち向かうスクラムマスターは、見かけ以上に遥かに大変な役割です。note.com
*4:「変革による利益と損失は、後者が確実に生ずるものであるのに対し、前者はその可能性があるにすぎない」(マイケル・オークショット)
*5:各人の技能のごとの技能向上を5段階化で示したドレイファスモデルでは、「全体像を持つ」かどうかが4段階目の熟練者になるためのポイントとされています。そして、ほとんどの人がほとんどの技能について3段階目の中級者より上の段階に行くことはないとされています。「複数の研究によると、悲しいことにほとんどの人がほとんどの技能について、人生の大半おいて、第2段階の中級者より上の段階に行くことはなく、「必要な仕事を行い、必要になると新しい仕事を学ぶが、仕事を広範かつ概念的に理解することは決してない」のです。(『リファクタリング ・ウェットウェア』より引用)」 www.amazon.co.jp
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで
はじめに
以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1
Spotifyモデルと取り上げた理由
今回Spotifyモデルの詳しい解説をしませんので、知りたい方は以下の記事を参照していただければ幸いです。
ただし、今回Spotifyモデルを初めて読んだ3人が驚いたのは、「スクワッド」や「ギルド」というキラキラの衣装を取り払うと、驚くべきほどのオーソドックスなマトリクス型組織が浮かび上がることです。日の下に新しきものなし。ただし、これが「スクラム」や「アジャイルマニフェスト」など使い古されたワードに退屈していた方には新鮮に映ったことも同時に想像ができます。
そして、2012年時点でSpotify社自体がSpotifyモデルを既に利用していなかったことも有名です。
にも関わらず今回なぜSpotifyモデルを取り上げたかというと、自分たちが観察するところ、とりわけWeb系企業/事業会社で無自覚にSpotifyモデルと同じような形で組織運営をしている所が多いからです。
つまり、Spotifyモデルとその失敗をおさらいすることは、今でもWeb系企業/事業会社でアジャイル組織運営をされている方の悩みに直結するものが多いと思い、何かの参考になればとブログにまとめました。
モデルの失敗ではなく、ヒトの失敗
まずはじめに、とても重要なポイントは、"Spotify"の失敗とは「Spotifyモデル」の失敗ではなく、Spotify社の中のヒトがSpotifyモデルにうまく適用できなかった、あるいは、ヒトに適さないモデルを適用しようとした、ということが失敗の要因であるということです。*2
Spotifyモデルに限らず、Scrum@ScaleであれLeSSであれSAFeであれ、私たちは問題解決をフレームワークや組織構造に求めがちなところがありますが、実際にフレームワークや組織構造を機能させて問題を解決するのは、あくまで運用するヒトの地道な努力であることを忘れてはなりません。*3
扱える以上の自由や権限を与えた悲劇
さて、前項でSpotify社の中のヒトがSpotifyモデルにうまく適用できなかった、と書きましたが、実際に何が起こったかを一言にまとめると、
「扱える以上の自由や権限を与えた悲劇」
と表現できます。
上記により、Spotifyには様々な悲劇が襲いました。
1. チームへの過剰な権限付与による、サイロ化の加速
2. 自由なプロセスや能力不足による、分隊間協力の困難化
3. 全員での意思決定を追求したことによる、意思決定コストの増大
1. チームへの過剰な権限付与による、サイロ化の加速
Spotifyモデルでの開発チームの単位は分隊(Squads≒スクラムチームみたいなもの)という。分隊とはクロスファンクショナルチームであり、自己組織化されており、それぞれ長期的なミッションを持ち、長い時間プロダクトの一部分を担当するチームのことである。
彼ら自身で自分たちの働き方を決めている。あるチームはスクラムのスプリントを使い、あるチームはカンバンをつかい、あるチームはいろんなアプローチを使っている。
(Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む)
さらに、各分隊毎に「座席やラウンジ、分隊で使える「相談」部屋といったすばらしい職場環境を与えられている。ほとんど全ての壁はホワイトボードとして使える」という充実ぶりだったと言います。
エンジニアだったらうらやましくなる環境ではないでしょうか!?
......しかし、ここからは前職での経験から、まさにこのように各分隊毎に長期的なミッション、働き方を自由に決める権限、そして豊かな職場環境を与えたことが分隊のメンバーの「自分のチームが全てという意識」を加速させたのではと想像します。
さらに紹介記事では、分隊間の依存関係を解決するイベントや、スキルをシェアする支部やギルドの紹介があるのですが、「会社のミッション」の共有についての記述がありません。
会社のミッションの共有が薄いまま、分隊へ長期的なミッションと協力な権限を与える中で、各分隊はまるで一つのスタートアップ企業のように機能していきました。
そして......組織はサイロ化に向かったのです。
2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化
1では、分隊への過剰な権限付与が分隊の部分最適を進ませたのではないかと述べてきましたが、分隊間は協力したくてもできないという事情がありました。前項で「分隊は働き方を自由に決められる」と書きましたが、ここが悪い方向に作用したのです。
Spotifyは、チーム（スクワッド）の横断的なコラボレーションのための共通のプロセスを定義していませんでした。すべてのチームに独自の働き方を認めることは、各チーム同士がコラボレーションを行う際にそれぞれ異なる関わり方が必要になることを意味していました。組織全体の生産性が低下していました。
(Spotifyは "Spotifyモデル "を使っていない)
つまり、各分隊毎に自由なプロセスを定義していったので、お互いにどう協力していいかわからなかったのです。それは全く異なる技術スタックのコンポーネントを連携をさせるような困難さに例えられます。
......共通APIがあればいいじゃないかって？
もちろんそうなのですが、共通APIにあたる「プロセスの問題を効果的に議論するための共通言語」について人々は「それらを解決するための教育、パフォーマンスを評価するための経験を欠いていました」ことがさらに悲劇を加速させました。
コラボレーションは知識と実践を必要とするスキルです。マネジャーは、メンバーがアジャイルプラクティスを良く理解していると思い込んではいけません
(Spotifyは "Spotifyモデル "を使っていない)
ここで自分は、アジャイルの原則についての基礎的な教育の重要性(守破離)や、能力の低い人ほど自らの能力について高い評価を下すという「ダニング＝クルーガー効果」*4を思い出していました。
もちろん、Spotify社のメンバーをディスりたいわけではなく、とても優秀とだ思われるSpotifyのメンバーでさえそうなのです。
独自のコンセプトを試す前に、最初は「守破離」の「守」を徹底的にやるしかないのではないかということを最近は考えています。
3. 全員での意思決定を追求したことによる、意思決定コストの増大
1,2でSpotifyが、自由なコンセプトの分隊がサイロ化した経緯とその感想について語ってきましたが、さらに3では、リーダー不在のまま意思決定権をメンバーに移譲したことによる悲劇について記載します。
分隊には公式に指定されたリーダーががいるわけではない。しかし、プロダクトオーナーは1名いる。プロダクトオーナーはチームによって完了されていく作業の優先順位づけに責任をもっているが、チームがどのように作業するかまでは関与しない。
(Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む)
分隊にはリーダーがいないので、実質はプロダクトオーナーの権限が優先されると思いきや、プロダクトオーナーは「チーム内で意見の相違が生じた」場合、「全てのエンジニア」と交渉し、「エンジニアが合意に達することができなかった」場合、「チームにいるエンジニアの専門分野の数だけ、エンジニアマネージャー（チャプターリード）にエスカレーションする必要」という途轍もない面倒なプロセスを踏まなければなりませんでした。
これもまた「扱える以上の自由や権限を与えた悲劇」の一つ、つまりメンバーの意思決定や合意能力が低い状態で、最終的な意思決定の責任者が不在なまま、メンバーに意思決定権を移譲したために発生した悲劇と考えられます。
まとめ
今回Spotifyモデルとその失敗を読んで強く思ったのは、どんなに良さそうなフレームワークやモデルは組織や人などのコンテキストに応じて適用すべきだ、ということです。
とはいえ、これからも、自律心が高く、権限に与えないと退職してしまうメンバーが多いWeb系企業/事業会社がSpotifyモデルを意図せずに採用する場合が多いと思います。
その際に起こりがちな落とし穴を、ここまで露骨に誠実に描いてくれたJeremiah Leeに本当に感謝です。
他にも様々な学びが満載なので、もし良ければ元のブログの方にも是非あたってみてください!!
今回長くなってしまいましたが、最後までお読みいただき、ありがとうございます!!
*1:前回のScrum@Scaleの記事についてはこちらを参照norihiko-saito-1219.hatenablog.com
*2:問題を安易に組織構造で解決しようとする危険性については、沼上 幹の『組織デザイン』を参照 www.amazon.co.jp
*3:ただし、他の大規模アジャイルフレームワークに比べてSpotifyモデルは適用体験が少ないため、脆弱なフレームワークという感覚があります。例えばLeSSではチーム毎にPOがいることが局所最適化に繋がる危険性が指摘されています scrummaster.jp
*5: 権限移譲については、Management3.0の7つのレベルのデリゲーションやリチャード・ハックマンの権限マトリクスなどが参考になりますwww.ryuzee.comhttps://www.infoq.com/jp/articles/what-are-self-organising-teams/
