アジャイルコーチが見た、上司を説得するための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/
NVCとManagement3.0と『インサイドヘッド』と私と
今年1月から、NVC(非暴力コミュニケーション/共感的コミュニケーション)の勉強会を企画し、現在は有志が集まり定期的に 『NVC 人と人との関係にいのちを吹き込む法』の読書会をしています。
この勉強会の特徴は、エンジニア、アジャイルコーチ、アーキテクトといった自分と近い立場の方から、産業カウンセラー/鍼灸師や占い師さんに至るまで様々なコンテキストの方が参加し、それぞれの専門分野や経験から毎回様々な意見が飛び出すこと。
とはいえ、読書会ではディープなプライベートなことを話しまくっているので、これまで会の参加レポートは書きませんでしたが、個人的に様々な参加者から紹介された知識や理論を毎回忘れてしまうのはあまりに惜しいと思い、そこだけをブログに残していければなーと思い書きました。
今回は、「第4章 感情を見極め、表現する」を取り上げました。
Management 3.0のフィードバックラップ
参加者から、NVCの観察、感情、ニーズ、リクエストの4ステップは、建設的なフィードバックを実施するためのManagement3.0のフィードバックラップというプラクティスに似ているのではという指摘がありました。
確かにめちゃ似ているー!
- フィードバックラップの5つのルール
- コンテキストを伝える
- 観察したことを挙げる
- 感情を伝える
- 価値を説明する
- いくつかの提案をする
『問いかける技術』(エドガー・シャイン)
じつはわたしはビクビクしているんだ。でもそれは、きみたちが黒人だからではない。わたしがビクビクしているのは、ここには誰も知り合いがいないし、きみたちに受け入れてもらいたかったからなんだ」。自分の弱さを打ち明けたことで、生徒の様子ががらりと変わった。彼らはわたしについて次々に質問を始め、自分のことを語り、ＮＶＣへの興味を表現しはじめたのだ
マーシャルが都市部のスラム街の生徒たちにNVCを教えたエピソードからの引用です。
この章では自分の感情、とりわけ弱さを表現することの重要性が指摘され「自分の弱さを打ち明けることで、対立を解決できる可能性がある」と書かれていますが、この主張は以前ブログでも取り上げたエドガー・シャインの『問いかける技術』と共通していると感じました。
TMS理論
今回、感情の身体性について議論しましたが、そんな中、参加者がご紹介くださった理論。
1984年にニューヨーク大学医学部教授のジョン・Ｅ・サーノ博士が発表した理論で、(私なりに超要約すると)感情的な「怒り」が血管を収束させた結果、腰痛などの「痛み」を引き起こす、という理論です。
※詳しくは以下を参照してください
インサイド・ヘッド/脳内ポイズンベリー
まだあまり日本では浸透していませんが、NVCと一緒によく紹介される理論に、「内的家族システム療法(Internal Family Systems Model)」があります。
「人の心は様々なパーツから成り立っていて、そのパーツ同士が家族のように相互に影響しあって、人の心を作っているという前提に基づく心理療法」という私が知っている内的家族システム療法の概要を参加者にお伝えすると、映画の『インサイド・ヘッド』や『脳内ポイズンベリー』に似ているのでは、という意見が出ました。
気になって調べると、『インサイド・ヘッド』のストーリーは内的家族システム療法をベースにしているのではという指摘がいくつかのブログから見つかったので、あながち的外れな連想ではないのかも。
私もまだIFSについては全くわかっていませんが、まだご覧になっていない方は『インサイド・ヘッド』、難しいことを抜きにして超オススメです。
泣けるよ......
- 発売日: 2015/09/25
- メディア: Prime Video
Maybe that’s because the story line of Inside Out is based on the Internal Family Systems Model (IFS), developed by Dr. Richard Schwartz.
Loosely based on the Internal Family Systems model developed by Dr. Richard Schwartz,
めっちゃ美しいけど危険な刃: Scrum@Scaleガイドを読んで
はじめに
最近は、アジャイルに造詣が深い若手2人( @tyantya41717651さん、@zakky_devさん )とアジャイルのトピックについて定期的にディスカッションさせていただいています。 そしてそれが個人的には楽しく、かつめちゃめちゃ為になる時間になっています。
先日、大規模アジャイル手法の一つであるScrum@Scaleについてディスカッションしたので、内容を残したいと思い、今回ブログにすることにしました。
今回Scrum@Scaleについて詳しく説明しないため、知りたい方はガイドか素晴らしい要約スライドをお読みください。*1
エグゼクティブ・アクション・チーム(EAT)について
エグゼクティブ・アクション・チーム(以下EAT)とは、アジャイル組織全体のスクラムマスターに例えられる存在です。具体的にはアジャイル組織移行にあたってのリファレンスモデルとなるチームを作成したり、組織や複数チーム間の問題を文字通り食べてしまう(EAT)ことが役割です。リファレンスモデルの維持や組織的な問題解決にはある程度の権限が必要なため、実質的には経営層中心で構成されるチームと考えられます。面白いのはEATは組織変容バックログを実現するためのスクラムチームとしてスクラムで運用されることです。
これは、エグゼクティブ・アクション・チーム(EAT)による作成が最善の達成方法である。
エグゼクティブ・アクション・チーム(EAT)は、変革戦略の策定と実行の責務があるためだ。
EATは、リファレンスモデルの存続を保証するために政治的、財政的に権限を与えられた個々人で構成されなければならない。チームのこのセットは、アジリティを阻害する組織的な問題を通じて働き、組織横断的なスクラムをスケールするためのパターンとして使われうるリファレンスモデルを作成する。
ディスカッションでの意見
- マネージャーや経営層の役割はスクラムガイドで規程されていないため、アジャイルをスケール化する際にこうしたチームが必要なのでは?
- (むしろスクラムが現実の組織を無視したイデア界の純粋概念ともいえる)
- 「必要最低限の官僚制」(Minimum Viable Bureaucracy)というコンセプトは面白い
- 名前的にトップダウンぽくて、むやみに反発を呼びそうな感
- 組織のスクラムの品質、アジリティの最終責任チームという印象
- 要するにマネージャー陣の集まりか?
- 実際の大手企業の実態に即しているのかも
- エグゼクティブという名前は、経営陣が喜んで入るための工夫では?
- (EAT頼りになり)EAT以下のチームの自律性や改善意欲の低下を招いてしまわないかが心配
HowとWhatの責任やプロセスの明確化について
スクラムでは、"How"と"What"の責任の分離に注意する必要がある。
Scrum@Scaleでも同様に、チームの最適な生産性を達成を邪魔する、無駄な
組織上の衝突を取り除くために、権限と責務を明確に理解し、注意する必要がある。
Scrum@Scaleでは、これまでスクラムガイドで詳細化されてこなかったプロダクトオーナーがビジョンからプロダクトバックログを作成し順位付けするプロセスがプロダクトオーナーサイクルとして明確化されている。それを担うのはアジャイル組織全体のプロダクトオーナーに例えられるメタスクラムというチームです。メタスクラムもEATと同じく一つのスクラムチームとしてスクラムで運用されます。
プロダクトオーナーサイクル
ディスカッションでの意見
個人的にはScrum@Scaleの最大の特徴はこのHowとWhatの責任やプロセスの分離にあると感じました。ここが一番ディスカッションでも盛り上がった部分です。
- 企画(What)と開発(How)を分離すると縦割り意識や受け渡しのムダが促進され、組織全体のパフォーマンスがかえって落ちるのでは?
- いきなり最初から全員アジャイルを導入してもうまくいかない、小さい型をちゃんと入れて、徐々に生まれていく。組織レベルでは最初の1歩として分離があるのは悪くないのでは?(もちろん成長していくにつれ境界がなくなるのは望ましい)
- 分離が問題と言っているが、そもそもスクラムも最初から分離している
- ただその分離を拡大してしまっていることが問題では
- 理想は全社員に経営状況が開示されていて、全員野球で仕事すること
- プロダクトオーナーサイクルもスクラムマスターサイクルもそれぞれのスキルが高度化しているため、全員野球で一緒に仕事することはできるのか? デザイナーが開発者の仕事できるのか?(逆も然り)
- そのあたりはデュアルトラックアジャイルで補完されている?(よくわからない)
フラクタル構造の美しさと、スケールフリーネットワークについて
Scrum@Scaleで印象的なのは、その構造の美しさとその構造からもたらされるスケールフリーネットワークです。
構造の美しさとは、「一部が全体と自己相似な構造を持っている」フラクタル構造があちこち見られること。たとえば、Scale@Scaleは全体としてスクラムチームとして機能しますが、その各構成チーム、たとえばEATやメタスクラムもスクラムチームです。そしてEATやスクラムオブスクラムを結節点にして、理論上は無限に各チームを追加することができます。このようにソフトウェアアーキテクチャのように組織を捉え、チームをコンポーネントのように追加していく発想は自分にはとても新鮮に映りました。
全体的な意見
その他、Scrum@Scale全体に対する意見です。
個人的には、「書かなくとも大企業ってこんな感じじゃねーの」には少し笑ってしまいました。
- 「スクラムガイドでは最適なチームサイズを3人から9人と定義しているが、ハーバードの調査では最適なチームサイズは4.6人であると判断されている。」とあって共感
- 小さいセットチームから作るって考え方には共感。いきなり複数チームは経験上うまくいかない気がする
- 書かなくとも大企業ってこんな感じじゃねーの
- EATは経営層がスクラムを理解するのに良い仕組みでは?
- 導入者の力量が問われる
- 大規模アジャイルの導入の足掛かりとして導入するのは良いが、ガイドをそのまま導入すると末端のチームは単なる部品となるリスクが高い
- 構造を変えるだけでは、現実のふるまいは変わらない
- LeSSでいうオーバーレトロスペクティブのような横断的なレトロスペクティブはあるのか?
- 企画と開発が分離されて縦割り組織になったり、フラクタル組織がピラミッド組織に堕落するリスクの指摘やリスクを軽減するプラクティスが見当たらない
- 導入はScrum.Incのコンサルティングが前提になっているのかな
さいごに、自分の印象
今回、Scrum@Scaleガイドを読んで、Scrum@Scaleへの全体的な印象は、"めっちゃ美しいけど危険な刃"です。
フラクタル構造やスケールフリーネットワーク性などの数学的な構造はとても美しくエンジニアとしてもとても惹かれるものがありますが、その分刃がめちゃめちゃ鋭く、素人が使うとあっという間に組織を傷だらけにさせてしまう印象です。現時点では、組織単独で導入するのは難しく、Scrum.Incなどの支援が必須と感じました。ただし、組織変革やプロダクトオーナーの仕事をスクラムで運用するというアイディアは使えるかも。日本での導入事例があまりないため、海外での導入事例も是非知りたいと思いました!
*1:文中の図やテキストは全てScrum@Scaleガイドからの引用です
