プロジェクトマネージャーの採用要件の作り方｜必須と歓迎を分ける基準

プロジェクトマネージャーの求人票の必須要件には、「大規模プロジェクトの管理経験」「プロジェクト管理の資格」「技術の理解」「予算管理の経験」「複数の委託先の管理」「経験十年以上」が並びがちです。全部を満たす人は、大規模の受託型で長く働いてきた人で、小規模の社内型のプロジェクトには合わないか、市場にいても条件が高い。結論を先に書くと、プロジェクトマネージャーの採用要件は、先に自社のプロジェクトの型（受託か社内か）・規模・権限を決め、必須を「入社初日に自社のプロジェクトを回す業務が成り立つか」で三つ以内に絞り、資格・経験年数・規模の大きさは必須にせず、経験の中身（回したプロジェクトの型と規模、調整した関係者、立て直しの有無）で書くと、自社に合う母集団が生まれます。型と規模を決めずに要件を積むと、「大規模で何でもできる人」を探すことになり、自社のプロジェクトに合いません。プロダクトマネージャーの要件はプロダクトマネージャーの採用要件の作り方に、代行に出す工程の線はプロジェクトマネージャー採用を代行に出す判断基準にまとめています。

プロジェクトマネージャーで要件が膨らむ理由

他の職種と共通する理由（現場の希望を全部書く、前任者を基準にする、失敗を避けたい）に加えて、プロジェクトマネージャーに特有の理由があります。

一つ目は、「大きいプロジェクトを回した人なら小さいのも回せる」と考えることです。大規模の受託型と小規模の社内型は、必要な力が違います。大規模の経験者は、決まった範囲を大人数で回す力があり、小規模の社内型で求められる「決まっていない範囲を少人数で決めながら進める力」とは別です。規模の大きさを必須にすると、自社に合わない人を探します。

二つ目は、資格を必須にすることです。プロジェクト管理の資格は、知識の目安にはなりますが、自社のプロジェクトを回せるかとは直接関係しません。資格があって社内型の調整が苦手な人と、資格が無くて調整に強い人がいます。

三つ目は、「技術も分かる」を求めることです。技術の判断を委託先や現場が持つプロジェクトなら、プロジェクトマネージャーに技術の深さは要りません。技術と調整の両方を求めると、市場が狭まります。

四つ目は、予算管理や委託先管理を、自社の権限と関係なく必須にすることです。自社が予算の判断や委託先の選定を経営が持つなら、その経験は初日には要りません。

五つ目は、年数です。年数と、自社の型のプロジェクトを回す力は一致しません。

必須と歓迎を分ける基準

基準は「入社初日に、自社のプロジェクトを回す業務が成り立つか」です。プロジェクトマネージャーでは「自社のプロジェクトの型・規模・権限で」を添えます。

基準の要点は、「規模の大きさを必須にしない」ことです。「大規模の経験」を必須にすると、自社の小規模なプロジェクトに合わない人を探します。「自社と近い規模」を必須にし、大きい規模は「歓迎、ただし面接で合うかを確認」とします。

エラベルの見解

相談で多いのは、「大手SIerで大規模プロジェクトを回した経験があって、資格を持っていて、技術も分かる人」というご要望です。自社のプロジェクトは、社内の業務システムの刷新で、関係者十数名、委託先二社。この要件で来る人は、自社のプロジェクトを「小さすぎる」と感じ、社内型の調整にも慣れていません。要件が、自社のプロジェクトの型と規模と合っていません。

見ていて差がつくのは、「自社のプロジェクトの型・規模・権限から、必須を逆算しているか」です。「社内型、関係者十数名、委託先二社、予算の範囲内の判断は任せる」なら、必須は「社内型で複数部門をまたぐプロジェクトを回した経験」「委託先を管理した経験」「関係者の調整で進めた経験」の三つ。大規模も資格も技術も、歓迎か不要です。エラベルでは、プロジェクトマネージャーの要件を整理するとき、依頼側に「自社のプロジェクトの型・規模・権限」を先に決めていただき、そこから必須を逆算しています。

必須を三つに絞る手順

プロジェクトマネージャー向けに、絞る手順を番号付きで整理します。

1. 自社のプロジェクトの型を決める。 受託型（納期・予算・範囲が決まっている）か、社内型（関係者の調整と、決まっていない範囲を決める）か。
2. 規模と関係者を書き出す。 人数、委託先の数、予算の規模の目安、関係する部門。
3. 権限を決める。 予算の判断、委託先の選定、関係者への指示のうち、何を任せ、何を経営が持つか。
4. 技術の判断を誰が持つかを決める。 プロジェクトマネージャーか、委託先や現場か。
5. 現場（報告先、主な関係者）の希望を全部書き出す。 ここでは絞らない。
6. 一つずつ、「初日に自社のプロジェクトを回す業務が成り立つか」を問う。 成り立たないものだけ残す。
7. 残ったものが三つを超えたら、「入社後に自社で覚えられるか」「別の担当や委託先が持てるか」を問う。 業界の業務、技術、予算管理（経営が持つなら）は歓迎へ。
8. 資格・年数・規模の大きさを、経験の中身に書き換える。 「資格保持」ではなく「〇〇規模の社内プロジェクトを複数部門と調整して完了した経験」。
9. 歓迎に回したものを、優先順位を付けて三〜五つ書く。 面接で見る点になる。
10. 報告先・主な関係者・人事・経営で確認する。 「この三つがあれば、他は入社後に補える」と言えるか。

手順の要点は、「一から四を先にやる」ことです。型・規模・権限・技術の担い手が決まれば、必須はそこから逆算できます。

経歴で確かめられる要件と、面接でしか分からない要件

プロジェクトマネージャーでは、経歴の「プロジェクトマネージャー」の肩書が実態を表さないことが多く、確かめ方の区別が重要です。

分け方の要点は、「面接で、自社のプロジェクトの現状を題材に、候補者の進め方を聞く」ことです。「要件定義の途中で前任者が退職した。あなたなら最初の一か月で何をしますか」。この問いへの答えで、社内型の調整の力と、立て直しの力が見えます。

転向層を母集団に入れる要件の書き方

プロジェクトマネージャーの肩書の経験者だけでなく、転向層を母集団に入れる書き方が、採用の現実性を決めます。

書き方の要点は、「社内型なら、事業会社の企画・管理部門と情報システム部門からの転向層が合う」ことです。肩書は無くても、社内の関係者を調整して物事を進めた経験があれば、社内型のプロジェクトマネージャーとして育ちます。

要件が決まらないときの原因

原因の要点は、「型・規模・権限が決まっていない」ことが最も多い点です。この三つが決まれば、必須は逆算できます。

代行に出せる工程

分け方の要点は、「型・規模・権限は、社内でしか決められない」ことです。代行は、決める打ち合わせの進行と、決まったものの言語化を担えます。

エラベルの見解

担当する側から見ると、プロジェクトマネージャーの要件で最も時間がかかるのは、依頼側が「大規模の経験」「資格」「技術も分かる」を手放すことです。安心のために積んだ要件が、自社のプロジェクトの型と規模に合わない人を探す原因になっている、と分かるまでに時間がかかります。自社のプロジェクトの型・規模・権限を書き出し、そこから逆算すると、必須は自然に三つになり、「安心のための要件」は歓迎か不要になります。

エラベルでは、プロジェクトマネージャーの案件で要件が整理されていない場合、担当者の最初の仕事を「型・規模・権限を決める打ち合わせの進行」にすることをお勧めしています。募集が始まるのは数週間遅れますが、自社のプロジェクトから逆算した要件で募集を始めると、合う経歴の応募が来て、面談での「規模が違う」「権限が無い」の辞退が減ります。

まとめ

• プロジェクトマネージャーの必須要件は、先に自社のプロジェクトの型・規模・権限を決め、「入社初日に自社のプロジェクトを回す業務が成り立つか」で三つ以内に
• 要件が膨らむ理由は大きい経験なら小さいのも回せると考える・資格を必須にする・技術も求める・自社の権限と関係なく予算や委託先の管理を求める・年数で書く
• 資格・年数・規模の大きさは必須にしない。経験の中身（回したプロジェクトの型と規模、調整した関係者、立て直し）で書く
• 絞る手順は型→規模と関係者→権限→技術の担い手→全部書き出す→初日に成り立つか→覚えられるか・別の担当が持てるか→中身に書き換え→歓迎に優先順位→四者で確認
• 面接では自社のプロジェクトの現状を題材に、進め方を聞く
• 転向層（受託から、企画・管理部門から、情報システム部門から、社内での昇格）は型ごとに合う転向元が違う
• 決まらない原因の多くは型・規模・権限が決まっていないこと

よくある質問

大規模の経験者のほうが、小規模のプロジェクトも安心して任せられませんか

大規模の受託型と小規模の社内型は、必要な力が違います。大規模では、決まった範囲を大人数で、役割分担と手順で回します。小規模の社内型では、決まっていない範囲を少人数で、関係者と直接話しながら決めていきます。大規模の経験者が小規模の社内型で戸惑うことは多く、「物足りない」と感じることもあります。安心の根拠を規模の大きさに求めず、「自社と近い規模で、社内型を完了した経験」に求めます。大規模の経験は歓迎にとどめ、面接で「小規模で自分で全部を見ることに魅力を感じるか」を確かめます。

プロジェクト管理の資格は、必須にしなくてよいのですか

資格は、知識の目安にはなりますが、自社のプロジェクトを回せるかとは直接関係しません。社内型のプロジェクトで求められる関係者の調整や、決まっていない範囲を決める力は、資格では測れません。資格は歓迎に置き、必須は経験の中身で書きます。面接で、自社のプロジェクトの現状を題材に進め方を聞けば、資格の有無に関わらず、回す力は分かります。資格を必須にすると、資格が無くても社内型の調整に強い転向層（企画・管理部門、情報システム部門）を弾き、母集団が狭まります。

技術が分からないプロジェクトマネージャーで、システムのプロジェクトが回りますか

技術の判断を誰が持つかで決まります。委託先や情報システム部門が技術の判断を持つ体制なら、プロジェクトマネージャーは技術の深さより、委託先と社内をつなぎ、関係者を調整し、進捗を管理する力が要ります。技術の判断もプロジェクトマネージャーに持たせたいなら、技術の理解を必須にしますが、その場合は市場が狭まり、社内型の調整に強い人を弾くことがあります。技術の判断の担い手を先に決め、担い手が別にいるなら技術は歓迎に、いないなら必須に、と分けます。両方を必須にすると、市場にほとんどいません。