eng-docs

知識共有

20 min read

知識共有

『Google のソフトウェアエンジニアリング』第3章を読んで理解した内容を、自分の言葉で書き直したもの。 本文の引用ではない。節番号は原典を引き直すときの手がかり。

前提

自分の組織は、インターネット上の誰よりも自分たちの問題領域を理解している。 だから組織自体の問題の大半には、組織が答えられて然るべき。

そのために必要なのは学びの文化で、 そこには自分に知識が欠けていると認めても許される心理的安全性が要る。

知識共有が失敗している兆候 (§3.1)

兆候状態
情報の重複自前の方法を再発明している
情報のスキュー同じ話が噛み合わないままねじれている
単一障害点(SPOF)決定的な情報が1人からしか得られない
全か無かの専門知識「全部知っている人」と初心者に二分され、中間がいない
猿真似目的を理解しないまま、必要だと思い込んでパターンやコードをコピーする
幽霊の出る墓場何か壊れそうで怖くて、誰も触らない場所

SPOF が生まれる理由は悪意ではなく、短期効率への最適化。 「自分がやった方が速い」は正しい。ただし長期的スケーラビリティを削っている。

「全か無か」の状態では、知識と責任が既に持っている人にさらに蓄積し、 新メンバーは取り残されて立ち上がりが遅くなる。

考え方 (§3.2)

どんな専門家もかつては初心者だった。 組織の成功は、組織が擁する人々の育成とそこへの投資にかかっている。

知識の置き場所は2つあり、性質が違う。

  • ドキュメント化された知識は専門家よりスケーラブルで、チームを越えて組織全体まで届く
  • 組織慣習的(tribal)知識は、個人の頭の中とドキュメントの隙間に存在する。 人間の専門家は、書き留められていないことを知っている

完璧なドキュメントを持つ全員専門家のチームですら、 互いにコミュニケーションを取り、他チームと協調し、戦略を適応させ続けなければならない。 単一の知識共有アプローチがすべての学びの正解になることはない。 両者の適切な混合比は組織によって違うし、組織の発展とともに変わる。

心理的安全性が土台 (§3.3)

学ぶには、まず自分が理解していないものがあると認めなければならない。 その正直さは、罰するのではなく歓迎する。

学びの大部分は「試せること」と「失敗しても安全だと感じられること」でできている。

メンター制度 (§3.3.1)

メンターは、チームメンバー・マネージャー・テックリード以外の誰かが務め、 質問への回答と新メンバーの立ち上がり支援を明示的な責務として持つ。

メンティーと同じチームに属さないのが要点で、 込み入った状況で助けを求めるときの気楽さが変わる。

健全なチームでは、質問に答えることに寛容なだけでなく、 質問すること — 何かを知らないと表明すること — にも寛容。

集団が大きいほど心理的安全性が要る (§3.3.2)

協力的(推奨)敵対的(アンチパターン)
基本的な質問や誤りは適切な方向へ導かれる粗探しをされ、質問者が責められる
質問者が学ぶのを手伝う意図で説明される自分の知識をひけらかす意図で説明される
回答は親切で、忍耐強く、助けになる見下すようで、皮肉っぽく、建設的でない
解法を見つけるための議論の共有「勝者」と「敗者」の論争

アンチパターン側は意図せず出てしまうので、具体的な禁止事項として言語化されている。

驚いたようなふりをしない
「えっと、実はね」と、正確さより自己顕示に寄った訂正をしない
会話に責任を持って参加していないのに口出しして議論の腰を折らない
「簡単すぎてうちの祖母でもできる」式の、バイアスを示す狭量な表現をしない

自分の知識を伸ばす (§3.4)

知識の共有は自分自身から始まる。 自分には常に学ぶことがあると認識する。

質問する (§3.4.1)

初心者がやる最大の間違いは、行き詰まったときに助けを求めないこと。

  • 「それが何か知らないので説明してくれませんか」と言うことを恐れない
  • 多くの場合、同僚が最良の情報源
  • 知らないことは、またとない機会が眠る領域として受け入れる
  • 学ぶことのある環境に常に身を置く。 そうでなければ停滞する(なら環境を変える)

立ち上がりに時間がかかることは前提として認めておく。 書籍は、新メンバーの立ち上がりに約6ヶ月かかると伝えている、と書いている。

非対称な効果があるのはリーダーの振る舞い。 リーダーが公然と質問し、知らない部分を表に出すと、他の人も続いていいのだと分かる。 答える側が忍耐と親切さを心がけると、安心して助けを求められる環境が育つ。

文脈を理解する (§3.4.2)

学びは新しいことの理解だけではない。既存の設計と実装の背後にある決定を理解することも学び。

何かを取り除いたり変えたりする前に、なぜそれがそこにあるのかをまず理解する

書籍が指摘しているのは、エンジニアは馴染みのないコード・言語・パラダイムに対して、 信じられているよりはるかに短時間で「これは無駄だ」という結論に飛びつくということ。

手順はこうなる。

  1. 文脈と目的を探して理解する。普通でないように見える決定については特に
  2. そのうえで自分の変更が依然として妥当か検討する
  3. 妥当なら変更する。妥当でないなら、そう考えた根拠を将来の読者のために書き残す

Google のスタイルガイドの多くが、恣意的なルールを暗記させるのではなく 背後の理論的根拠を書いているのはこのため。 根拠を理解していれば、そのガイドラインを適用すべきでない場合や、 ガイドライン自体を更新する必要があるかどうかも判断できるようになる。

質問をスケールさせる (§3.5)

細部を全部記憶するのは無理。一対一の議論から何か学んだら書き留め、それを共有する。

グループチャットは、誰が答えを知っているか分からないときや相手が多忙なときに強い。 ただし手っ取り早い代わりに構造的ではない。

グループの外に共有する必要が出たとき、あるいは後で参照できるようにする必要が出たときが、 ドキュメントを書くタイミング。

自分の知識をスケールさせる (§3.6)

誰もが、異なる領域にわたって異なるレベルの専門知識を持っている。 ダイバーシティが組織の成功に決定的なのはこれも理由で、 様々な人が様々な観点と専門知識を持ち寄ることで貢献が生まれる。

講習が効くとき (§3.6.2)

トピックが、よく誤解の種になるほど複雑である
トピックが比較的安定している(教材の更新には相当な手間がかかる)
質問への回答や個別の支援を行う講師がいることで恩恵を受ける類のものである
定期的に提供するに値する需要がある

指導なしで受講者が容易に学べるなら、ドキュメントや録画などセルフサービスの方が効率的。

ドキュメント (§3.6.3)

何かを初めて学ぶときが、既存のドキュメントや教材の改善点に気づく最良のタイミング。 オーナーが他部署でも、自分で更新を試みる。

新しく書く場合。

  • 新しい開発フローを立ち上げるなら、その手順を書く。後で他の人がその道を辿れる
  • 発見しにくい・探しにくいドキュメントは、存在していないのと同じ。 定番はソースコードのすぐ側に置くこと
  • フィードバックを受け取る仕組みを用意する。 古い・不正確だと読者が簡単に指摘できないなら、誰も指摘せず、 次の新人が同じ問題にぶつかる。 自分の提案が実際に見てもらえると感じられれば、人は変更を出すことを厭わなくなる

チームメンバーを直接支援するだけでなくドキュメントへ誘導すると、将来の時間が節約でき、 チームと組織がスケールしやすくなる。

コード (§3.6.4)

実装コメントは時を越えて知識を伝える。 将来の読者には未来の自分も含まれる。

ただしドキュメントもコメントも積極的に保守しなければ、すぐに古く無効になる。 コードと完全に矛盾したコメントは誰もが見たことがあるはず。

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

成果物(コードなど)だけを見るより、まず文化と環境に注目する方が良い結果につながる。

尊敬 (§3.7.1.1)

ほんの数人の好ましくない行動で、チームやコミュニティ全体が不寛容になりうる。 最悪の場合、最も感じの悪いメンバーだけが残る。そこから持ち直すのは難しい。

テック業界には「才気あふれる嫌な奴」を容認する、あるいは尊敬すらする風潮が浸透していて、 それが悪影響を及ぼしている、と書籍は明言している。

リーダーがやることは、周囲の資質を引き上げ、心理的安全性を高め、 共同作業の文化を作り、緊張を緩和し、価値観の模範を示すこと。 嫌な奴は良きリーダーではない。

インセンティブと表彰 (§3.7.1.2)

よくある間違いは、価値観を表面的に掲げながら、 その価値観を実現しない行いに報奨を与えてしまうこと。

ボトムアップ文化の作り方の例として、 同僚同士が卓越した業績を称えて贈れるピアボーナスが挙げられている。

カノニカルな情報源を確立する (§3.7.2)

専門知識を標準化して伝播させる手段として置く。 これがないと組織は情報の孤島群になる。

条件は2つ。

  • その分野の専門家によって検証されていること
  • 明示的なオーナーがいること。 トピックが複雑なほど決定的に重要になる

そして対象読者を考える。この情報で得をするのは誰か — 自分か、チームか、製品領域か、全エンジニアか。

具体的な仕掛けとして挙げられているもの。

仕掛け効き方
開発者ガイド全部を読ませようとしない。精通した専門家が同僚にリンクを送り、そこから辿って学んでもらう
go/ リンク元の URL が変わってもコンテンツへのパーマリンクが保たれる
codelab動くサンプルコードとコード演習の組み合わせ。静的なドキュメントと講習の中間点。ただし保守コストは高い
静的解析ベストプラクティスをツールのチェックに入れると、使う全員がそれを認知する。 教える時間と労力を他のことに回せる

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

  • ニュースレターは、頻度が低く、有用で面白い内容が多いほどエンゲージメントが高い
  • 組織横断のコミュニティを作ると、直接の付き合いの外にいる人から学べ、 情報の孤島化と重複を避けやすくなる

リーダビリティ: レビューを通じた標準化されたメンター制度 (§3.8)

すべての変更にリーダビリティ承認を求める制度。 承認できるのは、その言語のベストプラクティスとスタイルを体現した 明確でイディオムに富んだ保守性のあるコードを、一貫して書けると示した人。

扱う範囲は、言語のイディオム、コード構造、API 設計、共通ライブラリの適切な利用、 ドキュメント、テストのカバレッジなど。

運用で決定的なのは性質の指定。

  • リーダビリティレビュアーには、言語の深い専門知識に加えて レビューを通じて人を教育する才能が求められる
  • メンタリングを通じた協力的プロセスとして扱う。 メンタリングを欠いた合否判定や敵対的プロセスにしない
  • コメントには関連する典拠を添えて、作者がガイドラインの根拠を学べるようにする。 根拠が不明確なら、作者の側から明確化を求めてよい

なぜこのコストを払うのか (§3.8.2)

コードは書かれるよりも読まれる方が圧倒的に多い。

コードベース全体の一貫性の価値は、どれだけ強調しても足りない。 得られるのは、一貫性の強制、情報の孤島化の回避、 確立された標準からの(多くは意図的でない)逸脱の回避。 読む側はコードが何をやっているかに集中できるようになる。

  • 大規模変更の作者は、何千ものチーム境界を越えた変更を実行しやすくなる
  • チームを異動しても、同じ言語の使い方が極端に変わらないという確信を持てる

弱点も明示されている。人間主導のプロセスなのでスケール上不利。

これは意図的なトレードオフ。 短期にはレビューの遅延と先行コストを払い、長期に高品質・一貫性・専門知識の増加を得る。 効果が長期に及ぶという前提は、コードが何年も存続するという期待から来ている。 だから短命だと分かっているコード(実験用ディレクトリなど)はこの要件を免除される。

関連

バックリンク