PM（プロジェクトマネージャー）は、プロジェクトを推進する上で必要不可欠な存在ですが、職務領域が不明確な場合に、しばしばトラブルを招く存在でもあります。

そのようなトラブルを最小限に抑制、可能であれば事前防止するために、GeNEE社の中のプロジェクトマネージャーの存在意義を明確にしようと考えていたのですが、これがなかなかな難しい。現在時点では、「プロジェクトマネージャーはこうあるべきだ。」と確固たる定義づけができませんでしたので、まずはその前工程として、「プロジェクトマネージャーはこのような行動を取ってはいけない。」といった内容をまとめてみました。

１：開発者に全て任せてしまう。丸投げしてしまう。
開発経験のないプロジェクトマネージャーにありがちなことですが、開発者に嫌われないようにと、全てを任せてしまう、ひどい場合だと丸投げしてしまうことがあります。開発者の主業務は『開発』になります。お客様のビジネスを完全に理解しているわけではありませんし、全てを任せてしまうのは非常に危険な行為と言えます。プロジェクトマネージャーの役割はお客様と開発者の架け橋になることでもあります。受けた情報をしっかりと咀嚼し、プロジェクトに参画するメンバーに適切な方法で共有することが大切です。

２：お客様の言いなりになってしまう。PMとしての意見を言わない。
お客様の気分を害さないようにと、何も意見を言わないプロジェクトマネージャーもいます。お客様はシステムやアプリのプロフェッショナルではないので、誤った判断をされることが多いです。「おっしゃる通りです。」と全て受け入れるのではなく、「●●●のケースを取る場合、将来的に×××といったリスクが発生する可能性がございますが、そちらのリスクを許容してこちらの機能を実装しますか。リスクを回避する策として▲▲▲案もございますが、こちらについて詳しくご説明してもよろしいでしょうか。」というような提案も時には必要です。お客様の発言や判断を客観的に考え、状況によってはしっかりと説得することもプロジェクトマネージャーの重要な役割の一つです。調整を煩わしいと感じ、「我関せず」の顔をするのは、職務怠慢ともいえます。

３：納期（リミット）を意識しない。
一例ですが、お客様側で準備すべきもの（業務フロー表や社内関係者へのヒアリングシートなど、開発会社側では取得が難しいものを指します。）が期日までに揃わなかったとき、「大丈夫ですよ。期限を１週間後ろ倒しにしましょう。」と言い、納期意識が薄いプロジェクトマネージャーも存在します。その場は丸く収まるかもしれません。しかし最終的な納期変更が許されない場合、後工程に控えた開発者、デザイナーなどは非常に困ってしまいます。気遣いで期限やスケジュールを変更してしまうと、最終的にどこかでしわ寄せが来ます。お客様都合で１週間遅れたならその事実を基に再交渉し、最終的な納期も調整する必要があるでしょう。

４：共有ドキュメントを作らない。適切な共有ができない。
最近では、slackやChatworkといったチャットツールでビジネスのやり取りをする機会も増えました。連絡速度は各段に上がりましたが、重要な情報をしっかりと管理し、共有しないとプロジェクトメンバーは古い情報を基に行動してしまう可能性があります。Googleスプレッドシートでも構わないのですが、メンバー内の知識レベルが均一になるように、共有環境を作るのもプロジェクトメンバーの重要な役割の一つです。

５：関連資料を確認せずに関係者に丸投げする。
プロジェクトマネージャーは、開発者とお客様から関連資料を受け取る立場にあります。開発者からは設計書、要件定義書、仕様書などを受け取って確認します。お客様からは要望書や提案書などを受け取ります。関連資料を受け取った際、そのファイルを一度も開くことなく、右から左に横流しするプロジェクトマネージャーもいます。これは非常に危険な行為です。開発者から上がってきた成果物に対しては、要件をしっかりと満たしているか、ミスがないか、抜け漏れがないか、を確認する必要がありますし、お客様からいただいた資料は、不明確な部分がないか、開発者がスムーズに作業に入れるか、などの観点でチェックをする必要があります。場合によっては、資料作成者に質問し、疑問点をつぶさなければなりません。

６：利己的な判断をしてしまう。
お客様と開発者の架け橋となるプロジェクトマネージャーは、時にその両者の職域にまで踏み込む必要があります。一例ですが、ライティングコンテンツをお客様側で準備する場合、コンテンツ管理を可能な範囲でしてあげたり、情報収集に役立つ情報やツールを提供したりすることで、プロジェクトが円滑に進むことがあります。反対に、「それはプロジェクトマネージャーの職域にはない仕事です。」と他人事のように割り切ってしまうと、お客様側のスキルや特性に全てを委ねることになり、スケジュールや品質が大きくブレるリスクになりかねません。請け負える範囲には限界があるかと思いますが、可能な範囲で職務領域を広げることで、プロジェクト全体にポジティブな影響を与えることが多々あります。

７：技術系の話を避ける。
技術の話になると、下を向いてしまうプロジェクトマネージャーもいます。法人営業のスタッフならまだしも、プロジェクトマネージャーを名乗る人間としては感心ができない話です。技術の話にも興味を持ち、状況によっては、その技術を深堀りして調べることもプロジェクトマネージャーの重要な役割です。システムやモバイルアプリというITサービスを扱っている以上、技術についても前向きに習得する、習得したいといった姿勢が必要です。

８：メールの返事が遅い。返事をしない。
大規模プロジェクトを牽引するプロジェクトマネージャーのもとには毎日大量のメールが届きます。お客様、開発者、関係会社、BPと呼ばれるビジネスパートナー、ベンダーなど、案件の規模が大きくなればなるほどその量は比例して増えていきます。メールが届いた際、急ぎか急ぎでないかを峻別する能力も勿論大切ですが、これはある程度の経験が必要です。ここでお伝えしたいことは、メールが届いているのに、返事をしなかったり、２，３日後に返事をするプロジェクトマネージャーは問題意識を持ってください、ということです。プロジェクトマネージャーがすぐに返信しないことで、開発者が本来対応すべきでない作業を始めてしまったり、お客様の意思決定を遅らせてしまう可能性があるのです。