エンジニア出身PMが一次請けで失敗しまくった話
PM界隈 Advent Calendar 2025の12月7日分担当のぴよです。このアドカレ、PMがいっぱい集まってて楽しいのと、ZennやQiitaじゃなくてnoteに書いてる人が多くて新鮮。
はじめに
私は元エンジニアで、二次請け以降のSIer案件でPMを何プロジェクトか経験し、現在はシステム開発会社を経営しています。経営しながらインフラ整備したりPMしたりしています。今回、初めて非IT系のエンドクライアントと直接やり取りする受託開発を担当しました。案件は「スプレッドシートで行っていた申請管理をシステム化する」という、よくある業務効率化案件です（正確にはシステム化スコープはこちらで提案しました）。
ところが一次請けとして直接クライアントと向き合ってみると、技術的な判断だけでなく「ステークホルダーとの交渉」「契約上のリスクヘッジ」など、二次請け時代には意識していなかったスキルが求められました。この記事では、案件で実際にあったことを適度にぼかしつつ、エンジニア力と進捗管理力以外に必要になる力について、同じ失敗を繰り返さないために記載します。
🌸合意形成の失敗
1. 見積もりOK後に「やっぱり高い」と言われた
何が起きたか
見積もりを提出し、窓口の担当者からOKをもらって開発をスタートしました。普段のMTGも順調に進捗報告をしたり、細かな確認をしていたのですが、開発が中盤に差し掛かったある日の定例MTGで、「このシステム、もっと安くできませんかね」「保守費用、高いですね....」といった声があがり、このまま開発してもお客さんは幸せじゃないだろうなという空気感が漂い始めました。後で聞いたところ、開発費と保守費用を合計したときの投資回収期間の長さをつつかれたみたいです。
原因
窓口担当者（現場マネージャー）の視点でしかヒアリングしておらず、経営層がどう評価するか考えていなかった
「スプレッドシートでの作業に時間がかかっているので、短くしたい」という現場のペインは把握していましたが、経営層に稟議を通すときや、現場以外からどんな声をかけられ得るかまでは想像できていませんでした。窓口担当者からOKをもらった時点で、ステークホルダー全体の合意が取れたと思い込んでいたのです。
保守費用を含めた総コストの説明が不十分だった
システム開発の保守には何が含まれているのか、今回の予算だとどこまで含むのが良いのかといったすり合わせをするタイミングが遅かったため、開発着手後にスコープを何度も擦り合わせることになりました。
教訓
- 経営層・窓口・現場の3つの立場について、「このプロジェクトの目的は何か」の合意を形成するようにしてから、要件定義を始める
- ROI計算を行い、稟議を通せる材料を用意して、決済者によるストップがかからないような状態にしておく
- 保守費用は最初からプランや内容を見せる。ROIの計算にも含んでおく
最初にこのプロジェクトをやると全員が嬉しいぞ、という目的と根拠をもっておき、さらにステークホルダー全体が共有していることが大事です。
2. 窓口担当者のOKが「現場のOK」ではなかった
何が起きたか
モックを作り、窓口担当者に「現場でも確認してください」とURLを渡しました。業務フローはお客さまから事前にシステム導入前後の両方を描いてもらえていたので、口頭で確認したものの、こちらで新しく図として整理はしませんでした。
モックにはOKをもらえたのですが、システムが部分的に動くようになった段階で、この業務フローだと使えない」という考慮漏れが発覚し、開発中盤で大きな仕様変更をすることになりました。
原因
窓口担当者と現場担当者で、業務フローの解像度が違っていた
現場担当者は日々の細かいオペレーションを実際に行っているため、「こういう例外ケースのときはこう処理する」という暗黙知を持っていました。「現場にも聞いてね」という指示だけでは、さらっと聞いたりモックURLを共有するだけになりがちです。そのため、詳細な洗い出しは期待できませんでした。」
業務フローを口頭で確認していた
そもそも窓口の担当者も現場の担当者も意識していない流れや要素もいくつかありました。特に異常系や、実はこういう業務が多いよねという点は、改めて業務フローを描いて見ながら会話しないと整理できません。
教訓
業務フローは開発側が改めて可視化する
- 現場担当者を定例MTGに呼んでもらう
- 業務フローは開発側で改めて可視化し、定例MTGの中で見せる。特に例外フローは能動的に確認する
- システムを現場が触る機会をなるべく早く設ける（モックではなく、可能なら実データに近いデータを入れたシステム）
🌸仕様策定の失敗
3. 「仕様凍結します」と宣言したのに凍結できなかった
何が起きたか
「この日で仕様凍結」と宣言しましたが、システムが出来上がるたびに小さい考慮漏れや「対応しないと業務がしにくい」という点が出てきました。さらに、チーム内で対応方針が統一されていなかったため、「バッファで対応する」や「小さいものも全て追加費用とする」といった極端な対応も生まれ、混乱を生みました。
原因
「どこまで標準対応か」の線引きがチームで共有されていなかった
見積もりにどこまで見込んでいるかの共通認識が取れていなかったため、何がバッファで吸収でき、何が交渉を必要とするのか、都度判断が必要でした。また、フロントエンドから見ると「簡単」だが、バックエンドから見ると「ここのロジックを考え直さないと」といった内容について、考慮しきれないままお客さまに回答してしまうこともありました。
仕様凍結の前提となるステークホルダー全体の合意が取れていなかった
仕様凍結は定例MTGの中で会話したので、窓口担当者だけと合意をとった形になってしまいました。ステークホルダー全体を巻き込んで、システムの全体像に対する合意をとり、特に現場担当者にも気になる点がないか、しっかり想像する時間と機会を提供するべきでした。
教訓
- 不確実性が高いなら、むやみに仕様凍結せず変化に対応できるプロセスを選ぶ（ウォーターフォール強行も、なんちゃってアジャイルでも、そのプロセスで大丈夫か考えてから進める）
- 凍結できないなら「この範囲は追加費用なし、それ以外は都度見積もり」等のルールを内部とも、クライアントとも先に決め、合意を取る
4. 納品直前にUX上の考慮漏れが見つかった
何が起きたか
検索機能を業務フローや定例MTGの内容を踏まえ、「完全一致」で設計していました。ほぼ完成した段階で「誤字があったら見つけられない」と指摘が入り、納品直前であいまい検索に変更することになりました。
原因
- UX設計の専門性がチームになく、「使われなくなりそう」というリスクを事前に検知できなかった
- クライアントに答えを求めすぎて、こちらから選択肢を提示できていなかった
教訓
- 生成AIを活用してUXリスクを事前に洗い出す
- 「検索機能のUXリスクを教えて」と言ったら完全一致の話をChatGPTが提示してくれました
- 一般的なシステムではなく特殊なUXが必要な場合、生成AIでフォローできない可能性が高いので専門家をアサインする
🌸チーム運営の失敗
5. スタートアップ出身とSIer出身での派閥（？）ができた
何が起きたか
前提とする開発プロセスが違い、話が噛み合っていないことがありました。たとえばドキュメントについて、スタートアップ出身のメンバーは「必要なときに必要なものを作ればいい」「マークダウンでとりあえず作ろう」というスタンス。SIer出身のメンバーは「設計は（生成AIも使うが）人が考える」「なるべく細かく設計して認識齟齬がないようにする」というスタンスでした。
結果、お互いのアウトプットをうまく噛み砕けず、slackに質問が飛び交うことが多かった気がします。
原因
- 開発プロセスの前提が違うことに開発初期は気づかなかった
- ドキュメントの粒度や形式を標準化していなかった
教訓
- できれば文化が近いメンバーでチームを組む、難しければ「この案件ではどのプロセスで進めるか」を最初に明示的に合意する
- ドキュメントとして残すものの粒度と形式を決めておく。省略するものはどう判断するか、誰が判断するか明文化しておく
🌸スケジュール管理の失敗
6. 納品前にお互い「何をすればいいか見えない」状態になった
何が起きたか
WBSで進捗管理していたが、納品直前はクライアントマターのタスクも増え、「いつ誰が何をするか」が不明瞭になりました。クライアント側のタスク（UAT、ドメイン設定、納品書処理など）も多く、開発中期までのように「N日までにお願いします」と口頭＋テキストで伝えても期日どおりに進まないこともありました。
原因
- 納品フェーズのタスクがWBSの粒度に合っていなかった
- クライアント側で窓口担当者以外が行うタスクを共有するのが手間だった
- クライアント側で何をいつまでにしないとどう遅延するか把握できず、通常業務との優先度の判断が難しかった
教訓
- 納品前は残タスクリストを共同編集できる形で共有する（担当・期日・進捗・依存関係を明記）
- 定例MTGで毎回リストを見ながら確認する
- 同期作業が必要な時間を事前にカレンダーで押さえておく
- 依頼するタスクは手順を確認し、担当者に展開できるドキュメントやリストをこちらで作る
🌻全体を通しての教訓
計画は変わる前提で「交渉できる状態」を作る
どのフェーズでも、どの案件でも、想定外のことは起きます。重要なのは、想定外が起きたときに適切なタイミングと方法で交渉できるかどうかです。
なお、交渉は「理論でねじ伏せる」ことではなく、お互いにメリットがある着地点を探り、説得力のある言い方で対話するといったニュアンスも含むので、日頃から信頼関係を築いておくことが大切です。定例MTG以外でもコミュニケーションを取る、レスポンスを早くする、約束を守る。こうした「信頼貯金」が、いざというときの交渉の土台になります。
不確実性となるべく早く戦う
システムではいろんなフェーズの「不確実性」が大きい事故につながります。逆に、最初にUnknown-Unknown領域を減らしておくことで、リスクヘッジをして傷を最小限にすることができます。
たとえば、スコープを小さく切ることで、不確実性が一定以上に膨らまないようコントロールすることが有効です。たとえば、要求分析だけでいったん区切る、開発フェーズをフェーズ1・フェーズ2に分ける、PoCを挟むなど。小さく区切れば、問題が起きても影響範囲が限定されます。
さらに、「このシステムでよくあるリスクは？」「UXで気をつけるポイントは？」とAIに聞いて、経験不足を補うことも大事です。
- この種類のシステムでよくあるリスクを教えてください
- 検索機能のUXで気をつけるべきポイントを洗い出してください
- データ移行でよく発生する問題を教えてください
といった質問をすることで、データ確認など、先にやると不確実性が減る作業を洗い出し、なるべく早い段階で不確実性を小さくしましょう。
固定と自由度を最初に把握する
QCDとスコープ、クライアントは「すべて絶対です」という顔をしがちです。しかし、すべてを固定することは現実的に不可能です。QCDとスコープについて、「譲れない箇所」＝固定する箇所を把握し、残った自由度をお互いに認知することで、合理的な進め方ができます。この時、決定者が目の前の窓口になっている人でないこともあるので、合意形成に巻き込むべき人の判断も必要です。
おわりに
いわゆるSIerで二次請け以降のPMと、一次請けのPMとの差分に注目して、反省を書き連ねてみました。
二次請け以降のPMであればエンジニア出身だと開発時のリスクマネジメントや、いざという時自分でコードを書くパワープレーなどでわりと困らず進められますが、エンドクライアントとの交渉やリソース調達といったスコープまで入ってくると、さらにいろんなスキルが必要ですね。世の中のPMってとてもすごい。
Discussion