社内SEの採用要件の作り方｜必須と歓迎を分ける基準

社内SEの採用要件を作ると、「基幹システムの導入・運用経験」「ネットワークとサーバーの知識」「開発経験（言語を並べる）」「ベンダー管理の経験」「セキュリティの知識」「情報処理の資格」「DX推進の経験」「コミュニケーション能力と主体性のある方」と膨らみます。中身の割合と一人目かどうかと決裁の範囲を決めずに、経営者や総務が「理想の社内SE」を要件にしてしまうことが原因です。膨らんだ要件は、全部を持つ人がいないか、持っていても大きな会社の情報システム部にいて一人目に向かないか、「開発経験」で一人情シスの経験者を外すか、のどれかになります。結論を先に書くと、社内SEの要件は「中身の割合と一人目かどうかと決裁の範囲」から決め、必須を「割合の高い中身に近い経験」「一人目なら決まりの無い環境で自分で調べて解決した経験」「ITの分からない人に説明した経験」の三つに絞り、それ以外の基幹システムの種類・開発経験・資格・DX推進・年数は歓迎に回すと、該当する人が現れ、面接で確かめるべきことも決まります。中身の割合と一人目かどうかの整理は社内SE採用を代行に出す判断基準に、母集団形成は社内SEの母集団形成にまとめています。

社内SEで要件が膨らむ理由

社内SEの要件が膨らむ理由は、三つあります。

一つ目は、中身の割合を決めずに要件を作ることです。「社内SEが欲しい」で募集を始めると、ヘルプデスクと機器の管理、基幹システムの保守とベンダー管理、社内の開発、DX推進のどれが中心かが決まっておらず、「全部できる人」が要件になります。実際には、割合が決まれば、要件は割合の高い中身に近い経験で足ります。

二つ目は、社内にITの分かる人がいないため、要件を「知っている言葉を並べる」形で作ることです。経営者や総務が、ベンダーの営業や求人の例から「基幹システム」「ネットワーク」「セキュリティ」「DX」の言葉を拾って並べます。並べた本人が中身を判断できないので、削れず、膨らみます。

三つ目は、「コミュニケーション能力」「主体性」を要件に書くことです。社内SEには、ITの分からない人に説明する力と、決まりの無い環境で自分から動く力が要りますが、これらは経歴では確かめられず、面接で確かめるものです。要件に書いても絞れません。

三つを合わせると、「割合を決めずに、知っている言葉を並べ、面接で確かめるべきことを要件に書く」のが、膨らむ構造です。

必須と歓迎を分ける基準

基準は、「その要件が無いと、中身の割合と一人目かどうかと決裁の範囲を回せないか」です。回せないなら必須、あれば早いなら歓迎です。

表の要点は、「開発経験」と「基幹システムの製品名」と「資格」を、割合を決めずに書かないことです。ひとり情シスや保守とベンダー管理が中心の会社で「開発経験」を必須にすると、最も向く一人情シスの経験者を外します。

もう一つの要点は、「ITの分からない人に説明した経験」を必須に入れることです。社内SEは、技術の深さより、経営者と現場とベンダーの間に立って翻訳する役で評価されます。技術は深いが説明できない人は、社内で孤立し、「提案が通らない」と辞めます。

エラベルの見解

相談で多いのは、「社内SEの要件を『基幹システムの導入経験、ネットワークとサーバー、開発経験、セキュリティ、情報処理の資格、DX推進の経験』にしたが、応募がまったく来ない」というご相談です。中身の割合を聞くと、社員数十名の会社の一人目で、ヘルプデスクとベンダー対応が七割、基幹システムはベンダーが保守、サーバーはクラウド、開発は当面無い、とのことでした。それなら要件は「ヘルプデスクとベンダー対応に近い経験」「決まりの無い環境で自分で調べて解決した経験」「ITの分からない人に説明した経験」で足り、基幹システムの導入も開発もサーバーも資格もDXも、該当者を減らしているだけでした。

見ていて差がつくのは、「割合を決めてから要件にしているか」です。「一人目、ヘルプデスクとベンダー対応が七割、クラウド、開発は当面無い」→必須は「ヘルプデスクとベンダー対応の経験」「自分で解決した経験」「説明した経験」、基幹システムの製品名と開発と資格は歓迎。ここまで決めれば要件は三つで済み、一人情シスの経験者とSIerで幅広く見ていた人が該当します。エラベルでは、社内SEの担当者に、要件を書く前に「中身の割合と一人目かどうかと決裁の範囲」を経営者に決めてもらっています。

必須を三つに絞る手順

手順は四つです。

一つ目：中身の割合と一人目かどうかと決裁の範囲を決める。 四つの中身の日々の割合。一人目か二人目以降か。自分で決められる範囲と予算と上司。使っているもの（基幹システム、クラウドか自社サーバーか、ベンダーの数）。

二つ目：その割合と条件を回すために、無いと困る経験を書き出す。 「PCとアカウントとネットワークの不調に対応した」「ベンダーと保守の話をした」「一人で調べて解決した」「経営者に説明した」など。書き出したら、「これが無いと本当に回らないか」「ベンダーに頼めるか」「入ってから覚えられるか」を一つずつ問います。

三つ目：「ITの分からない人に説明した経験」を必須に入れ、面接で確かめる形にする。 経歴では読めないので、面接で経営者が「自社の課題を材料に説明してもらう」形を用意します。

四つ目：残りを歓迎に回し、形容詞を外す。 基幹システムの製品名、開発経験、サーバーとネットワークの深さ、セキュリティ、資格、DX推進、年数は歓迎に。「コミュニケーション能力」「主体性」は要件から外し、面接で確かめる項目に移します。

手順の要点は、二つ目で「ベンダーに頼めるか」「入ってから覚えられるか」を問うことです。「基幹システムの導入経験」は、ベンダーが保守しているなら「回らない」ではありません。「サーバーの知識」は、クラウドなら深さは要りません。「資格」は、そもそも力を示すものではありません。問うたびに必須が減り、三つに近づきます。

経歴で確かめる要件と、面接で経営者が確かめる要件

要件を、経歴（職務経歴書、媒体のプロフィール）で確かめられるものと、面接で経営者が確かめるものに分けます。

経歴で確かめられるのは、「担当した中身（ヘルプデスク、保守、ベンダー管理、開発、整備）と会社の規模と人数」「一人で担当したか、部門の一員だったか」「扱った基幹システムとクラウドと業務ソフト」「開発の言語」「資格」「経路（SIer、SES、事業会社の情シス、社内開発）」「何年か」です。書類の段階で、必須のうち「割合の高い中身の近さ」「一人で担当したか」はここで確かめます。ただし、「自分で調べて解決した経験」と「ITの分からない人に説明した経験」は、経歴には結果しか書かれていないことが多く、面接で確かめます。

面接で経営者が確かめるのは、「説明の力（自社の課題を材料に、ITの分からない経営者に説明してもらう。専門用語を使わずに説明できるか）」「自分で解決した経験（前の職場で、分からないことをどう調べ、誰に聞き、どう解決したか）」「決まりの無い環境での動き方（うちに入ったら、最初の三か月で何から手を付けるか）」「ベンダーとの関係の作り方（ベンダーに言われるままにならないか、ベンダーの提案をどう判断するか）」「決裁の範囲と上司を説明した上で受け入れられるか」「離れたい動機の場合、離れた先で何をしたいか」です。要件の「コミュニケーション能力」「主体性」は、この項目に翻訳して、経営者が確かめます。

確かめる方法は、自社の課題を材料にすることです。「うちはPCの設定が人によって違って、アカウントも誰が持っているか分からない。何から手を付けますか」「ベンダーから基幹システムの更新の提案が来ている。どう判断しますか」。答えの技術的な正しさは経営者には判断できなくてよく、専門用語を使わずに説明できるか、順番を付けられるか、ベンダーの提案を鵜呑みにしないかを見ます。技術の深さは、外部のエンジニアに一時間ほど面接に入ってもらって確かめます。候補者の現在の職場のシステムやセキュリティの機微な情報は聞かず、自社の課題を材料にします。機微な情報の扱いは、専門家にご確認ください。面接の設計は面接の構造に書いています。

経路ごとの要件の書き方

社内SEの候補者は、経路によって持っているものが違います。要件の書き方も、経路を意識して変えます。

表の要点は、「社内SEの経験」を必須にしないことです。SIerやSESで客先の情シスに常駐していた人や、ヘルプデスクから広げたい人は、「割合の高い中身に近い経験」を持っていて、一人目か二人目以降かの条件が合えば向きます。

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

要件を作ろうとして決まらないとき、原因は要件ではなく、その前にあります。

一つ目は、中身の割合が決まっていないことです。「社内SEが欲しい」で止まっていると、要件は「全部できる人」になります。四つの中身の割合を、いまの社内SEか総務か経営者に聞いて決めます。

二つ目は、決裁の範囲と上司が決まっていないことです。決まっていないと、面接で「提案は通るのか」と聞かれて答えられず、候補者に「通らない職場」と読まれます。範囲と手続きと上司を先に決めます。

三つ目は、社内にITの分かる人がいないため、要件を判断できないことです。ベンダーの営業や求人の例から言葉を拾って並べても、削れません。この場合は、外部のエンジニアか、社内SEの採用を知る人に、要件の案を見てもらいます。

四つ目は、経営者が要件に関わっていないことです。総務だけで作ると、「理想の社内SE」になります。経営者に「一人目に最低限何が要るか」を聞くと、「PCとネットワークを止めずに、ベンダーと話せて、自分に分かる言葉で説明してくれれば、あとは一緒に決める」のように、要件が下がることが多い。

四つのどれかが決まっていないなら、要件より先にそれを決めます。要件が固まらない場合の進め方は採用要件が固まらないときに、高すぎる場合は採用要件が高すぎるときにも書いています。

代行に出せる工程

要件作りの工程を、社内で持つものと外に出せるものに分けます。

分け方の要点は、「割合と決裁と経営者の意見は経営者が決め、翻訳と振り分けと段取りは外に出せる」ことです。社内SEの要件で難しいのは、社内にITの分かる人がいないため要件を判断できないことで、外に出すのは「経営者の意見を聞き取って要件に落とし、経歴を読み、技術の確認を外部に頼む段取りをする人」の役です。担当者に社内SEか情報システム部門の経験があると、要件の案の妥当性を自分で判断できます。担当者の経歴の見方は担当者の経歴の見方に書いています。

エラベルの見解

担当する側から見ると、社内SEの要件で最も効くのは、「開発経験と製品名と資格を歓迎に下げて、『ITの分からない人に説明した経験』を必須に入れること」です。前者で一人情シスの経験者とSIerやSESで客先の情シスに常駐していた人が母集団に入り、後者で「技術は深いが説明できず孤立する人」と「経営者と現場とベンダーの間に立てる人」を面接で見分けられます。社内SEは、技術の深さより翻訳の力で続くかどうかが決まります。

エラベルでは、社内SEの案件で担当者を紹介するとき、最初の一週間で「中身の割合と一人目かどうかと決裁の範囲」を経営者に決めてもらい、「最低限何が要るか」を聞き取り、そこから必須三つを作るところまでをお願いしています。面接では、自社の課題を材料に説明の力を経営者が確かめ、技術の深さは外部のエンジニアが確かめる形を担当者が段取りします。セキュリティと機微な情報の扱いは、専門家にご確認いただくようお伝えしています。

まとめ

• 社内SEの要件が膨らむ理由は割合を決めずに作る・知っている言葉を並べる・面接で確かめるべきことを要件に書くの三つ
• 基準は「無いと中身の割合と一人目かどうかと決裁の範囲を回せないか」。必須は割合の高い中身に近い経験・一人目なら決まりの無い環境で自分で解決した経験・ITの分からない人に説明した経験の三つ
• 基幹システムの製品名・開発経験・サーバーとネットワークの深さ・セキュリティ・資格・DX推進・年数は歓迎。「コミュニケーション能力」「主体性」は要件に書かず、面接で確かめる項目に
• 手順は割合と一人目かどうかと決裁の範囲を決める→無いと困る経験を書き出して「ベンダーに頼めるか」「入ってから覚えられるか」を問う→説明した経験を必須に入れ面接で確かめる形にする→残りを歓迎に
• 経歴で確かめるのは中身と規模・一人か部門か・扱ったもの・言語・資格・経路・年数。経営者が面接で確かめるのは説明の力・自分で解決した経験・決まりの無い環境での動き方・ベンダーとの関係・決裁と上司の受け入れ・離れた先で何をしたいか。技術の深さは外部のエンジニアに
• 「社内SEの経験」を必須にしない。客先の情シスへの常駐やヘルプデスクからの転向者は割合の高い中身に近い経験を持つ
• 決まらないときは割合・決裁と上司・ITの分かる人の不在・経営者の関与のどれかが先に決まっていない

よくある質問

社内にITの分かる人がいないので、要件が正しいか判断できません

一人目の社内SEの採用で最も多い悩みです。要件の案を、外部のエンジニアか、社内SEの採用を知る人に一度見てもらいます。見てもらうときは、「中身の割合」「一人目かどうか」「使っているもの」「決裁の範囲」を先に伝えると、「この割合ならこの要件は要らない」「これは入ってから覚えられる」と削ってもらえます。代行に出す場合は、この判断と、面接での技術確認の段取りも含めて任せられます。

情報処理の資格を必須にしてよいですか

資格は実務の力を示すものではなく、無資格で一人情シスを回している人は多くいます。必須にすると該当者を減らします。歓迎に置き、経歴で「担当した中身と規模」を、面接で「自分で解決した経験」と「説明の力」を確かめるほうが効きます。法令や業務で資格が要る場合は別ですが、社内SEで要ることは多くありません。資格の要否は専門家にご確認ください。

「社内SEの経験三年以上」は書かないほうがよいのですか

年数だけの要件は、大きな情報システム部で一つの領域を三年担当した人と、小さな会社で一年で一人情シスを整えた人を、逆に評価します。書くなら「社員数十名規模の会社で、ヘルプデスクとベンダー対応を一人で担当した経験」のように、中身と規模と一人かどうかで書きます。年数の目安が無いと不安な場合も、「〇年」より「担当した範囲と、自分で解決した経験」のほうが、面接で確かめやすく、該当する人に届きます。