【事例】よくあるプロマネ「失敗理由」と「原因～解決策」

昨今、デジタル化やデジタルトランスフォーメーションなどが言われています。社会や企業でのITの活用は当然のこととなり、ますます拡がりをみせています。実際、スマートフォンでの決済や、画像認識によるログインなど、IT活用の進化は目を見張るものがあります。一方で、企業の根幹を支える業務システムなどの開発はクラウド化や自動化などで進化していますが、引き続きITエンジニアによる開発プロジェクトで構築されており、プロジェクトマネジメントの重要性は増しています。

社会のさまざまなITシステムは連携しており、一部のITシステムが障害などでダウンすると社会に大きなインパクトをもたらします。したがってITシステムは高い信頼性が求められ、いかに品質の高いITシステムを構築するかは開発プロジェクトのマネジメントを行う、ITエンジニアであるプロジェクトマネージャーにかかっていると言えます。

今回の記事では、プロジェクトマネージャーとして成功するために、参考としていくつかのプロジェクトマネジメントの事例を解説します。その中で、プロジェクトマネージャーの失敗事例、想定し得る対応策などをお伝えします。

【目次】

1. 進捗管理でよくある事例：最終テスト直前でシステムの未完成が発覚
2. 仕様確定でよくある事例：顧客との間で仕様のズレが発覚

進捗管理でよくある事例：最終テスト直前でシステムの未完成が発覚

「プロジェクト規模30名程度のプロジェクトマネジメントにて」

あるシステム開発における、30人ほどのエンジニアを擁するプロジェクトマネジメントの例になります。このプロジェクトでは数か月に及ぶ業務システムの開発を行っていました。プロジェクトマネージャーは約30名のITエンジニアを3社のSIerに発注し、システム開発をシステムのパーツであるサブシステムに分けて開発していました。1社にはシステムの根幹をなす業務システムの業務サブシステム、もう1社にはモバイル画面まわりの顧客フロントサブシステム、最後の1社にはOSやデータベースなどのインフラサブシステム、に分けて開発を行っていました。

開発の進捗確認は、各サブシステムのリーダーを集めて開催する週に一回の定例会で行っていました。各サブシステム内での詳細な進捗確認は各リーダに任せていました。

顧客との仕様が確定し、プログラム行程もほぼ予定通りに進捗していました。顧客への定例報告なども各サブシステムリーダーと共同で行い、些細なバグや修正などはありますが、全体としてはシステム開発は順調に進んでいるとプロジェクトマネージャーは認識していました。

「最終テスト行程直前で、システム品質が著しく悪いことが発覚」

さて最後の顧客との仕様通りにできているかなどの確認を行う最終テストが迫ってきました。それを終えるとシステムはリリースされ、システム開発は完了になります。ただし最終テストの前に内部での最終テストを行います。結合テストとも言われ、各サブシステムでテストを終えたモジュールを接続し、全体がシステムとして仕様に沿ってできているか、全体が連携して正常に稼働するか、などを確認します。

ところが、この内部での最終テストで思わぬことが発覚してしまいます。業務サブシステムが顧客との最終テストで確認するための最終品質に達していないことが分かったのです。今までサブシステムリーダから順調に進んでいるとの報告を受けていたのですが、実際の内部での最終テストでは全く品質が基準に達していないことが分かりました。

業務サブシステムは、この品質では大幅な修正どころが、ほとんど作り直しに近い改修が必要です。プロジェクトマネージャーは慌ててそのサブシステムを担当するSIerに増員を依頼し、全面見直しです。顧客との最終テストの予定が迫っているため、それからは昼夜を問わずシステム開発を続けました。影響は業務サブシステムにとどまらず、顧客フロントサブシステム、インフラサブシステムも同時に昼夜システム開発を続け、なんとか顧客との最終テストに間に合わせることができました。

しかし、プロジェクトチームメンバーは徹夜作業の連続で、非常に疲弊してしまいました。また長時間の追加工数がかさみプロジェクト費用も追加され損益も悪化してしまいました。

対策：進捗管理は任せっきりではなく自ら確認を

プロジェクトの進捗管理を定期的に実施しており、プロジェクトマネジメントをしっかりと実施しているようにも見えました。何が要因だったのでしょうか？

まず、各サブシステムのリーダーを集めて進捗会議を週に一度行っていましたが、この頻度は正しかったのでしょうか？

おそらく頻度は毎日実施する、が正しかったと考えられます。毎日進捗確認を行っていれば詳細な状態が共有できていた可能性がありあす。また各サブシステムリーダーの報告を鵜呑みにするのではなく、時には自らサブシステム内の進捗報告に出席したりして詳細な内容を確認すべきだったでしょう。

加えて、このケースではプロジェクトマネージャーがインフラエンジニアの出身だったこともあり、インフラサブシステムには、より気を払っており、詳細な進捗も把握していました。モバイル系の顧客フロントサブシステムも新しい内容だったため、注視して内容の確認も行っていました。顧客の業務詳細を把握する必要がある業務サブシステムは任せっきりになっていた所も要因だったと言えます。プロジェクトマネジメントの注力が自身の得意分野に偏っていたということも否めないでしょう。

プロジェクトマネジメントの重要な内容の一つである進捗確認は、確実に、詳細に、が基本です。今回のケースのように少しでも大雑把になってしまうと、行程の後半では取返しのつかないことになってしまいます。加えて、まかせっきりではなく自らの目と耳で進捗管理を行う、ということが非常に重要です。

仕様確定でよくある事例：顧客との間で仕様のズレが発覚

「運用保守を行う顧客システムで追加改修依頼を受けシステムを開発」

ある顧客システムで顧客要望でインセンティブ支払いシステムの追加改修を行った際のプロジェクトマネジメントの例になります。

プロジェクトマネージャーはある中規模プロジェクトで運用保守のプロジェクトマネジメントを行っています。ある日顧客からシステムの追加改修の依頼をうけました。システムの追加改修内容は顧客配下の販売店に対し、販売店の売上に伴なったインセンティブ料金の計算を行い、支払いをするシステムです。

プロジェクトマネージャーは追加改修システム開発に対応するため、現プロジェクトチームの中に新しいサブシステムグループを立ち上げチームを作りました。新しいチームはリーダーとサブリーダに加え3名のエンジニアを擁する陣容です。早速プロジェクトマネージャーとサブシステムのリーダー及びサブリーダーで、顧客の新システムに対する仕様の打ち合わせを開始しました。顧客の販売店管理部門と、インセンティブの仕組みの確認や料金計算方法など、詳細に渡って打ち合わせが続きます。

顧客とは日々保守運用を行っている関係もあり、なんら問題なく仕様の打ち合わせは進みました。ある程度概略が決まってきたところで、プロジェクトマネージャーはプロジェクト全体や他のサブシステムもマネジメントする必要があり、この販売店管理サブシステムについては、販売店サブシステムチームのリーダーとサブリーダーに、料金計算方法など詳細仕様は任せることにしました。

仕様が確定し、販売店管理サブシステムの開発が始まり、内部テスト、顧客との最終テストも順調に終え、販売店管理システムが完成し、システムの追加機能がリリースされました。

「顧客の販売店管理システムで料金計算ミスが発覚し、販売店から計算ミスの差分の支払いと責任の対応を求められる」

ある日、顧客から重大な相談がある、との連絡を受け、顧客及びプロジェクトマネージャーと販売店管理サブシステムのリーダーとサブリーダーで打ち合わせを行いました。

顧客の販売店から売上に見合ったインセンティブが支払われていない、というクレームについての相談でした。システムの仕様や内容を確認したところ、インセンティブ支払いの計算が間違っていたのです。したがって販売店のクレーム内容は正しく、システムのインセンティブ料金計算ミスで支払い額も足りませんでした。

急遽不足分を計算し、販売店への追加支払いを顧客から行いました。それから詳細な原因の分析を行い、料金計算確定のどの行程でミスが発生したかなど、を確認しました。

このシステム追加改修プロジェクトでは、顧客の要望に従ってシステムでの計算内容の案をサブシステムチームで策定し、顧客に提示し確認を得た上でリリースを行い、正しい運用を行っていました。

したがって料金計算の間違った計算内容でシステムを構築したのはサブシステムチームですが、それを承認したのは顧客でもある、ということが判明しました。

最終的には、顧客の販売店に追加のインセンティブを支払うことになったのですが、顧客との折衝ので責任は半々ということになり、プロジェクト側からも費用を捻出することになってしまいました。

対策：顧客との仕様確認は念には念をおす

このケースでは、料金計算の間違いはプロジェクト側のミスではありますが、顧客が内容を承認しており、最終的には顧客の瑕疵にあたると考えられます。ところが、結局責任は半々となり、プロジェクトの損益にも影響が出る結果になってしまいました。何が要因だったのでしょうか？

まず顧客との仕様確定と最終テストの段階で、顧客が確認をしたという明確な証明にあたる議事録などが不備でした。逆に顧客との関係が良好なこともあって、プロジェクト側も一緒に確認をした、というようなあやふやな内容になってしまい、責任の所在を文書などで明確にできず、瑕疵に対する支払い分担なども半々となってしまいました。

プロジェクトマネージャーは顧客との料金計算などの詳細な仕様確定の打ち合わせは、販売店管理サブシステムに任せていました。しかし仕様確定のプロセスの記録や責任所在の明確化などのマネジメントはプロジェクトマネージャー自らがしっかりと行うべきでした。

=================

＞プロジェクトマネージャーのキャリアに関する記事

【事例】よくあるRPA導入の課題と、情シスへの入社間もない転職者が担当する際のケアすべきポイント
https://www.axc.ne.jp/media/careertips/rpa_casestudy

=================

今回は、プロジェクトマネージャーの失敗事例、想定し得る対応策などをご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。