プロダクト開発における暗黙知との向き合い方 Strategies For Tacit Knowledge Transfer At Software Development 株式会社スタディスト　北野 勝久 1 Gaiax Technical Meetups 2019/06/25

北野 勝久 / @katsuhisa__ Katsuhisa Kitano 株式会社スタディスト 開発部 SRE Linux カーネルと同い年 Organizer of SRE Lounge 2

“伝えることを、もっと簡単に。”
 https://studist.jp/
 会社紹介 3

サービス紹介 4 サービス紹介

本発表の前提 ● サービス提供活動のライフサイクル全体を指して 「プロダクト開発」という用語を使用します ※プロダクト開発だけでなく、その後の運用も含む ● スタートアップの現場で学んだことを話しますが、 学びの活用先はスタートアップに限らない話をします 5

今日話すこと ● 暗黙知とは何か ● プロダクト開発において暗黙知と向き合う必要性 ● どうやって暗黙知と向き合うか ○ 暗黙知を認識する ○ 暗黙知を形式知にする ○ 暗黙知を共有する 6

暗黙知とはなにか 7

世の中には二種類の知がある ● 技術知⇔実践知 by 政治における合理主義 ● 形式知⇔暗黙知 by A Dynamic Theory of Organizational Knowledge Creation →いずれも区別可能だが、切り離せないもの 8

技術知と実践知 “要するに技術知は、その語の最も単純な意味において、 教える（teach）ことも学ぶ（learn）ことも できるのである。” “他方実践知は、教えることも学ぶこともできず、 伝え（implict）、習得する（acquire）ことが できるだけである” 9

暗黙知と形式知 “「暗黙知」は、主に現場で生み出されてくる 明文化や仕組みとなっていないような知恵です。 このような知恵は、現場が接している問題点や課題から、 湧き上がってくるものです。” “それに対して、「形式知」というのは、 その逆で明文化や仕組みとなっている知恵のことです。” 10

プロダクト開発において 暗黙知と向き合う必要性 11

12

13

14

暗黙知が多いと自律的に動けない ● 「◯◯さんに聞かないと分からない」場面が多いと、 プロダクト開発はスケールしない ○ 呼び出し頻度の高い知識であれば尚更 ● スタートアップは、急激な事業拡大を目指す ○ 事業拡大に伴い組織拡大が求められる場合は、 組織としてスケールしないことは減らしていく必要がある ※事業としては、スケールしないことに取り組むフェーズが必要な場合も 15

B2B SaaS では、一般的に急激な組織拡大が必要 “SaaS企業に「少数精鋭」は、ない。” “大規模で、人がたくさんいる状態を イメージして経営した方が良い。 会社の文化、採用基準、 コミュニケーションの取り方、 目標設定の仕方など、 これら全てを上手くまわしていくことが 出来ないと100人、300人が在籍する 組織の経営は不可能だ。” 16 https://hiromaeda.com/2019/03/25/100marryo/

暗黙知が多いと自律的に動きづらくなり、 組織がスケールしづらくなる ただし、暗黙知があることは悪いことではない 暗黙知に向き合い、改善できることがないか？を 自分自身に問いかけ続ける姿勢こそが重要 17

どうやって暗黙知と向き合うか 18

暗黙知を認識する≒暗黙知の特性を知る ● 個人の経験に依存しており 行動指向 ● 日常の経験に密接に関連 ● 定義が不十分、 定式化されていない、 または再定式化が必要 ● 手続き的知識の一種 （手続き的知識⇔宣言的知識） ● 形式知とは対照的に 活動の実行方法に関する知識 19 https://www.sciencedirect.com/science/article/pii/S1048984303000067

プロダクト開発における暗黙知の例 ● このサーバ何やってるんだっけ？ ● なんでこのミドルウェア動かしてるんだっけ？ ● このサーバのログってどうやって見る？ ● DB のカラム変更を含むデプロイって どうやって安全にロールバックするの？ ● 良い Pull Request の出し方って？ ● この構成だと、なぜスケールしない？ ● 検証用に EC2 欲しいけど、 インスタンスサイズはどうすればいい？ ● 負荷検証したいけど、どうすれば？ 20

暗黙知と形式知の関係性 21 A Dynamic Theory of Organizational Knowledge Creation http://bg.svilendobrev.com/1/Nonaka_1994-Dynamic_theory_of_organiz_knowledge_creation.pdf

暗黙知と形式知の関係性 “野中らの研究の重要なポイントは、 湧き上がってくる「暗黙知」が、「形式知」に代わり、 その「形式知」が、組織全体に広がり「暗黙知」として根付いたとき、 それらを土台にさらに新しい「暗黙知」が生まれてくるようなループが 組織内において知識を広げ、深めていくために必要なプロセスであると考えました。” 広木 大地. 『エンジニアリング組織論への招待』 22

暗黙知を形式知にする ● 設計観点・ポリシーについてチームで対話し、共通認識を洗い出す ○ スタディストSREでは、 話した内容をポリシーとしてまとめている 23

暗黙知を放置しないインフラ構築 ● インフラをコード化し、 バージョン管理する ● また、 Pull Request で変更を行い、 変更背景のやり取りを記録する 24 アプリケーションコードだけでなくシステムもバージョン管理すれば 組織パフォーマンスが向上することを述べた Puppet のレポート https://puppet.com/resources/whitepaper/2014-state-devops-report

暗黙知を共有する方法 1. Collaboration and Social Networks 2. Show Your Work 3. Storytelling 4. Tracking Lessons Learned 5. Guided Experience 6. Reinvention 25 http://theelearningcoach.com/learning/tacit-knowledge-transfer/

スタディストSREチームにおける暗黙知共有の実践 ● オンボーディング ● ポストモーテムとポストモーテム読書会 ● モブプロ・モブオペ ● 輪読会 ● チームのミーティング 26

オンボーディング ● 新メンバーが加わった際に オンボーディングを実施 ● 自身のキャリアを振り返りつつ チーム内で自己開示する場や、 チームの価値観を語る場を用意 → メンバー同士の信頼関係構築につながることが大事 27 https://medium.com/studist-dev/sre-onboarding-67faa61e473

メンバー間の信頼関係が暗黙知共有において重要 “it facilitates the building of mutual trust among members, and accelerates creation of an implicit perspective shared by members as tacit knowledge” 28 A Dynamic Theory of Organizational Knowledge Creation http://bg.svilendobrev.com/1/Nonaka_1994-Dynamic_theory_of_organiz_knowledge_creation.pdf

ポストモーテム ● SRE本で紹介されている プラクティスの一つ ● 障害振り返りのドキュメント ● 非難しないことが重要 ○ 問題⇔私たちの構図になるように ● うまくいったことや、 うまくいかなかったことを書く 29 Site Reliability Engineering https://landing.google.com/sre/books/

ポストモーテム読書会 ● チームが過去に経験した出来事を 知らないメンバーに共有する場 ● 当時の状況を伝え、経験について語る ● 議論しながら気づいた点は、 別ドキュメントに記録し、学んだことを行動にうつす 30

チームでの継続的な対話によって、 暗黙的な視点を概念化する 31 “the shared implicit perspective is conceptualized through continuous dialogue among members” A Dynamic Theory of Organizational Knowledge Creation http://bg.svilendobrev.com/1/Nonaka_1994-Dynamic_theory_of_organiz_knowledge_creation.pdf

モブプロ・モブオペ ● チームで一つの作業に取り組む ● 声に出して作業する ● 他人のワザを盗めたり、 分からないことを その場で質問できる 32

自分の仕事を見せることは暗黙知の移転を助ける 33 Tool: Working Out Loud “knowing what gets done is not the same as knowing how it gets done.” Show Your Work https://www.amazon.com/dp/B00JWNLV2C/

輪読会 ● 週に1時間弱の輪読会 ● 書籍の読み込みは事前に終わらせ、 お互いの知識の共有と対話に重点を置いている ● 「技術書を読む意義と輪読のすすめかた」という ドキュメントを社内に整備 ○ なぜやるか、どう進めるか ○ 技術書の読み方や向き合う姿勢も 暗黙知だと思っているから 34

チームのミーティング ● 次のような Agenda にしている ○ 採用関連 ○ 全社情報 ○ 障害振り返り/パフォーマンスチェック ○ 最新技術情報チェック ○ 勉強会参加情報交換 ○ Project/Issue の進捗確認 ○ 雑談したいこと ● 暗黙知となりうるような情報を共有するように 35

まとめ 36

まとめ ● プロダクト開発をするための組織のスケールにおいて 暗黙知とはうまく付き合う必要がある ● うまく付き合うには、暗黙知を認識して形式知化したり、 暗黙知を共有することが大事 ● 銀の弾丸はなく、 暗黙知は、チームとして継続的に向き合い続けるもの 37

おわりに 38

おわりに ● 確実性に対する執着をしないことが、 暗黙知と向き合うポイント ● 知識を整理する際は、 知識が今後変わる前提で情報設計しておくとよい ○ 更新するドキュメントとそうでないドキュメントを 明確に分ける 信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール https://muziyoshiz.hatenablog.com/entry/2017/01/10/074713 39

皆さんの工夫も教えてください！ 感想いただけるとめちゃ嬉しいです！ 40 ⇒ @katsuhisa__

● [増補版] 政治における合理主義 https://www.amazon.co.jp/dp/4326302232/ ● エンジニアリング組織論への招待 https://www.amazon.co.jp/dp/B079TLW41L/ ● スケールする開発組織の作り方 https://speakerdeck.com/naoya/sukerusurukai-fa-zu-zhi-falsezuo-rifang-number-jawsug ● Design for How People Learn https://www.amazon.co.jp/dp/B018OJP5QW/ ● Show Your Work https://www.amazon.com/dp/B00JWNLV2C/ ● A Dynamic Theory of Organizational Knowledge Creation http://bg.svilendobrev.com/1/Nonaka_1994-Dynamic_theory_of_organiz_knowledge_creation.pdf ● Strategies For Tacit Knowledge Transfer http://theelearningcoach.com/learning/tacit-knowledge-transfer/ ● Identifying and assessing tacit knowledge: understanding the practical intelligence of military leaders https://www.sciencedirect.com/science/article/pii/S1048984303000067 ● 情報 https://www.amazon.co.jp/dp/4344973283/ 41 参考文献