【スキルなし】ダメなPMが仕切ったらプロジェクトがこうなった【無能】

フリーランスのエンジニアをやってます。

エンジニアなら誰しも、一度は、

「このPM（プロジェクトマネージャー）、必要ないのでは…」

と思った事があるはずです。

毒にも薬にもならないPMなら、まだマシです。

まれに、プロジェクトにマイナス影響を与えるPMも存在しています。

 

私が開発現場で出会った、ダメなPMの特徴は、次の通りです。

 

ダメなPMに当たってしまったら、プロジェクトはどうなるのか？

書いていこうと思います。

 

タスク管理が複数ある

redmineやbacklog…

システム開発の現場では、プロジェクトやタスクを管理するツールが導入されています。

その管理ツールをもとに、進捗状況を把握し、適宜リソースの調整などを行います。

 

管理ツールは、プロジェクトメンバー内で共有される情報なので、

使いやすさを考慮すれば、一元管理されているのが通常です。

 

複数の管理ツールを使っている開発プロジェクトは、要注意です。

私の体験談ですが、以前、参画した現場では、1つの開発プロジェクトに対して、なぜか、4つの管理ツールが使われていました。

• backlog
• jira
• google spreadsheet
• excel

の4つの管理ツールが使われていました。

これら4つの管理ツールに、それぞれ、同じタスクを登録して管理が行なっていました。

 

これは、タスク管理が非常に煩雑になる問題点があります。

煩雑ゆえに、プロジェクトが進むにつれ、次第に、タスクの管理ができなくなっていきます。

 

たとえば、

「WebアプリケーションのバグAを改修する」

というタスクが発生したとします。

これを対処する為に、

 

• backlog

「WebアプリケーションのバグAを改修する」

• jira

「WebアプリケーションのバグAを改修する」

• google spreadsheet

「WebアプリケーションのバグAを改修する」

• excel

「WebアプリケーションのバグAを改修する」

 

とそれぞれ、同じタスクを起票することになります。

で、それぞれに、管理IDを振るわけなので、

 

• backlog

ID: 1 「WebアプリケーションのバグAを改修する」

• jira

ID: 8 「WebアプリケーションのバグAを改修する」

• google spreadsheet

ID: 21 「WebアプリケーションのバグAを改修する」

• excel

ID: 55 「WebアプリケーションのバグAを改修する」

 

という具合になります。

 

すると、定例の時、

「backlog 管理ID 1 で、jira 管理ID 8 で、spreadsheet 管理ID 21 で、excel 管理ID 55 の『WebアプリケーションのバグAを改修する』というタスクを現在、対応しています」

と、報告することになります。

 

ちなみに、PMの方針でこうなりました。

それとなく、複数の管理ツールを使う理由を、PMに聞いてみました。

その理由は、

「一つの管理ツールに障害が発生しても他の管理ツールが生きているだろ」

的なことを言われました。

もしかしたら、デュアルシステム的なことをイメージしているのかもしれませんが、

この回答も意味不明です。

backlog、jira、spreadsheet、excel の管理ツール間で同期を取っているわけでもないですし。

 

それで、この案件。

最終的には、管理するべきタスクが、ぐちゃぐちゃになっていきました。

 

backlogにあるタスクが、jiraに起票していない、とか。

プロジェクトメンバー総出で、何日もかけて、管理ツールにタスクを打ち込む作業も発生しました。

全員が、管理ツールにタスクを打ち込むのが、仕事になってしまい、肝心の、システム開発のタスクが消化できなくなりました。

「我々は、一体、何をやっているんだ…」

そう思いますよね。

結果、管理ツールを捨てて、各々が、本来の作業に戻りました。

気づくと、PMが、いつの間にか、消えていました。

 

無駄なコミュニケーションが多過ぎる

報連相やコミュニケーション能力は、大事とよく聞きますが、これを勘違いしているPMも少なくありません。

「コミュニケーションを取る = 仕事をしている」と誤解しているPMです。

こうしたPMに当たると、無駄なミーティングやチャットなどでのやり取りが増えます。

 

ミーティングが異常に多い

デイリーミーティングや定例と称して、一日に何度もミーティングに駆り出される現場があります。

そして、そうしたミーティングは、だいたい、必要のないものです。

無駄な会議と聞くと、オンサイトでの仕事を想像させますが、リモート案件でも多からず出くわします。

大抵は、管理しているPMに問題があります。

 

朝礼で今日やるタスクを共有。

その後、一日中、会議に駆り出され、日が暮れる。

終礼で、作業報告。

振り返ると、今日やったことは、無駄な会議に参加していただけで、やるべきタスクが何一つ終わっていない。

 

（ダメな）PMにとっては、会議をすることで、仕事をしていると勘違いしているのかもしれませんが、エンジニアにとっては、単なる迷惑です。

実質、PMがエンジニアの邪魔をしているのです。

 

slack（チャット）の使い方に問題がある

無駄なミーティング、同様です。

ダメなPMは、よくチャットを打ちます。

しかも、頻繁に、かつ、長文で。

 

エンジニアは、チャットを受信するたびに、思考と作業の手が止められます。

 

私が以前、参画した案件ですが、

常時、PMが私にslackを送りつけてくるので、私も、それの返信を余儀なくされ、気づくと、一日中、slackを打つことしかやっていなかった…なんて経験をしたことがあります。

 

当のPMにとっては、

「slackの送信 = 仕事をしている」

ひいては

「slackの送信回数が多い人 = たくさんの仕事をしている人」

と思っているようでした。

エンジニアにとっては、単なる、PMの嫌がらせですけどね。

 

PM自身が、自分が何をやっているか理解できていない

PMは、必ずしも、開発経験を必要としません。

そう、よく言われますよね。

とはいえ、最低限の、開発プロジェクトの管理能力は、必要なのですが、ごくたまに、開発に関して完全無知なPMがいます。

これは、経験の乏しいPMで、見られます。

PMOを取得しているか否かに関係はありません。

 

こういった、無知なPMと関わると、エンジニアやクライアントは、苦労します。

 

以前、参画した案件ですが、

クライアントと開発プロジェクトのメンバー、全員、理解している内容を、PMだけが、分かっていない、という状況がありました。

slackやミーティングなどでの、議論の間に、この無知PMが入ると、クライアントも、エンジニアも、みんな、混乱するのです。

当の本人自身（PM）は、場をコントロールしているつもりでいる、らしいのですが。。

何も理解できていないので、黙っていてくれれば、いいのですが、PMゆえに、前のめりで、話の中に入ってきます。

そして、まとまろうとしていた、議論がぐちゃぐちゃになります。

それを繰り返します。

 

この手のプロジェクトでは、

• 無知PMを教育する
• 無知PMを無視する

のいずれかの対応が必要になります。

大抵は、後者の「無知PMを無視する」の選択が取られます。

 

このプロジェクトの場合は、ミーティングのたび、無知PMが、場を掻き回すので、最終的に、クライアントがキレてしまいました。

それで、無知PMが、どうなったのかと言うと、余計なことは、一切言わなくなり、「（エンジニアとクライアントに向かって）ほら、しゃべって、しゃべって」としか、言わなくなりました。

 

「ほら、しゃべって」しか言わない存在。

これなら、PMなんて、要らないのでは、、

そう、思われても不思議ではないですよね。

 

【まとめ】優秀なPMとは

それは、単純に、プロジェクトの邪魔をしない人なのではないでしょうか。

ダメなPMの反対のことをすればいいのです。

 

 

これって、ごく普通のPMですね。

普通でないPMに、ご注意ください。