未来が見えなくなったとき、僕たちは何を語ればいいのだろう
これを書いている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に「頑張っても報われないスクラムマスターへ」という記事を書きました、
よろしければお読みくださいませ!!
アフターコロナまたはTwo Loopsモデルによる古いシステムの終焉 #distributed_agile_team
先日、5月5日に開催された「第2回分散アジャイルチームについて考える会」で久々にLTしました。
私達は現在外出が制限されているので時間があり、ZoomやDiscordなど他人とつながるためのツールも溢れている。そんな中、誰かが始めたコミュニティに参加するのも素晴らしいけど、自分自身の関心からコミュニティを作ることはもっと素晴らしいという趣旨でした。
感動したのは、実際に参加者がその会でとあるオンラインコミュニティを立ち上げたことです。
自分の言葉が誰か一人にでも届いたのが嬉しかった。
さて、その後、ふとしたきっかけで社会変化のためのTwo Loopsモデルを知りました。
Two Loopsモデルとは、どのように古いシステムから新しい社会システムが生まれるかを現すMargaret Wheatleyとthe Berkana Instituteによるシンプルなモデルです。
そこでも鍵を握るのがコミュニティです。
自分なりに整理するとTwo Loopsモデルとは、以下のようなモデルです。
- 古いシステムがピークを過ぎ衰退期を迎えると、そこから抜け出す人が出てくる
- 抜け出した人は、はじめは一人で、新しいシステムを作る
- 抜け出した人同士がつながり、コミュニティを作る
- コミュニティ同士がつながり、実践コミュニティを形成する
- 最終的に古いシステムが新しいシステムに置き換わる
システムを内部から変えることはできません。システムを変えるのはシステムの外側にあるコミュニティ同士の連携によるネットワーク効果です。
現在、無数のコミュニティが静かに生まれているのを感じます。
アフターコロナの世界を変えるのは、あなたが何気なく友人と始めたコミュニティかもしれません。
派遣/フリーランス中心でも良い感じにチームビルディングする方法
はじめに、アジャイルにおけるチームビルディングの重要性
マサチューセッツ工科大学のダニエル･キム教授が提唱した「組織の成功循環モデル」という考え方があります。上手くいっている組織は最初にメンバーの信頼関係や相互理解などのメンバーの「関係の質」を高め、結果グッドサイクルが発生し「結果の質」向上に結びつく。という理論です。
また、ジェームス・コプリエンによる『組織パターン』では、全てのパターン言語の起点に「信頼で結ばれた共同体」パターンがあるとし、どんなテクニックを適用しようとしても、最初に信頼関係を構築しなかったら無意味だということが示唆されています。
ですので、もしアジャイルを組織に導入する際にまず何をすべきか? と聞かれたら、私は「チームビルディング」と答えます。一見遠回りに思えるかもしれませんが、チームの相互認識や信頼関係を向上させないままスプリントを開始することは、基礎工事をしないまま高層ビルを建設するようなものです。
そしてチームビルディングが圧倒的にうまく行くのは自社メンバーだけで構成されたチームです。
他社/フリーランス中心チームのチームビルディング
しかし、実際は、経営戦略やエンジニア不足から、自社だけでエンジニアをまかなえず他社またはフリーランスメンバー中心の開発チームになることが多いですし、今後はさらにこのような形態のチームが国籍含め増えていくでしょう。
そして、このような場合、チームが成立するまでに到らず、いわゆる寄せ集めのまま終わってしまうケースが多いのも現実です。
なぜならチームとは「共通の目的のために集まった人物の集合(Wikipediaより)」。にも関わらず、自社メンバーの目的は「自社プロダクトの成功」に対し、自社以外のメンバーの目的は「より高い単価や増員」などと両者の目的が根本的に異なるからです。加えて、チーム内に顧客-受託企業などの階層構造が持ち込まれることも、一致団結することをさらに困難にします。
もちろん、両者の立場による目的のズレを完全に埋めることはできません。
しかし、このようなケースでも目的のズレを調整し寄せ集めからチームになることは決して不可能ではありません。
今回は私がこれまで実施してきた方法と一言解説をお伝えします。
目的の共有
- インセプションデッキ
スキル/価値観/プライベートの共有、「お互いを知る機会」作り
- スキルマップ
- ドラッカー風エクササイズ
- wevox values card
- 雑談
- チームランチ、飲みニケーション
プロダクトの価値やビジョン、POの情熱の共有
- プロダクトへの価値、情熱を共有する
- ユーザー/利用シーンに参加してもらう
組織が支援できること
- 一括請負型契約ではなく準委任型契約にする
- できるだけ会社の教育/福利厚生に参加できるようにする
- チームビルディングに投資する
解説
目的の共有
繰り返しになりますが、チームとは「共通の目的のために集まった人物の集合」です。なのでチームになるためには目的を統一させるのが先決です。そのためにはインセプションデッキなどで、プロジェクトのゴールや目的をしっかりと把握する必要があります。
スキル/価値観/プライベートの共有、「お互いを知る機会」作り
チームの目的を把握したら、次はお互いを知ることが重要です。
複数の立場が混ざったチームビルディングのポイントは、できるだけ立場や役割を超えた一人の人間としてお互いに接すること。スキルだけをシェアするよりも、ドラッカー風エクササイズなどでお互いの期待や価値観をシェアすることをオススメします。また、そのために業務とは関係ない雑談を積極的に取り入れてきました。
プロダクトの価値やビジョン、POの情熱の共有
いくらチームの目的がはっきりし、お互いを知ったところで、肝心のプロダクトビジョンがショボかったら元も子もありません。POは是非プロダクトの価値やビジョンを情熱を持って正面からメンバーに伝えてください。もしも情熱がなくてもあるフリをするのがPOの重要な仕事です。
また、経験上ユーザーインタビューや利用シーンを見学してもらうこともとても効果的でした。実際にプロダクトを求め、利用するユーザーの声を聞くことは、エンジニアにとって大きな励みになります。
組織が支援できること
チームはチームビルディングを頑張っていても、組織はそれに無関心または冷ややかに見つめている現場をよく見かけます。しかし、チームビルディングは組織の支援なしには不可能といっても過言ではありません。たとえば契約。一括請負契約で受託企業にリスクを押しつければ、どんなにチームビルディングを頑張っても次第次第にメンバーが契約によって身動き取れなくなる現場を見てきました。また、困難かもしれませんが、トレーニングやランチなどの福利厚生を自社以外のメンバーに適用することも是非ご検討ください。チームビルディングはアジャイルの要ですが、効果が得られるまで忍耐が必要な投資だと認識してください。
スプリントゴールの効果
私は支援の際、スクラムが健全に機能してるかどうかを示す指標の一つとしてチームがスプリントゴールを設定しているかどうかを見ています。実際、スプリントゴールを設定していないチームは多いです。以前とあるチームに何回かスプリントゴールを設定するよう促しましたが、最後までチームはスプリントゴールを設定することはありませんでした。そこで今回は、今までの経験から、スプリントゴールを設定しないチームの特徴やスプリントゴールの効果について説明します。
スプリントゴールを設定しないチームの特徴
経験上、スプリントゴールを設定しないスクラムチームには共通点があります。
それは、開発チームが「下請け扱いされている」または「ビジネスに関心が薄い」ことです。
具体的には開発チームがPOの下請け扱いされている組織(とそれと似た力関係の組織)、POやUXデザイナー等が詳細な仕様やデザインを決定してしまう組織、またはビジネスに関心が薄い開発チーム、スクラムを始めたばかりの開発チームに多い現象です。
スプリントゴールとは文字通りスプリントで達成したいゴールですが、上記組織での多くの開発チームは「ビジネスゴールの実現ではなく、あらかじめ決定された具体的な機能を実現すること」が求められます。そのため、スクラムチーム全体で抽象的なスプリントゴールを設定する意味が薄く、具体的なバックログリストがスプリントゴールの代わりとして利用されます。
とはいえ、スプリントゴールの欠如はやがて大きな問題につながると筆者は見ています。
スプリントゴールがないことによる問題
スプリントゴールとは、スプリントの目的です。
スプリントゴールとは、チームが一致団結して作業するための旗印です。
スプリントゴールの欠如は、3つの問題を開発チームにもたらし、次第に組織全体にダメージを与えます。
1つ目は、ゴールではなく具体的なバックログのみが与えられた開発チームは「ゴール実現のためにより良い手段はないか」という視点から創意工夫や提案することが必要ないため、自律性や思考力が育たないことです。
2つ目は、ゴールがないと「スプリントでこのバックログを実現しなくてはならない理由」が開発チームがわからないため、次第にモチベーションを失っていくことです。人は作業に意味と目的と求める生き物です。
3つ目は、ゴールは共通の判断基準として機能するため、ないと細かい調整や判断に時間がかかり、やがて集中力が途切れてしまうことです。
では、スプリントゴールを設定するとどのような効果があるのでしょうか？
スプリントゴールの効果
例えば、あるチームでは「できるだけ速く様々なビジネスアイディアをユーザーテストしたい」というスプリントゴールを設定した結果、チーム全員が自動的に下記の共通認識を持てました。
- プロダクションコードを修正しなくてよい
- デザインを凝らなくてよい
- 速さ重視のため、既存プロダクトを積極的に利用しなければならない
- チーム全員で様々なアイディアを出さなければならない
- ユーザーテストをするため、カスタマーサポート部と連携しなければならない
スクラムチーム全体でスプリントゴールを共有することで、何をすべきで何をすべきではないかという判断基準が明確になり、意思決定や調整がどんどん素早くなっていきました。
さらに、チームが向かうべき共通のゴールがあることで、自分のスキル外のタスクを実施し、助け合うカルチャーが生まれるきっかけとなります。
組織を変えるとはマインドセットを変えること。初めての #RSGT2020 参加レポート
会社 (Graat | Growth Architectures & Teams, Inc - Graat（グラーツ）) のブログに Regional Scrum Gathering Tokyo 2020 の参加レポートを書きました、よろしければお読みくださいませ〜!
