システム構築のプロジェクトマネジャー（以下、PM）という仕事は、とても価値のある素晴らしいものだ。特にベンダーに所属するPMは、いわばプロのPMである。その仕事はハイエンドのナレッジワークの一つと言ってよいだろう。AI（人工知能）の普及によって、近い将来、多くの職種がAIに取って代わると予測されているが、PMの仕事はそう簡単にはAIに置き換わることはないだろう。
何しろPMがカバーする仕事の領域は広く、仕事をこなすために必要な知識や能力は多岐にわたる。プロジェクトには提案活動から参加。提案活動全体を指揮するのは営業かもしれないが、提案の中身を作る主役はこの商談を受注した場合のPM候補である。
また提案プレゼンも候補が指名されることが多い。そして受注してプロジェクトが開始すれば、文字通りPMとなってプロジェクトを仕切る。要件定義フェーズでは、ユーザーの業務に関して理解しなければならない。設計や開発フェーズでは、ソフトウエアエンジニアリングの知識が必要となる。テストを経て移行、本番稼働へと進む段階では、順調なプロジェクトであってもやるべきこと、留意すべきことは山のようにある。
一般には、プロジェクトの進捗管理やリソース管理、品質管理などがPMの主な仕事と考えられている。だが、PMの最も重要な仕事は、コミュニケーション管理である。利害が異なる多くの関係者のコミュニケーションのハブとなって、意見調整を迅速かつ適切に行う（図1）。関係者とは、まず発注者であるユーザー。このユーザーもシステム部門とエンドユーザーは利害が異なる場合も少なくない。そして自社のベンダー。営業やPMO（Project Management Office）などと衝突することもあるだろう。
プロジェクトがマルチベンダーの場合は、他ベンダーとの調整も発生する。この利害にかかわる意見調整は、理屈や数字だけでなく、人の立場や感情といったアナログ要素も非常に重要なだけに、一筋縄ではいかない。
PMの仕事は付加価値が高いがゆえに、なかなか難しい仕事でもある。だから実際のプロジェクトの現場では、失敗するPMも少なくない。「ダメPM」というのは厳しい言葉だが、現実に失敗するとこう呼ばれてしまう。PMは周囲の期待も大きく、費用も高いので失敗すると容赦なく叩かれる。
プロ野球解説者の野村克也氏の言葉に「勝ちに不思議の勝ちあり、負けに不思議の負けなし」があるが、失敗するPMには必ず理由がある。そこで本記事では、PMとしてダメな理由をいくつかパターン化してみた。他山の石としていただければ幸いである。