PMは「みんなに指示を出す人」だと思っていた

「次の案件、PMをお願いしたい」

上司からそう言われたとき、少し誇らしい気持ちになった人は多いのではないでしょうか。

これまでは開発メンバーとして、割り振られた機能を実装し、テストを行い、進捗会議で状況を報告する側でした。それが今度はプロジェクト全体を見る立場になります。スケジュールを引き、メンバーへ仕事を割り振り、会議で方針を決め、課題があれば適切な判断をする。映画やドラマほど格好よくはなくても、チームの先頭に立って開発を動かしていく仕事を想像していたはずです。

ところが、実際に始めてみると、朝から晩までやっているのは想像していた仕事と少し違います。

予定表を作ったと思ったら、翌日に前提条件が変わる。担当者へ進捗を聞くと「ほぼ終わっています」と言われるが、三日後も「ほぼ終わっています」のまま。顧客からは「前に伝えたはず」と言われ、開発者からは「それは聞いていない」と言われる。会議では全員が納得したように見えたのに、会議後のチャットで反対意見が次々に出てくる。

仕様を決める立場だと思っていたら、自分には決定権がない。チームを管理する立場だと思っていたら、メンバーの上司は別にいる。品質を守ろうとすると納期が危なくなり、納期を守ろうとすると品質が危なくなる。そして問題が起きると、なぜか最初に説明を求められるのはPMです。

PMの仕事は、単に計画を立てて人を動かすことではありません。むしろ、予定どおりに進まない現実を受け止め、関係者の認識のズレを埋め、誰も拾わなかった作業を拾い、問題が致命傷になる前に表へ出す仕事です。

この記事では、初めてPMを担当した人が「こんなはずではなかった」と感じやすい場面を、架空の開発プロジェクトをもとに紹介します。登場する出来事は創作ですが、開発経験者であれば、どこかで見たことのある光景が一つや二つはあるはずです。

今回のプロジェクト

今回の舞台は、ある企業が利用する受発注管理システムの刷新プロジェクトです。

既存システムは十年以上使われており、画面が古い、処理が遅い、担当者しか分からない操作が多いという問題を抱えています。そこで、Webブラウザから利用できる新システムへ作り替えることになりました。

プロジェクト期間は九か月。メンバーは、PMになったばかりの佐藤さん、業務担当者、社内の開発者三名、協力会社の開発者二名、インフラ担当者、品質管理担当者です。顧客側にはシステム部門と業務部門があり、さらに部長や役員も節目の会議へ参加します。

佐藤さんは開発者として七年の経験があります。技術には自信があり、要件さえ決まれば大きな問題は起きないと考えていました。

プロジェクト開始時、佐藤さんは細かなWBSを作り、担当者と期限を設定し、週次会議の予定を入れました。リスク管理表も課題管理表も用意しています。キックオフ会議では、顧客から「非常に分かりやすい計画です」と評価されました。

佐藤さんは思いました。

「準備はできた。あとは、この計画に沿って進めればいい」

もちろん、そんなに簡単には進みません。

あるある1――要件定義が終わった翌日に「少しだけ追加」が来る

要件定義の最終日、顧客と開発側は二時間かけて機能一覧を確認しました。画面、帳票、権限、データ移行、外部連携について一通り合意し、議事録にも「要件確定」と記載しました。

佐藤さんは、その日の夕方に開発チームへ宣言します。

「これで要件は固まりました。明日から設計へ進みます」

翌朝、顧客の業務担当者からメールが届きました。

「昨日の会議後、現場へ確認したところ、出荷確定後にも数量を修正したいという意見がありました。小さな変更だと思いますので、追加をお願いします」

画面に入力欄を一つ増やす程度に聞こえます。しかし、出荷確定後の数量変更は、在庫数、売上金額、請求データ、操作履歴、承認権限、外部システムへの連携内容に影響します。すでに確定したデータを誰が、いつ、どの条件で変更できるのかも決めなければなりません。

佐藤さんが影響範囲を説明すると、顧客は少し驚いた様子で言います。

「でも、今のシステムではできていますよ」

既存システムでできることは、新システムでも当然できる。顧客から見れば自然な考えです。一方、開発側から見れば、要件一覧に記載されていなかった機能です。

ここで初めてPMは、「要件確定」という言葉の意味が関係者によって違うことに気づきます。

開発側の要件確定は、「これ以降の追加や変更は、費用と納期への影響を確認して扱う」という意味です。しかし顧客側では、「大体の方向性が決まり、細かな部分は今後調整できる」という意味で使われていることがあります。

PMがやるべきことは、「もう確定したので変更できません」と突っぱねることでも、「小さそうなので入れておきます」と安請け合いすることでもありません。

まず、変更内容を具体化します。次に、影響する画面、データ、テスト、外部連携を整理します。その上で、追加費用、納期への影響、代わりに削れる機能、次期対応へ回す選択肢を示します。

つまりPMの仕事は、変更を止めることではなく、変更の値段を見えるようにすることです。

初めてPMをすると、要件変更を「顧客のわがまま」と感じることがあります。しかし実際には、顧客自身も設計や画面を見て初めて必要性に気づく場合があります。問題は変更が起きることではなく、変更が無料で、影響なく、予定どおり入れられるように扱われることです。

あるある2――進捗率90％から一週間動かない

設計工程が始まり、佐藤さんは週次会議で各担当者に進捗率を確認しました。

「受注登録画面の設計はどのくらいですか」

担当者は答えます。

「90％です。ほぼ終わっています」

翌週も同じ質問をします。

「受注登録画面はどうですか」

「引き続き90％です。細かいところを確認しています」

その翌週も90％でした。

PM初心者が陥りやすいのは、進捗率を客観的な数字だと思ってしまうことです。しかし、作業者が感覚で答える進捗率は、かなり曖昧です。

人によっては、着手した時点で30％、大枠を書いた時点で70％、自分の中で書き終えた時点で90％と答えます。残り10％には、レビュー、指摘修正、顧客確認、関連資料の更新など、実は作業の半分近くが残っていることもあります。

また、「遅れています」と報告しづらい空気があると、進捗率は少しずつ楽観的になります。担当者に悪意があるとは限りません。本人も「今日集中すれば終わる」と信じています。ただし、その“今日”が毎日更新されます。

そこで佐藤さんは、進捗率ではなく完了条件を確認するようにしました。

「設計書は作成済みですか」

「自己レビューは終わっていますか」

「レビュー依頼は出しましたか」

「指摘事項は何件残っていますか」

「顧客へ確認が必要な項目はありますか」

この聞き方に変えると、90％の中身が見えてきます。設計書は書かれているものの、レビューは未実施。権限に関する不明点が三つあり、顧客へ質問も出していない。つまり、完了予定日はまだ見えていませんでした。

PMの仕事は数字を集めることではなく、その数字が何を意味しているかを確認することです。

進捗会議で「順調です」と言われ、そのまま議事録へ書くのは簡単です。しかし、本当に必要なのは、完了した成果物、残作業、阻害要因、次に誰が何をするかを明確にすることです。

「何％ですか」より「何が終われば完了ですか」の方が、現場では役に立ちます。

あるある3――会議では誰も反対しなかったのに、終わった瞬間から反対意見が出る

ある日の設計会議で、検索画面の仕様について議論しました。

A案は検索条件が少なく、操作が簡単です。B案は細かな検索ができますが、画面が複雑になります。会議ではA案を採用する方向で話が進みました。

佐藤さんは最後に確認します。

「では、A案で進めることで問題ないでしょうか」

参加者は黙っています。反対意見はありません。

「異論がないようですので、A案で決定します」

会議終了から十分後、開発者からチャットが届きました。

「A案だと、運用開始後に絶対困ると思います」

さらに別の担当者からも届きます。

「私もB案の方がよかったと思います。ただ、顧客がA案を希望しているようだったので言えませんでした」

顧客側の担当者からは、別のメールが届きます。

「社内で確認したところ、検索条件はもっと必要ではないかという話になりました」

会議では決まったはずなのに、何も決まっていません。

PM初心者は、沈黙を同意として扱いがちです。しかし会議の沈黙には、さまざまな意味があります。

内容を理解できていない。反対だが空気を壊したくない。上司や顧客の前で発言しづらい。自分の担当外だと思っている。早く会議を終わらせたい。後から考えればいいと思っている。

そのため、単に「異論はありますか」と聞くだけでは不十分です。

佐藤さんは次回から、役割ごとに確認するようにしました。

「業務担当の立場では、A案で運用できますか」

「開発側として、実装上の懸念はありますか」

「保守担当として、問い合わせが増えそうな点はありますか」

「今日決められない場合、いつまでに誰が確認しますか」

また、重要な決定は会議の最後に、決定事項、保留事項、前提条件を読み上げます。会議後には議事録を送り、「認識相違がある場合は何日までに連絡してください」と期限を設けます。

PMは会議を開催する人ではありません。会議で何を決めるのかを定義し、発言しやすい状態を作り、決定した内容が後から蒸発しないようにする人です。

会議の回数が多くても、決定が残らなければプロジェクトは進みません。

あるある4――「確認します」が積み重なり、誰も回答期限を持っていない

プロジェクトでは、分からないことが次々に出てきます。

「旧システムのこの項目は、新システムへ移行する必要がありますか」

「確認します」

「返品時の承認者は誰ですか」

「業務部へ確認します」

「外部システムの接続先はテスト用がありますか」

「ベンダーへ確認します」

言葉だけを聞けば、すべて前へ進んでいるように感じます。しかし一週間後、回答は一つも戻ってきません。

佐藤さんが状況を聞くと、それぞれ次のような返事が返ってきました。

「担当部署へメールは送りました」

「まだ回答がないので待っています」

「誰に聞けばよいか確認しているところです」

ここで問題なのは、質問した人が悪いということではありません。「確認する」という作業に、責任者と期限と次の行動が設定されていないことです。

PMになったばかりの頃は、課題表へ「顧客確認中」と書くだけで管理した気になります。しかし、「確認中」は状態であって計画ではありません。

必要なのは、誰が、誰に、何を、いつまでに確認し、回答がなければいつ催促し、さらに回答がなければ誰へ相談するかです。

たとえば次のようにします。

担当者：顧客システム部の田中さん。
回答期限：水曜日の正午。
回答がない場合：水曜日午後に再連絡。
金曜日までに決まらない場合：暫定案で設計を進め、週次会議で判断を依頼。

ここまで決めると、初めて課題が管理可能になります。

PMの一日は、「あの件どうなりましたか」と聞く時間でかなり消えていきます。格好よく言えばフォローアップですが、実態は催促です。

しかも、強く催促しすぎると関係が悪くなり、遠慮すると予定が遅れます。相手も別の仕事を抱えているため、プロジェクトの質問を最優先にしてくれるとは限りません。

PMに必要なのは、威圧的な催促ではなく、回答が必要な理由と期限への影響を伝えることです。

「まだですか」ではなく、「この回答が木曜日までにない場合、画面設計とテスト準備が止まり、来週のレビュー日程へ影響します」と伝える方が、相手も優先度を判断できます。

あるある5――一番詳しい人が、一番忙しくて会議に出られない

旧システムの仕様を理解しているのは、業務部の鈴木さん一人でした。

過去の資料は断片的で、なぜその処理になっているのか誰も説明できません。鈴木さんへ聞けば分かりますが、鈴木さんは通常業務の中心人物でもあります。

要件確認会議へ招待しても、「月末処理のため欠席します」「トラブル対応が入ったため参加できません」と返ってきます。

代わりに参加した人へ質問すると、こう言われます。

「そこは鈴木さんでないと分かりません」

会議後に鈴木さんへメールを送りますが、返信は数日後です。しかも短い回答だけで、追加の疑問が生まれます。

初めてPMをすると、必要な人を会議へ呼べば参加してもらえると思いがちです。しかし現実には、プロジェクトで最も必要な人ほど、本業でも重要人物であることが多く、予定を確保できません。

そして、その人の知識へ依存したままプロジェクトを進めると、確認待ちがボトルネックになります。

佐藤さんは、鈴木さんへ毎回一時間の会議参加を求めるのをやめました。代わりに、週二回、十五分だけ質問できる時間を確保してもらいます。質問は事前に一覧化し、選択肢と推奨案を付けました。

「この処理はどうしますか」と丸投げするのではなく、次のように聞きます。

「現行どおりAとする案と、運用を簡略化するB案があります。利用頻度と影響を踏まえ、開発側はB案を推奨します。問題があれば教えてください」

回答後は、その内容を業務ルールとして文書化します。

PMの役割は、詳しい人を探し続けることではありません。詳しい人から知識を取り出し、チームが共有できる形へ変えることです。

「その人がいないと分からない」は、担当者の能力の高さを示す一方、プロジェクトにとっては大きなリスクです。

あるある6――偉い人の「それ、スマホでも使えるよね？」で計画が揺れる

開発が半分ほど進んだ頃、役員向けの中間報告会が開かれました。

佐藤さんは、進捗、課題、今後の予定を説明し、開発中の画面をデモしました。大きな問題もなく、報告は順調に終わるように見えました。

最後に役員がスマートフォンを取り出し、何気なく言いました。

「これ、外出先からスマホでも使えるよね？」

会議室が静かになります。

今回のシステムは社内PCから利用する前提で設計されています。スマートフォン対応は要件に含まれていません。画面サイズだけでなく、認証方式、社外からの接続、端末管理、操作性、セキュリティ対策まで検討が必要です。

顧客のシステム担当者は答えます。

「現時点ではPC利用を前提にしています」

役員は悪気なく言います。

「今どきスマホで使えないのは不便じゃない？　難しくない範囲で考えておいて」

会議後、「難しくない範囲」が何を意味するのかを巡って議論が始まります。

業務部門は「役員要望なので対応したい」と言い、システム部門は「契約外なので難しい」と言い、営業担当は「追加費用の話をすると印象が悪い」と言います。開発者は「レスポンシブ対応だけならできるかもしれないが、安全な社外接続は別問題」と言います。

PMは、この一言を無視することも、その場で約束することもできません。

ここで必要なのは、曖昧な要望を具体的な選択肢へ変えることです。

閲覧だけ必要なのか。承認操作も必要なのか。会社支給端末だけか、個人端末も許可するのか。社外ネットワークから接続するのか。今回のリリースに含めるのか、次期開発とするのか。

その上で、最低限の対応、完全対応、次期対応という複数案を作り、それぞれの費用、納期、リスクを示します。

PMにとって怖いのは、偉い人の要望そのものではありません。「考えておいて」が、いつの間にか「対応することになっている」へ変換されることです。

重要な発言は議事録へ残し、決定なのか、検討依頼なのか、単なる意見なのかを明確にする必要があります。

あるある7――担当者が突然いなくなり、引き継ぎ資料は「ソースコードです」

開発が佳境に入った頃、中心メンバーの一人が体調不良で長期休暇に入ることになりました。

その担当者は、外部システム連携部分を一人で実装していました。佐藤さんは心配しながらも、別の開発者へ引き継げば対応できると考えます。

引き継ぎ資料の場所を確認すると、返ってきた答えはこうでした。

「基本的にはソースコードを見てもらえれば分かります」

設計書は途中まで。接続先の仕様書は古い版。テスト用アカウントの申請状況は本人のメールボックスにしかありません。動作確認で使っていたデータの作り方も、ローカルPCのメモに残っているだけでした。

別の開発者がコードを読むと、処理自体は理解できました。しかし、なぜ特定のエラーを無視しているのか、再送条件がなぜ三回なのか、外部ベンダーとどのような合意をしたのかは分かりません。

PM初心者は、人員計画を人数で考えがちです。六人のうち一人が抜けたなら、残り五人で分担すればよいと考えます。しかし実際には、知識、権限、接点、作業環境が特定の一人へ集中していることがあります。

人が一人減るのではなく、プロジェクトの記憶が一部消えるのです。

これを防ぐには、普段から次のような状態を作る必要があります。

設計上の判断を記録する。外部とのやり取りを共有場所へ残す。重要な作業を複数人でレビューする。接続情報や申請状況を個人管理にしない。定期的に担当を入れ替え、他の人でも作業できるか確かめる。

ただし、これらは忙しいと後回しになります。

「資料を整える時間があれば実装したい」

「今は本人が分かっているから問題ない」

「リリース後に整理する」

そして、整理される前に担当者が抜けます。

PMは、目の前の生産性だけでなく、誰かが明日休んでも継続できる状態を作らなければなりません。これは効率を下げる作業に見えますが、実際にはプロジェクトを止めないための保険です。

あるある8――テスト環境では動くのに、本番環境だけ動かない

結合テストが終わり、いよいよ本番環境へのリリース日を迎えました。

手順書どおりにアプリケーションを配置し、データベースを更新し、サービスを起動します。ログイン画面は表示されました。

佐藤さんは少し安心します。

しかし、外部システムへデータを送信するとエラーになりました。

テスト環境では何度も成功しています。プログラムも設定値も確認済みです。開発者は首をかしげます。

調査の結果、本番環境から外部システムへ接続するためのファイアウォール許可が入っていないことが分かりました。

申請したはずでした。

インフラ担当へ確認すると、「申請書は受け取っているが、接続元IPアドレスが未確定だったため保留していた」と言われます。開発側は、未確定なら連絡が来ると思っていました。インフラ側は、確定情報が送られてくるのを待っていました。

誰も嘘をついていません。誰も作業を拒否していません。それでも必要な設定は入っていませんでした。

これは開発現場でよく起きる、「依頼した側は依頼済み、受けた側は情報待ち」という状態です。

PMはタスク表に「ファイアウォール申請」と書き、完了にしていました。しかし本当に必要だったのは、「申請書提出」ではなく「本番環境から疎通できることの確認」です。

作業の完了条件を、書類を出したことにするか、目的を達成したことにするかで結果が変わります。

同じことはアカウント発行、DNS設定、証明書準備、監視登録、バックアップ設定などでも起きます。

「依頼メールを送った」

「申請チケットを作った」

「担当部署へ連絡した」

これらは途中経過です。

PMは、依頼系のタスクほど、受付、情報不足、実施予定日、実施完了、結果確認まで追う必要があります。

リリース当日に初めて本番接続を試すのも危険です。可能であれば事前疎通を行い、本番固有の設定差分を一覧化し、誰がいつ確認したかを残します。

本番障害の原因は、高度なプログラム不具合より、「一つ設定が入っていなかった」という地味なものだったりします。そして地味な原因ほど、関係者全員が「誰かがやっていると思った」と言います。

あるある9――不具合を直したら、別の場所が壊れる

受入テスト中、顧客から「受注を取り消した後も在庫が戻らない」という不具合が報告されました。

開発者が原因を調べ、在庫を戻す処理を追加します。修正後、受注取消では正しく在庫が戻るようになりました。

ところが翌日、返品処理をすると在庫が二重に増える不具合が見つかりました。

受注取消と返品で共通処理を利用しており、今回の修正が返品側にも影響していたのです。

さらに修正すると、今度は外部連携データの在庫数が合わなくなりました。

顧客からは言われます。

「一つ直すたびに別の不具合が出ていますが、品質は大丈夫ですか」

開発者は言います。

「仕様が複雑で、影響範囲が広いんです」

品質管理担当は言います。

「修正箇所以外の回帰テストが不足しています」

納期は迫っています。

PMはここで、「全部直してください」と言うだけでは仕事になりません。不具合の重要度、発生条件、業務影響、修正リスク、回避策を整理し、優先順位を決める必要があります。

すべての不具合を同じ重さで扱うと、チームは重要でない表示崩れに時間を使い、重大なデータ不整合への対応が遅れます。一方、「軽微だから後回し」としすぎると、顧客の不信感が高まります。

また、不具合件数だけを見ても品質は判断できません。

百件見つかっても、早い段階で軽微な問題を多く発見できているなら健全な場合があります。十件しかなくても、テストが不足して見つかっていないだけかもしれません。

PMが見るべきなのは、未解決件数、重大度、増減傾向、再発率、修正後の確認状況、特定機能への集中、テスト消化率です。

そして何より、修正のたびにどこを再確認するかを決める必要があります。

不具合対応は、穴を一つずつ塞ぐ作業ではありません。配管全体のつながりを見ながら、別の場所から水が漏れないようにする作業です。

あるある10――「納期優先」「品質優先」「予算厳守」を全員が同時に言う

リリースまで一か月となった時点で、開発は二週間ほど遅れていました。追加要件と不具合修正が重なり、テスト期間が圧迫されています。

佐藤さんは、顧客へ選択肢を提示しました。

一つ目は、リリース日を二週間延ばし、当初範囲をすべて実装する案。

二つ目は、重要度の低い機能を次回へ回し、予定日にリリースする案。

三つ目は、人員を追加し、予定日に全機能を目指す案。ただし費用が増え、途中参加者の立ち上がりにも時間がかかります。

すると関係者から次々に要望が出ました。

業務部門は「現場へ告知済みなので日程は変えられない」と言います。

システム部門は「不安定な状態で出すことはできない」と言います。

購買部門は「追加費用は認められない」と言います。

営業担当は「機能削減は顧客満足度に影響する」と言います。

全員の意見をまとめると、「納期は守る、品質は落とさない、機能は減らさない、費用は増やさない」となります。

しかし、魔法はありません。

初めてPMをすると、この矛盾を自分の努力で解決しようとします。会議を増やし、残業し、メンバーへ頑張ってもらい、何とか全部を成立させようとします。

短期間なら乗り切れるかもしれません。しかし、そのやり方を続けると、疲労によるミスが増え、さらに品質が悪化し、プロジェクトはもっと苦しくなります。

PMの役割は、無理な条件を黙って引き受けることではありません。何を優先し、何を諦めるかを、決定できる人へ判断してもらうことです。

そのためには、「厳しいです」だけでなく、数字と影響を示します。

現時点の残作業。必要工数。利用可能な人数。テストに最低限必要な日数。削減可能な機能。延期した場合の業務影響。予定どおり進めた場合に残るリスク。

判断者が選べる材料を作るところまでがPMの仕事です。

そして、決定内容は必ず記録します。後から問題が起きた際、「なぜこの範囲でリリースしたのか」を説明できるようにするためです。

あるある11――問題を早く報告すると怒られ、遅く報告するともっと怒られる

プロジェクト終盤、データ移行テストで重大な問題が見つかりました。

旧システムの顧客データに重複や不正な文字が多く、そのままでは新システムへ取り込めません。修正には業務部門の確認が必要で、予定していた移行リハーサルへ間に合わない可能性があります。

佐藤さんは、状況がまだ完全には分かっていないため、もう少し調査してから報告しようと考えました。中途半端な情報で不安を与えたくなかったからです。

二日後、影響範囲が大きいと判明し、顧客へ報告しました。

顧客から言われます。

「なぜ、分かった時点ですぐ共有しなかったのですか」

別のプロジェクトでは、問題の可能性を早めに報告したところ、「まだ確定していない話で現場を混乱させないでください」と言われたこともあります。

PMは、報告の早さと確度の間で悩みます。

ここで大切なのは、「確定した事実」と「まだ分からないこと」と「次に確認すること」を分けて伝えることです。

たとえば、次のように報告します。

現時点で、一部データが移行できない事象を確認している。対象件数と原因は調査中。移行リハーサルへ影響する可能性がある。明日の正午までに一次調査結果を報告する。現段階ではリリース延期を決定する状況ではない。

これなら、未確定な情報を断定せず、問題の存在は早く共有できます。

悪いPMは問題を起こす人ではありません。問題を隠し、判断の時間を失わせる人です。

ただし、何でも即座に全員へ投げればよいわけでもありません。影響範囲に応じて、まず誰へ伝えるか、どの段階で顧客へ共有するか、次の報告時刻をどうするかを決めます。

報告で重要なのは、完璧な説明よりも、相手が次の行動を判断できることです。

あるある12――リリース成功の翌日に「ここからが本番です」と言われる

さまざまな問題を乗り越え、システムは予定日から一週間遅れでリリースされました。

主要機能は正常に動作し、大きな障害もありません。佐藤さんは、ようやく肩の荷が下りた気がしました。

チームで簡単な打ち上げを行い、「大変だったけれど、無事に終わってよかった」と話しました。

翌朝八時、問い合わせが届きます。

「ログイン方法が分かりません」

続いて、別の問い合わせが届きます。

「昨日まで使っていた帳票と並び順が違います」

さらに電話が鳴ります。

「処理が遅い気がします」

「マニュアルの画面と実際の画面が違います」

「退職した人のアカウントが残っています」

「この操作を元に戻したいのですが」

システムとしては正常でも、利用者にとっては問題になることがあります。操作に慣れていない、説明が不足している、権限設定が実態と合っていない、旧システムとの違いが受け入れられない。リリース後に初めて見える課題は少なくありません。

顧客の責任者は佐藤さんへ言いました。

「リリースはスタートです。ここから安定運用までお願いします」

佐藤さんは、プロジェクトが終わったのではなく、フェーズが変わっただけだと気づきます。

PMはリリース日だけをゴールにしてはいけません。問い合わせ窓口、初動体制、障害時の連絡先、よくある質問、利用者教育、監視、バックアップ、保守チームへの引き継ぎを準備する必要があります。

また、開発メンバーがリリース直後に別案件へ移動すると、問題を調べられる人がいなくなります。少なくとも初期安定期間は、主要メンバーの対応時間を確保しておくべきです。

花火が上がるようなリリース成功の裏で、運用担当者の仕事は始まっています。

初めてPMをして分かる「自分には決定権がない」という現実

PMという名前から、プロジェクトに関することを自由に決められる立場を想像する人もいます。しかし、実際のPMは多くの責任を負う一方で、すべての決定権を持っているわけではありません。

予算を増やす判断は上司や顧客が行います。納期を変更するには業務部門や経営層の承認が必要です。メンバーの評価や配置は、それぞれの所属長が決めます。仕様は顧客が決めますが、技術的に実現できるかは開発側が判断します。セキュリティや運用には、別部署のルールがあります。

PMができるのは、情報を集め、選択肢を作り、影響を説明し、決定が必要な人へ期限内に判断を求めることです。

つまり、PMは「何でも決める人」というより、「誰が何を決めるべきかを明らかにする人」です。

この現実を知らないと、決められないことまで一人で抱え込みます。そして判断が遅れたとき、自分の能力不足だと感じてしまいます。

しかし、PMの失敗は、すべてを自分で決められないことではありません。決定者が不明なまま放置すること、判断材料を用意しないこと、判断期限を設定しないことです。

PMの仕事は「人を管理する」より「認識のズレを管理する」

プロジェクトの問題の多くは、技術だけが原因ではありません。

顧客は伝えたと思っている。開発者は聞いていないと思っている。インフラ担当は情報待ちだと思っている。依頼者は作業中だと思っている。担当者は自分の作業範囲ではないと思っている。

このような認識のズレが、小さな遅れや手戻りを生みます。

PMが管理する対象として、スケジュール、コスト、品質、リスクがよく挙げられます。しかし現場で毎日起きているのは、言葉の意味、完了条件、優先順位、責任範囲、期限の認識を合わせる作業です。

「対応します」という言葉一つでも、人によって意味が違います。

今日中に着手する。

今週中に終える。

余裕があれば対応する。

担当者へ依頼する。

検討だけする。

PMは、この曖昧さを具体化します。

誰がやるのか。いつまでか。何をもって完了か。完了後に誰が確認するか。できない場合はいつ相談するか。

細かく聞くと、管理が厳しいと思われることもあります。しかし、問題が起きた後で責任を追及するより、最初に確認する方がはるかに健全です。

初心者PMがやりがちな失敗

自分が全部理解してから動こうとする

技術者出身のPMほど、自分で詳細を理解し、正しい答えを出そうとします。しかしプロジェクトが大きくなると、一人ですべてを理解することはできません。

PMに必要なのは、すべての答えを持つことではなく、誰が答えを持っているかを知り、必要なタイミングで参加してもらうことです。

遅れを取り戻すため、自分が作業を引き取る

資料作成やテスト、場合によっては実装まで自分で引き取るPMもいます。一時的には進みますが、PMの確認や調整が止まり、別の問題が大きくなります。

PMが実作業を行うこと自体が悪いわけではありません。ただし、自分にしかできない管理作業を止めてまで引き取ると、全体としては遅くなることがあります。

悪い報告を整えてから出そうとする

原因や対策が決まってから報告しようとすると、共有が遅れます。重大な可能性がある場合は、事実、未確定事項、次回報告予定を分けて早めに伝える方が安全です。

会議を増やせば解決すると思う

問題が増えると、定例会議、課題会議、品質会議、進捗会議を追加したくなります。しかし、参加者と目的が同じなら、報告のための時間が増えるだけです。

会議では、共有だけなのか、相談なのか、決定なのかを明確にします。資料で済む内容は事前共有し、会議では判断が必要な論点へ時間を使います。

メンバーへ気を遣い、遅れを聞けない

厳しいPMと思われたくないため、進捗確認を遠慮する人もいます。しかし、遅れを早く知ることは責めるためではなく、支援するためです。

「なぜ遅れたのですか」だけでなく、「完了を妨げているものは何ですか」「誰の支援があれば進みますか」と聞くことで、確認は追及ではなくなります。

顧客の要望をすべてチームへそのまま渡す

顧客から来た要望を整理せず、開発者へ転送するだけでは、PMが伝書鳩になります。

要望の目的、優先度、期限、背景、受入条件を確認し、実現方法の検討に必要な形へ整えることが必要です。反対に、開発側の「難しい」という回答も、そのまま顧客へ返すのではなく、理由と代替案を整理します。

初めてPMをする人が、最初に用意しておきたいもの

完了条件を記載したタスク表

担当者と期限だけでなく、何をもって完了とするかを書きます。「設計書作成」ではなく、「設計書作成、内部レビュー完了、指摘反映、顧客確認依頼まで」とした方が、認識が揃います。

決定事項を残す記録

誰が、いつ、何を、どの前提で決めたかを残します。議事録が長すぎると読まれないため、決定事項、保留事項、担当者、期限を冒頭にまとめると実用的です。

課題とリスクを分けた一覧

すでに起きている問題が課題、今後起きる可能性があるものがリスクです。両方を同じ表で管理しても構いませんが、対応の考え方は異なります。

リスクには、発生確率、影響、予防策、発生した場合の対応、監視する兆候を設定します。

変更管理のルール

要件変更を禁止するのではなく、変更時に影響を確認し、誰が承認するかを決めます。口頭やチャットで出た要望が、そのまま確定仕様にならない仕組みが必要です。

エスカレーション先

自分で解決できない問題を、誰へ、どの条件で相談するかを決めておきます。PMが抱え続けるほど、上位者が判断できる時間は減ります。

リリース後の体制

問い合わせ窓口、障害連絡、初期対応者、開発者の待機期間、保守への引き継ぎを、開発中から準備します。リリース前日に考えるには遅すぎます。

PMが毎日している地味だが重要な仕事

PMの成果は、完成した画面やプログラムのように目で見えません。

質問へ回答期限を付ける。

会議で決まらなかったことを明確にする。

担当者が休む前に引き継ぎを依頼する。

曖昧な要望を具体化する。

問題が小さいうちに関係者へ共有する。

不具合の優先順位を整理する。

依頼した設定が本当に反映されたか確認する。

顧客の言葉を開発者が判断できる形へ翻訳する。

開発者の技術的な懸念を顧客が理解できる言葉へ翻訳する。

誰も担当していない作業を見つける。

これらは、一つひとつを見ると小さな仕事です。しかし、この小さな仕事が抜けると、後で大きな問題になります。

優秀なPMがいるプロジェクトでは、重大な問題が何も起きていないように見えることがあります。そのため、「PMは何をしていたのか」と思われることさえあります。

実際には、問題が大きくなる前に見つけ、関係者を動かし、表面化しないように処理しているのです。

消防士が火を消す姿は目立ちますが、火災報知器を点検し、避難経路を確保し、火が出ないようにする仕事は目立ちません。PMの仕事も、それに似ています。

「良いPM」は、強く引っ張る人とは限らない

PMにはリーダーシップが必要だと言われます。その言葉から、大きな声で方針を示し、迷わず決断し、チームを引っ張る人物を想像するかもしれません。

しかし現場では、話を聞く力、分からないと言える力、問題を早く表へ出す力、意見の違う人同士の間に立つ力の方が重要になる場面があります。

技術者が懸念を言いやすい。顧客が変更の背景を説明しやすい。遅れが隠されない。分からないことが放置されない。失敗を報告しても、まず対策を考えられる。

このような空気を作れるPMのチームは、問題がなくなるわけではありません。しかし、問題を早く扱えるようになります。

逆に、PMが強く見せようとして何でも即答し、遅れを厳しく責め、反対意見を遮ると、表面上は統制が取れているように見えても、悪い情報が上がってこなくなります。

プロジェクトにとって最も危険なのは、問題があることではなく、問題が見えないことです。

それでもPMの仕事には面白さがある

ここまで読むと、PMは催促と調整と謝罪ばかりの、割に合わない仕事に見えるかもしれません。

実際、楽な仕事ではありません。自分が書いたコードのように、成果を直接示しづらいこともあります。うまく進めばチームの成果、失敗すればPMの管理不足と言われることもあります。

それでも、PMにしか見えない景色があります。

業務担当者が何に困っているのか。開発者がどこで苦労しているのか。インフラやセキュリティがなぜ慎重なのか。経営層が何を重視しているのか。予算、納期、品質、運用がどのようにつながっているのか。

個別の作業だけを見ていたときには分からなかった、プロジェクト全体の構造が見えるようになります。

また、対立していた関係者が同じ目的を理解し、難しい判断に納得し、チームが一つの成果を出した瞬間には、大きな達成感があります。

PMの価値は、誰よりも多く作業することではありません。それぞれ異なる立場の人が、同じ方向へ進める状態を作ることです。

PMは予定を守らせる人ではなく、予定が崩れたときに前へ進める人

初めてPMを担当すると、計画を立て、指示を出し、進捗を管理する仕事を想像します。

しかし、実際のプロジェクトでは計画どおりに進まないことの方が多くあります。

要件は変わります。担当者は休みます。回答は遅れます。会議で決めたことが覆ります。本番環境だけ動きません。不具合修正で別の不具合が出ます。納期、品質、費用のすべてを守るよう求められます。

PMの仕事は、この現実を力ずくで計画へ戻すことではありません。

何が起きているかを見えるようにする。

誰が判断すべきかを明確にする。

選択肢と影響を整理する。

決定事項を残す。

問題を早く共有する。

チームが動けない理由を取り除く。

そして、予定が崩れた後にも、プロジェクトを次の一歩へ進める。

これが、実際のPMに求められる仕事です。

初めて担当した人が「想像と違う」と感じるのは、能力が足りないからではありません。PMという仕事が、外から見るよりはるかに地味で、複雑で、人間くさいからです。

完璧な計画を作れるPMはいません。すべての問題を予測できるPMもいません。

良いPMとは、問題を起こさない人ではなく、問題を隠さず、関係者と一緒に扱い、現実的な次の手を作れる人です。

もし初めてのPM業務で、毎日「あの件はどうなりましたか」と聞き、会議の認識違いを直し、誰も拾わない作業を拾い、予定表を書き換えているなら、それはPMらしい仕事ができていないのではありません。

むしろ、まさにPMの仕事をしています。