はじめに

「PMになれば、これまでのSE経験を活かしてプロジェクトをうまく進められるはず」
PMを目指している中堅SEの方の中には、そう考えている方もいるのではないでしょうか。
確かに、SEとしての経験はPMになるうえで大きな武器になります。
設計書を読める。
開発工数の感覚が分かる。
システムの技術的な問題を理解できる。
開発メンバーの気持ちも分かる。
これらは、PMとして非常に重要な能力です。
しかし、SEとして優秀だった人が、そのまま優秀なPMになれるとは限りません。
なぜなら、PMになると「自分で問題を解決する」だけではなく、人を動かし、判断し、プロジェクト全体を管理することが求められるからです。
私自身、PMとして経験を積む中では、「もっと早く気づいていればよかった」と思うような失敗がたくさんあります。
そして、PMの失敗にはある程度パターンがあります。
今回は、これからPMを目指す中堅SEに向けて、実際に起こりやすいPMの失敗を5つ紹介します。
失敗そのものを恐れる必要はありません。
大切なのは、失敗する前に「こういうことが起こる」と知っておくことです。

この記事はこんな方におすすめ

この記事は、次のような方におすすめです。
これからPMを目指している中堅SE
初めてプロジェクトリーダーを任される方
将来的にPMとして活躍したい方
SEとPMの違いを知りたい方
PMとして失敗しやすいポイントを知りたい方
チームマネジメントに苦手意識がある方
顧客との調整に不安がある方
特に、これまで技術面を中心に仕事をしてきた中堅SEの方には、ぜひ知っておいてほしい内容です。

よくある失敗談

失敗談1：自分で仕事を抱えすぎてしまう

PMになったばかりの頃にありがちな失敗が、自分で仕事を抱えすぎてしまうことです。
SEとして優秀な人ほど、この失敗をしやすい傾向があります。
例えば、メンバーから、
「この作業がよく分からないので、見てもらえませんか？」
と相談されたとします。
そこで、
「分かった。自分がやっておくよ」
と引き取ってしまう。
最初は問題ありません。
しかし、これを繰り返していると、気がつけばPM自身が大量の作業を抱えることになります。
本来PMがやるべきなのは、すべての作業を自分で解決することではありません。
メンバーが仕事を進められるように環境を整え、必要なところで判断することです。
例えば、メンバーから相談を受けたら、
「どこで困っているの？」
「自分ではどう考えている？」
「必要なら一緒に整理しよう」
といった形で、まず本人が解決できるようにサポートします。
もちろん、緊急時にはPM自身が作業を引き取ることもあります。
しかし、それが常態化してはいけません。
PMになったら、
「自分が作業する」から「メンバーが作業できるようにする」
という意識への切り替えが重要です。
この失敗から学べること
仕事を抱え込むのではなく、適切にメンバーへ任せましょう。
「自分でやったほうが早い」という気持ちは分かります。
しかし、短期的には早くても、長期的にはチームが成長しません。
PMにとっては、自分が10の仕事をするより、メンバー10人がそれぞれ仕事をできる状態を作ることのほうが重要です。

失敗談2：進捗が「順調です」を信じすぎる

2つ目は、メンバーからの「順調です」という報告をそのまま信じてしまうことです。
PMとしてプロジェクトを管理していると、
「進捗どうですか？」
「順調です」
という会話をすることがあります。
しかし、これだけでは本当の状況は分かりません。
例えば、予定では「設計完了まであと3日」なのに、
「だいたい終わっています」
という報告があったとします。
ここで安心してしまうと、後から、
「実は仕様が一部決まっていません」
「レビューで大量に修正が出ました」
「想定より実装が難しいことが分かりました」
という問題が出てくることがあります。
「順調」という言葉には、人によって違う意味があります。
ある人にとっては「予定より少し遅れているけど問題ない」。
別の人にとっては「まだ問題はないが、かなり厳しい」。
つまり、言葉だけでは進捗を正確に判断できません。
そこでPMは、具体的な数字や成果物を見る必要があります。
例えば、
「何％終わっていますか？」
ではなく、
「設計書は全部で10本ありますが、レビューまで完了しているのは何本ですか？」
と確認します。
さらに、
「残作業は何ですか？」
「問題になっていることはありますか？」
「予定どおり進めるために、何か必要なものはありますか？」
と確認することも重要です。
この失敗から学べること
PMに必要なのは、報告を疑うことではありません。
事実を確認することです。
「順調です」という報告を受けたら、「それなら安心」と終わらせるのではなく、
「何をもって順調と言っているのか？」
を確認する習慣をつけましょう。

失敗談3：顧客の要望を何でも受け入れてしまう

3つ目は、顧客の要望を何でも受け入れてしまうことです。
これは、顧客との関係を大切にしたいPMほど陥りやすい失敗です。
顧客から、
「この機能も追加してもらえませんか？」
と言われたとします。
PMとしては、
「お客様の要望なので対応しましょう」
と考えてしまうかもしれません。
しかし、追加要望には必ずと言っていいほど、
工数・スケジュール・品質・コストへの影響
があります。
例えば、1つの追加機能に100時間必要だとします。
それを無料で追加した場合、100時間分の作業をどこかで吸収しなければなりません。
その結果、
メンバーの残業が増える
他の機能の開発が遅れる
テスト期間が短くなる
品質が低下する
プロジェクトの利益が減る
といった問題につながる可能性があります。
顧客の要望を断ることがPMの仕事というわけではありません。
重要なのは、影響を整理したうえで、顧客と合意することです。
例えば、
「対応可能ですが、追加で○日必要になります」
「この機能を追加すると、現在のリリース日への影響があります」
「今回のリリースではA機能を優先し、今回の要望は次回リリースにする方法もあります」
といった形です。
この失敗から学べること
PMは「何でもできます」と言う人ではありません。
できること・できないことを整理し、関係者と合意する人です。
顧客との良好な関係を築くことは重要ですが、無理な約束をしてプロジェクトを破綻させてしまっては意味がありません。

失敗談4：問題を上司に報告するのが遅れる

4つ目は、問題を抱えたまま、上司への報告が遅れてしまうことです。
PMとして責任感が強い人ほど、
「自分のプロジェクトだから、自分で何とかしなければ」
と考えてしまいます。
例えば、プロジェクトの進捗が少し遅れているとします。
最初は1日程度の遅れだったので、
「このくらいなら自分たちでリカバリーできる」
と判断します。
ところが、その後も遅れが続き、気がついたときには、
「納期に間に合わないかもしれない」
という状態になってしまいます。
ここで初めて上司に相談すると、選択肢がかなり少なくなっています。
一方、早い段階で、
「現在3日遅れています。現時点では納期への影響はありませんが、このまま進むと影響する可能性があります」
と報告しておけば、メンバーの追加やスケジュール変更など、早めの対策を検討できます。
PMにとって、悪い情報を早く伝えることは非常に重要なスキルです。
問題を報告したら怒られるのではないか、と考えてしまう気持ちは分かります。
しかし、問題が小さいうちなら、解決するための選択肢がたくさんあります。
問題が大きくなってからでは、選択肢が限られてしまいます。
この失敗から学べること
「問題が起きたら報告」ではなく、
「問題になる可能性が見えた時点で共有する」
ことを意識しましょう。
PMは、問題をゼロにする人ではありません。
問題を早期に発見し、被害を小さくする人でもあります。

失敗談5：技術的な問題に深入りしすぎる

最後は、中堅SEが特に注意したい失敗です。
それが、技術的な問題にPM自身が深入りしすぎることです。
中堅SEとして技術経験が豊富な人ほど、
「この障害なら自分が調べたほうが早い」
「この設計なら自分のほうが分かる」
と考えてしまいます。
確かに、その判断が正しいケースもあります。
しかし、PMが技術問題に長時間入り込んでしまうと、その間に別の問題が発生する可能性があります。
例えば、PMが数時間かけてプログラムの原因調査をしている間に、
顧客から問い合わせが来る
スケジュール調整が必要になる
別チームとの問題が発生する
メンバーの作業が止まる
上司への報告が遅れる
といったことが起こります。
PMにとって重要なのは、必ずしも自分が技術問題を解決することではありません。
「誰が調査するのか」
「いつまでに調査するのか」
「影響範囲はどこなのか」
「顧客にはどう説明するのか」
「納期への影響はあるのか」
といった、問題全体を管理することです。
技術に詳しいPMは大きな強みを持っています。
だからこそ、その技術力を「自分で作業するため」だけではなく、「正しい判断をするため」に使うことが重要です。
この失敗から学べること
PMになったら、技術から離れる必要はありません。
むしろ、
「技術を理解したうえで、マネジメントする」
ことが理想です。
ただし、「自分がやったほうが早い」という理由だけで、すべての技術課題を自分で抱えないようにしましょう。

5つの失敗に共通していること

ここまで5つの失敗を紹介しました。
実は、これらには共通点があります。
それは、
「SEとして優秀であること」と「PMとして優秀であること」は、少し違う
ということです。
SEでは、
「自分で問題を解決する」
ことが評価されます。
一方、PMでは、
「チームとして問題を解決できる状態を作る」
ことが重要になります。
SEとして経験を積んできた中堅SEほど、これまでの成功体験があります。
そのため、
「自分でやったほうが早い」
「自分が詳しいから対応しよう」
という考えになりがちです。
しかしPMでは、そこから一歩引いて、
「誰に任せるべきか」
「どのように進めるべきか」
「誰に相談すべきか」
「プロジェクト全体への影響は何か」
を考える必要があります。
この視点を持てるようになることが、SEからPMへステップアップするうえで非常に重要です。

まとめ

今回は、PMとして経験しやすい失敗を5つ紹介しました。
改めて整理すると、以下の5つです。
自分で仕事を抱えすぎる
「順調です」という報告を信じすぎる
顧客の要望を何でも受け入れる
問題を上司に報告するのが遅れる
技術的な問題に深入りしすぎる
PMになると、SE時代とは仕事の進め方が大きく変わります。
特に中堅SEの場合、技術力や開発経験があるからこそ、「自分で解決する」という行動を取りやすくなります。
しかし、PMに求められるのは、自分一人で問題を解決することではありません。
人を動かし、問題を整理し、関係者と合意し、プロジェクト全体を成功に導くことです。
もちろん、すべてを最初から完璧にできるPMはいません。
失敗することもあります。
大切なのは、失敗したときに、
「なぜ起きたのか？」
「次はどうすれば防げるのか？」
を振り返ることです。
そして、PMを目指している中堅SEの方は、今の仕事から少しずつPMの視点を取り入れてみてください。
自分の担当作業だけではなくプロジェクト全体を見る。
問題が起きてからではなく、起きる前に考える。
自分で解決するのではなく、チームで解決する。
この3つを意識するだけでも、PMとしての考え方は大きく変わってきます。
失敗は、PMとして成長するための貴重な経験です。
失敗を恐れるのではなく、失敗から学びながら、少しずつ「SEの視点」から「PMの視点」へ切り替えていきましょう。

関連記事