組織・運用定着

レビューの属人化は、毎回の指摘を問いにして手放す

用語

CRM（顧客管理システム）

公開 2026年10月25日

自社のLinkedIn会社ページの投稿を、担当者に任せはじめたときの話です。

1本あたり、本文で2〜3回、画像でさらに2〜3回。合わせて4〜6回ほど、私が赤入れをしていました。正直、かなりしんどかった。

原因は担当者の力量ではありませんでした。「出していい投稿」の基準が、私の頭の中にしかなかった。それだけです。

いまは、私が見るのは月に1回の振り返りだけです。変えたのは人ではなく、基準の置き場所でした。

見積を出す前に必ず部長の確認が要る、商談のステージを進めてよいかをマネージャーが口頭で決めている。営業組織で起きている確認待ちも、たいてい同じ構造をしています。後半では、そちらに当てはめるときの線引きも書きます。

基準が一人の頭にあると、レビューは待ち行列になり、判定も日によって揺れる

基準が自分の中にしかないと、判断できるのは自分だけになります。

担当者は毎回、私のチェックを待つ。私は優先度の高い仕事に追われて、戻しが遅れる。投稿が止まっている間、誰も怠けてはいないのに、日数だけが積み上がります。

もう一つ厄介だったのは、私の判定が、その日の私のコンディションで揺れることでした。

昨日はOKだったものが、今日はダメ。担当者から見れば、正解が毎日動いているのと同じです。往復が増えるほど私の指摘は厳しくなり、担当者は「Seikoならどう言うか」を当てにいくようになっていきました。

この状態で担当者に「もっと考えて書いて」と言っても、何も変わりません。考える材料が、担当者の手元に無いからです。

書き出したのは「質」ではなく、毎回口で言っていた指摘そのもの

やったことは単純です。私がレビューのたびにしゃべっていた指摘を、全部テキストにしました。最終的に21項目のチェックリストになりました。

大事なのは、項目を「質を高く」「読者目線で」のような心がけにしないことです。それでは結局、判定できるのは私だけに戻ります。

項目は、担当者が自分で合否を付けられる問いの形にしました。たとえば次のようなものです。

1行目に挨拶や自己紹介が入っていないか
冒頭3行で、読んでほしい職種が1つに絞れているか。マーケ責任者向けの投稿なのに、途中から受注率が主役になっていないか
課題から解決までの間に、現場で起きる変化が1つ挟まっているか。「風が吹けば桶屋が儲かる」になっていないか

書き出してみると、私が「なんか違う」と感じていたものの大半は、この形の問いに落ちました。

落ちなかったものも、少しだけ残りました。半分は私の好みで、これは捨てました。残りは、時事の話題に触れてよいか、特定の会社や人に言及してよいか、のように一律の問いにしにくい判断です。これは担当者に「迷ったら聞いて」と渡す例外として、私の手元に残しました。

一次判定は仕組みに、最終判断は担当者に渡す

次に、その21項目を毎回自動で当てる仕組みを作りました。

担当者がNotionで投稿のステータスを「確認待ち」に変えると、その投稿とチェックリストがAIに渡り、判定とスコアと直す箇所がNotionに書き戻されます。担当者が新しく何かを起動する手間はありません。どのみちやるステータス変更に、判定を相乗りさせました。

最初に一つだけ決めていたのは、AIの判定はあくまで一次チェックで、最終判断は担当者がする、ということです。

AIがAを付けても、担当者が読んで違和感があれば直していい。Bでも「これでいい」と判断したら出していい。

ここで判定の正確さを求めると、精度を確かめるために、結局また私が毎回見ることになります。標準化の目的は、私をレビューから外すことでした。AIを新しいレビュー役にすることではありません。

レビュー役が見るのは1本ずつではなく、月1回の結果

毎回4〜6往復していたレビューは、月1回の振り返りになりました。

切り替えの前後で投稿の反応を比べたわけではないので、質が保てたかどうかは数字では言えません。担当者自身の努力や、回数を重ねた分の慣れもあります。言えるのは、私の手が空き、質を確かめる場所が1本ずつのレビューから月1回の振り返りに移った、というところまでです。

振り返りでは、インプレッションを見ながら、良かった投稿と良くなかった投稿を1本ずつ開きます。一覧を眺めて終わらせず1件ずつ開くのは、「営業の数字の会議は、一覧を眺めず受注1件と失注1件を開く」と同じ考え方です。この記事で足したいのは、その後のこと。良くなかった投稿の原因が分かったら、直すのはその投稿より、チェックリストのほうです。1本を直しても次の1本には効きませんが、基準を1行直せば、次からの全部に効きます。

いちばん驚いたのは工数ではありませんでした。担当者の言葉が変わったんです。

「この書き出し、反応がいいですね」「このテーマは数字が落ちます」。私が毎回採点していたころには、出てこなかった視点でした。基準を私が握っていたころ、担当者は私の正解を探す人でした。基準を渡してからは、自分で見比べて直す人になった。

営業組織に当てはめるときは、一次判定に渡す範囲を対象ごとに決める

クライアントの営業組織でも、同じ詰まり方によく出会います。見積や提案書の部長確認、ステージを進めてよいかの判断、CRM（顧客管理システム）の入力が足りているかの差し戻し。判断している人が悪いわけではありません。基準がその人の頭の中にあり、判断できる人が1人しかいないだけです。

ただし、社内の投稿と違って、ここは間違えたときの影響が大きい。だから手順は同じでも、一次判定に渡す範囲を対象ごとに決めます。

レビュー役が直近で3回以上言った指摘を、書き出す。 新しく考えるのではなく、すでに言っていることを拾う
合否が付けられる問いの形にし、既存の項目で判定できるものだけを残す。 「十分に記載」ではなく「ステージを進めた時点で、『決裁の進捗』が所定の段まで進んでいるか」「顧客側の締切日が入っているか」。判定のために新しい項目は作りません
書き出した問いを、今のレビュー役とその上長が確認し、すでにある運用の会議で採用を決める。 合意のないまま判定を入れると、判定する人が1人から2人に増えるだけです
対象ごとに、仕組みに渡す判定と、人が持ち続ける判断を分ける

4の分け方は、たとえば次のとおりです。

見積・提案書：記載漏れや表記の確認は一次判定に渡す。価格、値引き、契約条件、他社との比較は、これまでどおり部長が見る
ステージの判定：基準を満たしていない商談を一覧に出すところまでを仕組みに渡す。月1回ではなく、毎週のパイプライン会議でその一覧だけをマネージャーが見る。基準を満たさないまま進めるかの最終判断は、担当者ではなくマネージャーに残す。予測の数字がこの判断で動くからです
CRMの入力チェック：ステージの移動を止める規則にはせず、不足を知らせる表示か、一覧への抽出にとどめる。止める規則を入れると、連携や一括更新、稼働中のワークフローによる更新まで弾かれることがあります。入れるなら、それらを対象から外せるかを先に確かめます（製品と設定によるので要確認）

基準の直し方も分けます。LinkedInの投稿なら、振り返りのたびに1行直してかまいません。CRMの判定基準は、気づいた点を毎週ためておき、反映は四半期に1回にします。期の途中で基準が変わると、過去のレポートと比べられなくなるからです。反映した日付は、チェックリストに残します。

どの種類の変更に確認が要るかを先に決める話は「コンテンツ制作のリードタイムは、待ち日数で測る」に書きました。あちらは確認の「範囲」を決める話で、この記事は確認の「基準」を外に出す話です。両方そろうと、確認者の手元に来るのは、本当に見るべきものだけになります。

レビューが一人に集まるときは、その人が毎回口で言っている指摘を、合否を付けられる問いの形で書き出す。一次判定は仕組みか担当者に渡し、問いにできない判断と、間違えたときの影響が大きい判断だけを人が持ち続けます。

もしいま、あなたのところに確認待ちが積まれているなら、今週自分が3回以上言った指摘を3つだけ書き出してみてください。それが、手放せる基準の最初の3行です。