『第76回 標準化が定着しない理由』にて、プロジェクトにおける標準化のメリットやデメリットについて考えた。しかし、「標準化」と簡単に言うものの、「標準化」自体をどのような観点で「標準化」していくかについては、それほど深く気にしていないのではないか。今回は、プロジェクトマネジメントの「標準化」について、少し深く考えてみたい。
後藤 年成
マネジメントソリューションズ 取締役 PMP
『第76回 標準化が定着しない理由』では、標準化のデメリットとして以下の5つの点を挙げました。
- 標準が絶対的なバイブルとなり、柔軟性がなくなる
- 「標準に従っていればよい」という心理を生み、改善意欲が失われる
- 標準どおりに実施した結果、現場の生産性が下がる
- 利用も何もしない無駄な指標を計測し続ける
- プロジェクト固有の習慣や文化、言葉などを標準に合わせるための“翻訳作業”が発生する
誤解を恐れずに上記の5つを要約すると、「不確実な例外処理（リスク）が発生した場合において、標準化したがゆえに柔軟な対応ができない」ということが一番のデメリットになると思います。
では、リスクに弱いという「標準化」のデメリットに、うまく対処する方法はないのでしょうか。一般的に、システム開発における「標準化」とは、下記の3つの要素に分解することができます。
（1）作業をするためのインプット（チーム間インタフェース）の標準化
（2）作業自体のプロセス（手順）の標準化
（3）作業結果のアウトプット（成果物）の標準化
システム開発の標準化としては、上記の（1）（2）（3）のすべてを標準化しようと試みます。そのため、「インプット→プロセス→アウトプット」という一連の流れのすべてにおいて「あそび」がなくなり、ほんの少しの例外（リスク）が発生した時点で身動きが取れなくなってしまいやすいのです。
標準化に必要な「あそび」
図1は、標準化において注力すべき観点についてまとめたものです。成熟度が高いプロジェクトとそうでないプロジェクトでは、強化すべきポイントが異なる点に注目してください。
この図から分かるとおり、標準化において不確実性に対応するために一番「あそび」を持たせやすい部分は「プロセス（手順）」になります。例えば課題管理やリスク管理などの協力・改善を推進するための最低限のルールを中心に標準化することで、運用手順そのものには柔軟性を持たせ、不確実性（リスク）に対する対応力を高めることができます。
その逆に、他のチームやプロジェクトへのインプットとなるインタフェース、成果物であるアウトプットに「あそび」を持たせるとどうなるでしょうか。各チームの成果を取りまとめたり受け渡したりしにくくなり、標準化のメリットを阻害してしまいます。どんな場合にも、インプットやアウトプットに「あそび」を持たせるべきではありません。
