DDD ディストーション駆動開発

ギターと音楽とRubyを愛するエンジニアのblog

Google re:Workを読む会に参加した

Google re:Workを読んでみるワークショップ

友人がGoogle re:Workの日本語訳を読むワークショップをやろう、と誘ってくれたので、会場提供などのお手伝いをさせてもらいました。

rework.withgoogle.com

Google re:Workは

データ分析を基に考えられた人事施策について、Google(グーグル)が他の組織と一緒に共有し推進しようとする取り組みです。

 というコンセプトの取り組みのよう。Googleが自身の研究成果をまとめてくれたものがこのページにあるので、今回は「効果的なチームとは何かを知る」というページを読みながら意見交換をしました。以下、当日出た感想などを書き連ねておきます。

メンバーの行動基準てないの?

マネージャーの10個の行動基準が紹介されていたことに対する疑問として出たもの。確かに、良いマネージャーにうまくマネージされるためのinterfaceをマネージされる側も持っておくというのは大事な気がする。

ワークグループとチームの違い

相互依存性の有無で「ワークグループ」と「チーム」という定義を分けているのが面白かった。相互依存性を作れればチームにできるのでは?と観点が出て、「joinしたメンバーをランチに連れまわすようにしている」という話が出た。なんとなく人を誘ってランチに行くのもいいけど、「チームになって欲しい人と相互依存性を作るための手段として一緒に飯を食う機会を作っているんだよ」っていう目的を念頭に置いてランチに行くと、ちょっと良い効果があるかも。

タックマンモデル

この文章に出てきた言葉ではないけど、意見交換の中で「タックマンモデル」というのを紹介してもらった。チームの形成は以下の5つの段階を経る、という話。

形成>>混乱>>統一>>機能>>散開

 機能するチームになるために、今チームがどの段階にあるのか、次に行くにはどうしたら良いのか、ということを考える上でとても役に立ちそう。言ってしまえば当たり前のことしか書いてないのだけど、これをチーム全員が知っていれば「お互いの価値観を知らないと混乱期にも行けないから統一もされない」とか「統一に向かわなきゃ機能しない、統一するためにはどうしたら良いんだろう」ということを考えることができるので、体系として知っているのと知らないのとでは全然違うなと思った。

心理的安全性の確保

ワークショップの中で出た「私はチームのことをすごく気にかけてたつもりなのだけど、上司から、君はチームに対する挨拶が足りなくて、チームとしてよくない、ということを言われた」というエピソードがすごく面白かった。

挨拶がチーム形成に大事、というのは、感覚的にはわかる。ただ、もし仮にチームとリーダーが本当に良い状態を築けていたとしても、上司一人が「挨拶がないことで心理的安全性が保たれていない」と感じたとしたら、上司にとっては心理的安全性が保たれていないチームであるということになってしまうということ。それって結局「何をどう感じるかはその人によりけり」ということになってしまう。

それに対して「チームが大切にすべき価値観をいくつか、毎週のふりかえりで確認すると良い」という話を伺った。「これが保たれていれば私の心理的安全性は保たれる」という価値観をみんなで確認するということ。もし仮に「毎朝の挨拶がないと疎外感を感じる」という人がいれば、「毎朝挨拶してほしい」というのをチームが大切にすべき価値観に加えれば良い、ということ。

チームとして何を重視するかはチームに集まった人によって変わってしまうから、チームみんなが気持ち良くいられるように話し合いをしよう、という、当たり前だけど気付きづらいことに気づけた気がした。

情報共有について

「メンバーに与える情報はできるだけ絞る」というのがよくある考え方なのだけど、そうすると情報格差が生まれて、それによってヒエラルキーができちゃう。なので最近はできるだけ情報をオープンにしようという会社が多いと思う。

ただ、「与える情報を絞る」という行為を「ありったけの情報全て与えると混乱するだろうから絞っとくね」というある種の好意とか効率性を考慮して行ってるケースがあるような気もする。別に情報格差によるヒエラルキーを作ることを目的としてなくて、単に過去のリーダーがそうしてたからそれが良いことだと思ってやってる、的な感じで。

実際にやるべきことは、「情報は可能な限りオープンにしておく、ただ、多すぎると必要な情報を掴むのが大変だと思うから、大事なところだけまとめて伝えるね」というキュレーションなんじゃない?という話が出ていて、興味深かった。「フィルター」するんじゃなくて「キュレーション」すれば良いのだ。メンバーからすれば「これだけ見ておいてくれれば良いよ」という情報の量は変わらないので特に混乱はしないけど、アクセス可能な情報は増える。

個人的には自分でフィルタリングできるからできる限り多くの情報をそのまま流して欲しいと思う。フィルターされてると感じた時にその意図を勘ぐったり、隠されてる事を暴くためにいらぬ情報収集に時間を費やしたりする必要が出てくるのでやましいことがないなら全部投げてくれよと思う。

雑感

お互いの期待値をコントロールするためにしっかり話し合いをするとか、状況を把握して共通認識を作っておくとか、無駄に考えなくて良いようにrequest-responseのプロトコルを揃えておこうぜ、とか、言ってしまえばそれだけなのに、なかなかそういう普通のことができてないので非効率とか悲劇が起こるのだなと改めて感じた。

こういうチームビルディングにかかる時間は直接的に何かを生産するわけではないから、人によっては無駄と捉えてしまうようなのだけど、何のためにやってるコミュニケーションなのかしっかりと定義しながらやっていけば理解も得やすくなるかもしれないなと思った。

このワークショップ自体も、「この言葉の定義は何なのだろう」とか、「ワークグループとチームをわざわざ定義してるということはこの違いは重要なんだろう」とか、一つ一つ丁寧に共通認識を作りながら読み進めていた。読み進められる量は少ないけど、得た物はとても多かったと思う。