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に「頑張っても報われないスクラムマスターへ」という記事を書きました、
よろしければお読みくださいませ!!
アフターコロナまたは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の重要な仕事です。
また、経験上ユーザーインタビューや利用シーンを見学してもらうこともとても効果的でした。実際にプロダクトを求め、利用するユーザーの声を聞くことは、エンジニアにとって大きな励みになります。
組織が支援できること
チームはチームビルディングを頑張っていても、組織はそれに無関心または冷ややかに見つめている現場をよく見かけます。しかし、チームビルディングは組織の支援なしには不可能といっても過言ではありません。たとえば契約。一括請負契約で受託企業にリスクを押しつければ、どんなにチームビルディングを頑張っても次第次第にメンバーが契約によって身動き取れなくなる現場を見てきました。また、困難かもしれませんが、トレーニングやランチなどの福利厚生を自社以外のメンバーに適用することも是非ご検討ください。チームビルディングはアジャイルの要ですが、効果が得られるまで忍耐が必要な投資だと認識してください。
