PDCAサイクルとは？回し方・具体例・OODAとの違い【2026年版】

「PDCAを回そう」という掛け声はよく聞きますが、実際に回っているチームは意外と多くありません。会議で改善策を決めて全員がうなずいたのに、3週間後には何を決めたのかも、効果があったのかも誰も覚えていません。そんな経験はないでしょうか。改善が続かない原因は、アイデア不足よりも、決めたことが手元に戻ってこないことにあります。PDCAサイクルは、この流れを閉じるための仕組みです。

この記事では、PDCAサイクルの意味と4つのステップの進め方、営業チームと開発チームの具体例、回らなくなる5つのパターンと対策を解説します。あわせて、「PDCAは古い」という批判が妥当かどうか、OODAやOKRとの使い分け、そのまま使えるテンプレートも紹介します。さらに、多くのチームが真っ先に抜けてしまうCheckとActの記録を、AIで自動化する方法にも触れます。

⚠️ 本記事は、2026年9月時点の公開情報やユーザーフィードバックを基に独自にまとめたものです。

目次

1. PDCAサイクルとは
2. 4つのステップの進め方
3. PDCAサイクルの具体例
4. PDCAが回らない5つのパターンと対策
5. 「PDCAは古い」は本当か
6. PDCAとOODA・KPT・OKRの違い
7. そのまま使えるPDCAテンプレート
8. 導入前チェックリスト
9. CheckとActの記録をAIで自動化する
10. よくある質問（FAQ）
11. まとめ

PDCAサイクルとは

PDCAサイクルとは、Plan（計画）・Do（実行）・Check（評価）・Act（改善）の4段階を繰り返し、業務やプロセスを継続的に良くしていく手法です。 1周して終わるチェックリストではなく、はじめから「輪」として設計されています。1周ごとにプロセスが少しずつ良くなり、学びが積み上がっていくのがねらいです。

歴史は、たいていの経営フレームワークより長いです。1930年代にベル研究所のウォルター・シューハートが原型を作り、1950年代にW・エドワーズ・デミングが日本の製造業に伝えて広まりました。日本の品質管理（TQC）の土台となり、その後は世界のリーン生産方式やISO 9001などの品質マネジメントシステムにも取り入れられています。ちなみにデミング自身は、Checkの代わりにStudy（学習）を使ったPDSAという呼び方を好みました。Checkが「合格か不合格かの検査」と受け取られ、学びの段階として働かなくなることを心配したためです。この心配は、後述するように現実になっています。

PDCAで成果を出すチームと、スライドに円を描くだけのチームは、何が違うのでしょうか。カギは、PDCAは仮説検証であって、タスクリストではないと理解しているかどうかです。Planは「やることを並べる」段階ではありません。どの変更が、いつまでに、どんな結果を生むと予想するのか、そしてそれを何で測るのかを書き残す段階です。計画に予測がなければ、Checkで確かめるものがなくなり、サイクルはいつの間にかただのタスク管理になってしまいます。

4つのステップの進め方

• Plan：問題・打ち手・期待する結果を定義します。 使える計画は、問題は正確には何か（できれば数字で）、どんな変更を試すのか、いつまでにどんな結果を期待するのか、何で測ってそのデータはどこにあるのか、という4つの問いに答えています。たとえば「対応スピードを改善する」では不十分です。「デモ依頼をすべて共有キューで受けます。3週間で初回応答時間が9時間から2時間以内に縮むと予想し、ヘルプデスクのダッシュボードで測ります」と書けば合格です。
• Do：小さく実行し、実際に起きたことを記録します。 ありがちな失敗は、検証しないままいきなり全体に展開してしまうことです。まずは1チーム、1拠点、1週間分だけで試しましょう。同じくらい大切なのが「逸脱の記録」です。忙しい日に新しい手順が飛ばされたなら、その事実はCheckの貴重な材料になります。書き残さなければ、来月には誰も覚えていません。
• Check：結果を、感覚ではなく最初の予測と比べます。 いちばん省略されやすい段階です。ここを飛ばすと、PDCAはPD・PD・PDになってしまいます。どの打ち手が効いたのか分からないまま、変更だけが積み重なっていきます。きちんとしたCheckでは、指標は予測どおり動いたのか、計画と違ったことは何でそれはなぜか、これまで知らなかった何を学んだのか、という3つの問いに答えます。なお、「指標が動かなかった」ことも立派な成果です。仮説を安く反証できたことになるからです。
• Act：標準化・修正・撤退のどれかを、はっきり選びます。 Actの結末は3つしかありません。採用は、効果があったので新しい標準にして、文書化して展開します。修正は、方向は良さそうでもやり方に手直しが要るので、それを次のサイクルのPlanにします。撤退は、仮説が外れたので打ち手をやめ、理由を記録することです。3つとも正当な結末です。Actで唯一の失敗は「沈黙」、つまり誰も判断しないままパイロットがだらだら続く状態です。

PDCAサイクルの具体例

輪の図を眺めるだけでは真似しにくいので、具体例を2つ挙げます。

フォローメールの送付率が低い営業チーム

• Plan：初回商談のうち、24時間以内にフォローメールを送れているのは40%にとどまっています。仮説は、議事録を元にその日のうちに下書きを作れば、1か月で送付率が90%に届くというものです。CRMで測定します。
• Do：2週間、1つのチームだけが、商談直後にAI議事録からフォローメールの下書きを作る運用を試します。逸脱の記録として、展示会の週に2名が手順を飛ばしました。
• Check：試したチームの送付率は85%、他チームは42%でした。返信率も上がっています。24時間の目標を外したのは、主に商談が1日4件を超えた日でした。
• Act：チーム全体に採用します。あわせて「商談ごとではなく、毎日16時にまとめて下書きする」案を、次のサイクルのPlanとして予約します。

リリース当日の障害が続く開発チーム

• Plan：直近5回のリリースのうち3回で、48時間以内にホットフィックスが発生しました。仮説は、リリース前に30分のチェックリストレビューを入れれば、次の2回のリリースでリリース週のホットフィックスをゼロにできるというものです。
• Do：次の2回のリリース前にレビューを実施し、チェックリストで見つかった項目をすべて記録します。
• Check：1回は無事に終わりましたが、もう1回はホットフィックスが必要でした。原因は、チェックリストの対象外だった設定変更です。一方で、チェックリストはほかの問題を4件、リリース前に食い止めていました。
• Act：採用ではなく修正を選びます。設定の差分をチェックリストに追加し、さらに2回のリリースでサイクルを回し直します。

2つの例には共通点があります。計画に数字と期限があり、Doで逸脱を記録していて、Checkが「良くなった気がする」ではなく最初の予測との比較になっている点です。この3点がそろえば、サイクルは回り始めます。

PDCAが回らない5つのパターンと対策

• 計画に予測がない。 「新しいオンボーディングを試す」はタスクであって、仮説ではありません。期待する結果と指標がなければ、Checkはただの意見交換になります。対策は、「XがZ日までにYになると予想する」と書けるまで、Doを始めないことです。
• Checkが開かれない。 パイロットが始まると関心は次の仕事に移り、誰も振り返りの予定を入れません。対策として、Planを承認したその場で、Doが始まる前にCheck会議を予約しましょう。カレンダーにCheckの日付がないサイクルは、閉じないサイクルです。
• 決定が蒸発する。 結果の議論はしたのに、結論が誰かの記憶にしか残っていません。1か月後には、同じ議論がゼロから繰り返されます。対策は、計画・結果・Actの判断を書いたサイクルの記録を残すことです。次の振り返りは、前回の記録を読むところから始めます。
• サイクルが長すぎる。 四半期単位のサイクルでは、学べる機会が年に4回しかありません。しかも振り返りの頃には、誰も細部を覚えていません。対策は、基本を2〜4週間にすることです。四半期のレビューは、短いサイクルで得た学びを束ねる場と位置づけましょう。
• Checkが犯人探しになる。 外れた仮説を誰かのミスとして扱うと、メンバーは測定できる計画を出さなくなります。曖昧な計画なら、「間違い」と証明されることがないからです。対策は、人ではなくプロセスを評価することです。きれいに反証された仮説は、「安く済んだ学び」として歓迎しましょう。

「PDCAは古い」は本当か

PDCAを調べると、「時代遅れ」「今のビジネスには遅すぎる」「OODAやアジャイルに置き換わった」といった主張にすぐ出会います。半分は当たっている批判なので、正面から答えておきます。

当たっている半分から見ていきます。状況がサイクル1周より速く変わる場面に、PDCAは向きません。障害対応のさなか、時間単位で動く交渉、毎日盤面が変わる競争環境では、3週間かけて仮説を検証している余裕はないからです。そうした場面には、OODAのような素早い状況判断のフレームワークが適しています。また、PDCAは運用を間違えられがちでもあります。形だけのCheckが付いた年次計画の儀式になり、改善ではなく書類ばかりを生んでいるという指摘は、そのとおりです。

当たっていない半分は、こうです。自分たちで制御できる反復可能なプロセスでは、仮説にもとづく改善は少しも古びていません。今のプロダクトチームが言うビルド・計測・学習やグロースの実験は、言葉が変わっただけで、構造はPDCAそのものです。仮説を立て、小さく変更を出し、予測と比べて測り、判断します。古いのはフレームワークではなく、長すぎるサイクルと省略されたCheckのほうです。サイクルを2〜4週間で回し、毎回はっきりしたActの判断で締めているなら、いわゆる「モダンな」手法が勧めることをすでに実践しています。

実務上の結論はこうです。自分で制御でき、測定できるプロセスには、PDCAを使い続けます。速い対応が要る場面では、OODA的な考え方に切り替えます。そして、サイクルが1か月を超えるPDCA運用は、手法を捨てる理由ではなく、設計のミスとして扱いましょう。

PDCAとOODA・KPT・OKRの違い

これらのフレームワークは対立するものとして語られがちですが、答える問いが違うだけで、組み合わせて使えます。

実務でうまくいく組み合わせは、次のとおりです。まずOKRで、今四半期の行き先を決めます。その主要な結果に向けて実験を重ねる方法が、PDCAサイクルです。CheckとActの議論を会議として進める型には、KPTが使えます。そして、何かが燃えていて仮説検証が贅沢になった瞬間に切り替えるのが、OODAです。KPTの詳しい進め方はKPTの解説記事にまとめています。

そのまま使えるPDCAテンプレート

チームの共有ドキュメントに貼り付けて、サイクルごとに複製してください。

# PDCAサイクル ― [プロセス/チーム名] ― サイクル #[n]
担当: [名前]   期間: [開始] → [終了]   Check会議: [日付・予約済み]

## Plan
- 問題（数字で）: [現状]
- 試す打ち手: [1文で]
- 予測: [指標]が[日付]までに[X]から[Y]になると予想
- 指標のデータ参照先: [ダッシュボード/レポート]

## Do（サイクル中に記入）
- 開始日: [日付]   範囲: [パイロット対象のチーム/セグメント]
- 逸脱の記録: [何を、いつ、飛ばした/変えたか]

## Check（振り返りで記入）
- 結果: [指標の前 → 後、予測との比較]
- 計画と違った点とその理由:
- 学んだこと:

## Act（必ず1つだけ選ぶ）
- [ ] 採用 ― 新しい標準として展開。文書: [リンク]
- [ ] 修正 ― 次のサイクルのPlan: [1文で]
- [ ] 撤退 ― 記録した理由: [1文で]

運用のポイントは3つです。1つ目は、Check会議をDoが終わってからではなく、Planを書いた時点で予約することです。2つ目は、逸脱の記録をDoの期間中ずっと付けることです（このメモがCheckを正直なものにします）。3つ目は、Actでは必ずチェックボックスを1つ埋めることです。空欄のActは、サイクルが閉じなかったことを意味します。

導入前チェックリスト

• 問題を、形容詞ではなく数字で書きましたか。
• 計画は、期限付きの具体的な結果を予測していますか。
• 指標のデータ参照先について、開始前に合意しましたか。
• パイロットの範囲は、安全に失敗できる大きさですか。
• Check会議は、すでにカレンダーに入っていますか。
• サイクルの担当者を、1人決めましたか。
• サイクルは4週間以内ですか。
• サイクルの記録を残す場所は決まっていますか。

8つすべてにチェックが付くなら、最初の1周の時点で、世の中の多くのPDCA導入より一歩先に進んでいます。

CheckとActの記録をAIで自動化する

ここまでの失敗パターンを見返すと、共通点が見えてきます。PDCAが行き詰まるのは、PlanやDoではほとんどありません。つなぎ目です。結果は会議で議論され、判断は口頭で下されますが、どちらも記録には残りません。Check会議は開かれたのに、その記録がどこにもないのです。

この部分は、AI会議アシスタントに任せられます。SuperInternは、PCのデバイス音声から直接会議を記録するボットレスのデスクトップアプリ（Mac/Windows対応）です。会議にボットが参加しないため、Zoom・Google Meet・Microsoft Teams・Webexのどれでも同じように使えます。Checkの議論が実際に行われがちな、会議室での対面ミーティングでも使えます。

PDCAでの使い方は、次のとおりです。

• AIキャンバス（AI Canvas）にサイクルの型を一度だけ教えます。 「これはPDCAの振り返り会議です。予測と結果の比較、逸脱、学び、担当者付きのActの判断を記録してください」と指定しておけば、以降の振り返りはこの構造のままリアルタイムで書き上がります。参加者は書記の役目から解放され、議論に集中できます。

• Actの判断が、発言と同時に記録されます。 「キュー方式は採用、まとめ書きは次のサイクルで検証しよう」と言えば、その一言が担当者付きの決定として、その場でノートに載ります。誰かの記憶に頼る必要はありません。
• 過去のサイクルをいつでも呼び出せます。 次の振り返りの前に、会議横断のAIチャットへ「直近3回のオンボーディング改善のPDCAで決めたことと、まだ開いている予測を一覧にして」と聞いてみましょう。その答えから会議を始められます。
• 拠点をまたぐチームでも、Checkを1つの言語で進められます。 50以上の言語のリアルタイム翻訳に対応しているので、海外拠点との振り返りでも共通言語は要りません。要約は、各自の言語で受け取れます。

できることの範囲についても、正直にお伝えします。SuperInternはライブの会議記録とノートに特化したツールで、指標のダッシュボードでもプロジェクト管理ツールでもありません。Checkで見る数字は、これまでどおり自社の分析基盤から持ってくることになります。多くのチームは、決まったアクションをSuperIntern MCP経由でClaudeやChatGPTなどのエージェントにつなぎ、LinearやJiraのチケットに起こしています。無料プランがあるので、次の振り返り会議から試せます。

よくある質問（FAQ）

PDCAとは何の略ですか？

Plan（計画）・Do（実行）・Check（評価）・Act（改善）の頭文字です。予測付きの計画を立て、小さく実行し、結果を予測と比べて評価し、採用・修正・撤退のいずれかを判断する、という循環を指します。

PDCAとPDSAは何が違いますか？

同じサイクルで、3番目の段階の名前だけが違います。デミングは、Checkが合否の検査ではなく、結果から学ぶ段階だと強調するために、Study（学習）を使ったPDSAを好みました。Checkの場で「何を学んだか」を問えているなら、この違いはすでに埋まっています。

1サイクルはどのくらいの長さが適切ですか？

業務プロセスなら、2〜4週間が基本です。指標が動くのに十分な長さで、振り返りの場で細部を思い出せる程度に短い期間です。四半期単位のサイクルは、PDCAが遅く感じられる最大の原因で、自分で招いているようなものです。

PDCAはもう古いのでは？OODAに置き換わったのですか？

2つは、解く問題が違います。OODAは、測定よりも状況判断が重要な、速い対応のための手法です。PDCAは、自分たちで制御できるプロセスを意図的に改善するための手法です。実験を軸にした現代のプロダクト開発も、呼び名がどうであれ、構造はPDCAです。

PDCAが失敗する一番の原因は何ですか？

大きく2つあります。予測のない計画では、本当のCheckができません。そして、予約も記録もされないCheck会議では、学びが消えてしまいます。どちらも「もっと頑張る」ではなく、プロセスの設計で直せます。

PDCAは個人でも使えますか？

規模を問わず使えます。自分の1週間の働き方に変更を1つ計画し、実行して、金曜日に振り返る個人版は、チームに持ち込む前に習慣を作る手軽な方法です。

まとめ

PDCAが90年も生き残ってきたのは、洗練されているからではありません。改善に必要な最小限の、飾らない構造だからです。予測して、試して、比べて、判断します。PDCAでつまずくチームの多くは、この考え方そのものにつまずいているわけではありません。つまずくのは、何も予測しない計画、開かれないCheck、会議室を出る頃には消えている決定です。

この3つを直せば、サイクルは積み上がり始めます。すべての計画を、数字と期限のある予測として書きましょう。Doが始まる前にCheck会議も予約します。そして会議の記録は自動で残るようにして、Actの判断が、下した人の記憶より長く残るようにしておきましょう。

SuperInternを無料で試す ― 会議にボットは入れず、Checkの結果とActの判断をリアルタイムで記録します。すべてのサイクルを、次の振り返りまで検索できる形で残せます。