属人化は悪ではない。属人化のまま組織が回らなくなるのが問題
最初に断っておくと、属人化そのものは別に悪ではありません。
制作の現場では、判断のスピードと精度が高いベテランが1人いると、その人に集中させたほうが結果が出るケースは多いです。ナレッジを全員にまんべんなく分散させると、判断の質が平均化されて、むしろ案件が地味になります。
問題は、その人が休んだ瞬間に止まる組織、辞めた瞬間に過去案件の経緯が永久に失われる組織です。属人化を許容しながらも、必要なときに別の人が拾える状態を維持する。結局これくらいの落としどころが、中小制作会社では一番回ります。完全な脱属人化ではなく、「いざとなったら拾える属人化」を目指す感覚です。
制作会社のナレッジが溜まらない、構造的な4つの理由
私が見てきた制作会社で、ナレッジ蓄積に成功している会社は正直少数です。失敗しているほうが圧倒的に多くて、しかも失敗の理由は似ています。
理由1：案件が終わった瞬間にチャンネルが閉じる
Slackで案件チャンネルを切って、メンバーを招待して、その中で議論を進める——制作会社では一般的なやり方です。ただ、案件が終わるとそのチャンネルはアーカイブされ、半年後に検索しようとしても、誰がメンバーだったかすら思い出せません。
メールも同じです。「過去のあの案件のメール」を探そうとしても、検索キーワードを思い出すのに10分かかります。情報自体は残っているのに、アクセスできない状態が量産されていきます。
理由2：振り返り会が「次回頑張る」で終わる
案件終了後の振り返り会、やっている会社は多いと思います。私もディレクター時代に何度もやりました。
ただ、議事録を取っても、その議事録がどこに置かれたかすら、3カ月後にはわからなくなります。「次回はもっと早めにクライアントに確認する」みたいな精神論で終わって、何が原因で何を変えるかが具体化されない振り返りも本当に多いです。
これは振り返り会の質の問題というより、振り返りを蓄積する場所と聞かれる項目が決まっていないことが原因です。
理由3：ナレッジ置き場がフォルダ階層の奥に埋もれる
Google ドライブの「ナレッジ」フォルダの中に「2024年」フォルダがあって、その中に「案件A」フォルダがあって、その中に「振り返り」フォルダがあって、その中にWordファイルが1つ——というやつです。
ここまで辿り着くのに、新人なら3階層目で諦めます。私も諦めたことがあります。検索性が低いナレッジは、置いていないのと同じです。
理由4：書く人にメリットがない
ここが一番根が深いと思っています。
ナレッジを書くと、読む人は得をします。書いた本人は、書く時間というコストを払います。コストを払った本人へのリターンが薄いと、書く人はだんだん減ります。「ナレッジを残しましょう」という掛け声だけでは、人は動きません。
私が見てきた中で、ナレッジ蓄積に成功している会社は、書く負担を最小化する設計か、書く人が後で得をする仕組みのどちらかを持っていました。
「貯まる」より「拾える」を優先する設計
理由が4つあるなら、対策も構造側に打つしかありません。私が試してきて、効果が大きかったやり方を、思いつく順に書きます。きれいに番号は振ってありますが、全部やる必要はなくて、刺さるものから始めてください。
設計1：案件と紐付いた構造にする
ナレッジを単独のWiki空間に置くのをやめます。
代わりに、案件管理の中にナレッジが紐づく構造にします。「案件Aの振り返り」「案件Aで使ったクライアント別の修正ルール」みたいに、ナレッジが必ず何らかの案件と関連付いた状態で保存される。これだけで、過去案件を起点に辿れるようになります。
「ナレッジ単独で残しても誰も見ない」というのが現場の感覚です。「あの案件、どうだったっけ？」と思った瞬間に案件ページに飛び、そこから振り返りが見える、という動線を作るほうが現実的です。
設計2：振り返りテンプレを固定する
「振り返りを書いてください」と言われても、何を書けばいいか分からなくて手が止まります。これは書く人の能力の問題ではなく、テンプレがないことの問題です。
私はいつも、最低でも以下5項目を埋めることにしています。
- 案件概要（クライアント・期間・予算規模）
- うまくいった判断と、その理由
- 失敗した判断と、その背景
- 次に同じクライアント／類似案件をやる人へのアドバイス
- 関連ファイル・参考リンク
聞かれる項目が固定されていれば、3カ月後に同じテンプレで書いた別案件と比較できる、というメリットも生まれます。テンプレが固定されていることで、検索性も上がります。
設計3：失敗事例の方を残す
成功事例より、失敗事例のほうが圧倒的に再利用されます。
「うまくいった案件」のナレッジは、「がんばりました」「クライアントに喜ばれました」で終わりがちで、再現性のある情報が少ない。逆に「失敗した案件」は、原因と再発防止策を具体的に書くことになるので、後から読む人が学べる情報量が桁違いに多くなります。
失敗を共有するのは社内に心理的安全性がないと難しいですが、これを習慣化できると、ナレッジが「読みに来る価値のあるもの」に変わります。
ちなみに、私が以前関わった会社では、月1回「炎上事例共有会」という名前で失敗共有を制度化していました。失敗を晒すと評価が下がる空気を排除するのが最大のポイントで、ここを経営層が明示しないと続きません。
設計4：検索性を最優先する
タグやカテゴリの設計に時間をかける会社は多いですが、正直、タグ設計の精度より「全文検索でヒットするか」のほうが10倍重要です。
理由はシンプルで、書く人は最適なタグを選んでくれないからです。3カ月後にナレッジを探す人は、当時のタグ名なんて覚えていません。「あのクライアント名」「あの機能の名前」で検索して出てくるほうが、絶対に拾える確率が高くなります。
ナレッジツールを選ぶときは、まず検索の速さで足切りしてしまっていいと思います。UIの見た目より、フルテキスト検索が速いかどうかのほうで決まります。
設計5：書く負担を最小化する
理由4で書いたとおり、書く人にメリットがないと続きません。だったら書く負担を最小化するしかありません。
私が試して効果があったのは、議事録を取った時点で半分ナレッジ化してしまう運用です。会議の議事録をAIに要約させて、決まったこと・残課題・参考になりそうな判断を3項目に整理する。これを案件ナレッジにそのまま追加する。書き直しの工程がほぼゼロになります。
AI議事録ツールが各社から出ていますが、議事録単体で完結するツールよりも、プロジェクト管理ツール内蔵のものを使うと、その後の案件タスクや振り返りに繋ぎ込みやすいです。
ナレッジツール比較——制作会社目線で正直に書きます
ナレッジツール選びは、各社のレビュー記事を見ても等距離で褒めているケースが多いので、現場感覚で正直に書きます。私が触ったことのある範囲です。
Notionはドキュメントとデータベースを組み合わせた柔軟性が魅力で、制作会社の導入実績も多いです。ただ、自由度が高すぎて、設計しないと迷路になります。3年使っていると「あのページ、どこに置いたっけ？」が頻発するのは、Notionあるあるです。料金は1ユーザー月1,650円（プラスプラン、税抜）からで、AI機能を入れるとさらに上乗せされます。設計力がある会社向けです。
ConfluenceはAtlassian製で、JiraやTrelloと連携する大手向けナレッジツールです。機能は豊富ですが、中小制作会社にはオーバースペック気味で、UIも重め。エンタープライズ開発寄りのチームには合いますが、デザイン事務所のような少人数チームには使いこなしのハードルが高いです。
Kibelaは国産で、Wikiとブログの中間みたいな立ち位置です。UIが軽くて使いやすく、Markdownで書けます。料金もNotionより抑えめで、1ユーザー月550円（スタンダードプラン、税抜）から。Notionほどの柔軟性はないですが、「ただ書いて残したい」という用途には十分です。
NotePMは社内Wikiの定番で、検索性能に強みがあります。全文検索が速くて、ファイル添付の中身まで検索対象になるのは大きいです。料金は8ユーザーまで月4,800円（プラン8、税抜）からと、Kibelaよりは高めですが、検索を最優先するなら有力候補です。
Google ドキュメント＋フォルダは無料で導入のハードルが低いですが、案件との紐付けがしにくく、フォルダ階層が深くなりがちです。「とりあえず置いておく」までは強いですが、「あとから拾える」までは設計でカバーが必要です。
正直なところ、ナレッジ単体ツールは「ナレッジを書く場所」としては機能しても、「案件と紐づいたナレッジ」を作るには別のツールとの連携が必要になります。連携の設計をサボると、結局Notionに書いたナレッジを案件管理ツールから見られない、みたいな不便が出ます。
プロジェクト管理と一体になっているナレッジの強み
ここ1〜2年で増えてきたのが、プロジェクト管理ツールにナレッジベースが内蔵されているパターンです。
案件管理・課題管理と分離されたナレッジは、更新が止まる確率が高いです。ナレッジツールをわざわざ開く理由が、案件と切り離した瞬間に消えるからです。案件のタスクを開いて、ついでに過去ナレッジを見る、という動線がないと、ナレッジ単独で開きに行く人は減っていきます。
逆に、「案件 → 課題 → 振り返り → ナレッジ」が同じツール内で繋がっていれば、案件を開いた時点でナレッジが視界に入ります。これだけで、参照される確率が大きく変わります。
LOGLIKEにもナレッジベース機能があります。案件・課題と同じツール内に置けるので、「過去の類似案件で何があったか」を案件画面から直接たどれます。さらに、プロジェクトを分析しながら議事録を自動生成するAIと会議機能や、自然言語から課題を自動生成するAI課題生成機能と組み合わせると、ミーティングログがそのままナレッジ候補として残り、手動で書き起こす工程を減らせます。書く手間の一部をツールに肩代わりさせられる感覚です。
正直に書くと、ナレッジベース単体機能で言えばNotePMやKibelaのほうが検索の細かい機能は揃っています。LOGLIKEのナレッジベースの強みは、それ単体ではなく「案件・課題・議事録・AI機能と地続きで使える」という点にあります。ナレッジツールを別で運用するか、案件管理と一体型を選ぶかは、自社のチームサイズと使い方で判断してください。
ツールを入れる前にやっておくべき、運用側の3つの準備
最後に、ツール選びより先にやっておくと効くことを書きます。これをやらずにツールだけ入れた会社は、半年後に「導入したけど誰も使ってない」状態になりがちです。
1つ目は、ナレッジを「書く担当」を決めないことです。専任のナレッジ管理者を置くと、その人だけが書く構造になって、現場のリアルが反映されません。代わりに、案件担当者全員に「振り返りテンプレを案件終了時に書く」というタスクを必ず課す。書く人を分散させるほうが、結果的にナレッジの量と質が上がります。
2つ目は、ナレッジを「探す訓練」をチームでやることです。「先月の○○案件の振り返り、3分以内に出してください」というクイズ形式で、新人もベテランも検索練習をする。検索できないナレッジは存在しないのと同じなので、検索動線そのものを訓練対象にします。私の周りでは月1回これを15分やっている会社があって、ナレッジの定着度がかなり違いました。
3つ目は、ナレッジに「賞味期限」を設定することです。3年前のクライアント別ルールはもう使えないことが多いので、年に1度棚卸しして、古いナレッジには「2024年時点」みたいな日付をタイトルに入れる、または非公開にする。古いナレッジが検索結果の上位に出てくると、現役のナレッジが埋もれます。鮮度管理ができていないナレッジベースは、図書館というより倉庫です。
まとめ：ナレッジは「貯める」より「拾える」を目指す
制作会社のナレッジマネジメントで一番大事なのは、ナレッジの量ではなく、必要なときに3分で拾えるかどうかです。
私自身、何度も失敗してきたので断言できますが、ナレッジを書く仕組みより、書かれたナレッジを拾う仕組みのほうが投資効果が高いです。書く側のインセンティブを整え、案件と紐付いた構造で残し、検索性能を最優先する。この順番で設計すれば、半年〜1年で「過去案件を起点に動ける組織」に変わっていきます。
案件・課題・振り返り・ナレッジが地続きになったプロジェクト管理を試したい場合は、LOGLIKEの活用のヒントにも具体的なシーンを書いていますので、気になる方は覗いてみてください。
ナレッジが個人の頭の中で消える会社から、案件の経緯がチームの資産として残る会社へ。地味で根気のいる変化ですが、3年後にスタッフが入れ替わっても回り続ける組織になるかどうかは、ここで決まると思っています。