「パパってどんな仕事してるの？」って娘に聞かれて、説明に困ります。
プロジェクトマネージャーと言っても当然伝わらないし、システム開発といってもわからない、プログラミングならわかるけど、プログラミングしないし。そんな私の仕事は、システム開発のプロジェクトマネージャーです。
PMOではなくて、プロのPMです。

私の生業

要請があれば、一人でプロジェクトに乗り込んでいって、PMポジションを担います。
SIerの社員からすると想像が付かないと思いますが、実際に、このような形で様々なプロジェクトを渡り歩いています。支援の要請は、問題が起こっている、あるいは既に炎上している状況で、対策を打っても改善されずに困り果てているプロジェクトが多く、それなりのフィーにもなるので、それなりの規模で、クライアントも大企業がほとんどです。支援の要請は、クライアントとプライムベンダーの両方がありますが、どちらの場合でも契約はベンダーと締結して、これまで推進していたPMに代わって指揮をとります。当然QCDの全てに責任を持つため、クライアントフェーシング、計画の見直し、体制の変更、ベンダーの収支構造まで開示して頂き黒字化にも責任を負います。収支に責任を負うと言っても、ベンダーの社員ではないので、収支を考慮した改善策をベンダーのマネジメントに提案し、承認を得た上で進めることは当然です。ベンダーからの要請の場合には、ベンダー社員のPM育成もサブミッションとして同時に行うこともありますし、人材が不足している場合には、プライムベンダーの社員はほぼいなくて、協力会社のエンジニアで固めた体制で推進することもあります。もはや何のためのプライムベンダーかという疑問はさておき、様々な関係性で、このような状況は実際にあります。

最近、コロナの影響により完全リモートで、1年と少しのあいだ顔も見たことも会ったこともない人達と毎日web会議を繰り返し、プロジェクトを推進し、無事にリリースしました。実際に会って話した方が良い場面も当然ありますが、数百人月程度のシステム開発プロジェクトであれば、フルリモートで成立することを立証しています。

PM不要論

システム開発の提案で「なんで管理費用がそんなに必要なの？」「どうしてPMの単価がそんなに高いの？」と言ってくるクライアントがいます。
何も問題が起きなければ、起きても何もしなくても良ければ、PMは必要ありません。クライアントが自分たちで対処できるのであれば、エンジニアだけ派遣して自由に使ってもらう方が費用も安いと真面目にそう思います。ベンダーとしても、指示書を受け取って、その通りに作ることだけを請け負う方がリスクは少ないので安心です。

PMはシステム開発のセット商品でもなければ、自賠責保険のような必須の決まりでもありません。
PMがプログラマーの延長線上と思われている節がありますが、パーツだけを作るのと、いくつものパーツを組み合わせて一つの製品を作るのでは、求められる知識も経験もスキルも全然違います。システム開発を請け負うというのは、一つの製品としてシステムを作り上げることにコミットすることです。そのためには、どのようなパーツが必要で、どう組み合わせたらよいか、各パーツの品質をどのように保ち、どういう順番で組み立てていくか、その計画を立て、作ることのできる要員を集め、メンバーの体調をも気にしながら品質と進捗を担保して進めていかなければなりません。
これがPMの役割です。これをクライアントが担うことができるならPMは不要ですし、このような働きをしない人はPMとは言えません。

いまや炎上の責任は経営層にまで及ぶ

ビジネスの競争力をあげる手段としてシステムの重要性は、以前よりも高まっているように感じます。一方でビジネスサイドの経営層にとっては、「なぜシステム開発にこんなに金がかかるのか」と、いまだに不可解な事として認識されています。数十億、数年間かけても完成する見込みもなく、まったく計画通りに進まないシステム開発プロジェクトがあれば、叱責したくなるのも当然です。マネジメント圧力に屈して突貫で作ってしまった結果、重大な問題が起きると、結果として経営層にその責任は跳ね返ってきて、先般のみずほ銀行の問題では、頭取解任に至る事態になっています。

システムの重要性も問題が起こった時の責任も大きくなっているにも関わらず、いまだにクライアント企業の中でのIT部門の立場は弱く、それに準ずるようにベンダー叩きが行われていることが悲しいです。ベンダーを叩いたところで、問題が解決するわけではないし、叩くくらいならベンダーを変えることを考えた方が良いですし、事情があって変えられないのであれば、叩くのではなく、一緒に対応を考えることに力を注いだ方が解決は早いと思います。

怪我を治すのは医者

炎上プロジェクトを立て直すPMは、例えるなら、医者です。
怪我をしても、免疫力を信じて自力で治す人もいるかもしれませんが、大怪我の場合には、病院に頼り、医者に診てもらわないと回復は難しいでしょう。

怪我を治すのが医者の仕事であるように、炎上プロジェクトを立て直すのは、プロのPMです。怪我をしたプロジェクトを自力で再建することは難しく、あるいは時間がかかります。仮に回復しても、その後、季節の変わり目や雨の日にシクシク痛むような不都合を残すことにもなります。
内科医に外科的手術は求めませんし、足を怪我して耳鼻科へ行く人もいません。

頑なに一人のPMに全ての処置を頼ることは、一般的に考えても得策ではないのです。問題があれば、その対応方法を考える前に、対処に適した人を見つけるべきと思います。

PMの主たる仕事

プロジェクトマネージャーの仕事を教科書的に書くと誰でも簡単に出来てしまうように思えるので、役割として重要だと考えていることを挙げます。
それは、”道筋”、”回避”、”自走”の３つです。

① 道筋をつける
完成するまでに、どのような工程が必要で、どの順序で進め、期間はどれくらい必要かといった道筋、つまり計画を立てることが、最も重要な役割です。

炎上プロジェクトのほとんどは、杜撰な計画が原因です。出鱈目な道筋でゴールに辿り着けと言われたら迷子になるか、崖に出くわすか、食料が尽きて飢え死にします。予定通りどころか、いつまで経ってもゴールに辿り着けない可能性すらあります。
炎上するプロジェクトの多くは、スタート時点で、この杜撰な計画に誰も気が付いていません。能力を評価せずに、たまたま空いていた社員をPMに据えるベンダーにも責任はありますが、ベンダーが提案してきた計画の杜撰さに気が付けないクライアントにも問題はあります。信頼関係で馴染のベンダーに発注して、問題を起こすと責め立てる。責めたところで時は戻せません。

綿密に選定したベンダーを信じることも必要ですが、クリティカルなプロジェクトであれば、セカンドオピニオンとして利害のない第三者による計画レビューを依頼することも時には必要だと思います。それほどプロジェクトの道筋となる計画は重要です。

② 問題を起こさせない
いくら道筋を立てても、いざ旅に出れば、状況は日々刻々と変化します。急に天候が悪化することもあれば、熊に出会うかもしれません、頼みの綱のスマホやラジオが壊れるかもしれません。一方で、進むにつれて体力はついていき、経験値も増え、日々の食事の用意は効率的になっていきます。

最初につけた道筋はあくまで道です。その道をどう進むかは、その時々の状況によって、これまでの歩みで得た経験によって、変えていくべきです。それこそが問題を回避することになるのです。問題が起きた時の対策として引き出しの多さもPMにとっての武器となりますが、先を予測し、起こりそうな問題を未然に回避し、臨機応変に見通しを立て直すことの方がはるかに重要です。

プロジェクトで問題が起きないのは、たまたまか、問題を隠しているか、PMが上手くやっているか、のどれかです。

③ チームを自走させる
システム開発は、ラインをコンピューター制御すれば、品質を担保したパーツを勝手に量産し、ロボットが組み立ててくれるというものではありません。ライン化やロボット化の志向も必要ですが、個々のエンジニアが補助なく自力で高品質に生産作業をできるようになることが大事です。いちいち個々人に詳細を手解きしていたら進むものも進まず、意図を捉え違えただけで停滞します。

言われたことだけやるような人の集まりでは、時間も労力もかかるため、大規模になればなるほど、この自走させることが重要になってきます。

責任感をもってもらうためには？

自走させるためには、個々人に責任感を持ってもらうしかありません。
多少哲学的ですが「自由と責任」という言葉そのもので、役割を明確にしつつも、ある程度自由にすることで責任を感じるようになります。
各自が責任を持ち、自走できるようになってくると信頼できるメンバーの目星がつき、信頼できるメンバーが増えれば増えるほど、PMにとっては管理のゆとりを生み、やりくりの幅が広がります。

“イノベーションオブライフ”にも書かれている「自由と責任⇄命令と管理」の通りで、命令すると管理されていると感じ、責任感は減退してしまいます。
この自由と命令のバランスが非常に難しくも、PMに求められる能力だと思います。

仕事に自信がもてない人

ちょっと脱線しますが、自由にやってもらおうと思っていても、仕事に自信が持てないと言う人がいます。
以前、このように言われても、ピンときませんでしたが、ある時、息子と話をしていて、ふと気が付きました。自信がないというのは、不安ってことなのかと。これが正しいかわかりませんが、不安は準備不足から来るので、自信が持てない人は、準備が足りていない、それは経験かもしれないし、練習量かもしれませんが、不安を抱えていると考えると、少しわかるような気がします。

会議に何も考えずに参加する人が多いと感じています。
それなりの相手と、それなりにシビアな交渉をする場だったら、当然、頭の中ででも想定問答を事前に考えていくと思うのですが、常日頃の会議でこの準備は必要です。多くの人が全くといっていいほど準備をしないで会議に挑み、質問に対する答えの言葉が出てこない、期待した結論が得られない、その繰り返しによって自信をなくしてしまうのではないでしょうか。
仕事に自信が持てない人は、自信がないからうまくいかないのではなく、準備が足りないのかもしれません。

自走させるためには、クライアントとのコミュニケーションも率先して行ってもらわないといけません。その準備は、内部レビューです。クライアントへの説明のリハーサルとして内部レビューを繰り返すことで、自信を得ます。そのためには、内部レビューでクライアントと同等以上の観点で指摘できないといけません。その教育もPMに求められる役割です。

これまで見てきた失敗プロジェクトのPMたち

炎上プロジェクトの立て直しで参画して思うことが、なぜPMの能力を評価しないで任せたのか。酷い時には、小学生に東大の入試問題を解けと言っているくらいPM能力とプロジェクト内容にギャップを感じる時があります。
とはいえ能力は鍛えれば、なんとかなるとは思いますが、性格はなかなか変わらないと、実体験として感じています。転職などの会社選びでもミスマッチということを聞きますが、プロジェクトとPMもミスマッチは有ります。プロジェクトの特性に合っていない性格のPMはリスクとなるため、本来、能力と性格の両面でPMを選定するべきと思います。
これまでの失敗プロジェクトで出会ったPMの特徴を紹介します。

・断れない人
何を言いたいのか、わからない。優しい雰囲気でふんわりと伝えたいのか、明確に断ることが出来ないのか、何やらごにょごにょと言っています。クライアントが日本人の得意とする行間を読む能力によって理解していれば良いと思ってしまいますが、ごにょごにょスタイルで進めてきた結果、蓋を開けてみたら、とんでもないことになっていることは多々あります。決まったことなのか決まっていないのかはっきりしない、開発側はやらなくて良いと思っていたら、クライアントはやってくれると思っていたなど。言い方はさておき、物事をはっきりと言えない人、特に断れない人は、クライアントとの関係性が良ければ良いほど危険です。クライアントが優しい人の場合は、共倒れする可能性があります。

・格好つける人
ステコミなど大きな会議でのクライアントからの問いに対して、中身を知りもせずに「大丈夫です」、現場に確認を取っていないのに「やります」と言ってしまう人。酷いと、やってもいないのに「やりました」と、言った後から何とかしようと考えているのかもしれませんが、その時点では、確実に嘘です。この人は、立場が上の人に良いところを見せようと、格好つけてしまう性格です。
素直に自分を出せない、正直に事実を言えない人がPMだと、現場が苦労することは間違いありません。クライアントが「言ったよね」で杓子定規に選別する人の場合は、後片付けが大変です。

・優柔不断な人
なかなか決められない。開発者から判断を求められても「どうしましょうか？」と逆に返してしまう。クライアントからのリクエストに対しても「いったん持ち帰って考えさせてください」と毎度この返事。結局、持ち帰ったところで結論は全然出ない。フォロワーシップ型で良い面もあり、プライベートであれば可愛げもありますが、PMという職においては危険です。一つの遅れは次の問題を引き起こし、次々と問題が勃発する状況になってしまって、間違いなく事態を悪化させます。判断の遅れや先延ばしは、後になればなるほど苦しくなるため、この人にタイトなスケジュールのプロジェクトや上流工程を任せては危険です。

・自分目線で考える人
他人を思うことが出来ない、しない人です。レビュー会では、まるで台本を読んでいるかのように終始説明のみで、ユーザーからの問いに対しても自分の言うと決めたことを言うだけ。報告会での指摘に対しても、感想を述べてしまうような、相手の求めていることに全く返さない人です。
この性格の人とは、質問と回答の応酬で、なかなか噛み合わず、会話や会議が長くなるため、遅延のリスクが高いです。
クライアントの機微を感じ取れないと後手後手の対応となりますし、開発エンジニアにも気を配れないと急に離脱者を出したりする可能性もあり、プロジェクトへの影響は大きいです。
他人にエネルギーを注げない性格の人は、開発チームが自爆するか、クライアントにチェンジを言われてしまう可能性があります。

まとめ

これまでに幾つものプロジェクトでPMをやってきましたが、プロジェクトが成功した時は、「プロジェクトがうまくいって良かった」「みんな頑張ったね」という感じの祝賀会で、特段PMとして評価されることは少ないです。優秀なプロジェクトマネージャーは、緻密な計画をたて、先を読み問題を回避し、即断即決でパワフルに進めていくため、遠目で見ているクライアントやマネジメントには凄さがわかりません。実際にPMを経験した者が一緒に時間を過ごせば分かるかもしれませんが、PMは基本一人なので、直接的に比較することも出来ず、評価されることは少ないのです。
誰も褒めてくれないかもしれませんが、プロジェクトが予定通りQCDを守って完遂できたのは、PMの力量だと、私は思っています。
プロジェクトを成功させた時はメンバーのお蔭、問題を起こせばPMの責任。PMとは、そんな仕事なのかもしれません。

イラスト①：PMの主たる仕事

イラスト②：失敗プロジェクトのPMたち

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！