PDCAを1人で回せる喜び

転職後編は、転職直後から順を追ってその時々の苦労や喜びを投稿しようと思ってましたが

昨日、中小企業ならではの仕事のやり易さを感じたので、忘れる前に記録を残します。



今日のキーワードはPDCAと複雑さの法則。




PDCAはPlan(計画)→Do(実行)→Check(評価)→Action(改善)のサイクルを繰り返し行うことで、継続的な業務の改善を促す方法で




複雑さの法則は、作業手順が増えると複雑さが増すという概念で、特に人に作業を依頼する場合は、その影響が大きくなります。







ちなみに複雑さの法則は、私の愛読書であるフォーカルポイントで提唱されている概念で、あまり一般的でないかもしれません


さて、私は大企業と中小企業で、共に新規製品の開発業務をしております。



その中でのPDCAを具体化すると

P:製造条件、試験水準、スケジュールを計画
D:その計画に基づき製造(試験)を実行
C:その結果が合格基準を満たしているか判定(品質確認も含む)
A:改善点や再現性確認のポイントを洗い出し、Pに戻る


至ってシンプルに見えます。


さて、このPDCAを私の経験を基に大企業VS中小企業で比較してみると



大企業
以下P
①製造条件、試験水準、スケジュールを計画
②親会社の担当者(当時の私)が製造を委託している子会社の管理者に計画を説明
③子会社の管理者が現場のオペレータに計画説明
(ここで現場から意見があり、計画が修正されると①に戻る)
④製品の品質評価も子会社に委託しているので、依頼書を作成
⑤依頼書の承認印をもらうために上司に説明

以下D
⑥子会社のオペレーターが計画に基づいた製造を実行
⑦何かトラブルが発生した場合、現場のオペレーターが子会社の管理者に連絡。子会社の管理者でトラブル対応の判断が困難な場合は、親会社の担当者に連絡
(開発業務はトラブルが付き物。計画通りいくことは稀)

以下C
⑧子会社の管理者が親会社の担当者に試験や製造の結果を報告。
 (ここで、トラブルの状況説明があるのだが、子会社の管理者も現場に張り付いているわけではないので、現場オペレーターの報告をベースに報告→親会社の担当者達が詳細の説明を求めるも、子会社の管理者は全てを回答できない(当たり前))
 →ここのやり取りが非常に長い。しかも伝言ゲーム式なので、生の情報がだんだん薄れていく
⑨品質評価の依頼をしている子会社の報告を受ける

以下A
⑩報告内容や操業データを基に、改善点や再現性確認のポイントを洗い出し、Pに戻る

以下A(additional work)
⑪開発業務の進捗を上位層の方々に説明するための資料作成
 →資料を作成し上長に確認→修正→上長に確認→修正
⑫進捗を説明
 →上位層からの疑問・質問を記録に残す
⑬質問の回答
 →詳細状況がわからない場合は子会社の管理者に確認→子会社の管理者がわからない場合は現場のオペレーターに確認→現場のオペレーターは当時のことを覚えていないことが多い(あぁ、どうすればいいんだ・・・。そして物語は作られていく。。。)














もうねぇ。一言で表すなら伝言ゲーム








ちなみに、大企業はPDCAではくPDCAAでしたね。






中小企業
以下P
①製造条件、試験水準、スケジュールを計画
以下D
②計画に基づいた製造を(私が)実行
以下C
③製造結果のレビュー。品質を(私が)確認
以下A
④結果と次回の計画を上長に報告。問題なければPに戻る







基本的に全て自分でやるので、製造のトラブルや設備の異変などの全ての情報を把握でき、説明・報告は最小限となってます。









今回の例、プラント規模が異なり、大企業側にとっては少し苦しい条件かもしれませんが、大企業の働き方は上述のような感じだとよく聞きます。





さて、冒頭に話した複雑さの法則を振り返ると一目瞭然だと思います。





複雑さを最小限化でき、マイペースで開発業務を進められる中小企業の働き方に喜びを感じた



以上











コメント

タイトルとURLをコピーしました