本園 明史
ウルシステムズ シニアコンサルタント

 

　プロジェクトの複雑性の高まり、情報システムの質の変化――。こうした環境変化を背景に、システムの構築プロジェクトには新たなイノベーションが求められている。この連載では、現場のコミュニケーション不全を撲滅し、プロマネの孤立を防ぐ仕組みを提案する。ユーザー側の不信感、ベンダー側の不満が拡大するのを未然に防止し、プロジェクトを成功に導く「マネジメントサポート」と「コーディネータネットワーク」という新たな2つの役割について紹介する。（ITpro）

　 「いいシステムを作りましょう」。顧客・ベンダーといった立場に関係なく、意気投合して始まったシステム構築プロジェクト。しかし、時が経つにつれ、双方から不満の声が聞こえてくる――。

ユーザー側プロジェクト担当者　「『実はあの件はまだできていない』とか『やはりその件は期日までには難しい』とか、ベンダーから上がってくる報告が、後からコロコロ変わってくる。本当に信用できるのか」。

ベンダー側開発担当者　「ユーザー側の要求が曖昧でちぐはぐ。再三『これでいいですね』と念を押しても、いろいろ理由をつけて後から変更を要求してくる。いくら相手は顧客だといっても限度がある。いちいち聞いていられない」。

　このようなユーザーとベンダーの「すれ違い」は、残念ながらしばしば見られる光景です。プロジェクトの複雑性が高まっていることから、最近はそのすれ違いが取り返しのつかない事態を招くケースが増えています。

　だからこそ、プロジェクトにはこれまでとは違うアプローチや仕組み、体制作りが求められています。この連載では、現場のコミュニケーション不全を撲滅するための役割を提案します。「マネジメントサポート」と「コーディネータネットワーク」です。マネジメントサポートはプロジェクト・マネジャのサポート役です。プロジェクトの舵取りに必要な現場の情報をプロマネが把握できるようにします。もう一方のコーディネータは、現場の中に入り込み、コミュニケーションの齟齬やあいまいさに起因する問題の予兆を見つけ、予防策を打つ役割です。通常、複数人で取り組むことが多いのですが、集団でとらえる際にはコーディネータネットワークと呼びます。

変化が新たな役割の登場を望んでいる

　なぜこれら新しい役割を置く必要があるのでしょうか。一言で表現すれば「システム開発をめぐる無視できない環境変化」がその理由です。

　企業の情報システムの歴史は、メインフレームによる集中処理の時代から始まりました。この頃のコンピュータの主な利用目的は、業務の効率化や省力化です。つまり、それまで人手に頼っていた様々な定型業務を機械化するものです。

　やがて1990年代に入るとクライアント／サーバ型による分散化の時代が始まり、そして現在のWebシステムの時代へと至ります。こうしたソフトウエア技術の進歩や新しいシステム・アーキテクチャの登場と合わせるように、コンピュータはそれまでの単純な業務の効率化のためだけではなく、多種多様な分野・領域で活用されるようになってきました。

　例えば、企業が蓄積してきた大量のデータをビジネスに役立てていく情報活用支援や、経営層による企業の舵取りをサポートするための意思決定支援はその代表例と言えるものです。最近はBI（ビジネス・インテリジェンス）などとも言われているのはご存じの通りです。また、新たな事業やサービスの創造、業務プロセスの標準化、従業員の能力開発支援など、その適用領域は枚挙にいとまがありません。

　こうした利用目的の多様化は、コンピュータの仕事の領域が、その得意分野から苦手な分野へと広がってきたことを意味します。与えられた作業手順だけを黙々とこなすコンピュータは、単純繰り返し作業の自動化や機械化といった目的には大いに強みを発揮します。IT分野の人なら言わずもがなですが、「応用」や「例外」という言葉から連想されるような作業は苦手としています。ところが時代の変化とともに、その目的はコンピュータが苦手とする領域、つまり曖昧かつ複雑な領域へと移ってきました。

難易度が高まるプロジェクトマネジメント

　利用目的の多様化は、システム開発のプロジェクトの進め方にも変化を促しています。単なる効率化や省力化を目的としていた時代では、システムの目的や手段は誰の目にも（ほぼ）明らかで、合理主義と技術的な正しさが議論を収束させるための強力なツールになってくれました。導入効果は計算式によって求められ、客観的な基準でシステムを評価する事が比較的簡単でした。この時代ではプロジェクト・マネジャは必ずしも一般的な存在ではなく、多くの場合、プロジェクト・リーダーがその役割を果たしていました。

　しかしコンピュータの利用目的が企業戦略あるいは経営支援といったものと結びつくようになると、システムに求められる要件を定めるために「不透明な将来予測」や「ステークホルダーの価値観」、あるいは「企業理念」といった曖昧かつ複雑な要素を考慮に入れる必要が出てきました。こうなると議論は論理的な思考と明白な事実だけでは収束しません。これまでは満場一致で決定していたような決定事項が、ステークホルダーそれぞれの過去の経験や価値観同士のぶつかり合いのために決定しにくくなってきたのです。

　そのため、プロジェクトは途端に難易度が高まる事になります。すべき作業も増える一方です。それまではプロジェクト・リーダーが兼任していたプロジェクト・マネジャとしての仕事は、独立した専任の役割に任せる必要が出てきました。かくしてプロジェクト・マネジャという役割が確立されることになります。

　この間、プロジェクトマネジメントのための知識や手法も着実な進歩を遂げていきました。当初はソフトウエア・エンジニアリングの延長線上にあるようなものが多く、形式的で論理的、かつアカデミックなものが幅を利かせていました。しかし「これでは使えない」という現場の声を反映してか、次第により実践的なものも登場してきました。

　ただ、現実は文字の世界とは比較にならないほどに複雑です。利用目的のさらなる多様化や、システムに要求される曖昧処理や例外処理の増加、それに伴うプロジェクトの複雑化の流れはとどまることがありません。マニュアルや方法論は分厚くなる一方です。

　結果、プロジェクト・マネジャにかかる負荷は高まる一方です。そのため近年、プロジェクトマネジメントの円滑な実施と品質向上を目的とする専任組織「PMO（プロジェクトマネジメント・オフィス）」を設立するケースが増えています。

　当初は現場のプロジェクト・マネジャを救うものと期待の高かったPMOですが、少なくとも現時点では、さまざまな問題を解決する役割をどれだけ果たせているかは、議論が分かれるところです。引き続きより良いあり方を探るべく検討すべきではありますが、「すぐに成果が期待できるものではない」というのがプロジェクトマネジメントを知る人々での一致した意見のようです。