Google流『チーム、組織における知識共有』

『Googleのソフトウェアエンジニアリング』の第3章を読んでいて、自分に役に立ちそうだと感じた内容の読書メモ。

3章 知識共有

組織は、組織自体の問題の大半に対して答えることができて然るべきである。そのためには、専門家とその知識を流通させるメカニズムの両方が必要である。このようなメカニズムにおいて、最も重要な点が学びの文化であり、これには学びの知識が欠けていることの自覚、並びに許容されるような心理的安全性を要する。

学びを阻む課題

• 心理的安全性の欠如
• 情報の孤島群
  互いにコミュニケーションを取らなかったり、共有リソースを使わないような組織、様々な部分で生じる知識の断片化
• 情報の断片化
  各孤島が持つ、より大きな全体像の不完全版
• 情報の重複
  　各孤島が、何かを行う自前の方法を再開発する
• 情報のスキュー（ねじれの位置）
  　競合があったりなかったりするような、同じ結果に対する各孤島の自前の方法やアプローチ
• 単一障害点
  　決定的な情報を一人しか持たないことで生じるボトルネック
• 全か無かの専門知識
  　全てを知る者と初心者の2種類に分断され、中間がほとんどいないような組織
• 猿真似
  　理解しないで行うコードのコピペ
• 幽霊がでる墓場
  　コード内にあることが多い、触れると何かがおかしくなると恐れられ、皆が避ける場所

哲学

ソフトウェアエンジニアリングは、複数バージョンのプログラムの複数人による開発として定義できる。ソフトウェアエンジニアリングの中心にいるのは人間なのだ。つまり、コードは重要な成果物であるが、製品開発の小さな一部に過ぎないのである。決定的に重要なこととして、コードは無から自然発生するわけではなく、それは専門家も同様だ。どんな専門家もかつては初心者だった。つまり、組織の成功は組織が擁する人々の育成と投資にかかっている。
　専門家から受ける一対一のアドバイスはプライスレスだが、属人化しやすく、またスケールしにくい。ドキュメント化された知識はスケーラビリティが高いが、一般化された知識であり、かつ内容の更新といった保守コストがかかる。両方を使って知識の共有を行う必要がある。

心理的安全性のアンチパターン

• 基本的な質問や誤りは粗さがしをされ、質問者は責められる
• 自分の知識をひけらかす意図で説明がされる
• 回答は相手を見下すようで皮肉っぽく、建設的でない
• 交流は「勝者」と「敗者」の論争である

このような態度を取らないようするために以下を意識する。

• 驚いたふりをしない（えっ、○○を知らないの！？）
• 「えっと…、実はね」をやめる
• 求められもしない回答をしない
• 陰険な差別をしない（こんなこと猿でも分かるよ！）

自分自身の知識を発展させる

「自分には学ぶべきことが常にある」という認識が重要である。以下のガイドラインに従うことで自身の知識の強化に繋がる。

1. 質問を委ねよ
   要するに「学び続けろ」ということ。行き詰っているときに他者へ頼ることを躊躇してはいけない。「自分の質問は簡単すぎるのでは？」と考えてはいけない。この思考は硬直マインドセットから来るものであり、学びを阻む原因となってしまうので、成長マインドセットを持つように、常に心掛けなければならない。また、シニアエンジニアは何でも知っているかのように振舞うことはせず、質問しやすい環境づくりに努めなければならない。
2. 文脈を理解せよ
   学びとは、新しい物事の理解のみにとどまらない。既存の物事の設計と実装の背後にあった決定について理解を深めることも、学びに含まれる。レガシーなコードベースを根本から書き直した誘惑にかられることは多くあると思うが、なぜそのような記述になったのかを全く調べずにリファクタリングを行ってはならない。

質問をスケールさせる：コミュニティへの質問

一対一で助けてもらうのは一番理解が深まるが、スケール面では限定される。また、教わったこと全てを覚えておくこともできない。このような問題を解決するために、学んだことは何かしらの形で残しておく。

• グループチャット
  質問を誰にすればいいか分からない、または相手が多忙という場合にはグループチャットが役に立つ。また、チャット内で交わされた質問と回答は他のメンバーも参照することができ、履歴をアーカイブとして活用することもできる。構造化されていないため、参照性は低い。
• メーリングリスト
  より多くの有識者に質問することができ、またチャットよりも構造化されているため参照性が高い。迅速性に欠ける、過去のアーカイブが現在でも有用であるとは限らない（グループチャットも同様）という問題点がある。
• Q&Aプラットフォーム
  メーリングリストよりも更に洗練された回答を得ることができる。

自分の知識をスケールさせる：教えられることは常にある

教えるという行為と専門知識は専門家の専売特許ではなく、また全てが高度なレベルである必要もない。組織の成功には多様性が決定的に重要であり、そのためには様々な人が様々な観点から知識を持ち寄り、共有する文化が必要である。Googleエンジニアが行っている、自分の知識のスケーリング方法には以下のようなものがある。

• オフィスアワー
  定期的に開催されるイベント。特定のトピックに対して答えられる有識者を一人以上確保しておく必要がある。理解が曖昧な分野や、非常な特殊な問題をトピックとして扱い際に有用である。
• テックトーク
  講演者が聴衆に直接プレゼンテーションを行う。
• 講習
  演習がメインで、出席者に積極的な参加が求められる。複数人の講師と、講習に使う資料と内容の保守が必要なためコストがかかるが、適切に運用できればスケーラビリティが高い。以下の場合に有用。
  • トピックがよく誤解の種になることがある
  • トピックが比較的安定している
  • 人が教えた方が効果があるもの
  • 定期的に提供する価値があるもの
• ドキュメンテーション
  ドキュメンテーションは書き記された知識で、読者が何かを学ぶ手伝いをすることが主要なゴールである

組織の知識をスケールさせる

組織が発展するにしたがって、専門知識を組織内で適切に共有することが難しくなる。組織がどの段階であったも重要な知識（文化など）もあれば、成熟段階で重要になる知識もある。

知識共有のぶんかを養う

文化とは多くの組織において、後付けで扱われるものである。しかしGoogleではその環境における成果物（コードなど）よりも、まずは文化や環境に焦点を当てる方が良い結果に繋がると考えている。
腐ったミカンよろしく、ほんの数人の好ましくない個人によって、チームやコミュニティ全体が不寛容な状態に陥ってしまう。テック分野では「才気あふれる嫌な奴」の容認、あるいはそういう奴への尊敬というものが浸透し、かつ悪影響を及ぼしている。専門家であることと親切であることは排他的なわけではない。
Googleのソフトウェアエンジニアリングの職務等級におけるリーダーシップの項は、次のように述べられている。

リーダーというものは、周囲の人々の資質を引き上げ、チームの心理的安全性を向上させ、チームワークと共同作業の文化を作り上げ、チーム内の緊張を緩和し、Googleの文化と価値観の模範を打ち立て、Googleをより活気と刺激に満ちた仕事場にするのである。嫌な奴は良きリーダーではない。

カノニカルな情報源の確立

カノニカルな情報源とは、専門知識を標準化して伝搬させる手段を提供する、中央集権型で全社的な情報のデータベースである。カノニカルな情報源は、組織内の全エンジニアリングに関連がある情報に関して最も効果的に機能し、それを欠く組織は情報の孤島群になりがちだ。
カノニカルな情報源の確立には多くの投資を必要とするが、同時により広範な恩恵ももたらされる。また、似た問題に取り組む複数チームが、自チーム向けガイドを作り出す際に発生しうる情報の断片化問題への対策にもなる。「開発者ガイド」あ「静的解析ツール」もカノニカルな情報源の一つである。