チームはいつルールを破るべきか? あるいはスクフェス大阪のキーノートを聞いて #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ガイドからの引用です
未来が見えなくなったとき、僕たちは何を語ればいいのだろう
これを書いている2020年5月26日、全国の緊急事態宣言が解除され、社会がゆっくりと復旧に向かって動き出そうとしています。それ自体はとても素晴らしいことです。
ただ自分のように、
- これまでの社会を元通りにするだけで良いのか? と感じている
- 何かを変えたい
- 誰かと一緒に始めたい
と感じながら、
- どうやれば良いかわからない
- 自信がない
という方も少なからずいるのではないかと感じています。
今回はそんな方に是非オススメしたい、『未来が見えなくなったとき、僕たちは何を語ればいいのだろう ――震災後日本の「コミュニティ再生」への挑戦』という本を取り上げます。
未来が見えなくなったとき、僕たちは何を語ればいいのだろう――震災後日本の「コミュニティ再生」への挑戦
- 作者:ボブ スティルガー,Bob Stilger
- 発売日: 2015/06/02
- メディア: 単行本（ソフトカバー）
本書は、ニュー・ストーリーズ共同代表/社会変革ファシリテーターのボブ・スティルガー氏による、2011年の東日本大震災時における福島県での様々なコミュニティ生成のレポートであり、それを支えた理論やテクニックが紹介された本でもあります。以前このブログでもご紹介した社会変化のためのTwo Loopsモデルも詳しく紹介されています。
norihiko-saito-1219.hatenablog.com
このコロナ禍において、いくつかのささやかなコミュニティ作りをしている自分の経験も交えながら、本書の印象に残った箇所を3つ取り上げます。
1. ないことよりもあるものに焦点を当てる
ボブが繰り返し示してくれる明確な思想がある。それは、ないものに焦点を当てるのではなく、あるものに焦点を当てるということだ。解決策がない、リーダーシップがない、専門家がいない、資金がない、といった視点からは、社会変革は起きない。
社会変革が起きるのは、私たちが自分たちの持っているものに気づいたときである。自分たちには強みがある、仲間がいる、それぞれが持つ知織やがある、そして何よりコミットメントがある。そう自分たちの組織や地域を信じることができたとき、変化は起きる。
著者が本書で繰り返し主張しているメッセージに、「ないことよりもあるものに焦点を当てる」があります。本書では、津波によって漁船や冷凍工場や魚介加工場があらかた破壊された後、船の帆の素材である帆布を利用してハンドバック作りに成功した気仙沼市のエピソードが印象的でした。
以前、自分が作ったコミュニティになかなか人が集まらないと嘆いた際に、あるメンバーから言われた言葉が忘れられません。
「もっとメンバーが欲しいという前に、今ここにいる人を大事にすれば?」
人脈がない、知名度がない、専門的な知識がない......自分はこれまでコミュニティ作りに限らず、ないものに目を向けがちでした。
ただ、これからは「あるもの」に目を向けていきたいと思いました。
2. 悲しみを受け止め、共有する
悲しみを抱きしめること。悲しみは現実であり圧倒的なものだ。知的に処理する必要はない。完全に凌駕されてしまう必要もない。来るに任せる。その中で呼吸する。それに親しむ。悲しみは本当の自分が何者なのかに関し、たくさんのことを教えてくれる。
上記と同様に本書で繰り返し主張されているメッセージに、「悲しみを受け取め、共有する」ことがあります。
私たちは、悲しみや不安から目を背けたり、ムダな感情だと流して前に進もうとしがちです。
「悲しみはとりあえず置いて、前に進もう」と。
このコロナ禍でも「私には影響なかった」「悲しみはとりあえず置いて、前に進もう」いう方が多いかもしれません。
ただ、そのような方でも悲しみや不安は必ずあると感じています。
それらを表現し、共有することが未来を創るコミュニティ作りではとりわけ重要と著者は語ります。
なぜなら、悲しみや不安は、私たちが大切にしていることを教えてくれる、とても重要な徴しでもあるからです。
3. "あなた"が始める
もし僕がしないなら、誰がするのか？僕が確信と勇気を持たず、言葉を紡がずにいたら、誰がするのか？この物語を織りなすすべての人たちとともに、僕もまた立ち上がらなければならない。
「外人」である著者が、日本のコミュニティの復興について書いても良いのかどうか怖れますが、最終的には意を決して書き始めます。
そして、本書では、ごく普通の人たちがコミュニティを立ち上げ、周りを巻き込んでいく様子が多く描かれています。
誰かと一緒に未来を創りたい、とあなたが思ったら、恐れることはありません。
あなたが始めれば良いのです。
おわりに
今回は、『未来が見えなくなったとき、僕たちは何を語ればいいのだろう ――震災後日本の「コミュニティ再生」への挑戦』という本から、これからコミュニティを始めたい方にとって役に立ちそうなアイディアを取り上げました。
本書は東日本大震災の経験が描かれた本ですが、東日本大震災が福島県をはじめとする一部地域に大きな被害をもたらしたのに対し、今回のコロナ禍は日本全体に被害をもたらしています。自分の周りでも、Code for Japan のように何かを変えたいとコミュニティを作っている方が増えてきていますし、自分でも作りたいと思っている方も大勢いるのではとも感じています。僕もそんな一人です。
その際、外国人でありながら東日本大震災下で福島で様々なコミュニティを形成していった著者の経験がとても活かせるのではないか、今こそ読む本ではないかと思い今回ご紹介してみました。個人的には関心がある「U理論」の実践例としても、とても興味深く読みました。
自分もコミュニティ作りに四苦八苦していますが、コミュニティのほとんどはうまくいかなくて当たり前だと著者は言います。それでも幸いなことに、現在は東日本大震災時と異なりオンラインツールが発達し、誰でも気軽にオンラインコミュニティが作れるようにはなりました。本書を読んでからは、いろいろなことを気楽に、試していければいいなーと最近は感じています。
人々は新しいことを試し、成果を見つけていく。試すことのほとんどはうまくいかないことを頭に入れておこう。それでも試みを続ける。何かが必要なことはわかっている。公式にあるいは非公式に互いにつながって、互いに学び合おう。行動する。止まる。吟味する。振り返る。学ぶ。そして再び行動する。
スクラムチームの学習/スキトラ方法4選
スクラムをやっていてチームでの学習やメンバー間のスキルトランスファー(以下スキトラ)に苦戦されている方は多いのではないでしょうか? かく言う自分も支援先でモブプロはしてもらっているものの、それ以外の手段でどうやって学習やスキトラを促進するかにいつも頭を悩ませています。
というわけで、「モブプロ以外のチーム学習やスキトラ、どうしていますか?」ということを先日5月15日に開催された「スクラムと大規模スクラム(LeSS)の探究 Lean Coffee 編」の参加者に伺ったところ、とても良いアイディアをいただいたのでここにご紹介します。
学習
学習をプロダクトバックログアイテムとして管理する
チームとして学習をしているチームは多いですが、学習をプロダクトバックログとして管理しているチームは少ないかもしれません。実施された方によれば、完了の定義(DoD)や受入条件を決めることで学習範囲や効果が明確化されたり、さらにチームとしての学習のベロシティが見えたという複数の効果があったとのこと。なるほどー!
自分たちでテーマを決め、毎朝30分勉強会をする
学習といえば定番の勉強会ですが、なかなか持続しないのも事実。
「みなさんが興味ないテーマの時にも参加していますか?」と尋ねた所、自分たちで挙げたテーマから投票で決めているため参加者のモチベーションが高く続けられているとのこと。また、毎朝30分ずつというのもみんなが続けやすくするための工夫だそうです。
スキトラ
バグ対応をSlackのスレッドに記録する
あるチームでは知識(=物事を知っていること)と技能(=物事が実際に行えること)を意識してスキトラしていました。そのチームでは"バグの解決"という技能をスキトラするために、バグ発生時は対応者にSlackのスレッドへ対応内容を逐一記録してもらったそう。"何のスキル"を伝えたいのかを明確化し、それに応じた対応をしていることがとても勉強になりました。
新人ほど人に説明する機会を作る
6人から新人6人が増え一気に12人のチームになった際の、新人へのスキトラ事例を教えていただきました。
こちらのチームではまず、既存メンバーと新人とでペアを組みスプリントプランニングをしてもらったそうです。さらに、新人に知識を定着させるために、新人がプランニング内容を他メンバーに説明するというルールがあるのが面白いと感じました。人に説明することは学習効果が高いため、何かを学習したい際は説明する機会を積極的に作ると効率が高そうです。
まとめ
今回は、モブプロ以外のチーム学習やスキトラついての教えていただいた方法をご紹介しました。早速現場でも提案していきたいなー! そしてもちろんこれだけではないと思うため、皆様が実施している工夫があれば是非教えていただければ幸いです!
そして、素晴らしいイベントを企画してくださったOdd-e Japan様、ありがとうございました!!
頑張っても報われないスクラムマスターへ
会社のblogに「頑張っても報われないスクラムマスターへ」という記事を書きました、
よろしければお読みくださいませ!!
