プロダクト開発における暗黙知との向き合い方

Gaiax Technical Meetups #スタートアップで開発 でお話した資料です！
https://gaiax.connpass.com/event/133136/

プロダクト開発をするための組織のスケールにおいて暗黙知とはうまく付き合う必要があります。
暗黙知を形式知化したり、暗黙知を共有したりする方法について話しました。

Transcript

1. プロダクト開発における暗黙知との向き合い方 Strategies For Tacit Knowledge Transfer At Software Development 株式会社スタディスト　北野 勝久 1 Gaiax Technical Meetups 2019/06/25
2. 北野 勝久 / @katsuhisa__ Katsuhisa Kitano 株式会社スタディスト 開発部 SRE Linux カーネルと同い年 Organizer of SRE Lounge 2
3. “伝えることを、もっと簡単に。”
 https://studist.jp/
 会社紹介 3
4. サービス紹介 4 サービス紹介
5. 本発表の前提 • サービス提供活動のライフサイクル全体を指して 「プロダクト開発」という用語を使用します ※プロダクト開発だけでなく、その後の運用も含む • スタートアップの現場で学んだことを話しますが、 学びの活用先はスタートアップに限らない話をします 5
6. 今日話すこと • 暗黙知とは何か • プロダクト開発において暗黙知と向き合う必要性 • どうやって暗黙知と向き合うか ◦ 暗黙知を認識する ◦ 暗黙知を形式知にする ◦ 暗黙知を共有する 6
7. 暗黙知とはなにか 7
8. 世の中には二種類の知がある • 技術知⇔実践知 by 政治における合理主義 • 形式知⇔暗黙知 by A Dynamic Theory of Organizational Knowledge Creation →いずれも区別可能だが、切り離せないもの 8
9. 技術知と実践知 “要するに技術知は、その語の最も単純な意味において、 教える（teach）ことも学ぶ（learn）ことも できるのである。” “他方実践知は、教えることも学ぶこともできず、 伝え（implict）、習得する（acquire）ことが できるだけである” 9
10. 暗黙知と形式知 “「暗黙知」は、主に現場で生み出されてくる 明文化や仕組みとなっていないような知恵です。 このような知恵は、現場が接している問題点や課題から、 湧き上がってくるものです。” “それに対して、「形式知」というのは、 その逆で明文化や仕組みとなっている知恵のことです。” 10
11. プロダクト開発において 暗黙知と向き合う必要性 11
15. 暗黙知が多いと自律的に動けない • 「◯◯さんに聞かないと分からない」場面が多いと、 プロダクト開発はスケールしない ◦ 呼び出し頻度の高い知識であれば尚更 • スタートアップは、急激な事業拡大を目指す ◦ 事業拡大に伴い組織拡大が求められる場合は、 組織としてスケールしないことは減らしていく必要がある ※事業としては、スケールしないことに取り組むフェーズが必要な場合も 15
16. B2B SaaS では、一般的に急激な組織拡大が必要 “SaaS企業に「少数精鋭」は、ない。” “大規模で、人がたくさんいる状態を イメージして経営した方が良い。 会社の文化、採用基準、 コミュニケーションの取り方、 目標設定の仕方など、 これら全てを上手くまわしていくことが 出来ないと100人、300人が在籍する 組織の経営は不可能だ。” 16 https://hiromaeda.com/2019/03/25/100marryo/
17. 暗黙知が多いと自律的に動きづらくなり、 組織がスケールしづらくなる ただし、暗黙知があることは悪いことではない 暗黙知に向き合い、改善できることがないか？を 自分自身に問いかけ続ける姿勢こそが重要 17
18. どうやって暗黙知と向き合うか 18
19. 暗黙知を認識する≒暗黙知の特性を知る • 個人の経験に依存しており 行動指向 • 日常の経験に密接に関連 • 定義が不十分、 定式化されていない、 または再定式化が必要 • 手続き的知識の一種 （手続き的知識⇔宣言的知識） • 形式知とは対照的に 活動の実行方法に関する知識 19 https://www.sciencedirect.com/science/article/pii/S1048984303000067
20. プロダクト開発における暗黙知の例 • このサーバ何やってるんだっけ？ • なんでこのミドルウェア動かしてるんだっけ？ • このサーバのログってどうやって見る？ • DB のカラム変更を含むデプロイって どうやって安全にロールバックするの？ • 良い Pull Request の出し方って？ • この構成だと、なぜスケールしない？ • 検証用に EC2 欲しいけど、 インスタンスサイズはどうすればいい？ • 負荷検証したいけど、どうすれば？ 20
21. 暗黙知と形式知の関係性 21 A Dynamic Theory of Organizational Knowledge Creation http://bg.svilendobrev.com/1/Nonaka_1994-Dynamic_theory_of_organiz_knowledge_creation.pdf
22. 暗黙知と形式知の関係性 “野中らの研究の重要なポイントは、 湧き上がってくる「暗黙知」が、「形式知」に代わり、 その「形式知」が、組織全体に広がり「暗黙知」として根付いたとき、 それらを土台にさらに新しい「暗黙知」が生まれてくるようなループが 組織内において知識を広げ、深めていくために必要なプロセスであると考えました。” 広木 大地. 『エンジニアリング組織論への招待』 22
23. 暗黙知を形式知にする • 設計観点・ポリシーについてチームで対話し、共通認識を洗い出す ◦ スタディストSREでは、 話した内容をポリシーとしてまとめている 23
24. 暗黙知を放置しないインフラ構築 • インフラをコード化し、 バージョン管理する • また、 Pull Request で変更を行い、 変更背景のやり取りを記録する 24 アプリケーションコードだけでなくシステムもバージョン管理すれば 組織パフォーマンスが向上することを述べた Puppet のレポート https://puppet.com/resources/whitepaper/2014-state-devops-report
25. 暗黙知を共有する方法 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/
26. スタディストSREチームにおける暗黙知共有の実践 • オンボーディング • ポストモーテムとポストモーテム読書会 • モブプロ・モブオペ • 輪読会 • チームのミーティング 26
27. オンボーディング • 新メンバーが加わった際に オンボーディングを実施 • 自身のキャリアを振り返りつつ チーム内で自己開示する場や、 チームの価値観を語る場を用意 → メンバー同士の信頼関係構築につながることが大事 27 https://medium.com/studist-dev/sre-onboarding-67faa61e473
28. メンバー間の信頼関係が暗黙知共有において重要 “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
29. ポストモーテム • SRE本で紹介されている プラクティスの一つ • 障害振り返りのドキュメント • 非難しないことが重要 ◦ 問題⇔私たちの構図になるように • うまくいったことや、 うまくいかなかったことを書く 29 Site Reliability Engineering https://landing.google.com/sre/books/
30. ポストモーテム読書会 • チームが過去に経験した出来事を 知らないメンバーに共有する場 • 当時の状況を伝え、経験について語る • 議論しながら気づいた点は、 別ドキュメントに記録し、学んだことを行動にうつす 30
31. チームでの継続的な対話によって、 暗黙的な視点を概念化する 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. モブプロ・モブオペ • チームで一つの作業に取り組む • 声に出して作業する • 他人のワザを盗めたり、 分からないことを その場で質問できる 32
33. 自分の仕事を見せることは暗黙知の移転を助ける 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/
34. 輪読会 • 週に1時間弱の輪読会 • 書籍の読み込みは事前に終わらせ、 お互いの知識の共有と対話に重点を置いている • 「技術書を読む意義と輪読のすすめかた」という ドキュメントを社内に整備 ◦ なぜやるか、どう進めるか ◦ 技術書の読み方や向き合う姿勢も 暗黙知だと思っているから 34
35. チームのミーティング • 次のような Agenda にしている ◦ 採用関連 ◦ 全社情報 ◦ 障害振り返り/パフォーマンスチェック ◦ 最新技術情報チェック ◦ 勉強会参加情報交換 ◦ Project/Issue の進捗確認 ◦ 雑談したいこと • 暗黙知となりうるような情報を共有するように 35
36. まとめ 36
37. まとめ • プロダクト開発をするための組織のスケールにおいて 暗黙知とはうまく付き合う必要がある • うまく付き合うには、暗黙知を認識して形式知化したり、 暗黙知を共有することが大事 • 銀の弾丸はなく、 暗黙知は、チームとして継続的に向き合い続けるもの 37
38. おわりに 38
39. おわりに • 確実性に対する執着をしないことが、 暗黙知と向き合うポイント • 知識を整理する際は、 知識が今後変わる前提で情報設計しておくとよい ◦ 更新するドキュメントとそうでないドキュメントを 明確に分ける 信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール https://muziyoshiz.hatenablog.com/entry/2017/01/10/074713 39
40. 皆さんの工夫も教えてください！ 感想いただけるとめちゃ嬉しいです！ 40 ⇒ @katsuhisa__
41. • [増補版] 政治における合理主義 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 参考文献