見出し画像

PDCAの「C」ができる人は、仕事できる感あるし、実際仕事できる


・「やりっぱなし」のタスクが多い
・  終わったつもりの仕事に「あれ、その後どうなった?」と言われる
・  タスクやプロジェクトがいつの間にか自然消滅する
・  気付くと手段が目的化している

こういう人は、PDCAの「C」ができてない(意識できてない?)かもしれません。


「Plan」と「Do」はできるのに…

これ、新卒に限った話ではありません。
ほかの職能(たとえばプログラミングとか)は一流なのに、自分でPDCAの輪っかを回す力がない人っています。

たとえば、「Check」ができない人ってこんな感じです。

とあるWebサービスで、
上司「利用登録から初期設定まで、ユーザーはスムーズに進めているだろうか?最近UI変更があったから、心配だなあ。」
Aさん「では、初期設定が完了してないユーザーを調べてみましょうか?」
上司「ああ、分析してみてくれ」

後日…
Aさん「利用登録したのに、初期設定が完了してないユーザーの一覧です!ご確認ください!」
上司「・・・あ、ああ。ありがとう。」

また別の日にはこんなことが…

Aさん「不正な使用を検知する仕組みを作りました!明日からチャットで通知がきます!」
上司「それはいい考えだね。ありがとう。」

次の日…
Aさん「今日は通知が3件ありました。」
Aさん「今月は累計で5件だったようです。」
Aさん「この数値は、全体の1%です。」
上司「・・・了解。」


「Check」とは、「意思決定できる状態を作る」こと

上記の例の何がいけないのでしょう?

私が思うに、上司や周囲に「で、どうすればいいの?」と思わせてしまう場合、そのタスクは「Do」で止まっている可能性が高いです。
Doの結果を踏まえ、原因や背景を観察し、解釈を加え、意思決定できる状態を作るのがCheckのプロセスです。

1つめの例で言えば、上司の目的は
「利用登録 → 初期設定 の完了率を調べること」ではなく、
「利用登録 → 初期設定 の完了率を改善すること」だったはずです。

PDCAに当てはめると、
・利用登録 → 初期設定 の完了率を改善したい(Plan)ので、
・直近のデータを使って事実を調べて(Do)、
・どこがボトルネックなのかを分析して突き止め(Check)、
・完了率引き上げのためのアクションを講じる(Action
となります。
そんなときに、AさんがDoの時点の結果を持ってやってくれば戸惑います。
で?このリストを使って、ここからは私が分析しろってことか?」となるかもしれません。

2つめの例でも同様です。
「不正を検知する仕組みを作る」という行動はよかったのに、結果を踏まえてどんな策を講じるかという意思決定を上司に丸投げしてしまっているために、Aさんの行動は本来の目的であろう「不正使用をなくす」に繋がっていません。


なんで「Check」ができないのか?

Type 1.  タスク思考のタスキーさん
自分の仕事の範囲を線引きし、その範囲を超えた仕事はやらないので、Check が機能しないタイプです。

こう書くと意識的な行為に聞こえますが、自分がタスキーさんになっていることに気づかない人もかなりいます。
実際には目的達成のためのファーストステップでしかないのに、いつの間にか手段が目的化し、それが完了すると仕事が終わったと思ってしまうのです。

Type 2. 意思決定するのが怖いフォロワーさん
Doの結果に自分の解釈を加えることが怖いので、とりあえず他人に見せて指示を仰ぎ、自分ではCheckしないタイプです。

このタイプは、自分の解釈によって結果が左右されるのが怖いので、意図的に主張・説明を排除しようとします。生の状態のデータを他人に見せて、他人の反応を見てから判断しようという意思が働いています。
どの情報が重要か判断できないので、とにかくたくさん資料を見せる人もいます。

Type3. とりあえずやってから考えるプロトタイパーさん
「考えるより先に行動したい」というタイプの人にも、Checkのプロセスが欠けがちです。そもそも「検証」というプロセスが好きではない人も多く、「やれば何とかなる」という考えから、Checkを飛ばしてしまいます。

その結果、説明がつかない状況、白黒ハッキリつかない状況に至った場合に、唐突にやる気を失ったりすることもあります。


重要なのは「P」の時点で(Dの前に)「C」を考えておくこと

「やりっぱなし」になっちゃうのは「Doの後どうするか?」を考えてないからです。

「もし結果がAだったら原因はA'だから、アクションA"を実行する」
「調査の結果、該当率が50%未満だったら効果がなかったとみなし、施策を中止する」

というように、Doについての起こりうる結果・その原因・意思決定 のパターンをPの時点で洗い出しておくのです。

逆にいえば、DoはCheckにおける意思決定の選択肢を減らすためのプロセスです。あらかじめCheckのときのことを考えておけば、Checkに必要な情報をDoで集めることもできます。


最後にPDCAがうまく回ったパターンを一つ。
(デフォルメしてますが、弊社で実際にあったやりとりです)

上司「利用登録から初期設定まで、ユーザーはスムーズに進めているだろうか?最近UI変更があったから、心配だなあ。」
Aさん「初期設定が完了してないユーザーを調べてみますね!」
上司「ああ、分析してみてくれ」

後日…
Aさん「初期設定が完了してないユーザーの一覧です。ユーザーIDのほか、利用登録日・経過日数を洗い出したところ、利用登録から5日以上経過すると休眠ユーザーになる確率が急激に上がることが分かりました。」
上司「なるほど。」
Aさん「まず利用登録から5日以内のユーザーには初期設定のフォローアップを、5日以上のユーザーにはリマインドメールの送付を考えていますが、いかがでしょう?」
上司「いいね。やってみてくれ。任せたぞ!」


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

読んでくださりありがとうございます!

気が合いますね ( ˘ω˘)
2

niri

某Webサービスの UXデザイナー。毎日の学びを残す場所。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。