システム開発プロジェクトにおいてプロジェクトマネジメントはオールマイティか？

　雑誌日経コンピュータによると、IT関係の成功率は30%台と言われており、ここ数年のコンサルティングを通して、一時期かなりトラブルプロジェクトは減った印象を持っていたが、成功率は相変わらず低いようである。ただ成功率といっても何をもって成功とするかの定義がアンケートを受ける側でかなり幅があり一概に評価は出来ない。私はIT関係のプロジェクトではQCDのいずれか一つが毀損した場合にトラブルが発生したと定義しているが、一般的な基準は無い。納期が守られ、ある程度実用に耐えることが出来れば赤字であっても成功したプロジェクトと捉える人もいれば、赤字ならどんな状態でも失敗という人もいる。QCDの全てが許容範囲の中に収まる状態のみを成功と呼ぶならば成功率は極めて低くなるのはいたしかたなく、この基準で見た場合過去何十年かのシステム開発の歴史上もそう成功率が高かった時期はないように思う。開発会社の企業性を失わない程度の採算で顧客の満足度もある程度確保出来るとした場合を成功と呼ぶなら成功率は高くなるのではないだろうか。それでなければシステム開発、ソフトウェア開発を専業とする企業は年々少なくなってしかるべきだが、関連業界で大型倒産した例もあまりない。ただ利益率が年々落ち、社員の待遇が悪くなり新3K、6Kとも言われる中に「給料が安い」が入っているのはこの2、30年前とは大きく異なる点ではある。原価を引き上げている要因には従業員の高齢化に伴う給与水準の上昇があり、この給与水準の上昇を賄うだけの売り上げ単価の改善が望めないこと、又国外への開発作業の流出により、国内の売り上げ単価は年々下がりつつあることも事実であろう。極端な例では10年前の単価の半分程度になってしまっている例もあるようだ。原価の引き上げ要因の一つに人件費の上昇もあるが、システム開発、ソフトウェア開発上でのトラブルの発生によりコストが上昇したことも見逃せないと思われる。大きなトラブルプロジェクトではかなりの頻度で同一工程を何度も繰り返す例が多く、原価を大きく引き上げることに繋がる。また最近のコスト上昇の要因の一つでは、プロジェクトマネジメントの近代化による過剰な管理による原価の上昇も無視出来ない。様々なステークホルダーからの要求に応えるため、製品の品質を直接向上させる以外の作業に多くの時間が割かれる現状は否めず、その為原価の割合が10%、20%上昇となれば、もともと利益率の低いシステム開発では採算ラインを突破してしまうだろう。様々なステークホルダーとは顧客、顧客側PMO、自社管理部門、自社PMOからの多重な厳しい報告に応えようとするとプロジェクトでは過剰な管理を行うことになってしまう。数十年前の物作りだけに邁進してプロジェクトが成功した時代とは明らかに違ってきている。プロジェクトマネジメントの重要性を啓蒙し、プロジェクトマネジメントを実際指導してきた私のような立場の人間が、結果として過剰管理になるよう仕向けた一面もあり責任を感じるが、このような状態が出現することを私は10年以上前から想定し、プロジェクトマネジメント、PMOの普及では現場プロジェクトの負担が増えないような制度の設計が必要であること、制度を新たに作る場合は、作るのと同数の過去の制度を廃棄するスクラップ＆ビルドを推奨して来た。古い制度を廃棄せず、新たな制度次々導入し、制度が複雑化し又重複、整合性が取れないことも発生する、制度を作っても、作ってもプロジェクトマネジャーの負担が増えるだけでトラブルが少なくならない企業をよく見かける。
　プロジェクトの弱点を具体的に補強することなく、直接生産性に寄与しないプロジェクトの外部の組織、制度をいくら作ってもトラブルは減りもせず、採算状況が好転することもない。改めてここ数年のプロジェクトマネジメント、PMOの導入が企業の戦略に沿っているのか、現場のプロジェクトの役に立っているのか見直すべきではないかとコンサルテーションを通じて私は指導・支援している。

　また、システム開発関連のプロジェクトではここ10年プロジェクトマネジメントの重要性が叫ばれ、PMP、PMSの資格取得者も増えている、ではこれら資格取得者の増加がシステム開発プロジェクトにおける失敗を少なくしているのかというと、プロジェクトマネジメント関係の資格取得者が増加する一方でシステム開発プロジェクトの成功率が上昇しないという関係から見ると、どうもシステム開発プロジェクトの成功にプロジェクトマネジメント関係の知識を持った人の増加は寄与していないのではないかと思う。
　プロジェクトマネジメント関係のコンサルティングを行っている人々の中にも下記二種類の人がいる。

�@	プロジェクトマネジメントの知識は産業には関係なくどの産業でもコンサルティング出来るとする人。
�A	同じプロジェクトマネジメントといってもそれを実現する方法は産業により全く異なるので出身産業以外の産業にはコンサルティグ出来ないとする人。

　どちらが正しいかどうかを議論するつもりは毛頭ないが、私自身はシステム開発、その中でもソフトウェア開発を行う産業の出身なのでシステム開発分野のプロジェクトマネジメントの指導・支援を行っている。私の個人的な感覚からするとシステム開発のプロジェクトのプロジェクトマネジメントの知識があるからといって他の分野のプロジェクトの指導支援が出来るとは思えない。
産業の知識とは無関係にプロジェクトマネジメントの指導・支援・教育を行ってもプロジェクト運営の表面的なことまでしか関与出来ず、産業の知識がないと個々のプロジェクト、プログラム、PMOの深い問題まで関与出来ないのではないだろうか。

システム開発のプロジェクトでは下記の知識が重要と思っている。

�@	対象とする顧客の産業・企業の業務知識
�A	顧客の業務を実現するためのIT技術知識 　　・コンピュータ・ネットワークに関する知識 　　・ソフトウェア開発技術に関する知識 (最近ではオブジェクト指向の知識、具体的にはJAVA、ASP.NETが重要な知識になっているが、時代とともに変化する)
�B	プロジェクトマネジャーのシステム開発に対する素養・知識
�C	プロジェクトマネジメントに関する知識

【下図参照】

　上記の顧客の業務知識、IT技術知識、プロジェクトマネジャーの素養・知識を関連づけ統合してマネジメントすることが出来るのがプロジェクトマネジメント知識だと思っている。
当然のことだが、顧客の業務知識、IT技術に相当するものは産業によって全く異なる、建設のプロジェクトでは建築技術、プラントであればプラントの技術が必須であり、システム開発ではソフトウェアエンジニアリングが不可欠であるのと同様である。ただシステム開発は対象とする産業が全産業でありそこにはシステム開発としての共通した技術は存在する、だからといってシステム開発でのプロジェクトマネジメント知識があるからといって全く異なる技術基盤を持つプロジェクトに知識は適用出来ない。金融系のかなり高度なシステム開発のプロジェクトを成功させることができるプロジェクトマネジメントの経験知識があるからと言って、プラント建設のプロジェクトのプロジェクトマネジマントが出来ないのは常識ではないか私は思っているが、出来ると言う人もいる、私のプロジェクトマネジメント力が不足しているからなのか、プロジェクトマネジメントのより高見に至る知識がないのかもしれないが、プロジェクトマネジメントはプロジェクト運営上のオールマイティな力を保証するものではないのではないだろうか。例えば病院建設のプロジェクトで建物と医事・医療の統合したシステムを開発するプロジェクトを伴う場合のプロジェクトをマネジメントするのはIT系のプロジェクトマネジャーがマネジメントすることになるが、IT系のプロジェクトマネジャーが顧客業務の医事・医療を統合するシステムとはどのようなものかという知識を持っていなければ、システム開発を指揮出来ないと私は思うのだが、顧客業務知識はその都度変わるのだから不要と言う人もいる。往々にしてシステム開発では全く新しい分野のシステム開発を担当することがある、顧客業務の知識が当初から詳しく無い状態でシステム開発が開始し想像できないようなトラブルが発生し、システム開発の成功率の低さにつながっていることあることはシステム開発業界関係以外の方は想像出来ず、システム開発業界でのトラブルの多さを理解することを難しくしている。
もちろんIT系のプロジェクトマネジャーでも顧客業務に精通している人もいるが、決して顧客の専門家と同じレベルのプロにはなれない、時々その産業のIT化を行っているとその対象産業のプロと勘違いし、顧客抜きで大規模なパッケージをシステム開発会社単独で行い数百億円単位の赤字となった例を何度も目の当たりしたこともあり、システム開発企業では時々顧客業務知識面で顧客と同等のプロになれると勘違いする人もいるようである。他業界、委託側の顧客にとっては驚きかも知れないが、一般的に新規で全てを作り込む大型のシステム開発では、システム開発期間の最終段階の本番稼働時期になってようやくシステム化した業務の内容が詳細に理解出来ることが多い。

　プロジェクトマネジメントがプロジェクトを成功させる唯一の方法とも取れる意見を時々耳にするが、そのようなプロジェクトマネジメント至上主義、プロジェクトマネジメント原理主義に近い意見には私は賛成しなし、自由気ままにプロジェクトを個人の力量で運営するような放任主義にも賛成しない、プロジェクトを成功させるにはプロジェクトマネジメント以外のその産業の基盤技術、システム開発業界ではコンピュータ、システム開発技術、顧客業務知識、プロジェクトマネジャーの質等の向上が必要であり、これらはシステム開発企業の経営戦略そのものであり、決してプロジェクトマネジメントの強化だけがプロジェクトを成功させるものではないと思う。私はプロジェクトマネジメントを職業とするものとして、プロジェクトマネジメントさえ知っていればなんとかなるとういような謙虚さを失った考えに囚われないように心がけている。
　日本独特の多段の下請構造で成り立っているシステム開発では、下請けに丸投げしているような構造が常態化している産業でいくらプロジェクトマネジメントを高度化し利用しても素の技術(基本設計、詳細設計、プログラミング、テストの技術)の理解がない所ではプロジェクトの成功は難しいと言わざるを得ない。
　私はシステム開発業界で成功率が増加しない原因は上記のように、プロジェクトマネジメントと会社マネジメントの差を明確にし、会社マネジメントが行うべきこと、プロジェクトマネジメント行うべきことを明確にし、行動しないことが大きな原因であり、システム開発自体が出来ないところで、プロジェクトマネジマントを導入してもプロジェクトは成功しないと思い、コンサルタントとして指導・支援を行っている。私がシステム開発プロジェクトのコンサルテーションを行っていても、その指導・支援の内容の6、7割程度はプロジェクトマネジメント固有の指導・支援ではなく、システム開発、ソフトウェア開発技術と密接に繋がっているもので、システム開発プロジェクトのシステム開発技術、コンピュータの技術、顧客業務知識とは無縁でなく、日々技術の進歩に追いつき、新たな顧客業務に対する興味を失わないようにしないとコンサルテーションが出来ない状態である。
　顧客業務知識、コンピュータ技術、システム開発技術、ソフトウェア開発技術を高めること無しにプロジェクトマネジメントだけに救いを求めても、システム開発でのプロジェクトの成功率は今後も高くならないと思われる。

イデオ・アクト株式会社  HPは こちら
代表取締役　葉山博昭