プロジェクト管理とチーム（Vol.28）

2018.04.16 株式会社システムインテグレータ

プロジェクト成功率

プロジェクトの性質や規模によって様々違いはあると思いますが、プロジェクトに関わるチームには一体どんなものがあるでしょうか。

2003年、2008年、2014年、2018年の4回に渡り、日経コンピュータがITプロジェクトの成功率に関する記事を書いています。詳細を書くとキリがありませんが、結果だけを抜粋すると、以下のようなものです。

2003年：プロジェクト成功率２６．８％
2008年：プロジェクト成功率３１．１％
2014年：プロジェクト成功率７５．０％
2018年：プロジェクト成功率５２．８％

年によってアンケートの有効回答数や成功の基準等に多少の差はありますが、いずれもあまり良くない結果であることは確かです。2014年の７５．０％は一見良いように見え　ますが、4分の1のプロジェクトが失敗しているという見方をすれば、決して喜べる数字ではないように思います。

プロジェクト管理の重要性が組織や人に浸透したことや、プロジェクト管理を効率化するためのツールが普及したことで、徐々にプロジェクト成功率は上がってきてはいますが、まだまだ多くの課題を抱えているのも事実です。

今回は、プロジェクトの成功率を上げるための重要な要素である「チーム」にスポットをあて考えていきたいと思います。

プロジェクトにおけるチームとは？

プロジェクトの性質や規模によって様々違いはあると思いますが、プロジェクトに関わるチームには一体どんなものがあるでしょうか。

大規模なシステム開発プロジェクトの場合、プロジェクト内に多くのチームを編成することがあります。代表的なものをあげると以下のようなものでしょうか。

・上流工程チーム（開発ベンダー側）
・開発チーム（開発ベンダー側）
・インフラチーム（開発ベンダー側）
・PMOチーム（開発ベンダー側）
・業務チーム（ユーザー側）
・受入検証チーム（ユーザー側）
・標準化チーム（開発ベンダー側、ユーザー側）
　etc

当然ですが、プロジェクトの成功率を上げるためには、これらのチームが独立して動くのではなく、密接に連携して有機的に動くことが求められます。チームにはそれぞれ役割がありますが、今回はその中でも特に重要な2つのチームに絞ってその課題と解決策を考えていきたいと思います。

PMOチームにおけるプロジェクト課題と解決策

まず1つ目は、前述した開発ベンダー側のPMOチームについてです。私は仕事柄様々な企業のPMOチームの方と話をしますが、その中で、機能していないPMOチームには、以下のような共通点があります。

・役割が不明確
・課題解決の実行権限がない
・出来る人がいない
・リソースに余裕がなくPMOチームをつくれない

①の課題は多くの企業で見受けられます。会社としてPMOチームの役割が明確になっていないことで、実績の集計が主業務になってしまっているPMOチームもあれば、第三者としてプロジェクトを管理・監視しなければならないPMOチームが、炎上プロジェクトの火消しに駆り出されてしまっていたりします。②についてもよくある課題です。PMOチームを編成し、第三者としてプロジェクトの課題把握までせっかく出来ているにも関わらず、現場の力が強く、言うことを聞いてもらえないという悲しい状況です。③については人材育成に関わってくる問題なので、簡単には解決できませんが、外部にPMOを委託する企業は最近多いようです。しかし、実際にそうしている企業を見ていると効果が出ているかどうかは疑問が残ります。④については、失敗プロジェクトのリスクを放置するのか、コストを割いてでもPMOチームを設置するのか、経営に判断を仰ぐ他解決策は無いように思います。

弊社の例を少しお話すると、弊社のPMOチームには以下の3つの役割と権限が与えられています。

・異常プロジェクトの検知と改善命令
・ルール違反プロジェクトの監視と改善命令
・ツール活用による更なるプロジェクト改善案の検討

上記の3つの役割と権限を、社長筆頭に経営層が全社に浸透させたことで、「PMOが言うことは必ず守らなければならない」という文化が定着し、プロジェクト失敗を未然に防ぐ環境が整っています。

4つの課題、また弊社の例を見ても、やはり経営層がしっかりとPMOチームの必要性を理解し、後ろ盾となることが唯一の解決策のように思います。

PMOチームが機能したプロジェクト事例紹介

実際にPMOチームが機能した例として少し変わった事例をご紹介します。2016年に日経BP社から出版された「プロジェクトマネジャー　最強の指南書」という雑誌に掲載されていたプロジェクトの事例（以降、Aプロジェクトという）です。

Aプロジェクトの要点として以下のようなものがあります。

・基幹システム開発プロジェクト
・詳細設計以降の工程で150人が参画し、8チーム編成
・コミュニケーションを見える化する実験がプロジェクト内で並行して行なわれた

この事例からお話したいのは他でもなく③です。

Aプロジェクトでは、参画する150名のメンバー全員が首から実験用のICカードをぶら下げます。ICカードは赤外線受信機を備えており、近くにいるメンバーのIDと近くにいた時間を記録する機能を持っています。つまり「誰」が「どのメンバー」と「何分」コミュニケーションを取っているかを計測する事ができます。実験開始から数ヶ月が経過した時、150人のICカードからデータを吸い上げ、解析した結果3つの課題が見える化しました。

・誰ともコミュニケーションをとっていないメンバーが数名いること
・特定のリーダー2人にコミュニケーションが集中していること
・開発チームとPMOチームのコミュニケーションが極端に少ないこと

①については、一人で課題を抱え込んでしまっている可能性のあるメンバーとのコミュニケーションを増やすきっかけとなり、②についてはリーダーへの過度な業務の集中を解消するきっかけとなりました。そして③はPMOチームのプロジェクトへの参画度合いを改善するきっかけとなりました。

PMOチームの業務でまず重要なのは、プロジェクトの現状を正確に把握することです。コミュニケーションの時間が長ければ良いかと言われるとそうとは限りませんが、第三者的な立ち位置のチームとして、他のチーム以上に蜜に連携を測る意味はあるのではと思います。

業務要件定義チームにおけるプロジェクト課題と解決策

2つ目のチームは、ユーザー企業側の業務要件を取りまとめるチーム（以降、業務チームという）です。当たり前のことですが、システムを導入する際にはまず現状の業務課題を把握し整理しなければなりません。

例えばERPを導入するプロジェクトを考えると、多くの場合において、RFPが作成されます。しかし、RPF作成のレベルは企業によってとてつもなく大きな差があります。自社の課題を的確に捉え表現できているものもあれば、抽象的な課題しかかかれていないもの、RFPと呼ぶには少し無理があるようなものしか作れない企業があるのも事実です。自社で作れないために、高い費用を払いコンサルにRFP作成を依頼する企業も多くいます。

RFPに書かれている業務課題と目指すべきゴールをより具体化し、システム化のために落とし込む作業として、要件定義を行なうわけですが、多くのプロジェクトはこの要件定義フェーズに課題が潜んでいるようです。

冒頭に述べた、2018年の日経コンピュータの記事の続きに、遅延プロジェクトの理由として最も多かったのは仕様変更が相次いだことという記述がありました。スケジュールを優先するあまり、要件定義に満足な時間を割くことが出来ず、その影響が下流工程に及び、結果、仕様変更が発生しプロジェクトの遅延へとつながったという内容です。

これらの課題の重要な鍵を握っているのが、業務チームのように思います。

実際に私が関わったERP導入プロジェクトで、要件定義で苦労したプロジェクトには以下のような共通点があります。

・業務チームが業務をまとめられない
・例外業務を含めた全ての業務をシステム対応しようとする
・一度決めた要件が確定直前でひっくり返ってしまう
　etc

通常、業務チームは情報システム部のメンバーで編成される事が多いように思います。いくつかの部署を経験して情報システム部にきたメンバーであれば、社内の業務をある程度理解していますが、そうでないメンバーの場合、現場の業務を表面的にしか理解しておらず①のような課題につながってしまいます。②についてはよく陥りがちな課題です。例えば、1ヶ月に数回、関わるメンバーは1人しかいないような例外的に発生する業務を全てシステム化しようとすると、膨大な予算と時間が必要になります。業務の重み付け、優先度を明確にするのはもちろんですが、現場にいかにそれを理解してもらうかというコミュニケーションも重要になってきます。

④がもっとも厄介です。これは業務チームと現場との信頼関係に根本的な原因があるように思います。当たり前のことですが、現場への業務ヒアリング、順次決まっていくシステム化要件の共有と理解確認をしっかりと行なっていくことしか解決策はないように思います。

システムを利用するのは現場ですし、その現場が納得をしてくれるシステムを作らなければ、導入する意味が薄れてしまいます。限られた予算と時間の中でプロジェクトを成功させるために、業務チームの担う役割は大きいと思います。