【後編】ゆるさと深さを両立！社内ナレッジ共有イベントレポート
こんにちは、ソリューション開発部の筒です。
この記事は、「ナレッジ共有」をテーマにしたイベントレポートの後半です！
ナレッジを共有するために、各部門・プロジェクトでどのような取り組みをしているのか。参加者のみなさんから共有された現場ならではの取り組みを多数紹介します。
■前編：イベント背景や仕組み設計について
■後編（この記事）：実際の社内事例紹介
前編はこちらです↓
https://devlog.arksystems.co.jp/2026/06/02/23531/実際の社内事例
前編で紹介した前提知識の紹介が完了して、いよいよ本番の事例共有会です。
参加者が持ち寄った「うちはこうしています！」が、具体例としてどんどん出てきました。
それぞれの事例がSECIモデルのどこに当てはまるのか、下記の図をぜひ参考にしながらお読みください。
共同化①：新人が育つ「囲む会」
青山さん：
「雑談とか、普段の共同化って何かしてます？」参加者A：
「うちは……『新人くんを囲む会』みたいなのがあります。新人教育の会っていうか。文字通り新人さんを取り囲んで、いろいろ教える会です」青山さん：
「いいですね、囲む会。それ何人くらいが参加するの？」参加者A：
「だいたい5人くらいです」青山さん：
「まさに、自分たちの暗黙知を新人の暗黙知にしていく会ですね」
別チームでは「囲む」というより「常時つなぐ」形式で実践していました。
参加者B：
「新人が入ったら、ほぼ1日中通話をつなげておくんです。誰かは常に質問に答えられる状態にしてます」青山さん：
「期間はどれくらい？」参加者B：
「目安2〜3か月くらいです」青山さん：
「話しかける心理的ハードルが下がるし、暗黙知が流れる仕組みとして強いですね」
「質問していいよ」が仕組みで担保されていると、知識って回りやすいね、という空気がありました。
共同化②： 社内Twitterや部会雑談で「話しかけやすさ」を作る
参加者C：
「うちでは部内専用の『Twitter』のようなものをTeams上で作ってます。一人がひとつチャネルを持ってて、気になってる話題をなんでも投げる感じで」青山さん：
「たまに盛り上がってますよね。でも反応を求めてないのが良い」
「無反応で音楽の話しかしない人がいてもいい（笑）」参加者C：
「あとは部内のみんなが集まる『部会』の最後に、いくつかのグループに分かれて雑談をするタイムを設けたりもしています」青山さん：
「井戸端会議って、知らない人にいきなり話しかけないですよね」
「だからこそ、そういう場で誰がどんな感じか知っておくと、しゃべる心理的ハードルが下がる。トピックが共有されるだけでも意味があると思います」
「資料を作る」だけじゃなくて、
話しかけやすさの土台を作るのも立派なナレッジ共有設計だなと感じた瞬間でした。
※この取り組みの詳細はこちら！
表出化①：社内版「知恵袋」で聞ける文化をつくる
参加者D：
「うちでは社内専用の『知恵袋』みたいなものを運用してます。技術寄りのQ&Aを社内だけで閉じて共有するやつです」青山さん：
「へえー。狙いはあるんですか？」参加者D：
「単純に、ベテランの人に知識を共有してほしいってお願いするだけだとわざわざ登録する動機がない問題があって……」
「だから逆に、分からないことを発信したら答えが集まる形にしたんです」青山さん：
「押し付けじゃなくて、引き出す型だ」参加者D：
「そうです！ 質問を起点に詳しい人が見て答えるっていう方針です」
運用の具体的な工夫が続きます。
参加者D：
「質問しても回答が付かないこともあるので、最近は詳しい人に通知が行く仕組みにしました」
「1週間回答が付かなかったら、催促が飛ぶみたいな」青山さん：
「メンションを自動で？ なるほど。回るようになりそうですね！」
ただし、まだ課題も残っているようです。
参加者D：
「そうなんですよ。そうなんですけど、実は、別で全然別のサービスでもナレッジを貯めてて……」
「両方あるから、どっちに載せるか迷うんですよね」青山さん：
「分散しちゃう問題か……。せっかく知識を集めても、散らばっているとつながりづらい。これ、まさに『連結化むずい』ですね」参加者（周囲）：
「あるある……」
表出化②：ヒヤリハット共有は「見るのは強制、書くのはお願い」
参加者E：
「うちは『ヒヤリハット確認』をしていて、障害になりかけたことや、ちょっとまずいと思ったことを、とにかくスプレッドシートに全部書き出しています」青山さん：
「どう回しているんですか？」参加者E：
「月1回、各自で確認しましょうってルールです。最低毎月2件は見てねって決めています」青山さん：
「任意じゃなくて強制で？」参加者E：
「見るのは強制に近いですね。書くのは……『気づいたら書いてね』って感じです」
この「書くより見るを強める」設計が実務的でした。
その場でも「確かに、書けって言うより『見ろ』の方がやりやすいよね…」という空気になっていました。
内面化①：黙ってもくもく作業する会
参加者F：
「うちにもいろいろ資料はあるけど、忙しいと結局見ないし、見ても覚えてないんですよね」
「必要になってから探す……になりがちです」青山さん：
「あーそうそう。だから、知ったことを実際に使う場が必要なんじゃないかと思っていて」青山さん：
「最近ソリューション開発部でやってるWebアプリの勉強会があるんですけど、あれ面白いんですよ」
「みんな通話だけつないで、無言でひたすらコード書いてる（笑）」
「もちろん、何か聞きたいこととか雑談があったらそのまま話します。でも特になければ喋らないこともある」参加者G：
「逆に集中できそう……」青山さん：
「これ、暗黙知がどんどん増えるやつです。内面化の場になり得ますね」
知識を自分のものにするには、結局「学ぶ場というよりやる場が必要」のようです。
連結化①：標準化テンプレ、でもスケールが…
青山さん：
「連結化、誰かやってる人いませんか？ なにかを標準化するとか」参加者H：
「過去に、サーバー仕様の標準化テンプレを用意していました」
「セキュリティ要件とかネットワーク要件とかの共通化しやすいところをベースとしてテンプレ化して、用途だけ埋めればOKという形にしたんです」青山さん：
「なるほど。いろんなベストプラクティスがマージされるやつだ」参加者I：
「うちではレビュー会に出す作業計画書のベースを作っていて、チェック項目が大量にあるんです」
「まずチェックを埋めて、落としやすい穴をふさいでからレビューに出す、みたいな」青山さん：
「テンプレを使う前提のフローやテンプレへの導線があるのが強いですね」
成功例の熱量と同時に、「ここまでやるとスケールが大きくなっちゃうよね」という感覚も共有されていて、やはり実務の場に基づいた会話になっていました。
みんな共通の悩みどころ
会話が進むほど、みんなの視線は実例の少ない2つに集まっていきます。
「連結化＝複数の形式知をまとめて標準化すること」と、「内面化＝使って自分のやり方にすること」です。
青山さん：
「連結化って難しい、事例もなかなか出てこないです。みんな右上（表出化）のところばかり出てくる」参加者：
「連結化してみんなに共有（標準化）したとしても、使う場がないと『関係ない』で止まってしまいそうです。内面化も進みづらいですね」青山さん：
「そう。できたとしても、使う場がないと『俺関係ない』になりがち」
「だから使ってみる場を設計できると内面化が起きやすいんじゃないかな。もくもく会みたいに」
さらに、モチベーションの話も出ました。
参加者：
「知識の共有を促しても、その結果自分が楽になるってことが示せないと難しいですよね」
「他の人も楽になるってメリットが見えづらいこともあるし……」青山さん：
「属人化への対処でいうと、強制力（例えばジョブローテ）も選択肢としてはある」
「でもそれが好きじゃない人も多いから、引き出す設計も大事かもしれないです」
成功談だけではなく、詰まっていることも同じ熱量で話せたのが、今回の会の良さでした。
アンケートで見えた反響
そんなこんなでイベントは無事終了。
イベント後にはアンケートを実施しました。
全体的に満足度はかなり高く、「期待を上回った」という声が多かったです。特に次の点が好評でした。
参加者の声（要約）
「SECIモデルを深掘りして業務に当てはめられたのが良かった」
「Miroで参加している感が出た」
「他部署の取り組みを聞けたのが参考になった」
一方で改善点も挙がっています。
参加者の声（要約）
「今回のテーブル配置だと、フィッシュボールの中心の会話が聞こえにくかった。マイク等の工夫がほしい」
「飲みが進むと中央と周囲で議論が分断されがち。周囲は周囲で、中央テーブルに行かずに勝手に盛り上がってしまう。中央の議論を共有する仕組みがあると良い」
まとめ：知識を回すには
「ナレッジ共有は小さな仕組みづくりから」
参加者それぞれが出してくれた事例のように、
大げさな設計ではなく、まずは小さな仕組みで回していくことが大事なのだと思います。
イベントの最後は、青山さんのこの一言で綺麗に締まりました。
青山さん：
「今日の目標だった『僕を楽しませる』は、僕が勝手に楽しんだので達成してます（笑）」
完璧な正解はないかもしれません。
でも、自分たちの現場の話を持ち寄って、ゆるく、でもちゃんと考える。
その時間自体が、次の知識を生む起点になる。そんな夜でした。
参加されたみなさん、そして案内人の青山さん、ありがとうございました！
