チームナレッジの育て方 〜知識は共有してこそ資産になる〜
「あの人に聞けば分かる」という状態は、その人にとって嬉しいことでもあるし、チームにとってリスクでもあります。知識を「個人の中」から「チームの中」へ移していく方法を考えましょう。
ナレッジが貯まらない理由
| よくある理由 | 実際のところ |
|---|---|
| 「時間がない」 | 書く時間より、同じことを何度も説明する時間の方が長い |
| 「どこに書けばいいか分からない」 | 場所のルールを決めれば解決する |
| 「自分の知識が役に立つか分からない」 | 3ヶ月前の自分が困っていたことは、今誰かが困っている |
「書く」ハードルを下げる
完璧でなくていい
ドキュメントは論文ではありません。「とりあえず書いた」状態でOKです。
誰かが読んで「ここ違いますよ」と言ってくれたら、そのときに直せばいいのです。
自分が困ったことを書く
「こんなところで詰まった、こうやって解決した」が最高のナレッジです。
技術書に書いてあることより、「うちの環境で、このバージョンでハマったこと」の方が10倍役に立つことがあります。
箇条書きでOK
文章が苦手でも、箇条書きでステップを書くだけで十分です。
「1. ○○をインストール → 2. 設定ファイルをこう書く → 3. コマンドを実行」これだけで、次の人が1時間の試行錯誤を省けます。
どこに書くか
| 種類 | 場所 | 例 |
|---|---|---|
| 手順・How-to | このポータル（Docs） | 環境構築手順、デプロイ方法 |
| 議論・決定した経緯 | Notion や GitHub Issue | 「なぜこのツールを選んだか」 |
| コードに近いもの | README や コード内コメント | APIの使い方、関数の説明 |
| 速報・共有事項 | Slack | 今日気づいたこと、一時的な情報 |
ドキュメントを「生きたもの」にする
書いて終わりにしない。これが大切です。
- 更新日を書く — 「この情報はいつのものか」が分かることで、信頼性が上がります
- 間違いを歓迎する — 「ここ古くなってますよ」というフィードバックはギフトです
- 定期的に棚卸しする — 四半期に一度、「これまだ正しい？」と見直す時間を作りましょう
「聞いた後」に書く文化
誰かに質問して解決したとき、その答えをドキュメントに書いてみましょう。
「聞いたら書く」の流れ：
- 詰まる
- 誰かに聞く
- 解決する
- その解決策をドキュメントに書く（5分でOK）
これを習慣にすると、チームのナレッジが自然に増えていきます。
ナレッジ共有で生まれるもの
- 新しいメンバーの立ち上がりが速くなる
- 同じことを複数回説明する手間が減る
- 「あの人にしか分からない」という属人化が減る
- 自分の理解が整理される（書くことで気づくことがある）
- チームとしての学習速度が上がる
📚 ナレッジの哲学
知識は使えば減るものではなく、共有するほど増えるものです。
あなたの「当たり前」が、誰かの「発見」になることがあります。
はじめの一歩
「何を書けばいいか分からない」という人へ。
今日、仕事中に一つでも「あ、そういうことか」と気づいたことがあれば、それを3行で書いてみてください。それがナレッジの種です。