SPIDERPLUS Tech Blog

建設SaaS「スパイダープラス」のエンジニアとデザイナーのブログ

みんなで回そうPDCAサイクル!

こんにちは
品質管理部の岡野です。
今回はPDCAサイクルについて書いていきたいと思います。

自分は品管以外の職務経験がないのでスパイダープラスの他部署でも使われているのかはわかりませんが、過去に経験したいくつかの職場ではこちらをベースにしていた場所が圧倒的に多かったので、スパイダープラスに限らずこれから「開発関連のお仕事に就きたいぜ!」って方は、知っておくとちょっとだけスムーズに仕事に入れるかもしれません。

PDCAとは

Plan(計画)、Do(実行)、Check(評価)、Action(改善)のそれぞれ頭文字をとったものです。流れとしては、

といった感じです。上記ですと「Action(改善)」は「Plan(計画)」にかかっていますが、別にこれに限った話ではなく「Do(実行)」にかかったりもします。自分はPDCAサイクルに関してはトライ&エラーを改善しながら繰り返していくというイメージを持っています。

スパイダープラスの品質管理で簡単に例を挙げると、

上記のサイクルで、大きな改善は頻繁に発生するわけではないのですが、上記の「Do(実行)」をしてく中で不足点や、次回類似箇所確認の際に事前に準備すべきことなどが「評価(C)」で洗い出され、それに対する「Action(改善)」を加えていく。というようなPDCAサイクルが回されています。

「評価(C)」と「改善(A)」が特に大事だし難しい

PDCAはどれも大事なのですが、自分は特に「評価(C)」と「改善(A)」が大事だと思っています。評価と改善はざっくり言ってしまえば反省会のようなものというイメージでいれば大きく外れてないかなと思います。
そうではありながらも自分の過去の経験上、評価と改善を苦手とする人は結構多い印象です。評価が実際の原因を深堀りし改善案を考えるものでなく、改善が精神的な反省や意識の向け方ののようなものが多くあったように記憶しています。

実際にあった良くない「評価(C)」と「改善(A)」の例

PDCAサイクルに慣れていない方の反省だと「見落としだったので、次回はより一層気を付ける」のような反省と改善点が上がってくることがありました。
この方の「実行(D)」に対する「評価(C)」は「悪い点があった、それは自分のミス」で、「改善(A)」は「ミスしないように気を付ける」なのですが、これでは反省点の原因とその対策ができておらず「次は精一杯頑張る」という精神的な反省となっており、PDCAサイクルを回せているとは言えません。
この場合ですと、「見落としの原因は何なのか、そしてそれを今後起こさないためにはどうすればいいか」までは最低限ほしいところです。一概に「見落とし」と言っても、「仕様に明るくないため、適切な手法で仕事ができず、見落としてしまった」のか「そもそも計画にそこが入っていなかったからそこを確認する工程が頭になく見落としてしまった」など種類はあり、それぞれの問題に適した対処法は必ず存在します。原因を深ぼるためになぜなぜ分析も取り入れ問題点の本質を洗い出し、改善へつなげる動きへ繋げました。

最後に

偉そうに書いてきましたが自分も完璧にPDCAサイクルを回せているとは思っていません。うまくいったときの「よりよくするための改善」というのもあるのですが、これが自分は苦手で、「うまくいった手法をベースに細部を変更して実行し、効果測定を行い、改善が見られれば継続とさらなる手法の模索、効率が落ちるなど改悪が見られれば廃止」くらいの引き出ししかありません。
なにか良い方法を知ってる方がいれば教えてください。

そして、スパイダープラスでは仲間を募集中です。
もっといい方法を知っている、自分だったらうまくCもAもこなせる、などなど、スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。