マネジメントで悩むすべてのエンジニアが見るべき完全無料テキスト「Google re:Work」

1705件のシェア(最高の記事)

「エンジニア天国な会社にしたい。したくない?」

「したい。けど、どうやって?わっしょい的な雰囲気で?」

今年の6月あたり、クラスメソッドAWS事業本部コンサル部で合宿を予定しているんですが、その合宿でやるネタを考えているときに知ったのが、この「Google re:Work」。

正解が見えづらい組織運営において、「良いチームとはなにか?」「採用で気をつけるべき点」「ビジョンがもたらす効果」など、マネジメントの頻出課題をギュッと凝縮して詰め込んだこのコンテンツがむっちゃ有用だったので、紹介します。

Webコンテンツとして完全無料なので、今マネジメントで悩んでいる人も、これからマネージャー目指そうとしている人にも参考になる点多いと思うので、一度気軽に読んでもらえれば良いかと思います。

(祭) ∧ ∧
 Y  ( ゚Д゚)
 Φ[_ソ__y_l〉     マネジメントダワッショイ
    |_|_|
    し'´J

re:Workとは?

Google re:Work

「働く」ことについて、私たちはもっと多くを期待してもいいのではないでしょうか。私たちは仕事に多大な時間を費やしています。しかし多くの人にとって、仕事は生活するための手段であって、充実感や刺激を得られる場とは感じてはいないのではないでしょうか。
引用:Google re:Work について

メッセージが強烈。人生において多大な時間を使っている仕事を、もっと真正面から楽しいものしようという強い意志が感じられます。

エンジニアの端くれとして、やっぱりGoogleという巨大企業のエンジニアリング文化には興味がありますし、よくある「伝説のなんたらコンサルタントが教える組織論」よりも、エンジニア比率が死ぬほど高いクラスメソッドには合うのかなぁという期待感が持てます。

re:Workは、2つのコンテンツから構成されています。

テーマ

採用や人材管理などのテーマを選んで閲覧し、具体的なトピックについて掘り下げることができます。

  • イノベーション
  • チーム
  • ピープルアナリティクス
  • マネージャー
  • 偏見の排除
  • 学習と能力開発
  • 採用
  • 目標の設定

テーマが最初から分かれているのは入りが良いですね。今自分が問題意識をもっているところから、読んでいくことができます。各テーマの中では、そのテーマの中で考えるべき大枠が提示されたのち、具体的にどうやってそのテーマを検討していくかが、下で紹介するガイドで紹介されています。

ガイド

Google re:Work - ガイド

人事プロセス、働き方を改善するためのグーグルの手法、研究、ツールをご紹介します。

こちらは、テーマよりはもう少し具体的で実践的なツールなどが紹介されています。ツールといっても、なにかそれ用のアプリケーションが提供されるというわけではなく、順序だったステップに基づいて、それぞれの課題を解決していくドキュメントやスライド、スプレッドシートといったものが提供されます。

このガイド、大量にあります。組織リーディングする立場の人であれば、何かしら「あぁ、せやねん、これいつも困ってるんだよなぁ」という項目が、必ず複数あるんじゃないでしょうか。

  • 公正な給与制度を設計し運用する
  • イノベーションが生まれる職場環境をつくる
  • 仕事の面だけでなく個人的な面でもチームに配慮する
  • 従業員感での学習プログラムを導入する
  • 無意識の偏見に意識を向ける
  • デザイン思考でイノベーションを生み出す
  • 構造化されたプロセスと成功基準を策定する
  • 何気ないメッセージに潜む偏見を見直す
  • 構造化面接を実施する
  • 優れたマネージャーの要件を特定する
  • 有意義な応募者体験を提供する
  • OKRを設定する
  • 偏見排除の責任は一人ひとりが負う
  • マネージャーにフィードバックを提供する
  • チームのビジョンを設定してメンバーに伝える
  • データを集めてアウトカムを測定する
  • マネージャーにコーチングを指導する
  • チームに権限を与える
  • 専門知識でサポートし、結果を重視する
  • マネージャーを育成・サポートする
  • 採用委員会を設ける
  • 募集要項を作成する
  • 履歴書を審査する
  • 面接担当者をトレーニングする
  • 「効果的なチームとは何か」を知る
  • 指標を明確にする
  • 分析的アプローチを採用する
  • 従業員アンケートを実施する

この後、ハマコーがre:Workを一通り目を通してみて、「これ、エンジニア組織にめっちゃ参考になるやん!」と感動したものを中心に紹介します。

「効果的なチームとは何か」を知る

Google re:Work - ガイド: 「効果的なチームとは何か」を知る

どんな仕事も「チーム」という概念であたる場合が多いですが、そもそも「効果的なチーム」ってなんなんですかね?

  • 飲み会をよくやってるチーム?
  • Slackのチャンネルの流量が多いチーム?
  • メンバーが自律的に動いているチーム?

良いチームのなんとなくのイメージはありつつも、それを真正面から定義してその効率性の指針に何があるかを学ぶことができるのがこちらのガイドです。

「チーム」の定義から始まり、「効果的なチーム」の評価軸を例示しながら、最終的には以下でまとめられています。

真に重要なのは「誰がチームのメンバーであるか」よりも「チームがどのように協力しているか」であることを突き止めました。

  • 心理的安全性
  • 相互信頼
  • 構造と明確さ
  • 仕事の意味
  • インパクト

心理的安全性の意味を噛みしめる

でましたね、心理的安全性。Googleのリサーチチームでは、効果的なチームを表す指標のうち圧倒的に重要なのが心理的安全性と結論づけています。でもね、皆さん、この言葉の意味を正しく理解できている自信ありますか?

最近エンジニア界隈ですごいよく聞く言葉だと思います。自分も「なんとなく発言しやすい雰囲気があれば、心理的安全性高いんだろうな」と安直に考えてたんですが、re:Workではもっと踏み込んで解説されてます。

ツール:心理的安全性を高める

凄く感銘を受けたので、ちょっと長めですが引用します。

この概念を「対人関係においてリスクのある行動をしてもこのチームでは安全であるという、チームメンバーによって共有された考え」と定義しています。
チームメンバーに対してリスクのある行動を取ることは、特別難しいことではないと思われるかもしれません。しかし、「このプロジェクトの目標は何ですか?」などのように、ごく基本的な質問をするときのことを想像してみてください。「そんなこともわかっていないのか」とあきれられることへの不安を覚えるのではないでしょうか。
無知だと思われないように、質問をせずにやり過ごそうとする人も少なくないはずです。
引用:Google re:Work - ガイド: 「効果的なチームとは何か」を知る

特にエンジニア集団で仕事をしている場合、特定技術に対して疑問があったときに「こんなこと知らないって言ったら、俺すげぇ馬鹿にされそう…」と思ったことありません?

自分はあります。めちゃくちゃあります。普段、AWSのことを生業にしている自分ですが、どこまで学んでも知らないことだらけだし、苦手領域も大量にあります。でもね、この会社で働いてるとね、まじで周りがとてつもないスーパーマンにしかみえなくてどうしても萎縮してしまうんですよ。特に入社した直後はそうでした。

でも、ある程度仕事に慣れてきて自分の得意領域ができてくると「うん。AWSは沼だ。全部理解するのなんて不可能だ」という、ある種悟りの境地に達してくるんですね。すると、逆に知らないことを自信持って知らないと言えるようになったんですが、これには時間がかかりました。

この「知らないことをすぐに聞ける」って、凄い重要な指標だと感じていて、そのあたりが明文化されて提示されているのは非常に参考になります。

また、もっと具体的なツールとして、以下のドキュメントが用意されています。

心理的安全性を高めるためにマネージャーにできること - Google ドキュメント

箇条書き形式で、心理的安全性を高めるためにマネージャーがやるべきことが、凄くコンパクトに纏まっているので、これをアレンジしながら日々のチェックに使えるんじゃないでしょうか。

効果的なチームを目指す

ツール:チームに必要なものを見極める

ここでは、心理的安全性以外の事柄も含めて総合的に、チームの効果性を高めるためのツールが紹介されています。

チームの効果性に関するディスカッション ガイド - Google ドキュメント

これも要素と質問例で構成されていて使いやすい。上の心理的安全性のチェックツールと合わせると、効果的に使えそうです。

チームの効果性に影響すくない指標も参考にする

もっと面白いのは、以下の指標はチームの効果性にそれほど影響していないと結論付けているところ。

  • チームメンバーの働き場所(同じオフィスで近くに座り働くこと)
  • 合意に基づく意思決定
  • チームメンバーが外交的であること
  • チームメンバー個人のパフォーマンス
  • 仕事量
  • 先任順位
  • チームの規模
  • 在職期間

仕事量や個人のパフォーマンス、チームメンバーの外交性とかがチームの効果性に影響しないって結論は面白いですね。もちろん、この指標を鵜呑みにして即チームに適用するのはナンセンスだけれど、一つの参考になるんじゃないでしょうか。

「チームのビジョンを設定してメンバーに伝える」

Google re:Work - ガイド: チームのビジョンを設定してメンバーに伝える

「ビジョンはあったほうが良い。みんなでそれを見て目指すことができる!」。そうなんとなくは、そう思いますよね。無いよりはあったほうが良いとは思うんだけれど、「で、ビジョンってどうやって設定するの?」という点を真正面から解説しているのが、こちらのガイド。

「ビジョンが必要な理由」から、それをチームメンバーとマネージャーで設定していくステップが具体的かつ詳細にまとめられています。

チーム演習として、2日間8時間を想定したマネージャー主導型のセッションとしてツールが紹介されてます。ちょっと目を通してみたんですが、確かにこれ全部やるとだいぶボリューミーだなぁと感じる分量です。メンバー全員のワーク用のドキュメントとマネージャー向けのファシリテート用のドキュメントの両方が用意されているのは、至れり尽くせり。

- 共有ビジョンの設定 - Google スライド
- 共有ビジョンの設定:ファシリテーターガイド - Google ドキュメント

基本はカスタマイズして使うことが前提のドキュメントですが、まずはフレームが提示されていることで、ビジョン策定のハードルを低くしてくれます。なにから手を付けたら良いかわかんない場合に参考になります。

その他のガイドも面白そうなのたくさん(全28種)

全部は紹介しきれないし目も通せていないんですが、面白そうなガイドが他にもたくさんあるんですよ。

およそ、組織運営をしていく中で遭遇するであろう様々なシチュエーションを網羅していて、斜め読みしているだけでも面白いです。

Google re:Workが圧倒的に優れている点

そんなこんなで、自分が3時間ほどかけてre:Workをあれこれ見てみた感想です。

ガイドが実践的でわかりやすい

各ガイドが具体的なテーマに絞って記載されているためか、内容が実践的わかりやすい。自分マネジメントに興味を持ち始めて何冊か有名なのも含めてマネジメント関連の本を読んでたんですが、re:Workは抽象論が少なく実践的で圧倒的に読みやすいです。

分量がちょうどよい

各ガイドの分量が、多すぎず少なすぎずちょうど良いです。ガイドによって差はあるけれど、原理原則からツールの紹介〜使い方までがコンパクトにまとまっているため読みやすいですし、そこから自分なりのアレンジもやりやすい。

エンジニアの会社が書いたマネジメント論という説得力がある

心理的安全性のところで強く感じたんですが、re:Workは全般が、「Googleの中での実験の結果」を元に記載されています。膨大な社員が在籍し圧倒的なアウトプットをだしている会社が、そのデータをベースに論旨展開されているものなので、凄い説得力を感じるんですね。

内容としては、別にITエンジニア組織に特化したものではないんですが、社内への啓蒙から利用全般において、エンジニア組織で展開するには非常に相性が良いマネジメント論だと思います。

エンジニアマネジメントにガイドを求めているすべての人へ

エンジニアな自分が常に感じるのは、「マネジメントって、正解が無いからこそ雲を掴むように難しい」ということ。

エンジニアリング的な問題、例えばアプリケーションの特定の処理が遅いときのチューニング(遅いSQLの特定、実行計画の確認、インデックスやSQLの見直し)って、課題の特定から解決策まで一定の正解があるわけじゃないですか。

これが、いわゆるマネジメント的な領域での問題、例えばチームのモチベーションやアウトプットの多寡、コミュニケーションコスト増加の対応って、物理的な課題の特定と明確な解決策が、すぐにはでてこないと思うんですよね。

そういうときに、「うーん、ここやろ。これ解決したらええ感じになるやろ!」と直感で動くのも良いとは思います。その組織のことを知り尽くしているマネージャーであれば、直感的に動いて解決できる問題は多くあるかと。

ただ、組織が大きくなり部門長以外にマネージャーが複数いたりさらに新しい人がどんどん増えてくるフェーズでは、チームの良い文化を保ちながら組織を成長させていくには、そのチームビルディングや組織運営の手法を形式知化して残していく必要がどうしてもでてくる気がしています。

そういったときに、一つのベースとなる教科書として非常に有用なのがこの「Google re:work」だと感じました。チーム運営に悩んでいたり何かしらの羅針盤が欲しいマネージャーには、巷にあるマネジメント論の書籍をあたるのも良いかとは思いますが、一度、この「Google re:work」に目を通して見るのも良いんじゃないでしょうか。

それでは、今日はこのへんで。濱田(@hamako9999)でした。

参考資料

re:Workを知ったきっかけは、先日、サーバーレス開発部の阿部があげていた以下のエントリです。

サーバーレス開発部では、既に合宿でこのre:Workを使ったとの事です。そちらの経緯も気になる方は、是非こちらのエントリも御覧ください。