(続)WEBエンジニアがどのように各工程に上がっていくのか具体例：「PMフェーズ」で求められる要件について

前回のコラムでは、「要件定義～詳細設計」までに必要なスキルや一人称で作成できるべき成果物について解説しました。今回は、更に上流のPMフェーズについてです。
10チーム・総勢50名を超えるような超大規模案件や、複雑なドメイン知識が絡み合うプロジェクトにおいて、計画を立案し、リスクを先回りして潰し、プロジェクトを推進するPMは、AI時代でも価値を高めていくはずです。
本コラムでは、PMフェーズで求められる要件、業務内容、面接で想定される質問をお伝えします。

1. 下流工程を経験したPMの強み

1-1. PG任せの「進捗管理担当者」が直面する問題

システム開発におけるプロジェクト全体の進行を管理するために、開発業務の割り振りを決めたり作業計画の立案（WBS作成など）を行ったりしますが、それはPM業務のごく一部。
複雑なプロジェクトでは、「進行管理のスキル（スケジュール帳の更新と、課題管理表の期日変更など）」だけでは対応しきれない場面もあります。

そんなときに強みとなるのが、PM自身に「開発に関する深い知見」があるかどうかです。
開発経験のないPMがプロジェクトを管理すると、進捗遅延が発生した際、プログラマの「ちょっと調整が難航していまして…」「あと数日で終わります」という言葉を鵜呑みにするしかなくなります。

その結果、トラブルの本質的な原因（アーキテクチャの選定ミス、複雑な依存関係によるバグの連鎖、技術負債の蓄積など）に気づかずに進み、気づいたときには手遅れになってプロジェクトが文字通り「大炎上」するのです。
そのため、プロジェクトをリードするマネジメント人材であっても、製造工程（プログラミング）から泥臭く経験していることは非常に強みとなります。

1-2. 理想的なPM像

PM経験があれば誰もが高評価されるわけではありません。
市場で大きく評価されるPMやPLのベンチマークは、「5〜6名規模のチームをリードするリーダークラスであり、プロジェクト全体の規模としてはそれが10チームほど（全体で50〜60名以上）連なる大規模案件を経験していること」です。

この規模になると、単に自分のチームを見るだけでなく、他チームとのシステム間連携やスコープの調整が頻発します。
要件定義フェーズで策定された機能要求を、各開発チームへ正確に連携・配分するだけでなく、プロジェクト全体の計画立案・遂行をリード・サポートできるレベルが求められます。

市場で評価が高い「プレイングマネージャー」
エンジニア歴が長く、圧倒的な技術力をバックボーンに持ちながら、マネジメントを主軸としつつも「いざとなれば自分も手を動かしてコードが書ける・トラブルシューティングができる」という人材は、どの現場に行っても求められています。
技術がわかるからこそ、エンジニアにリスペクトされ、顧客とも対等に技術的な会話ができるのです。

2. PMフェーズにおける具体的な業務内容

プロジェクトマネジメントの現場で、PMが日々遂行する業務は大きく4つのフェーズに分類されます。
ビジネス要求をシステムへ翻訳し、現場のエンジニアが最高のパフォーマンスを発揮できるように泥臭い調整を続けるための具体的な業務内容です。

2-1. 現状分析・課題定義

プロジェクトのキックオフ、または途中参画時に「今、何が起きているのか」を正確に把握するフェーズです。

• 既存システムの仕様や関連業務フローの分析・可視化：既存システムの仕様や、関連する業務フローをヒアリングやドキュメントから徹底的に分析・可視化します。ドキュメントの読み込みに留まらず、必要に応じてレガシーコードの構造やデータベース内に蓄積された生データを直接確認し、ブラックボックス化している仕様を炙り出します。さらに、現場のオペレーターに「なぜこの手順を踏んでいるのか」を泥臭くヒアリングし、暗黙知となっている業務フローを「見える化」します。
• 現行業務の課題や新システムで解決すべき要件の抽出・整理：現行業務の課題や、新システム・新フェーズで解決すべき要件を漏れなく抽出・整理します。顧客から上がってくる「システムが重い」「画面が使いづらい」といった表面的な不満（表層課題）の裏にある、ビジネス上の本質的なボトルネック（例：マスタデータの一元管理ができていない、非効率な手作業が介在している等）を特定し、新システムで何を解決し、どの指標を向上させるかをロジカルに整理します。

2-2. 要求定義・仕様策定

プロジェクトのゴール（どこまでを今回のスコープとするか）を確定させ、仕様化するフェーズです。

• ユーザー（各事業部門）へのヒアリングを通じたビジネス要求の具体化：ユーザー（各事業部門）へのヒアリングを通じ、新システムへのビジネス要求を具体化します。システムに詳しくない事業部門の担当者と同じ目線に立ち、「新システムを使って、どのようなビジネス価値を生み出したいか」を引き出します。経営層のトップダウンの要望と現場のボトムアップの要望に齟齬がある場合、その利害関係をロジカルに整理し、目指すべき共通のゴールを定義します。
• ユーザーストーリーやユースケースの作成、機能・非機能要件への落とし込み：ユーザーストーリーやユースケースを作成し、「システムが何をするか（機能要件）」だけでなく、大規模案件で最も致命傷になりやすい「非機能要件」（想定同時アクセス数、レスポンス速度、セキュリティ基準、BCP対策としてのバックアップ体制等）を具体的な数値目標として定義します。
• 要求定義書などのドキュメント作成：これらをまとめた要求定義書などのドキュメント作成を行います。顧客側（ステークホルダー）と開発チームの双方が「完成イメージ」を完璧に共有できるよう、要求定義書、概念データモデル、大まかな画面イメージ図をドキュメントに落とし込み、顧客の「サインオフ（承認）」を確実に取得して後々の仕様変更を防ぐ防波堤を作ります。

2-3. 開発チームとの連携

設計・製造フェーズにおいて、開発チームと密に連携し、仕様をカタチにするフェーズです。

• 策定した要件・仕様のエンジニアへの正確な説明と質疑応答対応：策定した要件・仕様をエンジニアへ正確に説明し、技術的な質疑応答に対応します。技術的なバックボーン（製造経験）を活かし、エンジニアが納得するロジックで要件の背景やビジネスゴールを翻訳して伝えます。現場から上がる「こっちの構造の方が綺麗で効率的だ」という逆提案を柔軟に取り入れながらディスカッションを主導します。
• 開発された機能の受け入れテスト計画の策定・実装：開発が終盤になってから慌てないよう、要件定義と並行して「何を以てこの要件をクリアしたとみなすか」の受け入れ基準（シナリオ）を策定します。顧客側のUAT（ユーザー受け入れテスト）の実行計画を主導し、テスト環境の準備やデータ仕込み、不具合発生時のトリアージルールを確立します。
• 開発の進捗に合わせた要件の優先順位付けや仕様の調整実施：開発フェーズで予期せぬ技術的トラブルや進捗遅延が発生した際、プロジェクト全体の納期を守るために、要件の優先順位（MoSCoW分析：Must/Should/Could/Won’t）を即座に再評価します。顧客と交渉して「フェーズ1ではこの機能を削り、フェーズ2で対応する」といった仕様の引き算を迅速に実行します。

2-4. プロジェクト推進サポート

プロジェクトを予定通りに着地させるための、日々の推進業務です。

• 進捗管理、課題管理、リスク管理の徹底サポート
  • 進捗管理：単にWBS（進捗率）の数字を追うだけでなく、クリティカルパス（遅れたら全体が遅れる重要なタスク）を常に注視し、遅延の兆候を早期に検知します。
  • 課題管理：日々発生するバグや仕様の不整合を課題管理表（Jira等）に集約し、期限と担当者を明確にして放置を防ぎます。
  • リスク管理：「ベンダのリソースが足りなくなる」「外部APIの仕様変更がある」といった未来のリスクを事前に予測し、発生時の回避策（プランB）を先回りして用意します。
• 定例会議のファシリテーションサポートや関係各部署との調整業務：週次や日次の定例会議において、アジェンダを明確にして議論をコントロール（ファシリテーション）し、結論の出ない不毛な時間を排除します。進捗状況や課題をダッシュボード化し、経営層や顧客などのステークホルダーへ透明性の高い報告を行うことで、プロジェクトに対する信頼感を強固に維持します。

3. PM向け面接での想定質問と回答のポイント

PMの面接では「言語が何に使えるか」といったスキルレベルの質問だけではなく「技術的バックボーンを活かしてプロジェクトを完遂し、顧客の信頼を獲得できたか」という実績です。

実際の面接で聞かれがちな質問と、面接官が見抜こうとしている意図・回答のポイントを解説します。

3-1. マネジメント・調整に関する質問

• これまでのPJにおけるマネジメント経験について
  • 面接官の意図： 過去にマネジメントしたチームの人数、期間、予算規模、そして自身の具体的な役割（PLなのかPMなのか）を聞き、自社の案件に適応できるサイズ感かを確認します。
  • 回答のポイント： 「〇名（〇チーム）体制、総予算〇億円、〇ヶ月のプロジェクトでPMとして参画」と定量的に述べ、進捗・コスト・品質をどのようにコントロールしたかを具体的に話します。
• 課題抽出や課題整理レベルでの顧客との調整経験の有無
  • 面接官の意図： 顧客から言われた通りの仕様を組む「御用聞き」ではなく、顧客自身も気づいていない本質的な課題をゼロから整理できる「超上流の戦闘力」があるかを探ります。
  • 回答のポイント： 混沌とした状況（例：要件が二転三転する、社内調整が難航している）に介入し、ワークショップやヒアリングを通じて課題を構造化し、合意形成へと導いたエピソードを披露します。
• ベンダコントロールにおける具体的な苦労エピソードとその時どう対処したか
  • 面接官の意図： 外部のベンダや開発パートナーが納期遅延を起こした際、当事者意識を持ってどのように介入し、泥臭くリソース調整やスコープ縮小などの舵取りをしてリカバリーしたかという「修羅場対応力」を見ます。
  • 回答のポイント： 相手を責めるのではなく、タスクの棚卸しを一緒に徹底し、仕様を削る（スコープ調整）、自社の優秀なエンジニアを局所的に投入するなど、現実的なトレードオフを選択して納期に間に合わせた経験を語ります。
• 関係各所との調整経験の有無と具体的なエピソード
  • 面接官の意図： 営業部門、情シス部門、経営層など、利害関係が全く異なるステークホルダーの間に入り、ロジカルかつ感情的にも納得のいく着地点（合意形成）を導き出せるコミュニケーション力があるかを確認します。
  • 回答のポイント： 感情論に逃げず、データ（費用対効果、リスク発生時の損失額）をベースにロジカルに説明しつつ、相手の立場に配慮した落とし所（代替案の提示など）を提案した経験をアピールします。

3-2. 技術的バックボーン・アーキテクチャに関する質問

• オンプレからクラウドへの移行経験の有無
  • 面接官の意図： 単なるアプリケーション開発だけでなく、インフラの構造変化に伴うプロジェクト特有のリスク（データ移行、ネットワーク経路、セキュリティ等）を理解し、移行計画をコントロールできるかを見ています。
  • 回答のポイント： クラウド（AWS等）へ移行する際のダウンタイムの最小化戦略や、移行後のコスト最適化、移行テストの進め方について、マネジメントの観点から留意した点を伝えます。
• 業務・業界独自のデータを用いた開発経験の有無
  • 面接官の意図： 金融、物流、不動産など、ドメイン知識が極めて複雑なデータを扱う際、データの整合性を担保するためにどのような考慮をしたか（業務理解の深さ）を見ています。
  • 回答のポイント： その業界特有のデータ連携（例：レガシーな固定長ファイル、複雑な税計算ルール等）をいかに素早くキャッチアップし、開発チームへ正確な仕様として伝達したかを述べます。
• データベースの操作やクエリの読解に対する経験
  • 面接官の意図： プログラマからの「遅れています」「原因不明のエラーです」という報告に対し、PM自らが技術的にファクトチェック（事実確認）できる技術的バックボーンがあるかを見ています。
  • 回答のポイント： 「トラブル時には自らSQLを叩いてデータの状態を確認したり、スロークエリを特定して開発メンバと改善案を会話した」というエピソードを話し、エンジニア任せにしないスタンスを示します。
• システム基盤をゼロから構築した経験の有無
  • 面接官の意図： 出来上がったシステムの保守・改修ではなく、何もない状態（スクラッチ）からインフラやアプリケーションアーキテクチャの選定リスクを背負い、プロジェクトを立ち上げた経験（0→1の突破力）を見ています。
  • 回答のポイント： 初期段階での技術選定（フレームワークやクラウドサービスの選定）における評価基準や、プロトタイプ（PoC）を作ってリスクを検証したステップを具体的に話します。
• スケーラビリティを考慮したシステム構築の経験の有無
  • 面接官の意図： リリース後にアクセスが集中してシステムがダウンするような、先見性のないマネジメントをしていないか、非機能要件への配慮の深さを見ています。
  • 回答のポイント： 大規模な負荷を想定したロードテスト（負荷試験）の計画、データベースのレプリケーションや分散処理、キャッシュ戦略などを技術チームとどう握って推進したかを語ります。
• サーバレス開発やサーバレスアーキテクチャについての知見の有無
  • 面接官の意図： 従来の常駐サーバー型開発とは異なる、モダンなサーバレス（AWS Lambda等）特有のリスク（コールドスタート問題、分散されたデバッグの難しさ、ベンダーロックイン）を把握してプロジェクト管理を行えるかを見ています。
  • 回答のポイント： サーバレスのメリットを享受しつつ、開発環境の複雑化やテスト自動化の難易度に対して、どのようなマイルストーンを引いたかを説明します。

3-3. スタンス・マインドに関する質問

• 自分に出来ない事があった場合にはどうするか
  • 面接官の意図： 最も重要視されるスタンス質問です。 知ったかぶりをしてプロジェクトを危険に晒す「独りよがりなプライド」を捨て、チームを勝たせるための「健全な巻き込み力」があるかを見ています。
  • 回答のポイント： 「自分の専門外や未知の技術トラブルに直面した場合は、即座にそれを認め、社内外の技術スペシャリストや有識者にリクエストを明確にして協力を仰ぎます。プライドではなくプロジェクトの成功を最優先し、チーム全員の知恵を結集して最速で解決を図ります」と回答するのが100点です。

［面接で確認されるポイント］

• 顧客との要件調整経験：仕様変更の要求に対し、QCD（品質・コスト・納期）の観点から顧客と対等にネゴシエーションし、プロジェクトの破綻を防いだ実績があるか。
• 要件の優先順位付け：進捗遅延や予算超過の危機に直面した際、どの機能をフェーズ1として死守し、どれをフェーズ2へ回すかの明確な判断基準（マスト/ウォントの切り分け）を持っているか。
• 業務ルール整理：開発チームが実装で迷わないよう、顧客の曖昧な社内規定や例外処理を、システムが処理可能なロジカルなルールへと翻訳・整理できているか。
• 非機能要件の定義：性能、セキュリティ、可用性など、後から変更すると莫大な手戻りが発生するシステム品質について、初期段階で顧客および技術チームと完全に合意を握れているか。

5. PMフェーズを突破するために磨くべきスキルセット

最後に、PMとして活躍するために必要なスキルセットをまとめます。
日々の開発やチームリードの現場でこれらの要素を意識的に積み上げることが、エンジニアとして高年収を獲得する最短ルートとなります。

【必須レベル】

• 業務分析・要件定義のご経験（3年以上）：業務フローを深く理解し、そこから課題を抽出した経験。ユーザーへの深いインタビューを通じてシステム化のスコープ（要件）を厳密に定義し、要件定義書、機能一覧、画面・帳票一覧など、開発現場のエンジニアが一目見て実装に着手できるレベルのドキュメントを自力で作成した経験。
• コミュニケーション能力（交渉・ファシリテーション・翻訳力）：顧客の「真のニーズ」を汲み取るヒアリング力、非エンジニアに技術制約を納得させる説明力、およびチーム間の衝突を解消する高い交渉力。
• システム開発におけるPM、またはチームリーダーのご経験：進捗管理（WBSの策定・マイルストーン管理）、課題管理（未解決タスクのトラッキング）、リスク管理（事前のボトルネック検知）、および関係各所（顧客、他チーム、外部ベンダ）との利害調整を主体的に行い、プロジェクトを納期通りに完遂させた経験。

【歓迎レベル】

• Webシステム開発プロジェクトへの参画経験：変化のスピードが早く、柔軟なリリースサイクル（CI/CDの活用など）やモダンなフロント・バックエンド構成が求められるWEB業界特有の技術カルチャーへの深い理解。
• システム開発ライフサイクル（特に上流工程）を理解し、エンジニアと円滑にコミュニケーションが取れること：要件定義から設計・製造・テスト・リリース・運用保守に至る全工程の「勘所」を理解し、エンジニアの心理や技術的負荷（技術負債のリスクなど）を汲み取った上で、リスペクトを持った指示や調整ができること。
• Jira, Confluence（Redmine, Backlogなど）のプロジェクト管理・情報共有ツールの使用経験：単にタスクを入力するだけでなく、ツールの機能をフルに活用して、カンバンボードによるボトルネックの可視化、バーンダウンチャートによる進捗予測、Confluenceでの仕様・ナレッジのストック化など、チーム全体の開発効率を高める仕組みを構築した経験。
• クラウド（AWS, Azure, GCPなど）を利用したシステムの開発・設計に関する基礎知識：マネージドサービス（ECS、RDSなど）やサーバーレス、ネットワーク（VPC）の基本を理解しており、インフラエンジニアとアーキテクチャの選定やインフラコスト、セキュリティ設計について対等に議論できるレベルの知識。
• 社内向け業務システムのプロダクトマネジメント経験、またはプロジェクトマネジメント経験：企業内の複雑な業務ドメイン（ERP、CRM、会計、人事システム等）に深く関わり、現場の業務効率化（DX）をプロダクトのライフサイクル全バリューチェーンにわたって主導した経験。
• アジャイル開発（特にスクラム）におけるプロダクトオーナーやそれに準ずる役割のご経験：固定された仕様ではなく、変化する優先順位（プロダクトバックログ）を常に管理し、開発チーム（スクラムチーム）と対話しながら、短いスパン（スプリント）で継続的に価値あるソフトウェアをデリバリーした経験。
• UMLなどを用いたモデリングによるシステム設計のご経験：クラス図、シーケンス図、ユースケース図、アクティビティ図などの共通言語（UML）を用いて、複雑なシステムの構造や振る舞いを曖昧さを排除して視覚的に表現・設計できるスキル。
• データベースに関する基本的な知識（SQLの読解・作成ができるレベル）：RDBのインデックスの仕組みや正規化理論を理解しており、自ら複雑なJOINや集計クエリ（SQL）を書いてデータの不整合調査やパフォーマンス分析を主導できるレベル。

6. AI時代の生存戦略としての「技術がわかるPM」

AIの進化によって、ソースコードの記述（製造）や詳細設計の自動化が進んだとしても、「複雑な人間社会の利害関係を調整し、技術的な制約を踏まえた上で、プロジェクトの進行をコントロールするPM」の役割が自動化されることはしばらくの間は難しいでしょう。

AIが10秒で100行のコードを生成する時代だからこそ、現場の進捗は加速し、その分「依存関係の複雑化」や「ブラックボックス（理解負債）」という新たなリスクがPMの前に立ちはだかります。

そこで生き残るのは、プログラマ任せにせず、製造から泥臭く経験してきたからこそトラブルの本質を見抜ける、「技術的バックボーンを持ったPM」です。

あなたがこれまでのキャリアで培ってきたコードを書く力、設計する力。それらすべては、このPMフェーズにおいて「現場を正確に支配し、プロジェクトを成功に導くための最強の武器」へと昇華します。
流行り廃りの激しい技術単体のスペシャリストを超え、プロジェクト全体をドライブする高付加価値なPMへの道を、ぜひ力強く突き進んでください。