チームビルディング合宿をやってみた話

この記事はProduct Manager Advent Calendar 2016の21日目の記事です。

SkyWayのプロダクトマネージャーをしている@mizuman_です。
※この発言は個人の見解であr(ry

ふとアドベントカレンダーを覗いたら、明日（というか今日）の枠が空いていたので先日行ったチームビルディング合宿について書いてみます。

1行にまとめると、「心理的安全性を高めて、議論が活発になるチームビルディング」です。

• 新しいチームをこれから作ろうとしている方
• リモートワーク中心のチームの方
• チーム内で意見を出す人（声の大きい人）に偏りが出てきたと感じる方
• KAIZENのネタが小さなものばかりになってきたと感じる方

の参考になれば嬉しいです。

前編は無駄に長いポエムです。
何をして、どんな結果だったのかを知りたい方は後編へどうぞ。

この後、プロダクトマネージャーって毎回書くのが面倒なので、PdMと略します。
PMってPjMかPdMかPgMかわかんなくなりますよね…

どうでもいいけど、阿佐ヶ谷の古民家でやってきましたが、最高でした。

前編：なぜチームビルディング合宿？

プロダクトマネージャー(PdM)の役割

そもそもチームビルディングってPdMの役割なの？って思う方もいるかもしれません。

組織によってPdMの役割って全然違うと思うのですが、「価値を明確にする」という軸があって、「チームの共感と信頼を得る」ための＋αがあり、その＋αとチームの状況によって役割って変わっていくんだろうなと思ってます。

サポート出身だと＋αは顧客の理解だったり、開発出身ならエンジニアリングだったり、センスや経験値など様々ですが、私の＋αはマーケティングで、チームマネジメントも伸ばしていきたいと思っています。

そのため、私のPdMとしての役割はチームが提供する価値を明確にし、チームの共感と信頼を得て、チームが効果的に機能するようにすることだと定義してます。

PdMはプロダクトを成功させる全責任がありますが、権限はないロールです。
プロダクトの成功という成果によって評価されるべきですが、＋αによって得る信頼がなければ良いプロダクトが生まれることはありません。

きっかけはサービスや組織について語り合いたかった

PdMをしていると、「この仕様はPdMに確認しましょう」っていうのがたくさん出てきて、DevOpsやDevRelのメンバーってどうしたいだっけっていうのがどんどん見えなくなってきます。

もうとにかくメンバーとサービスや組織について語り合いたい！
どんなお客さんに価値を届け、どんな変化を起こしたいのか話したい！
incrementsさんの「全社合宿に行ってきました」みたいに、組織やサービスのVisionやOKRをみんなで議論しながら考えたい！
と思い、チームビルディング合宿を考え始めたのですが、やってみると実はもっとたくさんの課題が眠っていました。

余談ですが、普段からハッカソンおじさんをしている立場を利用し、次の合宿のテーマはチームビルディングですって言っても、みんな何も聞かずにOKしてくれました。
プロダクトマネージャーにとって、こういう信頼貯金も大事ですよね

良いプロダクトは、良いチームから生まれる

効果的に機能する良いチームの土台は「お互いを理解し、尊重し、思いを話せるチーム（＝心理的安全性が高く、活発に意見が交換されるチーム）」だと思っています。
私達はリモートワーク中心のチームだということもあり、非同期でのコミュニケーションによる必要最低限な情報のやりとりに偏りがちで、雑談などによる価値観の共有やアンビエントな情報といったものがどうしても少なくなっていました。

そのため、オフラインでのチームビルディング合宿によって、それぞれの価値観や考え方を共有することで、行動や発言の意図をバックグラウンドから汲み取ったり、違いを意識して的確に伝えられるようにしたいというのがメインの目的となっていきました。

もし、みなさんのチームでも以下のような傾向が出てきていたら、是非後編も読んでみてください

• 雑談がしづらい雰囲気で気兼ねしてしまう
  • すぐそこにいるのにslackで声をかけちゃう
• チームの雰囲気はいいけど、パーソナリティや価値観、夢がわからない
• 会議などで声の大きい人ばかり話している
  • （私のことです。すみません）
• KAIZEN MTGをしても、大きなTryが出てこない
• 判断待ちや指示待ちが多くなる
• PJの外への影響を考慮しなくなる
  • PJ間やチーム間の情報流通が1人に依存している
  • PJ外やPJ間の球拾いや雪かき（サポートとか）を同じ人がいつもやっている
• メンバー構成が変わっても、ミッション・ステートメントや行動指針を見直していない

良いチームって何？って思った方は、@jitsuzonさんが7日目としてチームの良さを確認するためにやったことをまとめられていますので、是非御覧ください。

後編：チームビルディング合宿で何をやったか

さらっと書きたかったのに、めちゃくちゃ長くなっちゃいました。
ここからは淡々と書いていきます。
気になるところはコメントいただければ、詳細を書きます。

環境やタイムライン

阿佐ヶ谷の古民家asagoroをお借りしての、1dayチームビルディング合宿です。
ちょっと駅から遠いですが、古民家の雰囲気は最高です。

時短勤務のメンバーもいるため、11時〜14時がチームビルディングのコアタイム、14時〜18時はアンカンファレンスです。

性格診断

ネタかな？もしくはアイスブレイク？と思った方もいるかもしれませんが大真面目に性格診断を実施しました。
利用したのは、Myers-Briggs psychological typeをベースとした16Personalitiesです。

事前に参加者には診断を実施してもらい、マッピングしておいたものをスクリーンに表示しながら、「外向型と内向型」、「思考型と感情型」などそれぞれのコミュニケーション方法の違いや気をつけるポイントを合宿の最初に説明しました。
「私とAさんはこんな違いがあり、これに気をつける必要がある」と話すと理解しやすいです。

これにより、考え方やコミュニケーション方法の違いを意識して、チームビルディング合宿に臨んでもらいました。
もちろん、キャッチーで誰でもネタにしやすいのでアイスブレイクの効果もあります。

事後のKPTでも、性格診断は「自己分析に役立った」と好評で、合宿以降、違いに配慮した取組が盛んに行われるようになりました。
例えば、話しながら考える外向型の人は、しっかり考えてから話す内向型の人に対して意見を聞き出そうと時間を始めから確保したり、考えを引き出そうとし、内向型の人は意見を素早く書き出して、積極的に話すようになりました。

ちなみに私はESTJ型の幹部タイプで、声が大きく（考えながら話し）、自分が正しいと信じているため、人の話を意識して聞き、自分の間違いを認めることを意識する必要があります。
（この記事も、書きながら考えてます。。。）
これを意識して改善したら、チームビルディングをしなくても前編で書いた課題のほとんどは改善するんじゃないかなと思っていたのは内緒です。
あと、この診断結果は、時間やその人のロールが変わると結果が変わったりします。
私も、1年前は「5年後の全社の技術戦略策定」みたいな未来を考える仕事をしていたため、ENTP型で柔軟な未来思考でしたし、今はPdMとして現実の情報を基に判断すること必要があるためESTJ型にシフトしています

アンケート

事前にアンケートをgoogle presentationで実施しました。

「作るのが楽しいか、使ってもらうのが楽しいか」みたいなお題を誰でも作れるようにして、事前に自分のアイコンをマッピングして回答してもらうことにしました。

• Pros
  • 合宿当日の時間を有効活用できる
    • 時短メンバーもいるため、コアタイムは3,4時間
  • じっくりと考えて回答したい人が考える時間を取れる
  • 各自の価値観が可視化され、違いを客観的に認識しやすかった
  • 合宿に行く前からディスカッションが始まり、関心が高まっていった
  • 当日、なぜそこに配置したのかという話をしながら、各自が位置を調整したりできた
• Cons
  • お題を複数人でいじくったため、意図や条件がわかりづらいお題があった
  • 事前準備/回答に稼働がかかる
  • 意思表示のコストが高い人は、話すよりも負荷が高かったかもしれない
  • 価値観や違いが重要で、プライベートな情報を開示することが心理的安全性に繋がるわけではないことに注意

事後のKPTでは、「各自のスタンス/考え方が知れてよかった」と好評でした。
また、KAIZEN MTGはHowの話をする場であり、合宿によりWhy/Valueの重要性に気づいたという声もありました。

チームの行動指針として、（大企業的作法への反発もあり）MTGは最小限に押さえて、集中してフロー状態に入ることが推奨されていましたが、実はみんな行動指針に遠慮しているだけで心の中では雑談やMTGの質を高めたいと思っていたことが明らかになりました。
これにより、合宿後には明らかに雑談や突発的なスタンドアップミーティングのような場が増えており、チームを越えたコミュニケーションが円滑に回り始めています。

アンカンファレンス

もっと、クリティカルで、具体的な話題を扱う場として用意しました。
事前にお題を募集しましたが、当日になって話したいテーマが増え、非常に密度の高いディスカッションとなりました。

実際に話した内容は内緒ですが、「○○リリース時に起こったミスの真因は何か」とか「DevチームとBizチームでお互いに不満に思っていること」とかのような普段は話しづらい話題を積極的に選択し、合宿中だからこそできる「相手にダメージを与えずにぶっちゃけて、建設的に課題を見つけて解決する」ということが可能です。

まとめ

• 書きすぎました。反省しています。
• チームビルディングのスタートは、心理的安全性の確保から
• 土台ができたので、次こそはincrementsさんの「全社合宿に行ってきました」みたいなVisionやOKRの策定へ