みなさんはPDCAを回していますか。

というかPDCAをご存知でしょうか。

 

Plan-Do-Check-Actionの頭文字をとったもので、

計画を立てて、実行して、評価して、改善策を立てる、そして計画へ・・・というものです。

やれPDCAサイクルを回せだの言われる昨今（最近はOODAとかG-PDCAとからしいです。）ですが、

 

実はPDCAにもやり方があるんじゃないかと思いました。

 

結論から言うと、3つポイントがあり、

①目的があるか（Objective）

②そもそもP・D・C・Aのそれぞれをすることが出来るか。

③P・D・C・Aをそれぞれ繋げられるか

です。

 

いろいろ考えたので聞いてください。

 

 

まずそれぞれ見ていきましょう

 

①目的があるか

なぜ目的が必要なのか。

それは②のそれぞれのPDCAの基準になるからです。

基準がないと、そもそもPDCAをすること自体なんて不可能なんですよ。

 

基準がないままPDCAサイクルを回すというのは、数字のない世界で個数を数えようとするようなもんです。

 

まずは目的を確認しましょう。

 

目標とは違う

目的と目標は違います。

目標はあくまで達成基準です。ゴールではありますが、ビジョンではありません。

目的はどちらかというとビジョンです。

どうあるべきか、何が理想か。

理念は何か、哲学は何か。

そう言ったレベルで形成されるのが目的です。

なぜそれをするのか。

その理由・動機こそが人を駆り立て、行動に移るんです。

 

目的の効果を、②で見ていきましょう。

 

②そもそもP・D・C・Aのそれぞれをすることが出来るか

次にPDCAサイクルを回すには、PDCAの個々が出来てないといけません。

じゃあ如何にしたら出来てると言えるのか。

 

例えば「何か資料を作成する」という作業を例にPDCAサイクルを考えてみましょう。

 

 

Plan

計画ですね。

まずは何をやるかを決めないといけません。

その際に、目的がなければ資料は絶対に作れません。

いや、もちろん作れますよ？

議事録取っといて、とかだったら話してたことをまとめればいいわけですし。

 

しかし、目的があれば、ササっと解決します。

何のために作るのか、誰のために作るのか、だとすれば何が書かれていないといけないか。

おのずと議事録作成の観点が生まれてくるはずです。

 

次に、作業のプロセスを分解します。（タスクばらしと呼ばれます。）

なぜ分解するのかというと、作業にかかる時間をより正確に見積もるためですね。

 

この時のポイントとしては、具体的に・適度な大きさで（大きさのことを粒度と呼びます）分解することです。いわゆる細分化ってやつです。

 

これが出来ると、非常に良い計画を立てることが出来ます。

僕はこれを具小タスクと呼んでいます（具体的な小タスクの略です）。

 

 

Do

実行です。

実際に立てた作業に従ってやってみます。

 

 

この時に必要になってくるのは、能力です。

資料作成でいえば、情報整理能力・うまく図にまとめる能力、データを抽出する能力などがあげられるでしょう。

計画段階ではあまりにもミクロな能力に関しては考慮されませんので、個々人のスキル・能力に依存すると言えるでしょう。

 

 

しかしここでも目的が必要になります。

何のために資料を作るのか。

全ての情報を詰め込むわけにはいきません。聞く人はそこまで暇じゃないからです。

どんな情報をまとめればいいのかの基準がここで決まるからです。

その基準によって、優先すべき情報が絞られて、結果の質も高まるでしょう。

 

 

Check

評価です。

良かったこと・悪かったことの両方を評価します。

そしてその原因を分析します。

 

基準となるのは、もちろん目的です。

目的にどれだけ沿っているか。ずれていないか。

その基準がないと、原因を分析したところで良い効果は得られません。

 

 

この時のポイントとしては、ロジカルシンキングを使うことです。

論理思考なんてものは巷に溢れ出していますが、ここでこそ使うべきです。

「なぜなぜ思考」やロジックツリーを思う存分使いましょう。

それで根本原因を炙り出すのです。

 

資料作成後に成果物を他人に見てもらってフィードバックをもらうもよし、自己レビューでどこが悪かったを考えるもよし、です。

言語化するなりアウトプットしてみると、非常に考えやすくなります。

 

Action

最後に改善策を立てます。

次どうするか、次にやることを考えます。

 

この時も目的がないとだめです。

基準がなければ、次にやることを立てたところで頓珍漢です。

 

 

この時のポイントも、ロジカルシンキングをつかうことです。

ここではhow型のツリーやピラミッドストラクチャーを使って次の施策を考えるとよいでしょう。

 

 

 

②のまとめ

ここまで②の個々のPDCAをちゃんとやるをざっと見てきました。

①の目的が、通奏低音のように、ボディブローのように、すべてに漏れなく効いていると思います。

次はこれらを繋げていきます。

 

 

 

③P・D・C・Aをそれぞれ繋げられるか

PDCAサイクルを回すには、P→D→C→Aそれぞれ繋げる作業が必要です。

 

 

P→D

計画から実行です。

これは簡単に出来そうですね。だって、計画したものをそのままやればいいんだもの、やすし。

 

ところが実はそうではありません。

P→Dをするのに必要なものがあるんです。

 

それは、資源（リソース）です。

人が使うエネルギー（思考・労力）であったり、時間であったり、お金だったりします。

これを解決しないことにはJustDoIt出来ません。

出来なかった場合はその観点でCheckとActionへと進んでください。

 

 

D→C

実行した後の評価です。

これもやったことの結果を評価すればいいだけです。

 

ですがここでも、必要なものがあります。

それは記録です。

 

結果はわかりやすいものもありますが、その過程は案外記録されていないことが多いです。

自分が何をしてその結果になったのか、どんなことをリアルタイムで考えたのか。

「この時こんなことしたっけ・・・」という記憶だけでは本当に振り返ることはできません。

 

メモといった記録をすることで、プロセスを可視化し、Checkでの原因分析でデータとして生かすことが出来ます。

なのでデータを記録することが重要だったりします。

 

 

C→A

分析結果に基づいて、改善策を立てます。

根本原因までにたどり着けていないと、次の打ち手そのものは曖昧で場当たり的になっていることが多いです。

また、次の打ち手によって本当に原因を解消できるのかという視点も必要です。

どちらも為されて始めて繋がった、と言えるでしょう。

 

 

A→O

施策を立てたら、目的へと組み込みましょう。

ここで立てた改善策・はPDCAすべての段階作用します。

そして次の計画へ・・・となっていくのです。

 

 

 

まとめ　PDCAの粒度

お気づきの方もいられると思いますが、タスクだけでなく、PDCAにも大きさがあります。

日々のPDCA、一週間のPDCA、一月の、半年の、一年の・・・。

というように入れ子であったり、パーツであったり、構造の骨子であったりします。

大きなPDCAには小さいPDCAがいっぱい積み重って形成されます。

 

そして一度立てた大きなPDCAも、サイクルを回していくと実はOが変化していくため、PもDもCもAも変化していくことがわかります。

実はPDCAというのは、一度立てたらあまり変えれない、ウォータフォールのような硬直的で一貫しているものとは違う、ということがわかります。

 

O-PDCAと言い、PDCAに目的（O）を取り入れるだけで、柔軟性のある、非常に使いやすいフレームワークとなります。

 

 

今一度、目的を考えてPDCAを回していきたいですね。