エンジニア組織の文化確立のための参考書籍
参考：Googleのソフトウェアエンジニアリング
https://www.oreilly.co.jp/books/9784873119656/
https://abseil.io/resources/swe-book/html/toc.html
エンジニア組織の知識共有で大事なこと1点
あなたの属する組織は、あなたの問題領域を誰よりも理解している。 （インターネット上の誰よりも）
組織が持つ知識を普及させるためには
問題の答えを知る専門家
専門家の知識を流通させるメカニズム
この二つが必要不可欠となる
知識を流通させるメカニズムには、質問する、知っていることをメモするなどの単純なものから、チュートリアルや講習など高度に構造化されたものも存在する。
しかし、最も重要な点は、組織に学びの文化が存在すること。である。
地震に知識がかけていることを認めない器の狭い組織では知識の共有は果たせない。
新卒エンジニアの悩みあるある6点
組織全体で専門知識を共有することは簡単な作業ではありません。
強力な学習文化がなければ、問題が発生します。
心理的安全性の欠如
新卒エンジニアにとっての最も大きい悩みの種がこれです。
「心理的安全性が欠如している環境」とは罰せられることを恐れて価値あるリスクを取る行動をやめてしまったり、人の前で間違うことを恐る環境のことを指します。
情報の孤立化
お互いのチームがコミュニケーションを取らない、または共有リソースを使用しない、などが原因で組織のさまざまな部分で発生する知識の断片化のことを情報の孤立化と読んでいます。
日本の歴史の中での「鎖国」にあたる状態で、お互いのチームは独自の文化が形成されます。 独自の文化や多様性は聞こえはいいですが実際には次のような弊害をもたらしてしまいます。
- 情報の断片化
お互いが断片的な知識しか持たないことにより、組織全体の体型的な知識を持つチームや個人が存在しない状態。
- 情報の重複
これは「車輪の再発明」に当たります。
- 情報の競合
各チームでの改修内容やリソースの確保で「競合」が発生してしまうこと。
新卒エンジニアのほったらかし〜単一障害点〜
重要な情報を 1 人しか入手できていない場合に発生する障害で、チームの重要なメンバーの離脱などにより突如として表出するタイプの障害です。
これは具体的には次のような手順により、善意から発生することがある問題です。
「自分がその作業をやった方が早い」という誤認
「あなたに変わって引き受けてあげましょう」という仕事の完全な譲渡
「一人だけに任せるのはよくないな」と思いつつも、一人に任せた方が短期的には早いので知識を共有しない。
長期的にその仕事をできるのが2で引き受けた人物だけになってしまう。
この問題が発生するそもそもの原因は「自分がその作業をやった方が早い」という誤認が元になっていますが、 この考え方は別の問題点を発生させてしまうのです。
それが、オール オア ナッシングの専門知識 という問題です。
共有されない専門知識〜オールオアナッシングの専門知識〜
「すべて」を知っている人と初心者に分かれており、中間層が存在しない状態。
この問題は専門家が常に自分ですべてを行い、メンタリングや文書化を通じて新しい専門家を育成する時間をとらない場合、に発生します。
このシナリオでは、知識と責任はすでに専門知識を持っている人に蓄積され続け負担は増加しいつか退職にまで追い込まれます。
また、新しいチームメンバーや初心者はこの状態に自力で対処し、やっとの思いでチームの戦力になるのです。
ソースコードの丸コピー
理解のない擬態。通称猿真似。
これは通常、その目的を理解せずに無目的に行動パターンやコードをコピーすることを特徴とし、 時には自分が何をしているのかわからないまま作業を行ってしまいます。
ですが新卒のメンバーはただ席に座っているだけでは居心地が悪いのです。
触りたくないコード（お化け墓地）
何か大きな障害が起こるのではないかと考え、変更したりするのを皆が避ける場所。
お化け墓地は、人々が恐怖と迷信のために行動を避けることを特徴としています。
新卒エンジニアの教育で重要なこと
新卒エンジニアの教育で最も重要な点は「文書化」である
文書化された知識は、チームだけでなく組織全体にまで拡大することができます。 チームwikiなどのツールにより、多くの資料作成者が自身の専門知識をより大きなグループと共有できます。
例えばドキュメント自動生成ツール（JsDocやJavaDocナドナド）を使うことで、ソースコードの更新とともに知識を最新版に保つことができます。
ソースコードから自動的にドキュメントを作成するツール（JSDoc）
文書化された情報は1対1の会話による共有よりもスケーラブルですが、そのスケーラビリティにはいくつかのトレードオフがあります。 最も大きいコストは、文章を最新の状態に維持するために必要な追加のメンテナンスコストが伴うことです。
また、文書化できない表現が存在することや、専門家が必ずしも自身の知識を広めることに長けているとは限らないことを考えると、文章のみの情報共有は危険です。
やはりどこかで「コミュニケーションによる情報共有」は行わなければならないようです。
新卒エンジニアの教育で重要なこと: 心理的安全の確保
学習環境を促進するには、心理的安全性が最も重要です。
新しいことを学ぶためには、まず自分が理解できない範囲があるということを認めなければなりません。そのような誠実さを罰するのではなく、歓迎すべきです。
そもそも最高の学習環境とは物事を試すことができ、失敗しても安心できること（身をもって体験できること）です。 健全な環境では人々は安心して質問をしたり、間違えたりして、新しいことを学びます。 これは、すべての Google チームの基本的な期待事項です。
新卒エンジニアの教育で重要なこと:メンター制度の確保
Google では、「Noogler」（新しい Google 社員）なエンジニアが入社したらGoogleの文化について教える制度が存在します。
心理的安全性を確立するための重要な方法の1つは、Noogler にメンターを割り当てることです。 新卒エンジニアは正式に任命されたメンターに助けを求めることで、同僚の時間を奪うことを心配することなく質問することができます。
Googleではメンターになるには次の資格が必要です。
重要なことは、メンティーが他に誰にアドバイスを求めたらよいかわからない場合に、メンターが相談できるセーフティネットになることです。 このメンターはメンティーと同じチームに属していないため、新卒エンジニアは難しい状況でも安心して助けを求めることができます。
新卒エンジニアの教育で重要なこと:交流時の禁止項目
新卒エンジニアは1on1での会話はおそらく可能だと思いますが、大規模なグループになるにつれて心理的安全性確保の難易度は跳ね上がります。
グループ内部でのより高いレベルの心理的安全性の確保のために、次の4つの項目を必ず禁止してください。
- 驚いたふりをする
キューとスタックが何かを聞いたことないの!?
驚いたフリとは詰まるところ、教える側にとっても想定外の事態であるということになります。
「基本的な質問や間違いは正しい方向に導くためのヒントになるということを肝に銘じておくべきです。
この傾向が続いてしまうとメンバーは「教えてもらう人を不安にさせてはいけない」と考えるようになり、自身の知識の欠如を認めるのを恐れさせます。
- ここだけの話だけどね...
想定外かもしれないけど... えっと実はね、裏側ではAIが動いているんだよ
自分の知識を鼻にかけて話す方法。「これ以外に秘密になっているロジックがあるのではないか？」と思わせてしまう。
ハンズオンとは、「自分の知識を披露する目的で説明が行われているショー」ではない。
質問者が学習できるように説明するということが大事。
- 責任のない人が話の腰をおる
会話に責任を持って参加していないにも関わらずに口出しして目下の議論の腰を折ること。
- 勝ち負けを決めない
偏見 (人種差別、年齢差別、同性愛嫌悪) のこと。
交流は、解決策を見つけるためのディスカッションです
新卒エンジニアの教育で重要なこと:リーダーが手本を見せる
リーダーシップの役職についてている人にとっては、「同僚に質問し続けること、自分の知らない部分を曝け出すこと、初心者のような質問でもし続けること」を チームメンバーの前で行い、常に学び続ける姿勢をメンバーに身をもって教えなければなりません。
シニアであることを誤って、「なんでも知っていること」と同一視しないことが重要なのです。
リーダーが公然と質問をしたり、知識を書いている部分を表に出し続けたりすると、それに続いても問題ないのだとメンバーは励まされます。
新卒エンジニアの教育で重要なこと:ナレッジを貯める
1on1での会話ベースのコミュニケーションは知識を得るのに有用ですが、会話ベースのコミュニケーションからツールを使ったオンライン上の1対多のコミュニケーションも有用です。
例えば、グループチャット、メーリングリスト、Q&Aシステムはそれぞれ不完全ではありますが、別々のトレードオフを持ちお互いに補完しあっています。
また、それぞれのツールの運用方法にもコツが存在します。
以下個人の意見）質問をナレッジとして蓄積する際のキーワードは、「コミュニティ」「グループが見えるかどうか」「タグ付け」だと思います。
「コミュニティ」とは自分と関係のある小グループのことです。 例えば、社内SEのECチームだったり、部署を跨いだアプリチームだったり、ダッシュボードプロジェクトなどです。 個人個人にはどのコミュニティに属するかを選択し、その中での行動に責任を持って質問に回答するのが良いと考えます。 「コミュニティ」一覧は全体から見える必要があります。
「グループが見えるかどうか」とは「チャットとQAサイト」の違いについてです。 例えば、チャットに対しては質問者は誰が返答するのかをある程度想定して質問を書かなければならないため、「上手い質問をしなければならない」という責任に駆られます。 ですがQAサイトであれば質問に答えるかどうかは回答者に委ねられており、曖昧な質問でも許容されることがほとんどです。
「タグ付け」とは「QAサイト」や「ナレッジ共有システム」で使われる言語や分野のことです。 以前質問した内容やヒントを探す際に「タグ付け」機能を利用して投稿を遡ることで簡単にアクセスできます。 この「タグ付け」があるのとないのとでは、情報の再利用性に雲泥の差が出るのです。
以上個人の意見でした。
備考
title:新卒エンジニアの教育で重要なこと6つ【Googleのソフトウェアエンジニアリング】
description:新卒エンジニアの教育で重要な6項目、「文書化、心理的安全の確保、メンター制度の確保、交流時の禁止項目、リーダーが手本を見せる、ナレッジを貯める」等々について
category_script:True
https://abikosan.com/wp-content/uploads/2018/06/Google-Logo-New.jpg
