- ホーム
- プロジェクトマネジメントのヒント
- プロジェクトを失敗させないヒント86『標準化の「標準化」』
プロジェクトを失敗させないヒント86『標準化の「標準化」』
『プロジェクトを絶対に失敗させない!やり切るための100のヒント』とは

本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない!やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。
当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
お問合せはこちらからどうぞ。
※『プロジェクトを絶対に失敗させない!やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます
『[ヒント81]標準化が定着しない理由』で、プロジェクトにおける標準化のメリットとデメリットについて考えました。しかし、標準化と簡単に言っても、標準化自体をどのような観点で「標準化」していくかは、それほど深く気にしていないのではないでしょうか。
標準化のデメリットは、不確実な例外処理(リスク)が発生した場合に、標準化したが故に柔軟な対応ができないことです。では、リスクに弱いデメリットに、うまく対処する方法はないでしょうか。システム開発における標準化は、次の3つに分解できます。
(1)作業をするためのインプット(チーム間インターフェース)の標準化
(2)作業自体のプロセス(手順)の標準化
(3)作業結果のアウトプット(成果物)の標準化
システム開発の標準化として、(1)~(3)の全てを標準化しようと試みます。そのため、「インプット→プロセス→アウトプット」という一連の流れの全てに「あそび」がなくなり、ほんの少し例外(リスク)が発生しただけで、身動きが取れなくなってしまいます。
標準化に必要な「あそび」
次の図16は、標準化で注力すべき観点をまとめたものです。成熟度が高いプロジェクトとそうでないプロジェクトでは、強化すべきポイントが異なる点に注目してください。標準化で不確実性に対応するため、「あそび」を一番持たせやすいのは真ん中の「プロセス(手順)」になります。例えば、課題管理やリスク管理の協力・改善を推進する最低限のルールを中心に標準化することで、運用手順には柔軟性を持たせ、不確実性(リスク)に対する対応力を高められます。逆に、他のチームやプロジェクトへのインプットとなるインターフェース、成果物であるアウトプットに「あそび」を持たせるとどうなるでしょう。各チームの成果を取りまとめたり受け渡したりしにくくなり、標準化のメリットを阻害してしまいます。インプットやアウトプットには「あそび」を持たせるべきではありません。

注意すべきなのは、プロジェクトメンバーの成熟度に合わせて標準化を進めることです。同じようなプロジェクトを何回か経験し、仕事の進め方や成果物について認識が共有されているメンバーが多いプロジェクトでは、不確実性に強い“プロセス中心の”標準化を作っていく必要があります。
一方、メンバーの成熟度が低い場合は、プロセス(手順)の「あそび」を少なくする方がいいでしょう。各担当者の勝手な判断や自由をある程度抑制し、プロセスをしっかりと標準化することで、一定の品質を確保しつつ生産性の向上を目指すべきです。