LASSIC Media らしくメディア
エンジニア中途採用の責任者候補、マネジメント経験を確かめる
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)
この記事の結論
- 責任者のマネジメント経験は、プロダクト・プロジェクト・人とチームの3つに分け、どれを担ったかを聞きます。
- 肩書きは会社の規模で中身が変わるため、率いた人数と、自分で決められたことを分けて確かめます。
- 評価・採用・育成は、一つの出来事に沿って、本人が決めたことまで掘り下げて聞きます。
※ 本記事は2026年9月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。
応募書類には「マネージャー経験5年」とあるのに、面接で聞くと部下の評価をしたことがない。前職ではチームを率いていたと言うものの、何人をどこまで任されていたのかが見えない——。エンジニアの中途採用で開発チームの責任者を探すと、こうした食い違いが起こりがちです。責任者に求めるマネジメント経験とは、チームの仕事の進め方を決め、メンバーの評価や採用、育成に関わり、その結果に責任を持ってきた経験を指します。
マネジメント経験を種類ごとに分けて聞くと、候補者どうしを同じ物差しで比べやすくなります。ただし万能ではなく、経験の年数や率いた人数が多いほど自社に合うとは限りません。本記事では、開発チームの責任者を中途採用で探す開発部門のマネージャーに向けて、マネジメント経験の分け方、肩書きだけでは分からない理由、率いた規模の聞き方、評価・採用・育成の担い方、そして面接での聞き方を整理します。
目次
責任者のマネジメント経験とは
エンジニアの世界で「マネジメント」と言うとき、指している中身は人によって違います。製品の方向を決める人も、開発の予定と品質を管理する人も、メンバーの評価や育成を受け持つ人も、同じように「マネジメントをしていた」と話します。エンジニア中途採用で責任者を探すときは、まずこの中身を分けておきます。
分け方の手がかりになるのが、IPA(情報処理推進機構)のデジタルスキル標準 ver.2.0です。DXを進める人材に求めるスキルを定めた標準で、スキル項目を細かく分けて定義しています。*1 マネジメントに当たる項目を拾うと、次の3つにまとめられます。
- プロダクトのマネジメント:何を作り、どこまでを作るか、どの順で作るかを決める
- プロジェクトのマネジメント:期限・予算・品質の制約の中で計画を立て、進み具合や課題、リスクを管理する
- 人とチームのマネジメント:チームを作り、メンバーに仕事を任せ、評価や採用、育成に関わる
同標準は、プログラム/プロジェクトマネジメントを「プロジェクト、もしくはプログラムを、期限・予算・品質の制約下で、計画から実行・監視・終結までを管理し成果を確実に創出するスキル」と定義しています。*2 リーダーシップについては、関係者が参画しやすいチーム作りや、それぞれの強みと関心を踏まえてタスクの遂行を働きかけるスキルとし、学ぶ項目としてチームビルディングやエンパワーメント(権限を渡して任せること)を挙げています。*2
もう一つ押さえておきたいのは、同標準がプロジェクト管理やチームの取りまとめ、人材育成を、独立したロール(役割の区分)としては定義していない点です。担い手がプロジェクトの性質によって変わるため、ロールに必要なスキルとして扱われています。*1 「マネージャー」という決まった職種があるのではなく、どの役割の人も、担う範囲に応じてマネジメントのスキルを求められるという考え方です。責任者の採用でも、マネジメント経験が「あるか、ないか」ではなく、3つのうちどれを、どこまで担ってきたかを聞くことになります。
ロールによって違うマネジメントの重み
同じマネジメントでも、どの役割から来た人かによって、得意な部分が違います。デジタルスキル標準は、ロールごとに各スキル項目の重要度をa〜dの4段階で示しています(リーダーシップなどのパーソナルスキルはzの1段階)。*2 マネジメントに関わる6項目を、開発に近い4つのロールで並べると次のようになります。
プロダクトマネージャーは、プロダクトスコープと優先順位のマネジメント、プログラム/プロジェクトマネジメント、チーム開発、技術的制約・アーキテクチャを踏まえたプロダクト判断が、いずれもa(高い実践力と専門性が必要)です。一方でフロントエンドエンジニアとバックエンドエンジニアは、ソフトウェア開発プロセスとチーム開発がaで、プロジェクトマネジメントはb(一定の実践力と専門性が必要)、スコープと優先順位はc(知識として説明できる程度の理解が必要)です。*2
開発の現場から責任者を目指してきた人は、開発の計画や品質の管理、チームでの開発の進め方に強みを持ちやすいということです。チーム開発の学習項目には、Gitの使い方、チームビルディング、読みやすいコードの書き方、技術文書の書き方が並び、ソフトウェア開発プロセスには、アジャイル開発手法や見積り、品質管理が含まれます。*2 逆に、何を作るかの優先順位を決めた経験は、前職の役割によっては薄いこともあります。自社の責任者にプロダクトの判断まで任せるのか、開発の進め方とチームの運営に絞るのかを先に決めておくと、どの経験を深く聞くべきかがはっきりします。
リーダーシップは、どのロールにも「役割や状況に応じた実践力が必要」なスキルとして置かれています。責任者だけに求める特別な力ではないので、面接では「リーダーシップがあるか」を聞くより、実際にどんな場面でチームを動かしたかを聞くほうが、答えを比べやすくなります。
なぜ肩書きだけでは分からないのか
応募書類にある「マネージャー」「リーダー」という肩書きは、会社によって指す範囲がかなり違います。デジタルスキル標準も、ソフトウェアエンジニアのロールを考える前提として、数十名以上のソフトウェアエンジニアのチームを持つ規模の企業を想定したと書いています。それより小さな企業ではすべてのロールを少数または一人が担うことがあり、大きな企業ではそれぞれのロールがチームになることもあるとしています。*1
たとえば、エンジニアが5人の会社のリーダーは、開発の段取りから採用の面接、評価の面談までを一人で受け持っていたかもしれません。数百人の開発組織の課長は、評価は担当していても、採用の判断は人事部や上位の部長が持っていたかもしれません。肩書きが同じでも、担ってきた範囲は大きく違います。
役職名と実際の権限が一致しないことは、法律の世界でも前提になっています。労働基準法の管理監督者について、厚生労働省の解釈例規は「名称にとらわれず、実態に即して判断すべきもの」としています。*3 これは労働時間の規定を当てはめるかどうかの話ですが、経歴を読むときの考え方としても役に立ちます。責任者の候補者には、肩書きより先に、当時の上司と部下が誰だったか、何を自分で決められたかを尋ねます。
率いた規模の聞き方
「何人のチームを見ていましたか」と一つだけ聞くと、答えの中身がそろいません。直属の部下の人数を答える人もいれば、協力会社から参加していた人まで含めた人数を答える人もいます。規模は、次のように数を分けて聞くと比べやすくなります。
| 聞く数 | 聞き方の例 | 分かること |
|---|---|---|
| 直属の部下 | 評価の面談をしていたメンバーは何人でしたか | 人とチームのマネジメントの広さ |
| チーム全体 | 協力会社や業務委託で参加していた人も含めると、何人でしたか | 開発の段取りを組んでいた範囲 |
| 評価を書いた人数 | 1回の評価の時期に、何人分の評価を書きましたか | 評価の経験の量 |
| 採用で関わった人数 | 面接をした人数と、そのうち採否の判断に加わった人数は何人ですか | 採用の経験の深さ |
| 期間と変化 | 何年担当し、その間に人数はどう変わりましたか | チームを広げたのか、引き継いだのか |
社員と、協力会社から参加していた人とでは、責任者が関わる内容が違います。両方を足した人数だけを聞くと、人のマネジメントの経験を大きく見積もってしまうので、分けて聞いておきます。
人数が多いほど良いわけではありません。自社で任せたいチームが6人なら、6人前後のチームで採用から評価までを担ってきた人のほうが、50人の組織で進み具合の管理だけを担ってきた人より合うこともあります。規模は、自社の責任者が見ることになるチームの人数と並べて読みます。
評価・採用・育成の担い方
人とチームのマネジメントは、さらに細かく分けて聞きます。参考になるのが、厚生労働省の2008年の通達です。多店舗展開する小売業や飲食業の店長が労働基準法の管理監督者に当たるかを判断する要素を整理したもので、採用、解雇、人事考課、労働時間の管理を、店舗の労務管理に関する重要な職務として挙げています。*3 業種は違いますが、責任者が人に関して何を担うかを分ける物差しとして使えます。
採用について、通達は「人選のみを行う場合も含む」と書いています。*3 面接で候補者を選ぶことと、採否や処遇を決めることは、同じ採用でも深さが違います。候補者には、求める人物像を自分で書いたか、面接官として加わったか、最終の判断を持っていたかを分けて聞きます。
人事考課は、通達のなかで「昇給、昇格、賞与等を決定するため労働者の業務遂行能力、業務成績等を評価すること」と定義されています。*3 評価の経験を聞くときは、評価の結果を書いたかどうかに加えて、目標をメンバーと一緒に決めたか、評価の理由を本人に説明したか、昇給や昇格の判断にどこまで関わったかを尋ねます。
労働時間の管理は、開発チームでいえば、誰にどの仕事を割り当て、残業や休日の対応を誰が指示するかに当たります。障害対応の当番表を組んでいた、リリース前の作業量を調整していた、といった話が出てくれば、チームの負荷を見ながら仕事を配ってきた経験があると分かります。
開発チームの責任者には、育成の経験も欠かせません。デジタルスキル標準がリーダーシップの学習項目に挙げるエンパワーメントは、メンバーに権限を渡して任せることです。「メンバーに任せたいちばん大きな仕事は何でしたか」「その人が一人で進められるようになるまでに、何をしましたか」と聞くと、育成の経験を具体的に確かめられます。
面接での聞き方
マネジメント経験は、考え方を聞くより、一つの出来事を選んでもらい、その中で本人が何をしたかを掘り下げると確かめやすくなります。「チームで苦労した場面を1つ挙げてください」と聞き、当時のチームの人数と構成、本人が決めたこと、上司や人事が決めたこと、結果とその後の振り返りを順に尋ねます。
| 確かめること | 質問の例 | 答えで見る点 |
|---|---|---|
| プロジェクトのマネジメント | 予定より遅れた開発で、何を削り、誰に何を相談しましたか | 期限・予算・品質のどれを優先したかと、その理由を説明できるか |
| 評価 | 評価が本人の期待より低かったメンバーに、どう伝えましたか | 評価の理由を事実で説明し、次の目標まで話したか |
| 採用 | 採用を見送った候補者について、見送った理由は何でしたか | 求める条件を自分で決めていたか |
| 育成 | 任せた仕事でメンバーがつまずいたとき、どこまで手を出しましたか | 任せる範囲と支える範囲を分けて考えていたか |
| 技術の判断 | チームの技術の選び方で、最後に自分が決めたことは何ですか | 技術の制約を踏まえて判断し、理由をメンバーに説明したか |
答えを聞くときは、主語に注意します。「チームで決めました」という答えが続くときは、「そのとき、あなたが決めたことはどれですか」と聞き直すと、本人の役割が見えてきます。前職の評価の中身やメンバーの名前は、守秘義務に触れない範囲で話してもらえば十分です。
技術の力を確かめる面接は、マネジメントの面接と分けておくと、それぞれの評価がぶれにくくなります。技術面接の評価項目の決め方は「技術面接の評価項目をスキルの水準から決める」で、採用基準を誰が作り、面接官をどう決めるかは「エンジニア中途採用の責任者と、人事・開発現場の役割分担」で扱っています。
つまずきやすい点
一つ目は、マネジメント経験の年数だけで判断してしまうことです。同じ5年でも、評価と採用まで担った5年と、進み具合の管理だけを担った5年では中身が違います。年数は、3つの種類のどれを担ったか、評価・採用・育成のどこまで関わったかと組み合わせて読みます。
二つ目は、自社で任せる範囲を決めないまま面接に入ることです。責任者にプロダクトの優先順位まで任せるのか、採用の最終判断を渡すのかが決まっていないと、どの経験を重く見るかが面接官ごとに変わります。求める範囲は、求人を出す前に書き出しておきます。
三つ目は、採用した後に権限を渡さないことです。評価や採用の経験を見込んで責任者を採っても、入社後の評価を従来どおり別の人が決めるままでは、その経験は活きません。入社の時点で、何を責任者が決め、何を上位の管理職や人事と一緒に決めるのかを、本人と確かめておきます。
まとめ:マネジメント経験で確かめたい3つの点
エンジニア中途採用で責任者を採るうえで、確かめておきたい点は3つに整理できます。第一に、マネジメントをプロダクト・プロジェクト・人とチームの3つに分け、自社の責任者に任せる範囲を先に決めること。第二に、率いた人数を直属の部下、チーム全体、評価や採用で関わった人数に分けて聞き、肩書きではなく担った権限で読むこと。第三に、評価・採用・育成のどれを担ったかを、一つの出来事に沿って本人が決めたことまで掘り下げることです。この3点を踏まえておけば、「マネージャー経験があると聞いて採ったのに、評価も採用も任せられなかった」という事態を避けやすくなります。責任者に求める経験の整理に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
マネジメント経験が浅い候補者は、責任者の候補から外したほうがよいですか
一律に外す必要はありません。任せたい範囲のうち、すでに経験のある部分と、入社後に広げていく部分を分けて考えます。開発の進め方とチーム開発の経験が十分なら、評価や採用は上位の管理職と一緒に進める期間を設け、少しずつ任せていく方法もあります。
前職の評価の内容や部下のことを、面接でどこまで聞いてよいですか
評価の仕組みと、その中で本人が何をしたかを聞けば足ります。部下の名前や個別の評価結果、前職の社外秘の数値は、守秘義務に触れるおそれがあるので求めません。話せる範囲でよいと先に伝えておくと、具体的な話を引き出しやすくなります。
責任者として採用した人は、労働基準法の管理監督者になりますか
肩書きだけでは決まりません。厚生労働省は、労務管理について経営者と一体的な立場にあるかを、職務内容、責任と権限、勤務態様、賃金等の待遇を踏まえて総合的に判断するとしています。*3 扱いに迷うときは、社会保険労務士などの専門家に確認しておきます。
開発チームの責任者の採用を相談したいとき
任せたいマネジメントの範囲と、チームの規模の整理からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考:独立行政法人情報処理推進機構「デジタルスキル標準 ver.2.0(分冊版:DX推進スキル標準 e ソフトウェアエンジニア編)」(PDF)(https://www.ipa.go.jp/jinzai/skill-standard/dss/rcu1hd000000j76k-att/sep_dss-p_swe.pdf)。出典:独立行政法人情報処理推進機構(2026年4月)。第Ⅲ部第1章のDX推進スキル標準の類型の範囲(プロジェクト管理、チームの取りまとめ、人材育成をロールに必要なスキルとして定義)、第Ⅲ部第2章のスキルマッピングの考え方(重要度の定義)、第Ⅲ部第3章のソフトウェアエンジニアのロール(ロールの分担について)を参照(2026年9月確認)
- *2 参考:独立行政法人情報処理推進機構「デジタルスキル標準 ver.2.0(共通スキルリストExcel版)」(https://www.ipa.go.jp/jinzai/skill-standard/dss/rcu1hd000000j76k-att/dss-p_ver2.0_skilllist.xlsx)。出典:同Excel(2026年6月22日修正版)。スキルマッピング(ロール別の重要度)、スキル項目一覧、学習項目一覧のうち、プロダクトスコープと優先順位のマネジメント、プログラム/プロジェクトマネジメント、ソフトウェア開発プロセス、チーム開発、技術的制約・アーキテクチャを踏まえたプロダクト判断、リーダーシップを参照(2026年9月確認)
- *3 参考:厚生労働省「多店舗展開する小売業、飲食業等の店舗における管理監督者の範囲の適正化について」(基発第0909001号)(PDF)(https://www.mhlw.go.jp/houdou/2008/09/dl/h0909-2a.pdf)。出典:厚生労働省労働基準局長通達(平成20年9月9日)。参考1の通達本文(職務内容、責任と権限についての判断要素)と、参考2の労働基準法第41条および管理監督者の範囲についての解釈例規(昭和22年9月13日付け発基17号、昭和63年3月14日付け基発150号)を参照(2026年9月確認)