どうも巷で「PDCAを回す」ってのが相当誤解されているようなので、正しい知識としての「PDCAサイクル」の話を書き残しておきます。カッコつきなのは、正しい知識のほうに重きがあるので、PDCA サイクル自体が有用であるか否かはここでは論じません。というか、ノウハウってのは適材適所があるので、うまく開発プロセスの中（会社の独自文化もあるだろうし各々の状況もある）にはまり込めば「PDCA は使えるよ」って形になるけど、はまらなければ「PDCA は使えない」って形になるだけ。うまいところに使って正しい形で PDCA を活用してください（場合によっては活用しないでください）ってのが主旨です。
PDCA とは何か？
そもそも PDCA とは何か？という前提があるので（いろいろなパロディを面白がるためには元ネタの知識が必要なのだ）、念のため書いておきます。
- Plan（計画）
- Do（実行）
- Check（計測、評価、検証）
- Action（再計画）
ですね。おそらく、「Action」のところが曖昧になってしまい、PDCA 回すといいつつ、PDCPDCPDC になっているパターンが多いので、これは PDCA サイクルとは言いません。「サイクル」と言うからには、計画→実行→評価、をした後に、この評価や検証をもとにして計画を見直す（あるいは新しい計画を盛り込む）というアクションを取る、という意味での「Action」です。
この PDCA って言葉自体は、私が就職したころ（1980年代）から日本にあるので、結構前からあります。本家？アメリカではどういう扱いをしていたのか定かではないのですが、改善が「カイゼン」になる前からあったような気がします。
で、PDCA を「回す」という言い方をするので、この PDCA をくるくると回転させる（ときには高速に回転させると効率がよさそう？）という話もあるでしょうが、いえいえ、そういう意味での「回す」ではなくて、単純に循環しているという意味での「サイクル」です。なので、この Plan, Do, Check, Action という各プロセス（昔は、それぞれの工程のことを「プロセス」と呼びました。今だと、工程の流れや繋がりを「プロセス」と言いますね）を循環させてつなげていく、特に Action を入れることによって、評価されたものを次の計画に反映させるという「循環/サイクル」という意味で、「PDCA を回す」という言い方をします。
PDCA はイテレーション開発のことなのか？
No. 違います。「イテレーション開発」はできあがったものを顧客に見せて、次の開発のステップへ進むというスタイルで、開発プロセスそのものを示しています。PDCA サイクルは、評価から次の再計画へ、という小さなステップを踏む改善のサイクルでしかないので、開発プロセスとはイコールになりません。
具体的に PDCA の活用の仕方をみていきましょう。
- 計画を立てる。主にスケジュールや、何をやるとか、何を目標にするとかを決める。
- 実行する。計画に沿って実行する。実行するときは途中であれこれ変更しない。だって、計画に沿わないと計画自体の意味がない。
- 実行を計測する。どういう風にやったとか、どういうことをやったとか、どのくらいの時間がかかったとかを記録して、評価できるようにする。
- 記録をもとにして、次の計画に役立てる。記録は次に役立てるために記録しているのであって、次の計画に何にも関わらないのであれば、記録している時間が無駄。
- 最初の計画を、実行して記録した結果をもとに見直す、再計画する、修正する。またはそのままでよいと確認する。
というプロセスになります。なんで、ここに顧客の意見とか、アジャイル的に顧客を巻き込みながら実行時に意見を取り入れて、ということはしません。だって、計画からずれるじゃないですか？計画通りに実行しないと、計画自体が妥当であったかどうかが分からないので、きちんと計画通りに進めて途中で記録を取ります、そして計画通りに進んでいるかどうかをチェックして、次に役立てるわけです。ここで計画を見直します。実行して記録していたものを見たときに、無理な計画であったとか、ぞれは意味がない計画であったとか、無謀だったとかを「計画通りに実行する」ことによって確認するのです。
そう、ある意味では初期のスクラム開発に似ています。スプリントの期間を決めてしまい、最悪「スプリントの2週間が完全に無駄であってもよい」という考えのもとに開発を行います。これはスクラムマスターが外部からの雑音をメンバに伝えないための防護壁となるためです。同時に、開発者はスプリントの最初に建てた計画（この計画は２週間のうちに間違っていることがわかったとしても）の最大限の努力をもってして進めます。現在のスクラム開発はどうかよくわからないのですが、少なくとも初期のスクラム開発はこれでした。
PDCA で何がダメなのか？
PDCA サイクルの適用範囲外の部分を先に話しておきましょう。範囲外のところに適用しようと思っても無駄です。意味がないので、やめましょう、って話ですね。
- 計画通りに実行しないと意味がありません。なので、計画がゆるゆるだと実行時に勝手に最適化するよう動いてしまいダメです。
- なんらかの形で記録を取れないとだめです。勤務時間だとかステップ数の進捗度とかなんかの記録を取らないと、計画が無茶だったのか妥当だったのかがわかりません。
- Action のところに重きがあるので「再計画」ができない計画に適用してはいけません。計画を見直す、計画の妥当性を見極めて改善するのが PDCA サイクルの主旨なのですが、そもそも最初の計画が動かない（短期スケジュールとか人を増やせないとか）という厳しい条件の場合には PDCA サイクルは意味を成しません。
なので、程よく計画プロセスと実行プロセスが分かれており、実行プロセスをチェックするする方法が確立して、それを踏まえたうえで次の再計画に意見できる、という組織でないと PDCA サイクルを使おうとしても無駄です。
PDCA の適用範囲は？
では、PDCA サイクルをうまく活用するためにはどういう条件が必要でしょうか？この「条件」を書いていない本や記事が多くて閉口するのですが、ノウハウというものは必ず適応条件というものが存在するのです。
- 実行可能な計画を立てる。スケジュールや手順を作る。
- スケジュールや手順に従って、実行してみる。途中で勝手にやり方を変えたりしない。
- 実行には記録が伴う。コード量や開発スピードなどの記録を取る。
- 記録をもとにして、計画が妥当であったのか、不具合があったのかを評価する。時にはよりよいアイデアを出して、より効率的に「実行」できる案を考える。
- 再計画する。手順やスケジュール、タスクの組み方などが改善されている。
というのが PDCA サイクルの効率的な取り入れ方です。
PDCA サイクルは、そのサイクルが長いか短いかは関係ありません。問題になるのは Action から Plan へサイクルになっていることであって、PDCA を回すスピードは問題ではないのです。なので、PDCA サイクル自体がひと巡りするの1年以上かかるかもしれないし（例えば、決算や年度末への改善案を出せば、年１回しかプロセス改善機会がないですよね）、1日や1時間程度の単純なものかもしれません（筋力トレーニングの計画を立てて、それにそってトレーニングをやる。疲れすぎたり、楽すぎたりすれば、筋力トレーニングの計画を見直して新しいトレーニングをしますよね）。
これらを知っていれば、正しい PDCA サイクルの知識をもってして、取り入れるか取り入れないかの判断ができますよ、というお話でした。
