PDCA

概要と基本定義

Plan(計画)→ Do(実行)→ Check(評価)→ Act(改善)のサイクルです。品質管理(QC)の世界で生まれ、現在では Web マーケティングや経営など幅広い領域で使われる継続改善の基本フレームワークで、「業務を回す」際の定型表現です。(※OODA や SCRUM など類似・派生フレームワークもありますが、日本では依然として PDCA が最も共通言語として浸透しています)

現場における PDCA の本質(業者との「共同 PDCA」)

Web マーケティングにおける本質は、「数字 → 仮説 → 次の一手」というサイクルを、自社単独ではなく外部業者と一緒に回す「共同 PDCA」として、SEO・広告・メールなど施策横断で貫くことです。

多くの会社が「PDCA を回しましょう」と口にしますが、実際には計画を立てて実行するだけ(P と D のみ)で力尽き、Check(効果測定)と Act(改善)のスケジュールを最初から組み込んでいない「やりっぱなし」の事例が後を絶ちません。

Web 担当者のリアルな実務フローと役割分担

業者との「共同 PDCA」においては、以下のロール分担と実務を徹底します。

• Plan(計画)：【業者提案】目的・期待効果・期限に加え、「何がどうなったら成功か」という具体的な成功基準(KPI)を明示して合意する。
• Do(実行)：【業者実装】施策の実施。※超重要：公開直前チェック(公開前チェック)に加え、後で Check をするための「計測タグ(計測タグ・GA4 等)の作動確認」や「UTM パラメータの付与」をここで確実に仕込んでおく。
• Check(評価)：【双方】個別施策レポートを用いて、データに基づく因果関係を評価する。
• Act(改善)：【合意】成功・失敗の要因を分析し、「失敗データベース」に記録して次の Plan へフィードバックする。

やってはいけない「現場の落とし穴」と失敗談

• やりっぱなしの罠：「P」と「D」だけで満足し、最重要な「C」と「A」がすっぽり抜ける(計測設定の漏れで「C」の段階でデータがない、という技術的事故も含む)。
• 成功基準のフワッとした定義：Plan が抽象的すぎて、「結果的に良かったです」というポエムのような報告で終わる。
• 時間軸のズレ：Check のタイミングが早すぎる(例：SEO は結果が出るまで 3〜6 ヶ月かかるのに 1 ヶ月で失敗判定する)、または遅すぎる。
• 丸投げの弊害：業者との PDCA が「業者が勝手に回すもの」という前提になり、発注側の関与が薄れ、自社にノウハウが全く残らない。
• 総花的な Act：Act の際、「あれもこれも」と打ち手を増やしすぎて、次に何が効いたのか検証不能になる(変数は 1 つに絞るべき)。
• 形骸化とスピード感の欠如：PDCA を回すこと自体が目的化し「会議のための会議」になる。また、AI 時代の急激な市場変化のスピードに対して、重厚長大な PDCA サイクルでは対応が遅れ、前提条件ごと覆されるリスクがある。