3章 知識共有
3章 知識共有
最も重要な点は、組織に学びの文化がなければならないことだ。
「学びの文化」大事。でもいざ勉強会とか社内コミュニティの運用を考えると超難しい
そのためには、自身に知識が欠けてい るのを認めることが許容されるような、心理的安全性を作り出すことを要する。
最近読む本、ほとんどが「まず心理的安全性があることが前提」という感じで始まる印象があり、これもその一つだった
組織・コミュニティに心理的安全性がないと情報を共有しようと思わなくなるので、とても重要。
3.1 学びを阻む課題
幽霊の出る墓場
コード内にあることが多い、何かがおかしくなるかもしれないと恐れて触れたり変更したりするのを皆が避ける場所。前述の**猿真似**とは違い、幽霊の出る墓場は、恐怖と迷信のために、皆、行動を避けようとするのがその特徴だ
3.2 哲学
ソフトウェアエンジニアリングの中心にいるのは人間なのだ。つまり、コードは重要な成 果物ではあるが、製品開発の小さな一部にすぎないのである。決定的に重要なこととして、コード は無から自然発生するわけではなく、それは専門家も同様だ。
2章の内容とも繋がるような文章 その上でコードとの違いから専門家の説明に着地している
ソフトウェア・サービスはロジックで動くけど人間は感情で動いたりするので、そこのバランスをとりながらエンジニアリングするのが大事だよね、ということなのかなと。
人間は理屈により納得するが、感情により動く 〜元アメリカ大統領のニクソン氏の言葉より〜
組織の知識は時間の経過とともに発展し、組織で最もよく機能する知識共有の方式もまた、組織の発展に応じておそらく変化するだろう。
言われてみれば確かに こういった観点もチームの運営には必要なことがわかった
ドキュメント化された知識にはスケーリング上の利点があるが、的を絞った人間による支援にも利点がある。人間の専門家は自身の持つ幅広い知識を合成して新しい知識を作れる。(中略)わかる者を知っているかもしれない。
このあたりを見逃して、ドキュメンテーションの過大評価が起きがち
知識の場面応答性、というようです
属人性をなくしたい欲望が過大評価を生んでしまう
3.3 舞台を整える:心理的安全性
3.3.1 メンター制度
メンターはチームメンバー、マネージャー、テックリード以外の誰かで、質問への回答やヌーグラーの立ち上がりの支援を、明示的な責務として担う。
「以外」のところが太線になっているのが気になった たぶん業務上での直接の関係性があると心理的安全性を損なうんだろうなあと予想
決定的に重要なのは、そうしたメンターたちが、メンティーが他にアドバイスを求める者を知らない場合に話しかけるためのセーフティーネットとなっていることだ。
海外の方がカウンセリングを受ける敷居が低いらしいし、保険が適用される場合も多いみたいなので、こういったメンターメンティーの文化は日本よりあるのかも。
能力的な支援も大事だけど、感情の支援も大事なのかなと。話を聞いて相槌を売ったり、肯定したり、自信をつけさせたりなど。
3.3.2 大規模集団での心理的安全性
集団の交流パターン
後からチャットを見返すと文字だけ見ると意図せずマウント取ってるように見えることがあって気をつけようと思う。例えば、誰かの投稿や発表の補足をしようと思った時。
壁紙に貼りたいくらい大事なことが書いていると思う。アンチパターンを使うと人が離れていってしまうので、常に意識したい。
3.4 自分の知識を発展させる
3.4.1 質問を尋ねよ
「誰かに助けを求める前に、とにかくもっと頑張ってみないといけない」などと考えてしまう。この罠にはまってはならない!
自分これやりがちだなーと思うと同時に、リモートワークだとこういう思考に陥ってしまう人も少なからずいるのではと思う
うまく同期する時間を作ってケアする仕組みが必要だよなーとつくづく思う
あとは、すでにいる人たちが実際に質問をお互いにする中で、どれだけ質問のハードルを下げられるかというのも大事かなと思う 「こんなことでも質問していいんだ」と思ってもらうことが大事そう
3.4.2 文脈を理解せよ
Chestertonのフェンス
こういうの、「ちゃんと名前付いてるんだ」と感心しちゃいますね
フェンスをつくるという当時の判断をした人にリスペクトを欠いた行動で、チームの古参を敵に回すという点でも悪手
newbieは早く実績を作ろうと往々にして焦ってるのでやりがち
「政治家の実績づくりで規制が推進される」のもこのケース
3.4.1 で立ち上がりに時間がかかると語られているのは、これを防ぐ目的があるのかも
エンジニアは、馴染みのないコード、言語、パラ ダイムについては特に、往々にして信じられているよりはるかに短時間で「これは駄目だ!」とい う結論に飛びつく傾向がある、という話だ。
「ライトついてますか」にも似たような話があったような気がする
未熟な問題解決者は、解くべき問題を定義する時間を惜しんで解答にとびつく。経験を積んだ問題解決者すら、社会的圧力にさらされると、この「急ぎたい」という気持ちに負ける。
ネットから拾ってきたので原文ママかはわからないけどこんなこと書いてあった気もする
「問題解決」は場合によってはそれほどまでに楽しい 一度極上の問題に手をつけてしまったら、他の人が割り込んできたとき喜ぶのは倒錯者だけである
これも関連しそう
3.5 質問をスケールさせる:コミュニティへの質問
3.5.1 グループチャット
3.5.2 メーリングリスト
シグナル/ノイズ比
便利な言葉だ……
公開メーリングリストは検索可能なアーカイブとしてパッケージ化されており、eメールのスレッドはグループチャットより構造的なのだ
GitlabではSlackが90日で削除されることで有名で、それ自体は良いことだと思うのですがドキュメンテーションの手間はどうしてもかかります
質疑応答をパッケージ化するという意味では、メーリスが回答のひとつなのでは、と思いました
ただ、Googleとはいえここを全員がちゃんと使い分けられるかというと……
3.5.3 YAQS:Q&Aプラットフォーム
知識の流通路を考えるにあたって、こうしたツールごとの差異をきちんと把握して使い分けるのは重要だなあと思う
3.6 自分の知識をスケールさせる:教えられるものは常にある
3.6.1 オフィスアワー
3.6.2 テックトークと講習
3.6.3 ドキュメンテーション
非対称なトレードオフは、少数の者の時間的な投資によって多数の者が恩恵を受けられるとすれば組織全体にとって良いことだが、適切なインセンティブがない限りそのような行動を促すのは困難となる。
わかる。wikiのメンテを全員が自発的にしてくれるようになるの難しい
言われてなるほどなと思ったけど、ドキュメンテーションにインセンティブと奨励を設けるというのを実践している会社は今のところ聞いたことないので、新しい知識を得たな〜と思った
3.6.4 コード
3.7 組織の知識をスケールさせる
3.7.1 知識共有の文化を養う
しかし Google において我々が確信しているのは、その環境の成果物(例えばコード) にのみ焦点を当てるより、まずは文化と環境に焦点を当てる方が良い結果につながるということ だ。
意図して文化を作っているということで、単純にすごいなと思った
文化が大事という考え方が必ずしも全員の共感や理解を得られるものではない(むしろ得られにくい)ものかなと自分は思っていたので
Googleはハッカー気質の人が多いからこれが効くのかもしれない
バランスが大事で、文化と環境を突き詰めるとムラ社会になる
イノベーティブであるための環境を作る
Google では、ピア(peer)ボーナスのプログラムがボトムアップ文化を形作る 1 つの方法 である。ピアボーナスは金銭的な賞与で、グーグラーが他のどのグーグラーに対しても相手の卓越 した業績を称えて贈れる、正式な表彰だ。
Gitlabでも同じような仕組みがあるのをそういえばどこかで見たな〜と思った
私の会社でもどんな指標か忘れたのですが、slackで積極的に発信やフォローしてくれる人へ少額ながらピアボーナス的なのがあるみたいです。(確かに社内の事務周りとか「わからん」って言うとどこからともなく助けてもらえてありがたい)
Uniposのようなイメージでしょうか
この制度を初めて知ったけど、「縁の下の力持ち的な人」が救われる制度だと思った。
3.7.2 カノニカルな情報源の確立
知りたい時に知りたい情報にアクセス出来ることが大事だなぁと。最初にドバッと大量の情報を渡されても理解できないし、溺れてしまうだけなので
go/リンク みたいなもので知りたいことに到達できるという前提がめっちゃいいなっておもった。Sharepointをいれるだけではダメなんだよ。。。みたいなのめっちゃ思う。
go/リンクの存在でドキュメントが構造化される、という効果もありそう
ただ、性善説を前提にしたシステムではある
カノニカルなコンテンツに明示的なオーナーがいることは、トピックが複雑になるほど決定的に重要となってくる。善意の読者は、何かが旧式になっていることには気づくかもしれないが、たとえツール環境のおかげで更新の提案が容易になっているとしても、修正に不可欠である重要な構造的変更を実施できる専門知識は持ち合わせてはいない。
ドキュメンテーションは気づいた人が更新してもいいのに対し、こちらはオーナーを設けて更新を制御している
知識の影響範囲に対応して、内容を制御する必要があるんだな〜と学び
3.7.3 情報の輪に参加し続ける
3.8 リーダビリティ:コードレビューを通じての標準化されたメンター制度
3.8.1 リーダビリティプロセスとは何か
リーダビリティをたもつためのレビュアー制度が自分達のためにボランティアでされているっていうのすばらしいなーっておもった。自分がもっているエキスパート性を自治のためにつかうのいい。
リーダビリティプロセス、初期の立ち上がりをどうしたのかものすごく気になる
個人の中にある暗黙知を徐々に形式知に変えていった&メンバーに暗黙知を再形成させた&それによってさらに形式知が改善された、という理想的なプロセス
余談も余談なんですが、「スマブラ」のバランス調整はディレクター1人で行っていたのを近い形でチームでやる体制にしたそうです
3.8.2 何故このプロセスがあるのか
リーダビリティとはこうした標準を強制しつつ同時に伝播させるメカニズムだ。リーダビリティプログラムの利点で主要なものとして、所属チームの組織慣習的知識のみならず、それ以上のものにエンジニアたちが触れられる、ということがある。
モノリポが好きなのでここの理由がめっちゃわかりみ。
そして、全社中のコードをレ ビューするリーダビリティレビュアーから成る中央集権的な集団が行うレビューを経なければなら ない。
3.9 結論
3.10 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
Googleはどこまでもスケールさせることへの情熱がつよいが、多くの企業ではスケールさせることが課題だとおもってもその課題解決の優先順位をあげるような決断を経営陣ができていない。(なにかちょっとでも対処していればそれでやった気になってしまったり、本当にスケールさせることが仕事をうまくいかせるために大事だとは思っていない or 実際にそうではない)
知識共有やそれに伴う文化づくりの重要性を経営レベルで認識してトップダウンで実行しているから?
途中でkyonさんが仰っていたように日本の会社はハックするような技術者が全然いないのに標準化とか統制する方向にばかりトップダウンで力を入れてしまいがちなのかなと思います。何も考えずそれに従うだけで、背景から考えて決まりやルールをもっとこう変えたらどうって考える人がいないような
そういう人が少ないのもそうだけど、少しそうだという人がいても言い出しにくいとかありそう
「言い出しっぺの法則」で必要以上に責任を負わされたり(マネージャーが責任を負わない)、工数貧乏性(時間的投資ができない)で新しい活動始めても自然消滅したり
「効率化」と言われて始まった手法が呪縛になってしまう
現場でどこまでできているか?
コミュニティへの質問は一部できている。大規模集団での心理的安全性やリーダビリティプロセスは取り組んではいるし、一部でうまくできているけど全社で見るとなかなかできていないと感じる。ドキュメンテーションは個人、チーム、部署、全社どれもまだまだ不足しているなーっていつも感じる。
全然まだできてない気がする... ナレッジを共有できる場所に貯めて欲しいとは言われるけど、あんまり活性化もしてない印象
共有できる形にナレッジを言語化するのがまず一定の難しさがあるし、インセンティブも不透明だからかな
テクニカルライティングって立派なスキルなのに軽視されすぎな気がする
「理科系の作文技術」さらっと読むだけでもずいぶん変わるのに
良さそうな本!今度読んでみよう
さっきkindleで買いました
全然出来てない( ;∀;)
ナレッジが人に溜まっているが、重要な機能を担当していたメンバーが2〜3年周期で入れ替わるので同じような問題が続出している、、、
ナレッジを組織のシステムに貯めようと、GitホスティングサービスのWikiを定期的に整理し始めた
進捗関連は鬼のように詰められるので心理的安全性が無いからか、進捗関連の共有があまり無い
ただ、ピアボーナスこそないものの、うちの部署では割とメンバーを褒め合う文化がある気がする
この本があるのになぜ実践する企業はすくないのか?
手を動かさないと儲からないビジネスモデルを取っている場合はそもそも不可能
手を動かさなくて良いビジネスモデルでも、普通は業務に直接コミットする人が評価される
業務に直接コミットするのは本人の自己効力感を支えるので、この点が問題になることは少ない
一方で、Googleはとにかく手を動かさなくても儲かる仕組みを構築して、社員をスーパーマンの集団に育てることに集中している印象を受ける
そうすると、業務に直接コミットする時間は減る。ラーニングモンスターでないとGoogleには合わない?
スーパーマンの集団によって創発した新しいビジネスが生まれるのを待っている
儲からなければすぐ捨てて次に行く
最近だとStadiaの撤退が話題になった
段々と知識共有が大事だってのは理解されるようになってきたと思うのですが、ボトムアップでそれをやっても評価に繋がらないのでわざわざやりたがらないかなぁ。
やはり評価
個人としてマネージャーがやってるのか、組織として評価する風土があるのかも全然違う
一番近いマネージャーが認めて承認欲求に訴える、制度を作ってトップダウンでお金を払う、いずれも3.7.1.2.に書いてあった
それの乗り越え方はなにか?
身もふたもないけど、勝手にお金が儲かる仕組み
Googleに関しては検索と広告で先行者利益を取ってハードウェアへ投資し、パブリッククラウドとG Suiteを構築した
お金があるからタダで配って参入障壁を築く&業務のコアに食い込んで当たり前にお金を払わせる
勝手にお金が儲かる仕組みがあったとしても、社内のナレッジが競争力そのものだという認識を作るのは難しい気がする
ナレッジベースへの貢献を評価する仕組み
スタートアップなんかで「OSSコミットを評価対象とする」というのは聞いたことあってエコシステムへのリスペクトという意味では良いけど、業務評価としては間接的過ぎる
継続的に社内のナレッジベースを作りつづけていて、それへの貢献を直接評価するというのはより本質的
ナレッジベースの構築は仕組みの構築、システムの導入、文化の生成、と多面的なのですごい人にコミットしてもらわなくてはいけない
すごい人がコミットしたくなるほどのインセンティブ
ステップを小さくするとしたらどうできそうか?
まずはチームの知識共有プロセスに対して小さく適用してみる
知識共有に対して、自分達の権限でできるインセンティブを考える
本でピアボーナスがもらえるような行為があったときに、チーム全員で感謝するとか
ランチをみんなで奢るとか
ナレッジベースを作る方針を打ち出してドキュメンテーションあたりから始めつつ、「3.2. 哲学」「3.3. 舞台を整える: 心理的安全性」の啓蒙活動
「ソフトウェアエンジニアリングの中心にいるのは人間」と考えている人は少数派なくらいな気がする