« Kensington ロックの安全性 | トップページ | クールビズ ポイント9か条 »

2005年7月14日 (木)

PDCA 本家の陥落

NASA はアポロ月面着陸プロジェクトのときにプロジェクト管理手法を確立させた。その後、その手法は「プロジェクト」と呼ばれるものすべてに採用された。いわば、NASA はプロジェクト管理手法のご本家だ。しかし、いまやその本家の威厳は地に落ちてしまった。


いまや工程管理の常識である、PDCA, WBS, PERT図などのプロジェクト管理手法やツールのほとんどは、米国 NASA がアポロ計画の中で生み出したものだ。
情報公開制度により、アポロ計画における当時の手書きの議事メモなども含めて見れるようになっている。
それらを目の当たりにすると、アメリカの先進性に驚かずにはいられない。

そんな NASA が今やプロジェクト計画本家の見る影もない。


毎日新聞 2005年7月14日 3時26分 (最終更新時間 7月14日 10時56分)を参照

発射直前の TBS ニュース23 で取材が放映されていたが、プロジェクト指揮官が長官に品質改善のためにプロジェクトの見直しを要請するも、当初計画日程遵守を偏重し却下されたため、指揮官が辞任している。
指揮官は取材の中で、「いまや現場は悪いことは上に報告できない環境にある。上も良い報告しか受付けない。」と言っていた。

HRO としてあってはならない環境だ。

いくら WBS と PERT 図を厳密に準備しても、PDCA がちゃんと機能しなければ意味がない。

最近ときどき、PDCA を PDC としているのを見かける。
Plan, Do, Check したら、Action を適切に取らなければならない。
Check しっぱなしでは意味がない。
Plan, Do, Check が手続き的に実施できるのに対して、もっとも重要な Action は、人の判断によることになる。
PDCA を P|D|CA と分けるのは、あまりに危険だ。
本質的なところでは、PDC|A で分けてもよいくらいだと思っている。
PDCA を PDC にする人達は、C+A をまとめて C にするということがあってはならない。
A が異質だから PDC についてまずは考える・・・というのはナンセンスだろう。

PDC については、より多くの人間の意見を求め、上位までの承認プロセスを持つのがよいだろう。
しかし、A については、現場にもっとも近い少数の人間の意見を十分に尊重する必要がある。
fail safe の観点からすれば、Go サインについては、現場全員の同意を必須とする必要があるだろう。
ひとりでも、No Go がいるならば、No Go をまずは決定すべきだ。

現場指揮官が No Go を要請し職を辞してまで訴えたものを、その長たる者が、Go を強行するような NASA には、もはや、アポロ計画の頃のようなプロジェクト遂行は期待できないのだろうと思った。

納期という圧力に人が負けたとき、現在のプロジェクト管理手法のすべてが機能しないことは、図らずもそれを生み出した NASA が証明したことの意味を考えるべきだろう。

アポロ計画の遺産である WBS や PM 手法を使った、昨今のIT構築であるが、ちゃんと PDCA ができているのだろうか・・・
似たような話しを見聞きするのは気のせいだろうか・・・

NASA は発射延期により、最後の最後でぎりぎり No Go のブレーキが残っていたわけだが、はたしてIT構築の現場はいかに?

7月 14, 2005 |

トラックバック


この記事へのトラックバック一覧です: PDCA 本家の陥落:

コメント

大切なのは、PDCAのサイクルを回して、継続的に効果的な業務プロセスを確立することにある。最初にPがあるので、そのサイクルの意味を不十分に理解している人がいる。実は、Pをいかに精度高く効率よく確立するかは、Aから導き出すのではなく、Cまで遡らないと不十分になる。Cには、いわゆる「実行後の現状把握」という貴重なデータが存在している。Aはその中の部分的な対策に過ぎない。改善のサイクルを回すためには、Cまで遡って、CからAに至ったプロセスを振り返ることにより、よりステップアップしたP(仮説)を導き出すことが出来る。PDCの時代がそうだった。Aを追加したのはCで留まるなという意味では重要だったが、Aがアクション(ひとつの仮説の実施)であり、肝心のPも仮説の立案であるため、AとPが少し離れたものになってしまったと危惧している。

投稿: | 2011/01/04 15:44:08

佐藤さま、
コメントありがとうございます。
Pはプランではなく、プランニングとして考えないといけないですね。その意味では、よくPDCAを円形に図示することがありますが、PDCAはすべてが並行している4つの線で示してもよいくらいだと思っています。

投稿: 佐藤慶浩 | 2011/01/04 16:24:27

はじめまして、少し思ったことをコメントいたします。

PDCAはサイクルプロセスです。よって、なぜそこにActionがあるのかわからないと私自身思っています。
PlanしてDoしてCheckしたらもう一回Checkした結果を元に改善計画(Plan)を立てて(Do)ではないでしょうか。

サイクルではないとしたらPDCAでいいと思いますが、PDCと記載している人は決してCとAをまとめているわけではないと思います。

余談ですが、WBSは1サイクルごとに作られ、PERT図は1サイクルごとに更新されるものだと思いますので、これらとPDCを一緒に議論するのも違うような気がします。

投稿: ヤツナミ | 2011/02/24 18:04:44

ヤツナミ様
コメントありがとうございます。

PDCAはサイクルプロセスですが、それを組織全体も1つのサイクルだと誤解している人がいます。組織の各階層や役割ごとに、PDCAサイクルがあるのであって、それを組織全体で書けば、ISMSユーザガイドにあるような図になりますし、それを平たくすればPDCAが4本走っているのと同じことになります。
PDCAで言うところのAは、P時点で決めるAのことと理解しています。Pで決めたDをして、それをCして、そのCの結果に応じてPしたことがAによる実施です。
その後、CやAで予想外のこと、いわゆるunplannedなことがわかれば、それは次のPへの入力になります。

PDCと記載している人は、Cに上記のようなAを含めて理解している人もいますが、その記載だけを見た人に、CがPに直接入力されるという誤解を与えることもあります。

WBSとPERT図については、ご意見と同じことを書いているつもりです。ここではPDCAのことしか述べておらず一緒の議論はしていません。PDCAサイクルの運用手法の例としてWBSとPERT図の利用もあるはずが、WBSとPERT図さえやっていれば、サイクルになっているという錯覚をしてしまうこともあるだろうということです。

投稿: 佐藤慶浩 | 2011/02/28 10:35:23

コメントを書く