第１０回　大規模プロジェクトの体験を通して（その５：ステーク・ホルダーとの関係）

プロジェクト・マネジメントにとって、ステーク・ホルダー（利害関係者）との間を良好な状態に保つことは重要です。ステーク・ホルダーについて「システム開発者」を中心に考えた場合、システムを使う人を「ユーザ」、システム開発作業の協力者を「パートナー」と呼ぶことにします。一方、プロジェクト費用の受発注関係で言うと、プロジェクトを発注する企業を「顧客企業」、「顧客企業」からプロジェクトを受注した企業を「受注企業」、「受注企業」からシステム構築作業の一部を受注した企業を「協力企業」と呼ぶことにします。一般的に大規模プロジェクトにおいては、「顧客企業」には、「ユーザ」部門と「システム開発」部門が存在します。「受注企業」には、ハードウェアやソフトウェア・プロダクトを製造販売する「ベンダー」、業務プログラムを開発およびシステム統合する「ＳＩ企業」、業務プログラム開発等に協力する「協力企業」群が存在します。「協力企業」群は、更に「協力会社」が「協力会社」に発注する多段階層になっています。大規模システムの開発プロジェクトのステーク・ホルダーは、企業数で言うと数十社ほどになります。通常、「ＳＩ企業」がプロジェクト・マネジメントの中心的役割を担うので、「ＳＩ企業」の立場で、プロジェクト・マネジメントの話を進めます。

「ＳＩ企業」にとって、「顧客企業」および「協力企業」が重用なステーク・ホルダーになるので、「ＳＩ企業」と「顧客企業」との関係および「ＳＩ企業」と「協力企業」との関係について述べます。

「顧客企業」は「ユーザ」としての顔と「システム構築者」という顔の２つの顔をもっています。「ＳＩ企業」は「システム構築部門」に対して、「顧客企業」と言う顔と「システム構築者」という顔の２つ顔に上手にお付き合いすることが大事です。「顧客企業」という顔の比重を高くし過ぎると、言うべき指摘事項が言えなくなり、「システム構築者」という顔の比重を高くしすぎると緊張感がなくなります。やるべきことはキチンとやり、言うべきことはキチンと言うメリハリをつけて付き合うことが肝要です。このメリハリが意外と難しいので、敢えて述べました。極端な例ですが、顧客企業の「システム構築部門」のリーダーが不適格な人だと分かった時に、「その人がリーダーとして不適格である理由を説明し、適格な人に交代して欲しい」と「顧客企業」にお願い出来るでしょうか？　このプロジェクトが成功するためにプロジェクト・リーダーの力は重要ですから、こういうケースは良くある事例です。「顧客企業」側がこの問題に気が付いて、自ら、自主的に対処するまで放置しておくのが常識的対応でしょう。敢えて憎まれ役を買って出て、波乱を起こすことはしないでしょう。しかし、対処が遅れると大トラブルに発展し、このシステムのサービス延期になることもあります。この問題の解決が遅れたために大問題になったプロジェクトを数多く知っています。筆者はこの問題を、大規模プロジェクトにおける失敗要因の大項目の１つに挙げています。法的な違反は無いのですが、ＳＩ企業」の「見て見ぬ振りをした」対応は、企業倫理を問われるでべきでしょう。

しかし、「受注企業」が「発注企業」にどのような手段で指摘をすれば良いのか難しい問題です。日頃から「ＳＩ企業」が「顧客企業」に対して、何らかの対策を講じるべき問題です。また「顧客企業」も内部統制機能として対策を講じるべき問題です。このような問題の予防策として、非公式コミュニケーションの場（本音の会話）の設定や第三者（外部）によるプロジェクト監査実施等の対策を講じるプロジェクトがありましたが、最近はＰＭＯを設置して、組織的に監視する大規模プロジェクトが多くなってきました。しかし、プロジェクトが円滑に推進されるためには、もっと前向きで積極的な関係を築くことが大切だと筆者は考えます。それにはコミュニケーションの仕組み、意思決定の仕組み、情報共有の仕組み、コラボレーションを促す仕組み、モチベーションを促す仕組みなどの構築が重要です。こうした仕組みはプロジェクト専任者だけでなく、ステーク・ホルダー全員で考慮すべき仕組みです。システム構築という技術的な仕事に、発注者対受注者という関係を歪んだ形で持ち込んでプロジェクトの冷静な判断を誤らせるべきではありません。ここが「ＳＩ企業」と「顧客企業」の関係の最も重要なポイントだと思います。

次に、「ＳＩ企業」と「協力企業」の関係について述べます。このケースでは、「ＳＩ企業」が「発注企業」であり、「協力企業」は「受注企業」です。発注者が「発注者の横暴」を受注者に押し付けてプロジェクトを混乱させた結果、大問題を発生させたプロジェクト事例を多く知っています。バブル崩壊後の激しい商談獲得競争の結果、赤字覚悟で受注したプロジェクトに多く発生した問題です。ここは、体力のある「ＳＩ企業」が大人の対応策として、「受注企業」を長期的な視点で支援していくことが重要だと思います。しかし最近の「ＳＩ企業」の多くは、目標管理や成果主義等の利益優先の人事評価システムを採用した企業に変化してきています。こうした環境下において「ＳＩ企業」のプロジェクト・リーダーの中には、発注者の横暴を「受注企業」に押し付けて自分の社内評価を良くする人が目立ってきました。ＳＩ企業としては悩ましい問題ですが、内部統制の仕組み構築等の組織的な対応をして欲しいと思います。個々のプロジェクトでは、システム開発作業費用の赤字と言う形で問題が表面化することになります。プロジェクトを円滑に進める仕組みを構築（コミュニケーション、意思決定、合意、情報共有、コラボレーション、モチベーション）して効率化を図ったり、技術的な創意工夫による実質的なコスト低減を図って解決して欲しい問題です。

プロジェクトを円滑に進めるためには、ステーク・ホルダー全員の「プロジェクト成功」への「熱意と協力」が必須ですが、大規模プロジェクトにおいてはステーク・ホルダーの企業数や関係者数が多すぎて、コミュニケーションが不十分になります。大規模プロジェクトでは、直接プロジェクト作業に参加していなくても、プロジェクトに影響力のあるステーク・ホルダー（プロジェクト参加企業の上司や経営陣）達の支援が重要です。プロジェクト現場では、直接的に接点のあるメンバ間ではコミュニケーションができますが、それ以外のメンバ間では殆どコミュニケーションできません。また、一括請負注の場合は、結果の報告だけで途中のコミュニケーションが欠如している場合が殆どです。こうした状態で遂行している大規模プロジェクトでは、参加企業の中で間接的に関わっている人達（上司や経営陣）のコミュニケーションがプロジェクト全体の実質的なコミュニケーションになっているのです。現場に任せてはいけない問題です。現場は報告に無駄な時間を使うとか、監視されるとかで嫌がるのですが、プロジェクト全体のためには、上司や経営陣レベルのコミュニケーションが是非とも必要です。現場メンバのコミュニケーションの仕組み構築と同様に、参加企業の上司や経営陣層のコミュニケーションの仕組み構築が重要です。これらの２重のコミュニケーションが有効に機能して、初めて大規模プロジェクトが円滑に遂行できるのです。現場から見ると、上司や経営陣層を煙たい存在と考える人がいますが、逆に現場が積極的に利用することが大事です。

筆者は、現場のメンバとは直接的に解決し難い問題（主として人事問題）をこうした上司や経営陣層の方々とのコミュニケーションを活用して客観的な視点で解決させて頂きました。とかく人事問題は感情的な遺恨を残す問題なので、本当に有り難い仕組みだったと思います。人事問題の厄介さをご理解頂いて、冷静な判断を下さった参加企業の幹部の方々に深く感謝致しています。