初めに
エンジニアのキャリアにおいて、プロジェクトの成否を大きく左右するのがPM（プロジェクトマネージャー）の存在です。本記事では、筆者が実際に経験した「困ったPM」の事例と、そこから得られた教訓を共有します。この記事を読んでいただくことで、同様の状況に遭遇した際の対処法や、未然に防ぐためのヒントが得られれば幸いです。
この記事で伝えたいこと
- 「失敗」は「成功」のもととされますが、時として避けられない失敗もあります
- 同じような状況に遭遇したとき、どのように対処するかのヒントになれば幸いです
目次
- 要望は取りまとめない！全部ベンダーに投げつけちゃうPM
- 失敗は全てSESのせい！どんどんSESをクビにしてトカゲの尻尾大作戦
- 危機管理？そんな事より目の前の工数を削っちゃおうPM
- 品質悪いぞ！テスト前のシステムに文句をつけてオーナーに告げ口しようPM
- 設計書は文量が大事！ドキュメントの負担を意味なく重くしてやろうPM
- 部下に丸投げ！1週間遅延をなんとかしてくれPM
筆者について
PMOとして6年間の下積みを経験した後、SESとして5つの現場を見てきました。その経験から、数々のPMと仕事をしてきましたが、中でも特に印象に残っているPMたちをご紹介したいと思います。
用語集
| 本記事で出てくる用語 | 本記事での意味合い |
|---|---|
| SES | システムエンジニアリングサービス。客先に常駐して開発支援を行う形態。筆者の立場。 |
| PM | プロジェクトマネージャー。プロジェクトの責任者。今回の主役。 |
| ベンダー | システム開発を請け負う企業。さらにそのベンダーから発注を受けてSESが参画する。 |
本題：やばいPMたちの事例集
1.要望は取りまとめない！全部ベンダーに投げつけちゃうPM
今まさに苦しんでいる現場での話です。本来、発注側のPMはベンダーへの要求を取りまとめる立場にあります。しかし、このPMは要求の取りまとめを一切せず、発注側の全員が思い思いの要求をベンダーに直接伝える状況を放置していました。
あるとき、リリース間際に変更要望が出され、ベンダーが「異常系は薄くなりますが、正常系を重視して開発すれば間に合います」と提案したところ、PMが「異常系こそ手厚くしないとリリースなど許さん！」と怒号をあげ始めました。結局、ベンダーが「では変更は受け付けられません」と断り、慌てて発注側で調整することになりました。
教訓
PMとして：要望の優先順位付けと実現可能性の見極めが重要です。チーム内の要望は一度PMが受け止め、妥協点を探ってからベンダーと協議するべきでした。
2.失敗は全てSESのせい！どんどんSESをクビにしてトカゲの尻尾大作戦
ベンダー側のPMの話です。このPMは進捗管理を全くせず、突然の締切を告げることが常態化していました。ある日、難しいタスクをアサインされた私は、完成度40%の状態でレビューを依頼しました。しかし1ヶ月以上放置された後、突然「明後日が締切だから、明日エンドのお客様と話すよ」と告げられました。
予想通り、お客様からは「やり直せ！」と指摘され、徹夜での作業を強いられました。最終的に私は現場を去ることになりましたが、それは進捗管理を怠ったPMの責任ではなく、私の能力不足という形で処理されました。後日、この件をきっかけに、他のSESメンバーも次々と退職したと聞いています。
教訓
進捗管理の甘さや突発的な締切設定は、プロジェクトの重大な危険信号です。このような状況に遭遇したら、早めに上位のマネジメントに相談するか、最悪の場合は現場を去ることも検討すべきでした。
3.危機管理？そんな事より目の前の工数を削っちゃおうPM
ベンダー側で機能の裁量権限があった現場での話です。モバイルアプリ開発において、私は「強制アップデート機能」の実装を提案していました。これは「新しいアプリバージョンがあります。更新してください」とユーザーに告知する機能で、アプリの初回リリース時に実装しておくべき重要な機能です。
しかし、PMは工数不足を理由にこの機能を切り捨てていました。それが発覚したのは総合テストの最中。私は「この機能がないと、将来的にアプリが突然使えなくなるユーザーが続出し、大量のクレームが発生します」と必死に説明し、なんとか実装にこぎつけました。冷や汗ものの出来事でした。
教訓
目先の工数削減は、時として取り返しのつかない問題を引き起こします。特にモバイルアプリ開発では、アップデート対応や互換性の問題は初期段階で考慮すべき重要な要素です。PMには、短期的な視点だけでなく、長期的なリスク管理の視点が求められます。
4.品質悪いぞ！テスト前のシステムに文句をつけてオーナーに告げ口しようPM
2チーム体制での開発現場の話です。私たちのチームはインフラとバックエンド、もう一方のチームはフロントエンドを担当していました。問題は、そのフロントエンドチームのPMの振る舞いでした。
テスト期間中にもかかわらず、このPMは些細な動作不具合を見つけては「バグだ！」「考慮不足だ！」と大騒ぎし、しかもそれを直接オーナーに報告していました。テスト中の不具合は当然のことで、見つかり次第修正していけばよいはずなのですが、その常識的な温度感が共有できませんでした。結果として、オーナーからの信頼を失い、正当な要求まで通りにくくなってしまいました。
教訓
品質管理は重要ですが、各開発フェーズにおける「あるべき品質水準」を理解することも同様に重要です。また、問題を指摘する際は、適切なルートと建設的な方法を選ぶべきです。
5.設計書は文量が大事！ドキュメントの負担を意味なく重くしてやろうPM
予算の都合で多くのドキュメント作成を担当することになった現場での話です。私は必要な情報を簡潔にまとめ、効率的にドキュメントを作成していました。ガイドラインに沿い、内部レビューも通過しているにもかかわらず、PMからは「文章が少ない」「図が少ない」という指摘ばかり。まるで小学生の読書感想文のような文字数チェックです。
内容の正確性や必要十分な情報量ではなく、ただ見た目のボリュームだけを求められる状況は、効率的な業務の大きな妨げとなりました。
教訓
ドキュメントの目的は情報の正確な伝達です。形式や量に過度にこだわることは、本質的な価値を見失うことにつながります。プロジェクトの規模や予算に応じた、適切なドキュメント作成の方針を定めることが重要です。
6.部下に丸投げ！1週間遅延をなんとかしてくれPM
現場に参画したての頃の話です。初日のタスク説明で、すでに1週間遅延しているタスクを任されました。しかも必要な情報も揃っておらず、それを探すところから始めなければならない状況。参画初日から残業続きで、毎日のようにエンドのお客様に怒鳴られる日々。なんとか遅延を挽回することはできましたが、その代償として体調を崩してしまいました。
教訓
どんなに緊急の案件でも、最低限の情報提供と環境整備は必要です。また、無理な要求に対しては、健康を害するリスクも考慮した上で、適切に断る勇気も必要です。
最後に
いかがでしたでしょうか。
プロジェクトの現場では、理不尽な状況に遭遇することも少なくありません。しかし、これらの経験は必ず次に活きてきます。重要なのは、問題に直面したとき、いかに冷静に状況を分析し、適切な対処を選択できるかということです。この記事が、同じような状況に直面した方々の参考になれば幸いです。