PDCAサイクルという「思考方法」がある。今やすっかりお馴染みとなったが、ISO9000シリーズや14000シリーズが話題となった、25年余り前から言葉としても、内容としても、急速に広まって行ったように思う。
「計画（P）→実行（D）→検証（C）→行動（A）」という言葉で表されることが多い。そして、言葉にも内容にも余り疑問を感じずに使われてきた。
もちろん計画（P）という段階の前に、現状分析や目的・目標の設定という作業が必要なのだが、そしてそれらを策定することが重要であり、かつ難しいものではあるのだが。
とにかくPDCAサイクルは、物事を成し遂げてゆく上で、一つの有効な考え方、方法論として受け入れられてきた。
それまでの「日本型の計画」における特徴は、目標も計画も「ザックリ」としていたことは否めない。月次試算表や営業目標などは、それまでも数値化され、定期的に検証されてきた。しかし、それは後追いで結果を見るためのものだった。
また、トヨタ方式として有名になった「視える化」という考え方もあるが、これは今回の話とは少し異なるので、とりあえず横に置いておく。
さて、そこでPDCAサイクルの根幹をなす計画（P）である。いきなり計画が立てられるわけはないので、現状分析から「問題点」を洗い出し、「問題点」から「課題」を抽出する作業が必要である。
これは、「仮説」を立てて、「問いかける」ことに他ならない。まず、ここにこんな課題がある、ということを認識する作業が行われる。それとともに「仮説」に対する「仮の解答」となるものを導き出すことが求められる。
これが「目的・目標」に該当する。ここまでの作業は、“何かを成し遂げる”ための計画づくりの「基礎的作業」であるが、PDCAサイクルを考えるときに、この部分抜きでは何も始まらない。
例えば、新製品を市場に投入する場合、「この製品は、こうした市場では、今まではこういう状況だった。そこにこれを投入すれば、こういう顧客層が新たに開拓できる。そのボリュームはこれだけ存在し、その中で○％のシェアを獲得できれば、新製品は３年後にこういうポジションを占めることになる」といったことが、検討されることになる。
そのための市場調査が行われ、この文章が埋められてゆく。これが「仮説」であり、○％という数字や、ポジションが「仮の解答」ということになる。
これを出発点として、PDCAサイクルを考えることになる。つまりこの「仮説」と「仮の解答」が“ダメなもの”だったら、それ以後の計画（P）や行動（D）は、すべて無意味なものになることもある。
まあ、そこは市場調査などを通して、ある程度クリアできたものとしよう。目的は「目指すポジションの獲得」であり、目標は「シェア○％」となったとしよう。
それでは、PDCAサイクルのP＝計画を立てる、という段階になる。ここでいきなり計画が作れるのか、ということになる。
例えば、ブレインストーミングなどを行って、“やるべきこと”を網羅的に挙げてみる。それらを括ってみて、関係者が気付いたことを上げてゆき、大筋の実行すべきテーマが絞り込まれる。
テーマごとに、行程と作業分担などが話し合われる。その場合には、これまでの経験も重要なサポートになるだろうし、これまでの失敗事例があれば、それの振り返りも、失敗を無駄にしないためには必要なことだろう。
こうして、お互いに知恵を出し合って、なすべきことと、それぞれの細部での時系列的な獲得目標も、ターゲットとしてわかってくる。
それと同時に、実行するに際してバッティングする部分がどこかに存在するかどうか、とか、最もキーとなる「クリティカル・パス」（ここが進まないと、他が停滞を起こしてしまう、というもっともネックとなる経路）はどれか、といったことも明らかにしてゆかないといけない。
これは昔から「PERT Chart」などと言う考え方で存在していた。つまり計画とは「全体計画」と「部分計画」があり、部分計画の集合が全体計画だとは限らないこともある。全体計画をブレークダウンした結果の部分計画と、細部を積み上げた上で出来上がった部分計画とが整合するかどうかも、計画策定段階における重要な検証ポイントになる。
そして、具体的な実行方法を役割分担と絡めて、策定することになる。ここでは、責任者（部署）・期限（時系列）・予算・人員などが具体的に積み上げられてゆく。
こうして初めて、計画（P）として機能するものが出来上がる。ところが、これまでこの計画（P）が、どうしてもざっくりしたものになっている傾向があった。
極端に言えば「みんな、頑張ろう」になりかねない粗さがあったと思う。それだから、計画倒れという結果になりやすかった。
そのそもそもは、「仮説」を立てる段階から、その「問いかけ」が正しいか、または適切なものかを十分に検討せずにきたから、ということが多い。細部になれば、経験やらなんやら、色々と意見が出るけれど、根本的なところは「鶴の一声」ならぬ「虎の一吠え」で押し切られたりしがちだった。
これでは、後はすべてそれに対する『辻褄合わせ』に陥ってしまう。だから、計画（P）には、「仮説を立てる（P1）」→「仮説から解ることを導く（P2）」→「全員が知恵を出し合う（P3）」→「方法を考える（P4）」という、結構長い手順・段階を踏んでゆくことが求められる。
こうなって初めて、それぞれが自分の役割を理解して活動できることになる。実行（D）段階になると、それこそ「成果の視える化」によって情報共有を図ることが必要になる。
さらに、検証（C）も1，2週間程度で、実行した上での矛盾点など“実行上の問題点発見”のための小検証、次いで毎月の検証による「視える化」の実施、そして３か月ごとの“成果の検証”と段階を踏んで検証して行くことが望ましい。
特に当初の１カ月までは、この段階で行動（A）、すなわち「見直し」を行うことも含めて、事前に予期していなかったことの発見と、その修正に充てられることが望ましい。
その上で、６か月目の検証（C）を経たなら、単なる計画（P）の見直しという行動（A）だけでなく、最初の「仮設」の良し悪しにも踏み込んだ上で、「仮説の問いは、正しかったか」を考えてみることが必要になる。
PDCAサイクルと言っても、何も新しいことでもなくなってきた現在、サイクル自体を小回りに回す短期の回転と、全体的な計画（P）の問題点の整理に充てる大回転のサイクルとが共存するという考え方を取るべきだと思う。
こんなことを考えるに至ったのも、「良い問いとはどんな問いか」ということが書かれた文章を目にしたからなのだが、その文中にも「良い問いこそが、正しい答えへの道」と書かれていたので、以前から考えていたPDCAサイクルというもののあり方を、少し掘り下げてみる気になったからなので。
今日の中味は、きっと自戒を込めたものでもあると思っている。