DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、プロジェクト崩壊を回避するためのアクションとしてのプロジェクト中断・再開始について考察しました。プロジェクトの崩壊を回避するためには、過去のベストプラクティスをどのプロジェクトにも適用できるようにするための標準化が大切なことは言うまでもありません。

しかし、独自性という特徴を持つプロジェクトにおいて、標準化を進めることはそんなに簡単なことではありません。その証拠に、「標準化の功罪」について書かれた記事が数多くネット上に公開されています。

今回は、プロジェクトマネジメントの標準化について考察します。

【　標準とは何か？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは用語の定義を確認しましょう。PMBOKガイド第５版には、次のような定義が記載されています。（※１）

A1.1　標準とは何か
国際標準化機構（ISO）やその他の機関は、標準を次のように定義している。「共通かつ繰返しの使用を図るため、コンプライアンスが義務付けられていないプロダクト、プロセスまたはサービスの規則、ガイドラインあるいは特性を規定するものとして、認知された機関によって承認された文書」（ISO9453）

また、経産省の「国際標準化１００年記念事業」の紹介ページには、次のような記載があります。（※２）

標準とは
標準（＝規格：Standards）は、「自由に放置すれば、多様化、複雑化、無秩序化 してしまう「もの」や「事柄」を少数化、単純化、秩序化するための「取決め」」と一 般には定義することができます。また、標準には、強制的なものと任意のものが ありますが、一般的には任意のものを「標準」と呼んでいます。

後者の方が標準化の目的に触れられていることもあり、少しわかりやすいような気がします。ただ、これら二つの定義の中には、規則、ガイドライン、特性、文書、規格、Standards、取決めなど、似たような用語がいろいろ出てくることもあり、やっぱり品質の定義と同じように、わかっているようで、とらえどころがない感じが否めません。（※３）

ということは、標準についても品質と同じように、プロジェクトに関係するステークフォルダーによって、いろいろなとらえ方がされている可能性があり、そのことが標準化が思うように進まない要因になっているとも考えられます。

したがって、標準化を進めようとしている組織の中では、標準の定義や標準化の目的を明確化し、規則、規格、ガイドラインなど、それぞれが具体的に何を示しているかなどの定義をきっちり行う必要があるのは言うまでもありません。そして、個別のプロジェクトにおいては、どの規則や標準に従うかをプロジェクト計画書上に明記して、関係するステークフォルダー間で認識を合わせておくことが大事になるわけです。

【　ポリシーなき標準化は、標準を肥大化させ、標準の崩壊を招く！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
長い間のプロジェクトマネジメントご支援の経験を通してさまざまなシステム開発を行う組織を見てきましたが、プロジェクトマネジメント標準は放っておくと、前回のブログで触れたローマ帝国と同じような運命をたどるのではないかと感じています。

つまり、最初はみんなバラバラで属人的な仕事をしている中で標準化を進めていくと、一定の成果をあげるのは確かだと思います。それでも全てのプロジェクトがうまく行くわけではないので、いくつかの失敗プロジェクトの教訓や世の中の新しい標準化の流れなどをもとにして、プロジェクト標準は少しずつ成長していきます。さらに、たとえば最初は進捗管理ルールだけだったのが、品質管理やコスト管理、リスク管理など標準化のスコープも広がっていくことになります。

時間の経過とともに、最初のころに作った標準は少しずつ色あせていき、新たに追加された標準との間で不整合が入り込むなど、一部が陳腐化し始めます。そのころには肥大化した標準の全体像を理解できる人がいなくなり、標準全体を再整備しようにもなかなか手が付けられない状態になっていきます。一方で、システム開発のプロジェクトは走り続けるので、陳腐化した標準を無視して独自のやり方を取り入れる人も多くなり、ますますプロジェクト標準は使いものにならなくなって、やがて崩壊するのです。

ローマ帝国もプロジェクト標準も、最初は順調なすべり出しを示すものの、徐々に肥大化して動きが悪くなり、最終的に崩壊してしまうという同じような運命をたどることになるのです。ローマ帝国の場合は、ゲルマン民族の大移動という事象が崩壊のきっかけになったのと同じように、プロジェクト標準の場合は新たなプロジェクトマネジメント手法の流行などの事象が崩壊のきっかけになるという構図も共通しているかもしれません。

国家の場合はそこに属している人民や統治者が長い期間を通じて入れ替わっていくという特徴があり、システム開発の組織も同じように組織の構成員やマネージャーはどんどん入れ替わるという特徴も共通しています。

さて、前回のブログで崩壊を運命づけられているプロジェクトの運命を変えるのはプロジェクトマネージャーの役割としました。では、崩壊を運命づけられているプロジェクト標準の運命を変えるのは誰の役割になるでしょうか？経営者でしょうか？品質保証部門でしょうか？しかし、システム開発の組織では、ＣＩＯはじめ、品質保証部門長などのキーマンはどんどん入れ替わるのが普通です。その特徴を踏まえて、プロジェクト標準の崩壊を防ぐ手立てを考えておく必要があるのです。

一般的に標準を変更する場合、たとえばＣＩＯや品質保証部門の部門長の承認が必要などと規定する場合が多いと思います。しかし、人が入れ替わる組織の中で、そのような人に依存した規定だけでは不十分ではないでしょうか？標準の崩壊を防止するようなポリシーを標準の冒頭に規定しておいた方が良いのではないでしょうか？

どのようなポリシーかと言うと、ローマ帝国もプロジェクト標準も、崩壊の前に肥大化というステップがあることは共通なので、この肥大化を防ぐためのポリシーが必要です。たとえば新たな標準を追加する場合、既存の標準との守備範囲をしっかりと確認し、もし守備範囲が重なる部分がある場合は、過去の標準を捨てたうえで新たな標準を追記するといったようなポリシーを明記しておくのです。

このポリシーは、当ブログの　【第６１回】レビューチェックリスト地獄からの脱出大作戦！　で触れた「選択と集中」というキーワードと同じことです。レビューチェックリストもプロジェクト標準の一部だと考えられますが、「選択と集中」はプロジェクト標準全体に対しても適用できることであり、それがプロジェクト標準の崩壊を防ぐためのポリシーとなるのです。

【　プロジェクト標準の発散収束技法　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここまで抽象的な話でしたが、ここからもう少し具体的な話に入ります。たいていのプロジェクトで使っている図１に示すような問題・課題一覧を取り上げます。（※４）

問題・課題一覧の誤った使い方として、次のような記載を良く見かけます。

１．単なるタスクを記載している。
２．要件の不明点に関する質問事項を記載している。
３．漠然とした不安が記載されている。

本来、問題・課題一覧に記載してほしいのは、プロジェクト目標を達成するために組み立てたプロジェクト計画と現状とのギャップです。そして、そのギャップがあることでプロジェクト目標に対してどんな影響が生じるのか、そのギャップが生じた原因は何か、そのギャップを解消するためにどんなアクションが必要か、また、そのアクションの実施状況などです。

誤った記載に気付いた都度、プロジェクトメンバーに指摘するのは非効率なので、たとえば標準改善活動の一環として、問題・課題一覧に原因欄をあらかじめ追加することで、ギャップが生じた原因を考えて記載するよう促そうと試みたりします。また、たとえばギャップによる影響がどの工程に対する影響なのかを一目でわかるように、影響工程欄を追加したりします。そんな具合に、問題・課題一覧に対して、改善目的でどんどん記載すべき欄が増えていく方向で進んでいきます。

しかし、どうでしょう？ただでさえ問題・課題一覧に何か書くことにハードルを感じているプロジェクトメンバーたちが、そんなにたくさん書かなければいけないフォーマットを見て、さらに書く気を無くすことは容易に想像できます。問題・課題一覧をきっちり書くことも大事ですが、せっかくプロジェクトメンバーが気づいた気がかり事項が埋もれてしまうことによる損失の方がよっぽど大きいはずです。そのように考えた場合、問題・課題一覧のフォーマットの記載欄は出来るだけ少なくすることになります。

このように、問題・課題一覧のようなプロジェクト標準のフォーマットや手順などについて、いったんは管理すべき項目や手順を詳細化して考えたうえで、それを実際に適用するプロジェクトメンバーの運営のしやすさなどを考慮してシンプルなものに煎じ詰めることを、私は「プロジェクト標準の発散収束技法」と呼んでいます。

組織としてのプロジェクト標準として、管理項目や手順を詳細化した発散バージョンとともに、それをもとに煎じ詰めた収束バージョンの両方を標準の利用者たちに展開してはどうでしょうか？そうすることで、個別プロジェクトへのテーラリングもやりやすくなり、より現場で使われる標準になることが期待できるはずです。

「プロジェクト標準の発散収束技法を用いて、
プロジェクト現場への標準定着化を図ろう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※２　国際標準化１００年記念事業について「標準とは（PDF形式：141KB）」（経済産業省） http://www.meti.go.jp/policy/economy/hyojun/kijyun/pdf/about20standard.pdf

※３　品質の定義については、当ブログの以下の回も参照してください。
・【第５６回】品質とは何か？

※４　問題・課題一覧については、当ブログの以下の回も参照してください。
・【第７３回】問題・課題、Todo、リスクの『「超」整理法』