そのPDCAの『C』間違っていますよ、マネージャさん

本来の意味合いを理解せずに、ただ言われるがままにやらされて、その本質を理解せずに間違ったままにみにつけ、本来だったら得られる効果を得られず最悪は無駄なことをやっている現場はいくらでもある。

PDCA
PDCAは、Plan/Do/Check/Actionであることはエンジニアであれば誰でも知っている。しばしば改善というスローガンで生産性を向上しろだとか、品質を上げろと課題を出されるやつで使われる。

PDCAは、計画、実行、確認、対策の意味合いで使われていることが間違いの要因であることに気づいていない。どこが間違いなのかというと、『確認』である。Doである実行を見たところで意味はない。やってしまった結果だけしかない。それを見て何を得られるか、ということ自体に気づかない管理職が多いのである。

CのCheckは『検証』でなければならない。検証は、

けん‐しょう【検証】出典：デジタル大辞泉（小学館）
［名］(スル)
１実際に物事に当たって調べ、仮説などを証明すること。「理論の正しさを検証する」
２裁判官や捜査機関が、直接現場の状況や人・物を観察して証拠調べをすること。「現場検証」「実地検証」
検証（けんしょう）の意味 - goo国語辞書

の意味のとおり、Doの実行の結果とPlanの計画を比較し、計画の妥当性を確かめなければならない。計画と実行の結果に差異があるのであれば、原因を分析し対策が必要かを判断しなければならない。

Actionの対策としてしばしばチェックリストを用いるが、これも機能しない。

例えば、本番システムのプログラムデプロイを1人で作業を行い、作業中のエラーメッセージを見たにも関わらず進め、本番の運用で障害を引き起こしたとする。

チェックシートで障害の再発防止に務めるのも、本当に再発防止ができるかは疑わしい。なぜなら、障害の原因は、プログラムのデプロイを1人でやっていることかも知れないし、デプロイを人手でやっているからかも知れない。

障害は基本的に作業プロセス上に問題があり、そのプロセスを変える必要がある。人に原因があるとする判断も間違いである。

問題が起きた箇所では、作業を安全に進められる条件が揃わないと先に進めないようになっていなければならない。

その意味で、チェックリストを作ったとしても作業者がチェック項目に書かれていることを理解し、項目の合否により作業を止められなければ意味がないばかりか効果のない無駄な作業を増やすことになる。その典型がチェックリストなのである。

単純に『それやってどうなる？』とやったあとの将来を見切れれば検証が妥当かは判断できるのだが、それをやらないのがアレなマネージャなんだな。