PMになりたいSEが最初に詰まること──進捗管理より先に見られる調整力

SEとして現場を経験していると、いつかPMを任される側に回るのかもしれない、と考える瞬間がある。

設計書は読める。開発の流れも分かる。課題管理表も見慣れている。進捗会議で話されている内容も、だいたい理解できる。だからPMの仕事も、SEの延長線上にあるように見える。

けれど実際に一歩近づくと、思っていたより難しい。
タスクを並べても、人はその通りには動かない。進捗を聞いても、本当の詰まりは出てこない。技術的に正しい説明をしても、相手が納得して判断してくれるとは限らない。

PMになりたいSEが最初に詰まるのは、進捗管理を知らないからではない。
最初に見られているのは、予定表をきれいに作れるかどうかではなく、利害の違う人たちの間で、物事を前に進められるかどうかだと思う。

進捗管理は、プロジェクトを進める力そのものではない

PMという言葉を聞くと、WBS、進捗管理、課題管理、報告資料、会議運営といったものが先に浮かびやすい。

もちろん、それらは必要だ。プロジェクトの状態を見えるようにしなければ、関係者は判断できない。期限、担当、課題、リスク、変更点を管理する力は、PMの基本に入る。

ただ、ここで誤解しやすいのは、進捗管理をすればプロジェクトが進むわけではない、ということだ。

進捗管理は、進んでいるかどうかを見えるようにする仕事であって、止まっている理由そのものを取り除く仕事ではない。遅れが見えたとしても、なぜ遅れているのか、誰の判断が止まっているのか、どの条件が揃えば前に進めるのかを整理できなければ、管理表はただ赤くなるだけで終わる。

SEの仕事では、比較的はっきりした対象がある。仕様、設計、コード、テスト、障害、問い合わせ。もちろん曖昧なことも多いが、それでも最終的には何かを作る、直す、確認する、説明するという形に落ちる。

一方でPMの仕事は、まだ形になっていないものを扱う時間が増える。
誰が決めるのか分からない。どこまでがスコープなのか曖昧。顧客は早く欲しいと言うが、開発側は品質を気にしている。営業は納期を守りたいが、現
場は前提が崩れていると感じている。

こうした状態の中で、単に正しいことを言うだけでは進まない。
PMに近づくほど必要になるのは、正解を持つ力よりも、違う正解を持っている人たちの間に、合意できる着地点を作る力だ。

技術説明と合意形成は違う

SEとして評価されてきた人は、説明が丁寧だ。
なぜこの仕様になるのか。なぜこの修正が必要なのか。なぜこの設計ではリスクがあるのか。相手に分かるように整理し、根拠を示し、技術的な妥当性を伝えようとする。

これは大事な力だ。PMになっても、技術を理解して説明できることは大きな武器になる。

ただし、技術説明と合意形成は同じではない。
技術説明は、相手に理解してもらうことを目的にする。一方、合意形成は、理解だけでなく、相手が何かを選び、引き受け、次の行動に移れる状態を作ることを目的にする。

たとえば、性能上のリスクがあると説明するだけなら、SEとしてもできる。けれどPMに近づくと、その先を問われる。

そのリスクは今すぐ潰すべきなのか。リリース後対応でもよいのか。追加コストを誰が承認するのか。納期を守る場合、どの品質条件を最低限にするのか。顧客にどの表現で伝えるのか。

ここまで整理しなければ、関係者は動けない。
技術的に正しいことを言っているのに話が進まないとき、原因は説明不足ではなく、判断の形になっていこと。

PMに求められる調整力とは、関係者の機嫌を取ることではなく、判断できる形まで論点を整える力なのだと思う。

調整力とは、間に入って我慢する力ではない

調整力という言葉は、少し誤解されやすい。

現場では、調整力がある人と言われると、何でも引き受ける人、相手に合わせられる人、場を荒らさない人を想像することがある。けれど、PMに必要な調整力をその意味で捉えると、かなり危うい。

ただ間に入って我慢するだけなら、調整役は消耗する。
顧客の要望をそのまま開発に流し、開発の不満を飲み込み、上司には大丈夫そうに報告する。これを続けると、表面上は丸く収まっているように見えても、プロジェクトの中には未処理のひずみが溜まっていく。

本来の調整力は、曖昧なものを曖昧なまま運ばない力だ。
相手の要望を聞いたら、それは希望なのか、必須条件なのか、期限付きの制約なのかを分ける。開発側の懸念が出たら、それは感覚的な不安なのか、実際に発生し得るリスクなのか、どの前提なら許容できるのかを確認する。

上司や顧客に報告するときも、単なる状況共有で終わらせず、判断してほしいことを明確にする。

つまり調整とは、人と人の間をなだめる仕事ではなく、判断に必要な材料を整え、責任を持つべき人に正しく渡す仕事だ。

ここを勘違いすると、PMになりたいSEは便利な中間管理役になってしまう。現場にも顧客にも上司にも合わせているのに、なぜか評価が残らない。

そう感じる人は、調整しているつもりで、実は判断の前処理だけを抱え込んでいる可能性がある。

PM志向のSEが最初に磨くべきこと

PMを目指すなら、最初から大きなプロジェクトを任される必要はない。
むしろ、今のSEの立場でも練習できることは多い。重要なのは、管理表を作る練習よりも、論点を前に進む形に変える練習だと思う。

仕様確認をするときは、単に質問を投げるだけで終わらせない。選択肢を二つか三つに整理し、それぞれの影響を添えて聞く。相手に自由に考えてもらうのではなく、判断できる形にして渡す。

課題を報告するときも、困っていますで止めない。何が止まっているのか、誰の判断が必要なのか、いつまでに決めないと何に影響するのかを添える。報告の目的を、状況共有ではなく意思決定支援に変える。

会議に出るときも、発言量を増やすことだけを目指さない。今日決めること、決めないこと、持ち帰ることを意識して聞く。議論が広がったときに、今は何を決めようとしているのかを戻せる人は、PM候補として見られやすくなる。

SEとして優秀な人は、与えられた論点に対して正確に答えようとする。PMに近づく人は、そもそも今の論点で決められるのか、決めるために何が足りないのかを見ようとする。

この差は小さく見えるが、任される役割を大きく変える。

PMは、人を動かす前に論点を動かしている

PMの仕事を、人を管理する仕事だと捉えると少し重くなる。

人を動かす、チームを引っ張る、関係者をまとめる。そう聞くと、声が大きい人や押しが強い人のほうが向いているように見えるかもしれない。

でも、実際に現場で信頼されるPMは、必ずしも強く押す人ではない。
むしろ、論点を動かせる人だと思う。

曖昧な話を、判断できる単位に分ける。対立している意見の裏にある条件を見つける。相手の発言をそのまま受け取るのではなく、何を守りたいのかを読む。決められない状態を放置せず、決めるために足りない情報を明らかにする。

それができる人は、声を荒げなくてもプロジェクトを前に進められる。
SEとして積み上げてきた経験は、PMになるときに無駄にならない。仕様を読めること、技術の制約を知っていること、現場の苦しさを理解していることは、大きな武器になる。

ただし、その武器を自分の正しさを証明するためだけに使うと、PMとしては伸びにくい。関係者が判断できるように使ったとき、SE経験はPMの信頼に変わっていく。

PMになりたいなら、まず進捗表をうまく作ることだけを目指さなくていい。

今日の会議で、何が決まれば前に進むのか。今の課題は、誰のどんな判断を待っているのか。自分の技術説明は、相手の理解で止まっているのか、それとも次の行動までつながっているのか。

その問いを持てるようになることが、PMへの最初の準備なのだと思う。

あなたが今の現場で任されている仕事は、作業を進めるための仕事でしょうか。それとも、誰かが判断できるように整える仕事でしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

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

＜PR＞

次のキャリアを考えたい方へ。
求人サイトGreenを応援しています。