見出し画像

プロジェクトマネージャしかできない仕事って、交渉だと思う。

この仕事だけはPjMがやらないといけないってのを一つあげるとしたら「交渉」だと考えている。他にもあげるなら、決断、政治、土下座かしら。
大抵の仕事は他のポジションの人がやっても問題ない。しかし、決算発表の会見を社長がするように、プロジェクトにおける交渉はPjMがしなければいけない。

交渉といっても多岐にわたる。納期、成果物、メンバーのアサイン、社内の予算、キリがない。ここでは顧客と社内上層部について書こう。

僕の愛するデスマーチの3章には交渉についての悲しい事実が列挙されている。中でも好きな一文だ。

デスマーチ・プロジェクトのマネージャーが、会社上層部と予算やスケジュール、開発リソースの交渉をする場合、結果は簡単に予測できる。プロジェクト・マネージャーが負ける。不可避だ。

デスマーチより

そして、こう続く。

これより少し合理的な交渉が、完成予定日の1、2ヶ月前に持てることがある。この時期は最初のプロジェクト・マネージャーが辞めるかクビになった後であり、新人のマネージャーが、元の日程や予算、開発する機能の量が現実的ではないことをプロジェクトの全員に認識させるときである。

デスマーチより

夢も希望もない。
しかし非情だが有効な手段だと個人的には思っている。「あいつは飛びました。プロジェクトはぐちゃぐちゃなので、仕切り直しましょう」って。

だが、これではあまりにも辛いので、そうなる前に対処したほうがよい。

当初の想定通りに進むプロジェクトは少ない、大抵の場合は何かしらの問題が発生し、ステークホルダーたちと交渉する必要が生じる。
システム開発で揉める要素は、納期、機能、予算、だいたいこのうちのどれかだ。この中で動かすことのできないものを見定めて、その他の要素について交渉をしなければいけない。こんな感じの話をしてみよう。

「システムが、9月1日ではなく、9月5日に完成するとしたら9月2日に倒産を宣言するのですか?」
「うちのメンバーは、良くて、速くて、安いものを作ろうと考えています。でも、会社の提示した条件では三つのうち、二つしか実現できません。どの二つにしますか?」

デスマーチより

本当に守らなければいけないものは少ない。交渉の余地はある。
だが、顧客や社内の上層部はプロジェクトマネージャーの申し出に猛烈に反対するだろう。だから、その要因を厳守できなかった場合、どのような問題が生じるかを明らかにする必要がある。

それぞれの要素について根気よく話を聞く。決して反論などしてはいけない。
最初は「このままでは予算が達成できない」「課の評価が下がる」みたいな皆のためにみたいな話が出るだろが、そのうち「私のメンツが潰れる」「誰々が怒る」「社内での立場が悪くなる」といった担当者の私的なものが紛れ込んでいることに気がつくだろう。

そこが交渉のポイントだ。泥を被ってもらおう。どんなに偉い立場の人でも関係ない。担当者の圧力に屈してしまったらプロジェクトは成功しないし、それ以上にプロジェクトメンバーが不幸な目に遭うことになる。

デスマーチの言葉を引用する。

一方、プロジェクト・チームのメンバーは、自分の身内だ。プロジェクトのメンバーに対し、倫理観や職業意識を持って接する以前に、マネージャーはメンバーを「擁護」する義務があり、何も知らずに政治構想の犠牲になることは何としても避けねばならない。

デスマーチより

SEを極めるって本の中に「退職願を常に持ち歩いて仕事をする」みたいな話が出てきたが、まさにこの覚悟を持って交渉に臨む必要がある。
僕自身いつクビになってもいいと思って仕事をしている。もちろん嫌だし、困るし、弊社はそんな会社ではないが、僕個人の性格の話だ。

自身の立場を顧みず、交渉の席に立ち、プロジェクトの成功とチームを守らなければいけない。それはPjMしかできない仕事だと、僕は思う。

夢も希望もない話になってしまった。
前にも書いたけど、嫌われるのも大切な仕事だ。

交渉が必要な局面になってしまった以上、放っておいても好転することはない。緩やかなプロジェクトの死を待つことはPjMの責務違反だ。このことを忘れてはいけない。



この記事は「プロジェクトマネジメントとか組織作りとか Advent Calendar 2022」の12月9日分として書きました。僕が普段考えていることを言語化しています。


この記事が気に入ったらサポートをしてみませんか?