PM1年目で失敗したことと学んだこと

今年、JMDCではアドベントカレンダーに参加しています。

本記事は、JMDC Advent Calendar 2025 12日目の記事です。

こんにちは。医療機関基盤チームのPMを担当している西村です。今回の記事では、エンジニア→PMへとロールチェンジした私が実際に直面した壁とどのように乗り越えたか、乗り越えようとしているのかをお話ししたいと思います。

PMを目指した背景

私はエンジニアとして約6年間、サーバーサイド開発や基盤の運用保守に従事してきました。
技術的な視点で課題解決をおこなうなかで、「なぜこの機能が必要なのか」「会社のビジネス的にどのような価値があるのか？」といった、プロダクトの戦略や仕様策定の背景にある「Why」や「What」への関心が高まりました。
技術的な問題だけでなく、ビジネス的な観点も持ったうえでプロジェクトに貢献したいと考え、1年前にプロジェクトマネージャーロールへ挑戦することを決めました。

1年目で直面した３つの壁

エンジニアとしての経験は、開発プロセスやプロジェクト上の技術的な課題解決において大きな利点になると考えていましたが、PMとして動き始めてからは、そう簡単にはいかず、いままでの経験ではすぐには解決できないような問題に直面しました。

今回は、PM1年目の私が直面した3つの壁と、それに対して現在どのように対策しているか、対策しようとしているかを共有します。

1.要望の背景にある「真の目的」を見落とすな

エンジニアチームとビジネスサイドの間には、用語の定義やシステムの前提知識に大きなギャップが存在していました。
例えば、あるときビジネスサイドから「あるテーブルに列を1つ追加したい」という要望がありました。
私はエンジニア的な思考で「仕様の定義」や「既存データへの影響」などの「どう実装するか？」をはじめにヒアリングし、定義しようとしていました。
しかし、ヒアリングを重ねた結果、ビジネスサイドの要望は「列を追加することで、他の基盤データとの紐づけが容易になることで、従来のデータをさらに顧客の要望に沿ったデータにして提供したい」という目的が背景にあることがわかりました。
先に「How」の詳細ヒアリングから入ってしまったため、ビジネスサイドは「なぜそんな細かいことを聞かれるのか？」と困惑したようで、会話がスムーズに進みませんでした。
もし私が先に「Why（なぜその列が必要か）」を確認していれば、「それなら列追加ではなく、既存の別マスタと連携する機能追加で対応できるのでは？」といった、より本質的で、開発工数を抑えられる解決策を提示できた可能性もありましたし、実際にシニアPMにフォローに入っていただいた際にはしっかりとWhyを引き出したうえで、よりベターな解決策をわかりやすく提示、合意のうえ開発に着手することができていました。
Whyを引き出すことを忘れてファシリテーションしたために、要求の背景を理解するまでに無駄なコミュニケーションコストを発生させる結果となってしまいました。

上記経験からの学び

「Why（目的）」を確認する：「What（列を追加したい）」という要望に対し、すぐに「How（どう実装するか）」を考えるのではなく、「Why（なぜそれが必要か？）」をまずヒアリングすることが重要だと感じました。今回の例で言えば、「その列を使って、最終的に何をしたいですか？」と目的からヒアリングすべきでした。
様々な観点から「解決策」を模索する：「Why」が明確になれば、要望通りの実装（＝列追加）が最適とは限らないこともあります。「それなら既存の別マスタとの連携で実現できるかもしれません」といった、双方にとってより最善な解決方法を模索し、複数の選択肢を提示することが重要だと感じました。

2.リファクタリングやセキュリティ対策等の定量的な価値をわかってもらいたいが…

エンジニアとして、リファクタリングやセキュリティ強化・対応の重要性は理解していましたし、当然やるべきものだという認識がありました。
しかしこれらを実際に着手するためにPMとしてプロジェクト化しようとした際、経営陣やビジネスサイドにむけて定量的に価値を提示することがとても難しく感じていました。売り上げ増加のように、ビジネスサイドにわかりやすい指標を提示しづらいプロジェクトの効果をどう表現するのか。という問題についてシニアPMたちと議論し、以下のような対策を考えました。

上記問題への対策

ビジネス指標への紐付け：技術的な改善を、ビジネス上のKPIに変換して説明する努力をしました。
- 例（リファクタリング）：「この改修により、運用作業によるコストが毎月X円削減される見込みです」「開発プロセスが効率化され、新機能のリリースサイクルがY%短縮できます」
「リスクの定量化」による説明：すぐに売上に繋がらない施策（セキュリティ対応など）は、放置した場合のリスクを提示しました（以下図参照）
- 例（セキュリティ）：「この脆弱性を放置した場合、インシデント発生時に最大X円の機会損失、あるいは信用の失墜というリスクがあります。」など

3.見えない作業を考慮できていない「詰め込みすぎ」なリソース管理

エンジニアとしての経験があるために、「この機能なら実装に3日あればいけるな」というような感覚を持っていました。そのため、開発メンバーの空き工数に対して余裕なくタスクを埋め込み、完璧なWBSを立てた気になっていました。

しかし、実際のプロジェクトではたびたび考慮漏れ等による遅延が発生し続けました。私が考慮できていなかったのは、コーディング以外の時間でした。
コードレビュー、ユーザー側との仕様・要件確認のミーティング、突発的なバグ調査、開発環境の問題解決、ユーザー受入テストの時間など、メンバーやユーザー側の業務都合を計算に入れず、「理論値」でスケジュールを引いていたため、想定外のことが起きるとすぐに遅延してしまうような計画になっていました。

私のせいで要件の事前調整ミスによる改修や遅延があったにもかかわらず、その状況下でも完了期日に間に合わせたいという自分都合から開発チームへ無理強いをしてしまい、結果、開発チームの疲弊を招いてしまいました。

上記経験からの学び

初期計画時に明確な「バッファ」を設ける：プロジェクトスケジュールを引く際、実際の工数見積もりに加え、プロジェクト全体に対して一定のバッファを確保するようにすべきでした。具体的には、仕様や技術の不確実性が高い初期段階では見積もりの1.3倍ほどのスケジュールを引いておき、プロジェクト後期で余っていればドキュメントの整備等に使用することができます。
関係者と完了期日・スコープを調整し続ける：進捗状況に応じて「終わらない可能性」が見えた段階で、早期にステークホルダーと調整を行うようにすべきでした。「リソースを追加する」「期日を後ろ倒す」「スコープを調整する」などの選択肢を提示しながら双方納得できるような合意形成を行うために、常にプロジェクトを監視しながら調整することで、遅延や追加の改修が発生してもユーザーや開発チームが納得してプロジェクト完了を迎えることができます。