Greenでプロジェクトマネージャーを採る｜受託と自社開発で変わる要件

プロジェクトマネージャーの求人で、「PM経験〇年以上」「チームマネジメント経験」と書いただけでは、候補者は自分に合う求人かどうかを判断できません。同じプロジェクトマネージャーでも、受託開発と自社開発では、相手にする人も、守るべきものも違うからです。受託では顧客との約束を守ることが中心になり、自社開発では社内の優先順位を調整することが中心になります。この記事では、Greenでプロジェクトマネージャーを採るときに、この違いを踏まえて要件をどう書き分けるかを整理します。Greenは、株式会社アトラエが手がける中途採用の求人サイトで、IT・Web業界の職種を中心に扱っています。

受託と自社開発で、PMの仕事はどう違うか

まず、二つの環境でPMが向き合うものを並べます。

候補者もこの違いを分かっています。受託で経験を積んだPMが自社開発に移りたいと考える理由は、「作ったものの、その後を見たい」「顧客の要望ではなく、自分たちで優先順位を決めたい」といったものが多くあります。逆に、自社開発のPMが受託に移りたい理由は、「さまざまな業界の案件に関わりたい」「プロジェクトの区切りがはっきりしているほうが合う」などです。

受託開発の会社が書くべきこと

受託開発の会社がPMを採るときは、次の点を求人票に書くと、候補者が働く姿を想像しやすくなります。

• 案件の規模と期間：小さな案件を並行するのか、大きな案件を長く担うのか
• 顧客の業界：特定の業界に寄っているのか、幅広いのか
• 契約の形：請負が中心か、準委任が中心か。見積もりにどこまで関わるか
• 体制：社内のエンジニアで組むのか、協力会社と組むのか

特に、見積もりと提案にPMがどこまで関わるかは、候補者が重視する点です。営業が受注した案件を引き継ぐだけなのか、提案の段階から入るのかで、仕事の手応えが大きく変わります。

自社開発の会社が書くべきこと

自社開発の会社がPMを採るときは、プロダクトマネージャーとの境目を明確にします。「何を作るか」を決めるのがプロダクトマネージャー、「決めたものをどう作り切るか」を担うのがプロジェクトマネージャー、という分け方をしている会社が多いですが、規模によっては一人が両方を担います。

• プロダクトマネージャーとの分担：仕様を決める人は誰か、PMはどこから関わるか
• 開発の進め方：短い周期で回しているのか、まとまった単位で計画するのか
• 関わる部署：営業やカスタマーサクセスからの要望を誰が受けるか

この分担が曖昧なままだと、候補者は「何でも屋として期待されているのでは」と不安を持ちます。プロダクトマネージャーの採用についてはGreenでプロダクトマネージャーを採るで別に整理しています。

エージェントベストの見解

受託開発の会社が「自社開発の経験者」を、自社開発の会社が「受託のPM経験者」を求める相談を受けることがあります。違う環境の経験が新しい視点をもたらすという期待です。それ自体は理にかなっていますが、求人票に書くべきは「違う環境から来た人に、最初の数か月で何に慣れてもらうか」です。受託出身のPMが自社開発に入ると、明確な契約の範囲がない中で優先順位を決めることに戸惑います。自社開発出身のPMが受託に入ると、顧客との合意を文書で積み上げる作法に戸惑います。この戸惑いを見越して、最初の担当案件や相談相手を決めておくと、候補者にも安心して応募してもらえます。異なる経験を歓迎すると書くなら、受け入れの段取りもセットで示すことを勧めています。

候補者への声のかけ方

PMの候補者に対しても、Greenの「気になる」とスカウトを使えば、企業の側から声をかけられます。PMの候補者は、職務経歴の書き方から、どの環境で経験を積んだかを読み取れることが多いです。

1. 同じ環境の経験者：受託なら受託、自社開発なら自社開発の経験者。案件の規模や業界が近い人を優先する
2. 環境を移りたい人：経歴の中で、移りたい理由が読み取れる人。スカウト文面では「なぜ環境を変える人に声をかけたか」を書く
3. エンジニアからPMに移りたい人：リーダー経験があり、マネジメントに関心がある人。育成の体制を示す

「気になる」は、環境を移りたい人や、エンジニアからの転身を考えている人に向いた接点です。経歴だけでは移る意思が読み取れない相手に、まず軽く関心を示し、反応があった人に詳しい文面を送ると、互いの時間を無駄にしにくくなります。

スカウトの文面では、担当してもらう予定の案件やプロダクトを、守秘の範囲で具体的に書きます。「どんな案件を任されるのか」が分からないままでは、PMの候補者は返信の判断ができません。

選考でPMの力を見るときの問い

PMの選考では、過去のプロジェクトの成功談より、難しい局面をどう乗り越えたかを聞くと、その人の進め方が見えます。

• 納期に間に合わないと分かったとき、誰に何を伝え、何を決めたか
• 顧客や社内の要望が対立したとき、どう優先順位をつけたか
• チームの誰かが手一杯になったとき、どう気づき、どう対処したか

あわせて、進捗の見える化の方法も聞きます。どんな道具を使っていたかより、「遅れの兆しに、いつ、どうやって気づいたか」を聞くと、その人の管理の細かさが分かります。週次の報告で気づいたのか、日々の会話で気づいたのか、メンバーから相談されて気づいたのか。気づくのが早い人ほど、打てる手の数が多くなります。

受託と自社開発で、答えの中身が違うのは当然です。面接官は、自社の環境に置き換えたときに同じ考え方が通用するかどうかを見ます。

エージェントベストの見解

Greenで求人を出してから最初の一か月で、PMの採用が止まる会社によく見られるのは、面接官が決まっていないことです。応募が来てから「誰が会うか」を決めようとすると、現場のPMや開発責任者の予定が合わず、一次面接まで日数が空きます。PMの候補者は在職中で、今のプロジェクトを抱えていることが多いため、選考の動きが遅い会社には次第に関心を失います。当社が運用を代行するときは、求人を公開する前に、一次面接を担当する人と、面接に使える曜日と時間帯を決めておきます。応募があった当日に候補日を返せる状態にしておくと、候補者の受け止め方が変わります。

まとめ

• 受託開発と自社開発では、PMが向き合う相手と守るものが違う
• 受託の会社は、案件の規模・業界・契約の形・見積もりへの関わりを書く
• 自社開発の会社は、プロダクトマネージャーとの分担を明確にする
• 異なる環境の経験者を求めるなら、受け入れの段取りもセットで示す
• 一次面接の担当者と時間帯を、求人公開の前に決めておく

よくある質問

PMの経験年数は条件に入れたほうがよいですか

年数だけで絞ると、短い期間に密度の高い経験をした人が外れてしまいます。「〇人規模のチームで、〇か月以上のプロジェクトを担った経験」のように、規模と期間を合わせて書くと、候補者が自分で判断しやすくなります。

エンジニア経験のないPMでも問題ありませんか

会社の求めるものによります。技術的な判断を自分で行うことを求めるならエンジニア経験は重要ですが、顧客との調整や進行の管理が中心なら、経験がなくても務まる場合があります。どちらを求めるかを求人票に書いておきます。

PMの採用は紹介とGreenのどちらが向いていますか

担当してもらう案件やプロダクトを求人票で具体的に書ける場合は、Greenのような求人型でも候補者が判断して応募してきます。部門の責任者として組織づくりまで任せたい場合は、背景を説明しながら会える紹介を併用する方法もあります。