KAKEHASHI でテックリードをしている横田です。 KAKEHASHI に入社して早 5 年が経ちまして、色々な経緯から社内勉強会の運営をしてきました。 その中で感じた社内勉強会による共有知の有用性について、紹介させていただきたいと思います

KAKEHASHI の勉強会について

KAKEHASHI 社内では、エンジニア・非エンジニアに限らずさまざまな勉強会が立ち上がり、チームをまたがって学習する文化があります。 例えば、今まで私が参加した勉強会には以下のようなものがありました。

• 技術Web API の設計 輪読会
  ドメイン駆動設計 勉強会
  実践的データ基盤への処方箋 輪読会
  データ基盤勉強会
  チーム間アーキテクチャ共有会
  
• 組織文化プロダクトマネジメント 輪読会
  チームが機能するということはどういうことか 輪読会
  Measure What Matters 輪読会
  
• ドメイン知識医療情報システムの安全管理に関するガイドライン 輪読会
  
• 雑多チーム内相談会
  全社 LT 会
  

見ていただいてわかる通り、技術から組織文化に関わるものまで多岐に渡ります。 それらの勉強会を企画したり参加した経験から、会社で勉強会をする一番のメリットは共有知を作れることだと感じています。

共有知とは

であると定義します。専門用語を調べてみたのですが良いニュアンスの言葉が見つからなかったので、 ここでの共有知とはチームとしての意思決定のベースとなる知識

例えば、Python を書く時に変数名はスネークケースで書くことが一般的だとチームの開発メンバーで共有できていたとしたら、それは共有知になっていると言えます。 我々のチームでは患者情報をユーザーに提供する時には相互認証が必要という知識があったり、全社的にはタイムアウトは前段ほど長くした方が良いという知識があったりするのですが、 それらは社内勉強会によって作られた共有知です。

共有知の１番のメリットは、仕事をする上でのコミュニケーションコストが減り仕事がスムーズに進むにようになることです。ある事柄について相手がそれを知っていると分かっていると確認する項目がひとつ減り、それだけコミュニケーションの往復がなくなります。チームでプロダクト開発をする時には、コードレビューをするときも仕様の確認をするときもコミュニケーションは避けられないので、共有知があればあるほどスムーズに仕事が回ります。

ではなく集団の中で共有されている知識として考えています。共有知を作ることは SECI モデルでいう共同化の活動に当たり、形式知・暗黙知の両方を含む概念だと考えています。 ゲーム理論の文脈での共有知識がニュアンスとして近い考えていて、ある事柄を全員が知っていることを知っている前提をもとにしたコミュニケーションの省略が、社内勉強会の大きなメリットだと考えています。ナレッジマネジメントの理論の観点ですと集合知・暗黙知・形式知などの用語がありますが、共有知は集合知とは異なるもので集団としての知性

共有知の範囲

どのグループで知識を共有すべきか、は難しい問題だと思います。

勉強会には拘束時間が生まれます。共有知として持っていてメリットがある人とそうではない人がいるため、何でもかんでも共有知にすれば良いわけではなくメリットがある人同士で共有知にすることが重要です。 範囲を上手く活用できると、チーム内のエンジニア同士の勉強会ではチームの利用技術に特化したトピックについて話すことでコードレビューの時に意思決定の背景を理解できてやりとりが減りレビューの時間短縮に繋がったり、チームのエンジニアやプロダクトマネージャーも含めたプロダクトマネジメントの勉強会によって α 版・β 版・GA 版などの開発フェーズの認識を揃えられたりなど、適切な範囲での知識の共有は良い効果が得られます。 一方で、範囲の設定に失敗した例としてフロントエンドエンジニアが多い勉強会でバックエンドの話をしても得られるメリットは限定的で、無駄な拘束時間が発生してしまうなどのデメリットの方が大きく出てしまうケースもあるかと思います。

知識を共有する範囲は、チームが良いのか？全社が良いのか？特定のスキルセットを持った技術者グループが良いのか？などの検討が必要です。

共有知とユビキタス言語

共有知とユビキタス言語 は役割としては似ているなと感じます。 ユビキタス言語は職種に限らず使えるチーム内の共通言語で、それがあると言葉の認識の齟齬を減らせるのでコミュニケーションコストを減らせるメリットがあります。

という言葉が何を意味するのか？はユビキタス言語であり共有知であるとも言えます。関係としては、共有知はユビキタス言語を包含する知識と言えるかなと思います。例えば、ベストプラクティスなどのソリューションは共有知にはなると思うのですがユビキタス言語として表現するのは難しいです。ユーザー

担当領域を超えて共有する

個人的には、担当領域を超えて共有知を作ることを推奨しています。 我々は薬局ドメイン向けのシステムを開発していますが、ドメインエキスパートの薬剤師・営業・エンジニア・デザイナー・法務などさまざまな職種の人が関わっています。 やはり専門外の事になると、どうしても判断してもらう必要が出てくるのでコミュニケーションが発生しますが、担当領域を超えて知識を身につけておけばコミュニケーションを減らせます。

例えば、我々のチームのプロダクトマネージャーは、Python を書けるぐらい技術への興味がありシステムの仕組みを理解してくださっているのですが、ユーザーからの質問に対して本来エンジニアが質問に回答すべき内容であっても回答してくれると、ユーザーとプロダクトマネージャー間でコミュニケーションが完結します。また、エンジニアが薬局ドメインの知識を知っておけば仕様バグなどに気づきやすくなり、開発の手戻りが少なくなります。

共有知についての課題

共有知を増やすことは重要ですが、新しいチームメンバーが増えた状況を考えると共有知を前提にしたコミュニケーションは内容がハイコンテキストになりやすく、新しいメンバーがチームに馴染むための敷居が高くなる課題があります。 この点は解決がなかなか難しいのですが、我々のチームでは採用と入社後のフォローでカバーしています。

採用に関しては、

• 前提知識を期待すると募集要項に書いておく
• 面接で一般的な知識については確認する
• 面接で継続的な学習の癖について確認する

入社後のフォローとしては、

• 推薦図書を用意しておく
• 最低限必要な知識について動画コンテンツを用意しておく
• 最低限必要な知識についてのチェックリストに沿って少しずつ身につけてもらう
• 入社後 1 ヶ月間は、メンターが毎日 1on1 でわからないことなどをフォローする
• チームメンバーが分報を定期的に確認し、適宜フォローする
• ユビキタス言語（社内用語集）を作っておき、必要な時に参照してもらう

などの取り組みをしています。 これだけではカバーできないものも当然あるので、それについては適宜フォローしている状況です。

ここで大事な点は、共有知を暗黙知にしないことと、 新しいメンバーが知っていて我々が知らない知識も当然あるので、お互いに知識を共有し新たな共有知に昇華していくことだと考えています。

KAKEHASHI の文化

を掲げていて、情報を形式知としてオープンにし謙虚に学び続ける姿勢を良しとしています。 また、継続的な学習を奨励していて月 1 万円まで書籍の購入費を補助してくれる仕組みがあったり、CEO が機械学習を実践するなどトップが領域を超えて学習していたり、色々なメンバーが勉強会を企画したりしています。KAKEHASHI では行動規範（Value）として情報対称性
や無知の知

この文化のおかげで、私としては 5 つの勉強会に参加し 3 つの勉強会を運営して情報のインプットとアウトプットをバランスよく行い継続的な学習を実現できています。 最後に、いま運営している勉強会とその効果について紹介できればと思います。

今までの勉強会の例

チーム内勉強会

• 目的近いチームで共有知を作るための勉強会
  
• 運営方法頻度: 週 1 回
  時間: 1 時間
  参加対象者: 特定のチームのエンジニアメンバー(参加は任意)
  テーマ: 最近気になっている技術や相談事などを共有する
  内容の決め方: 毎週の開催枠に発表したい人が自由に発表したい内容を書き込む。開催枠に発表内容が 1 つもない場合はコードリーディング会になる
  
• メリット最近使ってみた CI/CD のツールやエディタの機能など、すぐに実践できる知識が多かった
  共有知としてシェアしたい情報を気軽に交換できた
  

チーム間アーキテクチャ共有会

• 目的チーム間でシステムのアーキテクチャについて共有する
  
• 運営方法頻度: 2 週間に 1 回
  時間: 1 時間
  参加対象者: アーキテクチャに興味があるエンジニアメンバー(6 チーム それぞれ、1 人ぐらい)
  テーマ: 自分のシステムのアーキテクチャについて紹介
  内容の決め方: 3 回に 1 回、振り返り会を実施し、その際に次の予定を決める
  
• メリット他のチームのシステムの仕組みを知れるので、チーム間で連携を取るときに構成を考えやすくなった
  ログイン・セキュリティ・開発環境(ステージング・本番)など、チーム間で揃えておいた方が良い情報の共有の場として機能した
  

データ基盤勉強会

• 目的データ基盤のトレンドをキャッチアップする
  
• 運営方法頻度: 週 1 回
  時間: 30 分
  参加対象者: データ基盤の技術に興味があるエンジニアメンバー
  テーマ: データ基盤に関わるトピックについて
  内容の決め方: 不定期にテーマ決めの会を実施し数週間分のテーマを決める
  
• メリットデータ基盤まわりの用語について整理でき(データスチュワードなど)採用の募集要項を作成する際に役立った
  チーム間で連携するデータ基盤のモデリングについての共通認識を作れた。（メダリオンアーキテクチャの考え方でデータを複数の層に分けようなどの方針の合意につながった）
  

まとめ

勉強会をする意義は多々あると思いますが、今回はその中でも共有知を作る点にフォーカスして紹介させていただきました。 共有知を増やせればコミュニケーションコストを削減できシステムの開発スピードを上げられます。 社内の文化を作るときの参考になれば幸いです。 会社を跨いだ合同オンライン勉強会なども興味がある方はお声がけいただけますと嬉しいです。

参考資料

• ナレッジマネジメント(wikipedia)
• 共有知識(wikipedia)
• ドメイン駆動設計(wikipedia)
• 普通の薬剤師が、気づいたら薬局向けサービスのプロダクトマネージャーになっていた話
• 非エンジニア CEO の僕だけど、カケハシをもっとテックな会社にしたくて、機械学習エンジニアを目指すことにした