プロジェクトが終わっても評価が残らないPMへ──"成果の言語化"で差がつく3ステップ

プロジェクトが無事に終わった。 大きな炎上もなく、納期も守り、顧客からのクレームもなかった。

なのに、評価面談で話せることが「調整を頑張りました」くらいしか浮かばない。

これは、PMとして現場を回してきた人ほどぶつかる壁だと思う。

僕自身、PMとして複数の案件を回していた頃に何度も感じたことがある。終わった直後は達成感があるのに、数ヶ月経つと「あのプロジェクトで自分は何を成し遂げたのか」がぼやけていく。振り返りの場で話そうとしても、出てくる言葉は「関係者と調整して」「スケジュールを管理して」「問題が起きたら対処して」──どれも正しいけれど、どれも自分じゃなくてもできそうに聞こえてしまう。

これはPMの能力不足ではない。PMの仕事の構造そのものが、成果を見えにくくしている。

なぜPMの成果は残りにくいのか

PMの仕事の多くは「起きなかったこと」で測られる。

炎上しなかった。手戻りが最小で済んだ。ステークホルダー間の認識齟齬が大きくならなかった。これらはすべてPMが機能していた証拠なのだけど、起きなかった問題は誰にも見えない。

一方で、開発メンバーには「この機能を実装した」「性能を改善した」という目に見える成果物がある。コンサルには「この提言をした」「このレポートを出した」という名前付きのアウトプットがある。PMにはそれがない。

さらに厄介なのは、PMの成果は「チーム全体の成果」に溶けやすいということ。プロジェクトがうまくいったとき、それはチームが優秀だったからなのか、PMのマネジメントが機能していたからなのか、外から見ると区別がつきにくい。

結果として、苦労して案件を収束させても、市場で語れる言葉が手元に残らない。

これが「終わっても評価が残らない」の正体だ。

成果の言語化で差がつく3ステップ

PMの成果を見える形に変えるには、プロジェクトの記憶が鮮明なうちに「言語化の型」を通しておく必要がある。

以下の3ステップは、僕自身が案件終了後のふりかえりで使ってきた整理法で、転職時の職務経歴書にもそのまま転用できる。

ステップ1：難易度を構造で示す

「大変だった」では伝わらない。大変さを構造化して伝える。

具体的には、次の3つの軸で案件の難易度を言語化する。

• 関係者の数と利害の複雑さ（例：5部門横断、ベンダー3社、意思決定者が7名）

• 制約条件の厳しさ（例：法改正対応で期限が固定、予算凍結中に追加要件が発生）

• 不確実性の高さ（例：要件が半分未確定の状態でキックオフ、途中で主要メンバー交代）

これを1〜2文で書けるようにしておくだけで、「ただ調整していた人」から「複雑な状況を制御していた人」に見え方が変わる。

ステップ2：自分の判断と介入を特定する

プロジェクトの中で、PMである自分が判断を下した場面、あるいは自分が動かなければ止まっていた場面を3つ以上挙げる。

たとえば、こういう場面だ。

• スコープが膨張しかけたとき、優先順位の基準を提示して顧客と合意した

• ベンダー間の責任分界が曖昧になりかけたとき、一枚の役割整理表を作って全員で確認した

• テスト工程でリソースが足りなくなったとき、品質の最低ラインを先に定義して段階リリースに切り替えた

ポイントは「何をしたか」だけでなく「それをしなかったら何が起きていたか」をセットで語ること。PMの成果は「起きなかったこと」だからこそ、仮定の裏側を見せることで初めて価値が伝わる。

ステップ3：結果を数字か事実で閉じる

最後に、自分の判断や介入の結果がどうなったかを、できるだけ具体的に閉じる。

数字で語れるなら数字がいい。「手戻り工数が見積比で15%以内に収まった」「当初計画から1週間前倒しでリリースした」「追加要件を受けつつ、予算超過なしで着地した」など。

数字が出しにくい場合は、事実で閉じる。「顧客から次期案件の指名を受けた」「プロジェクト終了後にチームメンバーから運用設計の型を他案件に展開したいと相談があった」など、第三者の行動で成果を裏付ける。

Before → After で見る言語化の差

同じプロジェクトでも、言語化の解像度でまるで印象が変わる。

Before： 「5部門が関わる基幹システム刷新のPMを担当。スケジュール管理と課題管理を行い、予定通りリリースした。」

After： 「5部門横断・ベンダー3社の基幹システム刷新（要件未確定率40%でキックオフ）のPMを担当。スコープ膨張リスクに対し、要件の優先度を3段階に分類し顧客と段階リリースに合意。テスト工程のリソース不足時には品質の最低ラインを先に定義し、受入条件ベースで判断を切り替えた。結果、追加要件を受けつつ予算超過なし・計画比1週間前倒しでリリース。顧客から次期案件のPM指名を受けた。」

Beforeは嘘ではない。でも、これだけでは「誰でもできそうな仕事」に見えてしまう。

Afterは、難易度の構造・自分の判断・結果を3層で語っている。同じ経験なのに、見え方がまるで違う。

よくある失敗：まとめて書こうとする

この言語化を、年度末の評価面談や転職活動の直前にまとめてやろうとする人は多い。でも、それだとほぼ間違いなく「ふわっとした成果」になる。

プロジェクト終了から3ヶ月も経つと、自分がどの場面でどんな判断をしたかの記憶は驚くほど薄れる。残るのは「大変だった」「なんとかなった」という印象だけだ。

だから、案件の区切りがついたタイミング──リリース直後、フェーズ完了直後、クロージング後──に30分だけ時間を取って、この3ステップで書き出しておく。それだけで、半年後の自分が圧倒的に楽になる。

まとめ

PMの成果は、放っておくと消える。

それはPMの力不足ではなく、PMの仕事が「起きなかったこと」で成り立つ構造だからだ。だからこそ、意図的に言語化する仕組みを持つことが、評価にもキャリアにも効いてくる。

1. 難易度を構造で示す

2. 自分の判断と介入を特定する

3. 結果を数字か事実で閉じる

まずは直近で終わった案件、あるいは今まさに佳境にある案件について、この3つを15分で書き出してみてほしい。完璧じゃなくていい。書き出しておくだけで、記憶が消える前に資産に変わる。

ひとりで棚卸しが難しいと感じたら、3日でキャリアの判断軸を整えるキャリア相談も用意しています。PMとしての実績を、市場で伝わる言葉に変えるところから一緒に整理できます。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！