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 手法を使った、昨今のＩＴ構築であるが、ちゃんと PDCA ができているのだろうか・・・
似たような話しを見聞きするのは気のせいだろうか・・・

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