外注先からの「毎回同じ質問」は、情報が整理されていないサインだ。トップ10の質問を洗い出し、外注先がすでにいる場所に答えを置く。それだけで、チームは余計なやりとりなしに動き出す。
繰り返される質問が、何かを教えている
「フォントは何を使えばいいですか」「入稿形式はPDFでよかったですか」「請求書の宛名はどう書けばいいですか」――こうした質問を、あなたは何度答えてきただろうか。
外注先から届く問い合わせには、パターンがある。同じ質問が来るとき、それは相手の理解力の問題ではない。情報がどこにも書かれていないか、書かれていても見つけにくい場所にあるかのどちらかだ。
複数の案件を並行して回すディレクターにとって、これは小さなロスに見えて、積み重なると深刻な時間の浪費になる。一問一答に費やす時間より、仕組みで解消した方がずっと速い。
ナレッジベースは「Wikiを作ること」ではない
「ナレッジベース整備」と聞くと、Notionで階層を作り、記事を百本書き、検索機能を整えて……というプロジェクトを想像してしまう。それは正しい方向性だが、多くのチームはその手前で力尽きる。
本当に必要なのは、そのような大型プロジェクトではない。外注先が実際に詰まっている質問に、あらかじめ答えておくことだ。
出発点はシンプルでいい。「先月、外注先から受けた質問を思い出してみる」。それだけで、整備すべき情報の輪郭がかなりはっきり見えてくる。
トップ10の質問を書き出す
まず一週間、外注先からの質問をメモしておこう。Slackのログでもメールでも、来た質問をリストに貯めるだけでいい。一週間後に振り返ると、同じ系統の質問が複数回来ていることに気づく。
それが、あなたのチームのトップ10だ。内容はチームによって異なるが、よくある傾向としては以下のようなものがある。
- 納品データのフォーマットと解像度
- 修正回数の定義と連絡方法
- 請求書の宛名・締め日・支払いサイト
- ブランドカラーやロゴの使用ルール
- フィードバックをもらう際の返信期限
これらの答えをどこかに書き留めておく。それがナレッジベースの第一歩であり、実は最も重要なステップでもある。
外注先がすでにいる場所に置く
ドキュメントを整備しても、外注先がそこにたどり着かなければ意味がない。社内専用のWikiに入れても、外注先はそもそもアクセス権を持っていないことが多い。
ポイントは「外注先がすでに使っている場所に置く」ことだ。タスク管理ツールを使っているなら、プロジェクトの冒頭に固定しておく。チャットツールでやりとりしているなら、ピン留めしておく。
Paqut では、プロジェクトごとに独立したグループスペースを作ることができる。そのグループの最初のタスクや説明欄に「このプロジェクトで知っておくべきこと」をまとめておくと、外注先はオンボーディング初日からそこを参照できる。URLを共有するだけで外注先を招待できるので、アカウント設定の手間もない。
外注先にとっての「自然な動線」に情報を置くこと。それだけで、質問の数は目に見えて減る。
プロジェクトタイプ別のFAQを作る
すべての外注案件に同じFAQが通用するわけではない。デザイン案件、ライティング案件、開発案件では、詰まるポイントがそれぞれ異なる。
プロジェクトタイプ別に最低限のFAQを用意しておくと、新しい案件を立ち上げるたびにゼロから説明する手間が省ける。テンプレートとして保存しておき、案件ごとに内容を微調整する運用にすると、整備コストが最小限で済む。
たとえばデザイン案件なら「使用フォントの一覧」「カラーコードのリスト」「ロゴの禁止使用例」をセットにする。ライティング案件なら「文体の基準（ですます/だ・である）」「想定読者のペルソナ」「NGワードリスト」を用意する。こうした情報を一度まとめておけば、外注先は最初に読むだけで仕事を始められる。
スタイルガイドはどこまで書けばいい？
「スタイルガイドを作る」と言うと、分厚いブランドブックを連想するかもしれないが、そこまでは必要ない。外注先が実際に迷うポイントに絞って書けば十分だ。
「迷ったらこう判断する」という基準を2〜3行で書くだけでも、何もないよりはるかに役に立つ。完璧を目指すより、今ある情報を外に出すことの方が、チームには価値がある。
オンボーディングと情報整備をセットにする
新しい外注先を迎えるタイミングは、ナレッジベースを更新する絶好の機会でもある。その外注先から来た最初の質問は、他の外注先も詰まっているかもしれない問いだからだ。
外注先のオンボーディング を設計するとき、「何を伝えるか」と同時に「何をドキュメントに落とすか」をセットで考えるといい。口頭で説明したことをそのままテキストに残しておく習慣をつけるだけで、次回のオンボーディングは大幅に楽になる。
外注先へのナレッジ移転 についても、単発の引き継ぎではなく継続的な情報整備の一部として捉えると、チームの底力が着実に上がっていく。
よくある落とし穴：「どこに何があるか分からない」問題
情報を整備し始めたチームがよく陥るのが、「作ったは作ったが、外注先がどこを見ればいいか分からない」という状況だ。FAQをNotionに、スタイルガイドをGoogleドライブに、ブランド素材をDropboxに、と分散してしまうと、外注先は毎回「あのファイルどこでしたっけ」と聞いてくることになる。
情報の場所を分散させないことが、ナレッジベース運用の要諦だ。外注先が最初にアクセスする一点を決め、すべてそこから参照できる構造にする。細かいファイルは既存のストレージに置いてもいいが、「入り口」はひとつに絞る。
タスクツールをその入り口にするのが、実務的には最もスムーズだ。外注先はどうせタスクを確認しにそこを開く。同じ場所に情報があれば、別のツールを開く手間がない。
更新し続けなくてもいい設計にする
ナレッジベースを作ったものの、更新が追いつかなくなって形骸化してしまう。このパターンをよく見かける。
維持しやすいナレッジベースのコツは、「更新頻度が低い情報だけをドキュメントに置く」ことだ。毎週変わるような情報をナレッジベースに入れると、古い情報が残り続けて混乱のもとになる。変わらない情報、たとえば入稿フォーマット・ブランドカラー・契約上の基本ルール、これらをドキュメントの中心に据える。
頻繁に変わる情報は、タスクのコメントやチャットで都度伝える方が実態に合っている。情報の性質によって置き場所を変えることが、長続きする運用につながる。
外注先のオンボーディングチェックリスト に「初日に共有する固定情報リスト」を組み込んでおくと、情報整備の漏れを防ぎやすい。
「毎回同じ質問」がなくなったとき、チームに何が起きるか
外注先への情報整備が整ってくると、やりとりの質が変わってくる。質問が「この仕事を進めるにはどうすればいいか」から「この仕事をより良くするにはどうすればいいか」に変わり始める。
ルーティンの確認作業がなくなった分、本質的な議論に使える時間が生まれる。外注先も、毎回基本的なことを聞かなくていいという安心感の中で、力を発揮しやすくなる。
複数の案件を回すディレクターにとっての理想は、追いかけなくても案件が前に進んでいる状態だ。そのために必要なのは、優れたタスク設計と、外注先が自分で答えにたどり着けるだけの情報だ。どちらも、地道に積み上げることで確実に手に入る。
情報を整備することは、外注先への敬意でもある。「あなたの時間を、質問への返答ではなく、本来の仕事に使ってほしい」というメッセージでもあるからだ。
Paqut では、外注先をゲストとして無料で招待でき、プロジェクト単位で情報とタスクを一元管理できる。ナレッジベースの置き場所として、また外注チームとの日常のやりとりの拠点として、ぜひ試してみてほしい。