📖 読書感想文10『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 https://amzn.to/3YrMBEn

• 前回: 📖 読書感想文9『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 https://amzn.to/3YrMBEn – oki2a24
  • 第2部　文化 2章　チームでうまく仕事をするには

今回は

• 『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 https://amzn.to/3YrMBEn
  • 第2部　文化 3章　知識共有

を読んでいき、学んだことや考えたことや印象的なことを記していく。

3章　知識共有

3.1　学びを阻む課題

Googleは、いくつものそうした課題を経験してきており、それは特に会社がスケールしてきた過程でのことだ。

言われてみれば、変化するときに学びを阻む課題が出てくるってのはなんとなくそんな感じは確かにする。そしてそれは大きくなるときにより顕著だと言う事。これも言われてみればなるほどと思う。今の自分たちに当てはまるのかもしれない。

そして起こり得る課題の全部で9つのうち、最初の7つは今の現場で起きるかも、いつ起きてもおかしくない感じがする。解消されていくのだろうが、今のプロジェクトが終わり解散した後に、また別のプロジェクトが開始されたら、別のメンバーで最初からチーム形成になると考えれば、また同じことが発生するのであろう。と言う事は、その時にでも対応できるような型、仕組み、を身に付けていけば対処は簡単になるはず。

3.2　哲学

3.3　舞台を整える：心理的安全性

学びの極めて大きな部分を構成しているのは、物事を試せることと、失敗しても安全であると感じられることだ。

甘いってことではない。むしろ失敗しても安全なので命綱があるのでガンガン失敗しろって意味。失敗自体は怖いし勇気がいる。

3.3.1　メンター制度

メンターはチームメンバー、マネージャー、テックリード以外の誰かで、質問への回答やヌーグラーの立ち上がりの支援を、明示的な責務として担う。

同じチームに属していない上の役職ではないと言うところが、メンターに質問する際の心理的障壁を取り去っているのに役に立ってる。

健全なチームでは、チームメイトは、受けた質問に答えることについて寛容であるというだけではない。質問を尋ねること、つまり何かを知らないことを表明すること、そして互いから学ぶことに関しても、寛容なのである。

3.3.2　大規模集団での心理的安全性

この安全で友好的な環境を勝ち取るために最も重要な方法は、集団の交流が敵対的ではなく協力的になるようにすることである。表3-1は、集団の交流における推奨パターン（と対応するアンチパターン）を列挙している。

表3-1 集団の交流パターン 推奨パターン（協力的） 基本的な質問や誤りは適切な方向へ導かれる

質問者が学ぶのを手伝う意図で説明がなされる

回答は親切で、忍耐強く、助けになる

交流は、解法発見のための議論の共有である

アンチパターン（敵対的） 基本的な質問や誤りは粗探しをされ、質問者は責められる

自分の知識をひけらかす意図で説明がなされる

回答は相手を見下すようで、皮肉っぽく、建設的ではない

交流は、「勝者」と「敗者」の論争である

集団で協力的に振る舞うとは何かと言うことの詳細化がなされている。当たり前と言えば当たり前だが、大事だとよくわかる。

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

3.4.1　質問を尋ねよ

初心者のする間違いの中で最大のものは、行き詰まったときに助けを求めないことである。1人で切り抜けようという誘惑に駆られたり、自分には解けない問題が実は「簡単すぎる」問題なのではないかという恐怖を感じたりするかもしれない。「誰かに助けを求める前に、とにかくもっと頑張ってみないといけない」などと考えてしまう。この罠にはまってはならない！多くの場合、同僚こそが最良の情報源だ。この貴重なリソースを活用しよう。

誘惑と恐怖に負け、罠にはまってしまうことが今でも度々ある。

3.4.2　文脈を理解せよ

エンジニアは、馴染みのないコード、音話、バラダイムについては特に、往々にして信じられているよりはるかに短時間で「これは駄目だ！」という結論に飛びつく傾向がある、という話だ。

解決策が勝手にストーリー理解して勝手に結論を出してしまう飛びついてしまう。これはエンジニアとより人間がそうだってことだと思う。

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

3.5.1　グループチャット

グループチャットは手っ取り早い質問には優れているが、あまり構造的ではない。そのため自分が積極的に関与していない会話から意味ある情報を抽出するのが難しくなる。グループの外部へ情報を共有しなければならなくなった、もしくは、その情報を後で参照できるようにしなければならなくなった時点で、ドキュメントを書くか、メーリングリストにeメールを送るべきだ。

3.5.2　メーリングリスト

メーリングリストで行った質問の答えを自力で見つけた場合、そのまま自分の作業に戻る誘惑に駆られる可能性がある。それはやるべきではない！ひょっとすると将来(https://xkcd.com/979/)誰かが同じ情報を必要とすることになるかもしれないため、その答えを元のメーリングリストへ投稿しておくのがベストプラクティスである。

3.5.3　YAQS：Q&Aプラットフォーム

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

3.6.1　オフィスアワー

どんな質問をするべきかエンジニアがまだわからないほどに問題が曖昧である段階（新しいサービスの設計を始めたばかりのときなど）や、非常に特殊な問題であるために関連ドキュメンテーションが全然存在しない場合に、専門家と対面で話すことは特に有用だ。

3.6.2　テックトークと講習

3.6.3　ドキュメンテーション

3.6.3.1　ドキュメンテーションの更新

既存のドキュメンテーションやトレーニング教材の改善可能な点に気づくには、何かを初めて学ぶ時こそが最良のタイミングである。新たなプロセスやシステムを吸収し終わって学び切っている頃までに、何が難しかったか、もしくはどういった単純なステップが「入門」ドキュメンテーションから抜けていたか、忘れてしまっているかもしれない。ドキュメンテーションに誤りや省かれている部分があったら、この段階で修正しよう！キャンプ場は来たときよりきれいにして帰るべきだ+22。そして、そのドキュメンテーションのオーナーが組織の他部署であるとしても、そのドキュメントを自分で更新することを試みるべきた。

＋22「ボーイスカウトルール」（https://oreil.ly/2u1Ce Henney編、和田卓人監修、夏目大訳／オライリー・ジャパン／2010年）（https://www.oreilly.co.jp/books/9784873114798/） を参照してほしい。

ドキュメンテーションに向き合うときのマインドにボーイスカウトルール。

3.6.3.2　ドキュメンテーションの作成

最後に、フィードバックを募るメカニズムを確保すべきである。そのドキュメンテーションが古くなっていたり不正確であったりすることを読者が指摘するための簡単で直接的な方法がない場合、おそらく読者は誰にもその指摘をわざわざ告げることはなく、次にやってくる新人が同じ問題にぶつかるだろう。誰かが自分の提案に実際に気づいて検討してくれると感じるなら、人は変更をコントリビュートすることをいとわないようになる。Googleでは、ドキュメンテーションのバグ報告を、そのドキュメント自体から直接提出できる。

編集して良い文化、もしくは編集リクエストが送れる、みたいな仕組みがあるといいんだろうな。

3.6.3.3　ドキュメンテーションの奨励

しかしながら、ドキュメントの作者が、ドキュメントを書くことで直接的に恩恵を受けられる場合も多い。チームのメンバーがある種の本番環境での障害をデバッグする際に、いつもあなたに助けを求めてくると仮定してみよう。手順をドキュメント化しておくには時間の先行投資を要するが、その作業が済んでしまえば、チームメンバーをドキュメンテーションの方へ誘導しつつ必要時のみ直接的な支援を行うことで、将来は時間を節約できる。

3.6.4　コード

コードのドキュメンテーションは知識共有手段の1つである。明確なドキュメンテーションは、ライプラリーの利用者のみならず、ライブラリーを将来保守する者にまで恩恵をもたらす。同様に、実装に関するコメントは時を越えて知識を伝える。

将来の読者、未来の自分へも。

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

3.7.1　知識共有の文化を養う

しかしGoogleにおいて我々が確しているのは、その環境の成果物（例えばコード） にのみ焦点を当てるより、まずは文化と環境に焦点を当てる+27方が良い結果につながるということだ。

ものではなくて、人間の何かに焦点を当てる。環境は違うなぁ。環境は割とものよりだ。成果物についてよりも焦点を当てる、そんなイメージかな。

3.7.1.1　尊敬

高位のレベルでは、ある程度の技術的リーダーシップが期待されるが、あらゆるリーダーシップが技術的問題を対象としているわけではない。リーダーというものは、周囲の人々の資質を引き上げ、チームの心理的安全性を向上させ、チームワークと共同作業の文化を作り上げ、チーム内の緊張を緩和し、Googleの文化と価値観の模範を打ち立て、Googleをより活気と刺激に満ちた仕事場にするのである。嫌な奴は良きリーダーではない。

知識共有の上ではあるが、ここでも尊敬が出てくるのは少し驚いた。嫌な奴は無用

3.7.1.2　インセンティブと表彰

組織が一連の価値観を表面的に持ち上げつつも、そのような価値観を実効化するわけではない行いに対して積極的に報奨を与えてしまうというのは、よくある間違いだ。人はつまらない言葉よりインセンティブに反応するものであり、したがって、給与と賞与のシステムを制定して、口先ではなく行動で示すことが重要である。

組織が一連の価値観を表面的に持ち上げつつも、そのような価値観を実効化するわけではない行い、今まで何度か目にしてきたが、言語がうまい表現だなぁと思った。

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

3.7.3　情報の輪に参加し続ける

3.8　リーダビリティ：コードレビューを通じての標準化されたメンター制度

Googleでは、「リーダビリティ（readability） 」は単なるコードの読みやすさ以上のことを指している。リーダビリティは、プログラミング言語のベストプラクティスを普及させるための、Google全社的な標準化されたメンター制度のプロセスである。プログラミング言語のイディオム（idiom） +48、コード構造、API設計、共通ライブラリーの適切な利用、ドキュメンテーション、テストのカバレッジ（coverage：対象範囲）などに加え、その他各種の広範囲な専門知識をリーダビリティは扱っている。

読みやすさを超えて理解しやすさに踏み込んでいるように感じた。

3.8.1　リーダビリティプロセスとは何か

3.8.2　何故このプロセスがあるのか

3.9　結論

3.10　要約

• 心理的安全性は、知識共有の環境を育む際の基盤である。
• 小さなことから始めよ。つまり、質問をすること、物事を書き留めることだ。
• 人間の専門家とドキュメント化されたリファレンスの双方から、必要な助けを簡単に得られるようにすべきである。
• 自身のみならず所属チームや所属織を越えて専門知識を教え広めていくのに時間を割く者は、制度的なレベルで奨励し報奨を与えよ。
• 銀の弾丸はない+ぶ。知識共有の文化を振するには複数の戦略の組み合わせが必要であり、どのような特定の配合が組織にとって最もうまく機能するかは、おそらく時間の経過に伴って変化するだろう。