プロジェクトマネージメントに関する知識を体系化したグローバルなデファクトスタンダードであるPMBOK(Project Body of Knowledge)第5版が昨年12月に公開された。その中で、これまでは「ステークホルダーマネージメント」は9個の知識エリアの一つである「コミュニケーションマネージメント」の中の1要素であったのが、10個目の知識エリアとして新設されたとの事だ。1996年の第1版発行以降知識エリアの新設は一度もなく、PMBOKの歴史の中でも画期的なことらしい。世界的に見ても「ステークホルダーマネージメント」が重要視され始めたと言うことだと、日経SYSTEMSの矢口竜太郎記者は言う。

その矢口記者が、日経SYSTEMS3月号の特集「プロジェクトの協力者を増やすステークホルダーマネージメント」に関してITproに投稿している（http://itpro.nikkeibp.co.jp/article/Watcher/20130225/458741/?mle）。なぜ、ステークホルダーマネージメントが重要になってきたか？「ステークホルダーマネージメント」とは、プロジェクトの利害関係者に参画意識を促し、プロジェクトへの協力者に変えていくことを言う。このことが以前にも増してとみに難しくなってきたとPMの多くは感じている。

一つは、プロジェクトの広がりだと言う。特にクラウドの共同利用の広がりで、グループ企業や海外拠点を巻き込むプロジェクトが増えてきたこと。もう一つは、抜本的な業務改革に踏み込むプロジェクトが増えたため、抵抗感もあり、ステークホルダー同士の利害衝突も生まれやすくなってきたこと。プロジェクトへの参画意識が薄かったり、プロジェクトそのものを面白く思っていなかったりするステークホルダーを一つのゴールに向かわせるのは容易ではない。こういう背景から、PMの役割として「ステークホルダーマネージメント」がより重要になってきており、管理能力だけではなく、良好な人間関係を築くための「人間系スキル」が必要になってくる。

日経SYSTEMSでは、一線級のPMに取材し、「真のキーパーソンを見つけるワザ」「印象を良くする会議進行のワザ」「確実に合意を得るワザ」などの現場技を多数掲載しているそうだ。世の中からバースト案件がなくならない要因の一つとも言える「ステークホルダーメナージメント力」について、考えてみる価値はありそうだ。

参考にPMBOKの９個の知識エリアを挙げておく。

• プロジェクト統合マネジメント
• プロジェクト・スコープ・マネジメント
• タイム・マネジメント： スケジュール管理。
• コスト管理： 資金面の管理。
• 品質・マネジメント：品質管理
• 人的マネジメント：プロジェクトメンバーの要員の管理。
• プロジェクト・コミュニケーション・マネジメント
• プロジェクト・リスク・マネジメント
• プロジェクト・調達・マネジメント

今週は、いろんな方とお会いし、いろんなお話をすることが出来た。JASIPA会員向けの研修コースに関するあるコンサル会社社長との議論、会計パッケージを扱う会社の社長との対話、ある企業から依頼された幹部への講話内容の打ち合わせ、そして大手製造業幹部との会食など、多士済々の方々である。その中での議論の主題は、社員満足度と、顧客満足度。その中での一つの話題を提供する。

SI企業でのバースト案件は相変わらず燃え盛っていると聞く。それも要件定義を曖昧にしながら、納期を意識してプログラムを作ってしまっての失敗を多く耳にする。その原因として、お客様とのコミュニケーション能力や対人関係に関する問題を指摘する人が多い。そして、その対策としてお客さまとのコミュニケーション能力養成のためのビジネスマナー研修が花盛りである。

しかし、考えてみると、いきなり「お客様とのコミュニケーションを良くしろ」「きっちりお客様の要求を聞き出せ」と言っても、難しいのではないかと思う。日頃社内で、上司と部下の間できっちりコミュニケーションをとる訓練が出来ていないのに、お客様との間でだけはコミュニケーションをしっかりせよと言っても無理というもの。

部下に仕事を指示する場合、その仕事のアウトプットレベル、納期などを明確に指示しているか？もし明確な指示がなければ、都度部下は上司に確認しているか？上司と部下の仕事の受け渡しも、契約関係にあるとの認識の下、日頃から訓練しておくことが必要ではないだろうか。このような訓練が出来ていると、部下の評価も公平性を持って出来、また部下も納得性を持って仕事に当たれることになる。さらには、明確な指示により、それを達成した時の満足感は、あいまいな指示をこなした時より大きなものとなり、モチベーションアップにもつながる。SEのコミュニケーション能力や、文章能力は、上司の責任として日ごろの訓練の中で磨くことを考えるべきと思うが如何？

このことが、バースト案件を減らすための基本動作となることを願う。要件定義をお客様との間で明確に決めてから、プログラムを作成するという「当たり前のこと」を実行するためにも。

｢日経SYSTEMS 2012年1月号｣に「さらば失敗プロジェクト」と題した特集をしている。その一部情報がITproに掲載されていた(2011.12.21)。その記事に驚くべき事実が載っていた。

現在または直近の開発プロジェクトの94.5%に深刻な問題が発生し、そのうち89.9%が同じ失敗を繰り返している。～昨年10月から11月にかけてITpro上で実施した調査結果で、システム開発に携わる当事者が、自分達が参加したごく最近のプロジェクトの実情を答えてくれた貴重な現場の声～とある。発生した問題としては、スケジュール遅延が45%,コスト超過21.7%、稼働後のシステム障害14.5%、関係者間の信頼関係の悪化10.1%。

失敗の原因としては、「人間力の欠如（合意形成が上手くいかない、対立関係を解消できない）」が44.9%、「マネージメント力の欠如〔計画が甘い、指示・伝達がまずい〕」43.5%と続き、「技術力の欠如」は11.6%と低かった。

現場実感として、ここまでひどいとは私は思っていない。これまでアメリカ、日本などにおけるプロジェクト成功率は20~30%というデータが何度か発表されていた記憶がある。それでも低いが、今回の調査結果は、「開発に加わった当事者の意見」というのが味噌かも知れない。すなわち、開発当事者の「プロジェクト終了時の満足度」を表しているものと考えた方が、問題は浮き彫りになるかも知れない。「いいシステムが出来た」「お客さまにも喜ばれた」「自分はプロジェクトを通じて成長できた」「部下も育った」・・・のような達成感が、今のお客様との関係（従属関係）や、外注パートナーとの関係（多重下請け）、プロジェクト管理方法で味わえるのかどうかが本質的な問題として浮かび上がるのではなかろうか。

先日、当ブログでも「世の中に亡くならないもの（http://jasipa.jp/blog-entry/7161）」とのタイトルで、失敗プロジェクトの話をした。今、ＩＴベンダーにとって、お客様と一体となってお客様のためになるサービスを提供し、お客さまから信頼されるIT業界に変貌することが叫ばれている。そのために「受託開発型からサービス提供型へ」、「労働集約型から知識集約型へ」、「多重下請け型から水平分業型へ」、「顧客従属型からパートナー型へ」、「国内競争から国際競争へ」の転換を積極的に図らねば、この実態からの脱却は出来ないのではなかろうか。失敗プロジェクトを減らす（同じ失敗は根絶）のはもちろんのこと、お客さまから、真に価値ある業界、満足を提供する業界と認められなければ先はないとの危機感を持って行動することが、今まで以上に求められている。