継続的改善とは？どう仕組みにする？
継続的改善とは、一度に大きく変えるのではなく、小さな改善を止めずに繰り返す考え方です。プロジェクトの進め方、品質、チームの働き方などを、少しずつよくしていきます。
「改善しよう」と呼びかけるだけでは続きません。仕組みにするには、次の3つを決めておきます。
- 改善の種を集める場：ふりかえり、品質の測定、教訓、監査の指摘など。いつ、誰が集めるかを決めます。
- 小さく試して測る手順：改善策と目標を決め、小さな範囲で試し、効果を数字で確かめます。
- 効いたものを標準にする手順：プロジェクトの手順を更新します。組織でも使えるものは、組織のプロセス資産（OPA：組織の手順・テンプレート・過去の記録など）に返します。
2026年版ECOで継続的改善はどう変わった？
2026年版のECOでは、Business Environment のタスク6「継続的改善」が新しく置かれました。例示されている仕事（イネーブラー）は3つです。「教訓を活用する」「継続的改善のプロセスが更新されるようにする」「組織のプロセス資産（OPA）を更新する」です（当サイトの訳・要約）。
旧版（2021年版）には、継続的改善というタスクはありませんでした。関係する記述は、次の程度でした。
- 品質のタスク（Process7）：品質の差にもとづいて改善の選択肢を勧める
- 手法のタスク（Process13）：教訓などの反復的な実践を使う
- チームのパフォーマンスのタスク（People3）：パフォーマンスの改善を確かめる
2026年版では、Process7（品質）にも「継続的改善を実施する」が入りました。品質の改善（Process7）と、組織としての改善の仕組み（Business6）の両方から問われる形です。
PDCAとカイゼンの違いは？
どちらも継続的改善でよく使う言葉ですが、役割が少し違います。
- 1
Plan（計画）
問題と原因を確かめ、改善策と目標を決める
- 2
Do（実行）
小さな範囲で改善策を試す
- 3
Check（確認）
効果を測り、目標と比べる
- 4
Act（処置）
効いたら標準にする。効かなければ次の改善へ
Act（処置）のあと、Plan（計画）に戻って繰り返す
当サイトの整理
| 観点 | PDCA | カイゼン |
|---|---|---|
| 性格 | 改善を回す手順（型） | 現場の小さな改善を積み重ねる考え方（文化） |
| 主な担い手 | 改善を計画する人・チーム | 現場で働く一人ひとり |
| 大事にすること | 効果を測って確かめること | 毎日少しずつ、だれでも改善すること |
| プロジェクトでの例 | テストの不具合の見逃しを減らす取り組みを計画し、効果を測る | 毎日の作業で気づいた無駄を、その場で直す |
実際には組み合わせて使います。カイゼンの考え方で現場から改善の種を集め、PDCA の手順で効果を確かめて標準にします。アジャイルのふりかえりも、スプリントごとに小さな PDCA を回す仕組みと言えます。
PDCAを1周回した例は？
架空の例で、PDCA を1周回してみます。結合テストで見つかる不具合に、単体テストで見つけられたはずのものが多い、というプロジェクトです。
| 段階 | やったこと（例） |
|---|---|
| Plan（計画） | 結合テストの不具合30件のうち18件（60%）が、単体テストで見つけられたはずのものだった。原因は、確かめる観点が人によって違うこと。単体テストの観点表を作り、この割合を30%以下にする目標を立てる |
| Do（実行） | 次の2つの機能の開発で、観点表を試しに使う |
| Check（確認） | 結合テストの不具合20件のうち、単体テストで見つけられたはずのものは5件（25%）。目標を達成した |
| Act（処置） | 観点表を開発の手順に入れる。ほかのプロジェクトでも使えるので、テンプレートへの追加を PMO に提案する |
ポイントは、目標と測り方を Plan の段階で決めておくことです。測らずに「よくなった気がする」で標準にすると、効かない手順が増えるだけです。目標に届かなければ、原因の見立てを変えて次の PDCA を回します。
改善のプロセスを更新するとは？
ECO の「継続的改善のプロセスが更新されるようにする」は、改善の結果を一度きりで終わらせず、手順に組み込むことを指します。
たとえば、レビューで不具合の見逃しが多いと分かり、チェックリストを足したら見逃しが減ったとします。ここで止めると、次のプロジェクトでは元のやり方に戻ります。チェックリストを組織のテンプレートに入れて初めて、改善が続きます。
- 問題を見つける（測定の結果、教訓、ふりかえり、監査の指摘など）
- 原因を調べる（なぜなぜ分析、特性要因図など）
- 改善策を小さく試し、効果を測る
- 効いたら、プロジェクトの手順を更新する
- 組織でも使えるものは、PMO などに提案して OPA を更新する
- 改善の効果を続けて測り、次の改善につなげる
教訓の残し方は、プロジェクトの教訓の残し方で扱います。
チームで改善を回すコツは？
改善は、PM が一人で決めて押し付けても続きません。チームが自分たちで回せる状態を作ります。
- 一度に1つか2つに絞る：改善策を10個並べても、どれも実行されません。
- 測れる形にする：「レビューを丁寧に」ではなく、「レビューでの指摘件数」「手戻りの時間」で効果を見ます。
- 責めない：問題を出した人を責めると、問題が報告されなくなります。
- 時間を確保する：改善の作業をバックログや計画に入れます。空いた時間にやる、では後回しになります。
- 効いたことを見える化する：改善の効果をチームに示すと、次の改善の意欲につながります。
改善は、組織の文化や変化への向き合い方とも関わります。組織に改善の文化が根付いていない場合は、変革の進め方も考える必要があります（組織変革マネジメントとは）。
予測型とアジャイルで改善の回し方はどう違う？
改善を止めずに回す考え方は同じですが、周期と「改善を決める場」が違います。
| 観点 | 予測型 | アジャイル |
|---|---|---|
| 改善のきっかけ | 品質の測定、監査、フェーズの終了レビュー | スプリントごとのふりかえり、日々の気づき |
| 周期 | フェーズや月次など比較的長い | 1〜4週間ごとと短い |
| 改善策の入れ方 | 品質管理計画や手順書を改訂し、変更管理を通す | 次のスプリントのバックログや作業の取り決めに入れる |
| 効果の確かめ方 | 指摘件数・手戻り時間などを次の測定で比べる | 次のふりかえりで、試した結果をチームで確かめる |
どちらでも、効いた改善をチームの中だけで終わらせず、組織の手順（OPA）に返すところまでが Business6 の範囲です。アジャイルのふりかえりの進め方は、スプリントレトロスペクティブ（ふりかえり）の進め方で扱います。
PMP試験では継続的改善がどう問われる？
新しいタスクなので、出題の傾向はこれから固まっていきます。ECO の書き方から考えると、次のような判断が問われると予想できます。
| 状況 | 選ぶべき行動 | よくある誤答 |
|---|---|---|
| 同じ問題が繰り返される | チームと原因を調べ、手順を直す | その場で直して終える／担当者を外す |
| 改善策を思いついた | 小さく試し、効果を測ってから標準にする | 測らずに全体へ広げる |
| プロジェクトで効いたやり方がある | 効果のデータを添えて、組織の手順（OPA）に返す | 報告書に書くだけ／個人で使い回す |
| ふりかえりの改善策が実行されない | 1〜2個に絞り、担当と時間を計画に入れる | PM が決めて割り当てる／回数を減らす |
新しいタスクの問題に触れておくには、無料模試30問が手軽です。
確認問題1
同じ不具合が繰り返される
（当サイトの独自問題）ここ3回のリリースで、同じ種類の設定ミスによる不具合が本番で起きています。そのたびにチームは急いで修正し、問題は解決しています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。同じ問題が繰り返されるのは、手順に原因があるからです。チームと原因を調べて手順を改善し、効果を測って標準にします。
1：直す速さを上げても、本番の不具合は防げません。2：原因を調べる前に、個人の問題と決めつけています。4：回数を減らしても、原因は残ります。
確認問題2
効いた改善を組織に残す
（当サイトの独自問題）あなたのプロジェクトで、受け入れテストの前に顧客と画面を一緒に確かめる場を設けました。その結果、仕様の食い違いによる手戻りが大きく減りました。プロジェクトはまもなく終わります。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。効いた改善を組織の手順に入れることが、OPA の更新です。効果のデータを添えて提案すれば、組織として判断しやすくなります。
2：一言の記録では、ほかのプロジェクトが使える形になりません。3・4：個人やチームの範囲にとどまり、組織に広がりません。
確認問題3
ふりかえりの改善策が実行されない
（当サイトの独自問題）スクラムのチームで、ふりかえりのたびに改善策が5〜6個出ます。しかし次のふりかえりで確かめると、ほとんど実行されていません。メンバーは「スプリントの作業で手一杯だった」と言います。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。改善策が多すぎるうえ、作業として時間が確保されていないことが原因です。チームと話し合って数を絞り、スプリントの作業に入れて、確実に実行できるようにします。
1：改善の機会が減るだけです。2：チームが自分で選ばないと、当事者意識が下がります。3：5〜6個をすべて入れると、また手一杯になって実行されません。