私は8年間、大企業（メーカー）でエンジニアとして勤務した経験があります。
PDCA を回すことは、とても大切でした。
より質の高い仕事ができるようにするために不可欠だからです。
今日は、エンジニアの「設計・開発業務」におけるPDCAについてお話しします。
エンジニア（技術者）の仕事内容を解説！ 大企業と中小企業・零細企業の違い
目次
大企業のエンジニアの「設計・開発業務」におけるPDCA、チェック・アクションが大事
PDCA サイクル
まずは、とても有名な PDCA サイクルについて、一応説明をしておきますね。
PDCA サイクルとは、Plan(計画)・Do（実行）・Check（評価）・Action（改善）を繰り返すことによって、業務を改善していく手法のことです。
Plan（計画）
業務の目標を設定して、達成できるように計画を立てる段階です。出てほしい結果もしっかり考えます。
その時点で、できる限り考え抜いた内容にするべきです。
Do（実行）
Plan の段階で考えた計画を実行することです。
Check（評価）
Do の段階で実行した計画を評価することです。
Plan（計画）の段階で予測していた結果と、実際の結果を比較して、最初に考えた Plan（計画）が有効か否か判断します。
Action（改善）
Check の段階で評価を受けて業務改善することです。
Plan で設定した目標を達成できるように、どのように改善するか決めて実行します。
スケジュールの PDCA
PDCA の事例をあげてみますね。
設計・開発業務を進める上で、スケージュールは非常に大事です。
何かのプロジェクトに着手する前に、スケジュールを立てる必要があります。
これが Plan（計画）です。
以下のことを行い、スケジュールを固めます。
・自分自身で考える
・関係部署と調整をする
・上司の承認を得る
この時点では、ラッキースケジュールです。
このようにして作ったスケジュールに沿って、業務を実行します。
これが Do（実行）です。
スケジュールを実行して行き、ある程度の期間が経ったら、当初の計画と進捗の度合を比較します。
これが Check（評価）です。
さて、だいたいのプロジェクトにおいて、当初の計画と比べて遅れが生じます。
トラブルがあったり、工数の見誤りがあったりするからです。
そこで、その比較結果を踏まえて、その先の計画を再考します。
そして、その後の計画を実行して行きます。
これが Action（改善）です。
実験の PDCA
実験でもPDCAを使います。
まずは、実験の計画（Plan）を考えます。
このときにどのような結果が出るか？ ちゃんと予測することが大事です。
その上で実験を実行する段取りを組み立てるのです。
こうして作った計画に沿って実験を行います（Do）。
さて、実験を行うと予測した結果と違う結果が出ることがよくあるのです。
予測と実際の結果の違いが分かるようにするために、実験データを測定したらすぐにグラフ化するなどして、結果を見えるようにする必要があります。
こうして予測と実際の結果の違いをはっきりさせたら、その原因を考えます（Check）。
そして、結果を予測し直して計画を微修正して、実験の残りの時間で行います（Action）。
Check（評価）・Action（改善）が大事
よくやってしまうのが Plan（計画）、Do（実行）だけを行い、Check（評価）・Action（改善）を行わないというパターンです。
Check、Action が無いと、自分が行ったことに対してフィードバックをしていないことになります。
そうなると、何も考えていないことと一緒になってしまいますよね。
PDCA は Check、Action こそが重要な過程ですので、やったことはしっかりと振り返りその後に活かすようにしましょう。
まとめ
エンジニアの「設計・開発業務」におけるPDCAについてお話ししました。
どの業界・業種でも PDCA は大事で、もちろんエンジニアの仕事にも大なことがお分かりいただけましたでしょうか？
PDCA の中の特に Check、Action が重要です。
Plan、Do だけで終わらせないようにしっかり意識しましょう。
エンジニア（技術者）の仕事内容を解説！ 大企業と中小企業・零細企業の違い
PDCA が大事って聞くんですけど、エンジニアの場合の PDCA ってどういうものですか？