社内SE案件は非IT企業を中心に増えている

社内SEの業務委託案件は、IT専門部門を持たない非IT企業を中心に需要が増えている傾向があります。こうした企業はエンジニアを育成する環境が社内にないため、即戦力となる外部の人材を必要としています。情シス担当者の退職や組織変更をきっかけに、「属人化した運用を整理しながら引き継ぎたい」「上場準備でISMS対応やIT資産管理を整備したい」という目的で募集が出るケースも多くあります。

案件内容は幅広く、ヘルプデスク対応や入退社管理、PCキッティングといった日常運用から、ベンダーコントロール、業務改善のためのツール導入、社内インフラのリプレースまで多岐にわたります。社内SEとして幅広く対応してきた経験は、こうした案件の要件と合いやすい構造になっています。

単価の幅と何が単価を決めるか

社内SE・情シス系の業務委託案件の単価は、月額で約40万円から80万円程度の幅があるというデータがあります。運用・保守中心の案件が比較的低めで推移し、ベンダーコントロールや改善提案、IT戦略の立案まで担える人材は単価が上がる傾向があります。開発経験がなくても、ベンダー折衝や業務改善の実績がある人材への需要はあります。

単価を決める要因は技術スキルだけではありません。「現場の業務をヒアリングして要件を整理できるか」「IT知識のない社員に対してかみ砕いた説明ができるか」「ベンダーとのやり取りで適切な判断ができるか」といった対人・判断系の能力が、案件の評価軸として明示されているケースが目立ちます。自分の経験がこの評価軸のどこに当たるかを整理しておくことが、案件獲得の出発点になります。

開発経験がなくても評価される経験がある

社内SEや情シス出身者が業務委託に出る際、「コードを書いていない」「開発経験がない」という点を懸念する人は少なくありません。ただし案件の要件を見ると、開発スキルよりも「社内SE・情シス業務の実務経験」「ベンダーコントロール経験」「社内調整・折衝経験」「運用ドキュメントの整備経験」が必須要件として記載されているケースが多くあります。

開発案件と情シス系案件では、求められるスキルセットが異なります。情シス系案件に絞って経歴を整理すると、自分の経験が要件に合っているケースは想定より多いことがあります。まず「自分の経験がどの案件カテゴリに当たるか」を確認することが、整理の出発点になります。

評価される経験の種類を把握する

案件要件に頻出する経験の種類を整理すると、大きく四つの軸に分類できます。一つ目は社内インフラの運用保守で、Windows Server、Linux、ネットワーク機器、Active Directory、MDMなどの管理経験です。二つ目はベンダーコントロールで、外部ベンダーとの契約交渉、進捗管理、品質管理の経験が該当します。三つ目は社内調整で、IT部門と現場部門の橋渡し、経営層への報告、非技術者向けの説明能力です。四つ目は改善・導入で、SaaSツールの選定・導入、業務フローの見直し、マニュアル整備の経験です。

自分がこれらのうちどれを実務として経験してきたかを棚卸しする作業が、経歴書作成の前段階として必要になります。「幅広くやってきた」という感覚のまま案件に臨むと、評価者に経験の輪郭が伝わりにくくなります。

経験の「伝わり方」が評価を決める

同じ実務経験を持っていても、経歴書や面談での伝え方によって評価が変わります。社内SEの仕事は多岐にわたるため、「何でもやっていた」という記述になりがちです。案件評価者が知りたいのは「何をどのレベルでできるか」「その結果として現場に何が残ったか」という点です。業務の列挙ではなく、担当した業務の規模・対象範囲・結果を具体的に示すことが、経歴書の評価を変えます。

「運用していた」では伝わらない理由

「基幹システムの運用・保守を担当していました」という記述は、経歴書でよく見られますが、案件評価者には情報量が少なく映ります。運用・保守という言葉は幅が広く、監視ログの確認だけをしていた場合と、障害時の一次対応から復旧手順書の整備まで担っていた場合では、実態が大きく異なります。評価者はどちらかを区別できないため、判断材料が少ない候補者として扱われます。

運用・保守経験を正確に伝えるには、「何を・何台・どのような役割で・どの範囲まで対応していたか」を具体化する必要があります。この四つの軸を埋めると、経歴の輪郭が見えやすくなります。

具体化の四つの軸

対象システム・機器の種類と規模

Windows ServerやLinux、ネットワーク機器、MDM、Active Directory、Google WorkspaceやMicrosoft 365といった環境の種類と、管理台数・拠点数・ユーザー数の規模を記載します。「社内インフラ全般を担当」という記述より「Windows Server環境・端末約200台・全社員への対応」と書くほうが、評価者が案件との適合度を判断しやすくなります。

対応範囲と役割の深さ

ヘルプデスク対応のみか、障害時の一次対応・エスカレーション判断まで担っていたか、定期メンテナンスの計画・実施まで関わっていたかを記載します。チームの中での役割が担当者なのかリード・主担当なのかも明示します。一人情シスとして全対応していた場合は、その旨を記載することが経験の幅を伝えることになります。

運用設計・ドキュメント化の有無

手順書・マニュアル・運用フロー図の作成・整備を担っていた場合は明記します。こうした成果物の作成経験は、案件で「ドキュメント整備」が要件に入っている場合に直結します。また、既存の属人化した運用を標準化した経験があれば、それは案件先が求めている課題解決の実績として評価されます。

改善・変更の判断に関わったか

既存の運用ルールを見直した経験や、障害から再発防止策を検討・実施した経験があれば記載します。言われた通りに運用していたのではなく、課題を発見して対処した経験は、案件先にとっての「即戦力として判断できる人材かどうか」の判断材料になります。

改善経験は単価に直結する

情シス系案件では、日常運用に加えて「現状の課題を発見し、改善を提案・実行できる人材」への需要があります。DX推進・ツール導入・生産性向上施策・業務の標準化といったテーマが案件概要に明示されているケースが増えており、こうした案件は純粋な運用・保守案件と比較して単価が高い傾向があります。過去に改善や導入に関わった経験がある場合、その経験が評価の分水嶺になります。

「導入しました」で終わらせない書き方

「Slack導入を担当しました」「経費精算システムを入れ替えました」という記述は、経験の事実は伝わりますが、評価者が見たいのは「その人が何をしたか」という関与の深さです。改善・導入経験を伝える際は、以下の構造で整理します。

課題の発見・起点

その改善はどこから始まったか。現場からの声なのか、自分が課題を発見したのか、経営層からの要望なのかを示します。「自分が現状分析をして課題を定義した」という経験は、案件でも同じ動きを期待されるため、評価者の判断材料になります。

検討・選定への関与の深さ

複数のツールや方式を比較検討したか、要件定義に関わったか、コスト試算や稟議資料の作成を担ったかを記載します。「選定段階から関わった」という経験は、ベンダー選定や費用対効果の判断が求められる案件に直結します。

社内展開・定着化の担当範囲

導入後の全社展開、社員向けの説明会・マニュアル作成、問い合わせ対応、定着後の効果確認まで担っていた場合は記載します。ツールの導入だけでなく、組織に定着させるところまで経験していることは、案件先が求める「社内への浸透まで面倒を見られる人材」像と一致します。

改善の「前後」を数字で示せるか確認する

改善経験を伝える際、可能であれば変化の幅を示します。「対応時間が短縮された」「問い合わせ件数が減った」「属人化していた作業が手順書化された」といった変化を、数値や事実で示せる場合は経歴書に記載します。数字が出せない場合でも、「何が変わったか」を具体的に言語化することが評価につながります。

社内調整経験が評価される案件が多い

情シス系の案件要件で繰り返し登場するのが、「IT知識のない社員に対してかみ砕いたコミュニケーションが取れる方」「業務部門・開発チーム・システム部との調整業務」という記述です。技術的なスキルに加えて、社内の複数ステークホルダーとの調整能力が求められています。この能力は、社内SEや情シスとして働いてきた人が日常的に経験していることでありながら、経歴書に書かれにくい領域でもあります。

社内調整経験の記載で伝えるべきこと

誰と・何について調整していたか

IT部門と現場部門の間の要件整理、経営層へのシステム導入の説明・承認取得、他部署からの問い合わせ対応の一次窓口、といった調整の相手と内容を具体的に記載します。「各部署との調整を担当」では伝わらず、「営業部・製造部・経営企画部に対するシステム移行の説明・合意形成を担当」という形で示します。

技術情報を非技術者向けに翻訳していた経験

ITの知識を持たない社員や経営層に対して、技術的な内容をわかりやすく説明した経験は、案件先で同じ役割を期待される場面で評価されます。「IT用語を使わずに現場に説明していた」「システム障害を経営層に報告する資料を作成していた」といった具体的な経験を記載します。

ベンダーコントロール経験の記載で伝えるべきこと

ベンダーコントロールの経験は、「何社・どのような規模のベンダーと・どの範囲で」という構造で整理します。単なる連絡役ではなく、SLAの確認、進捗・品質の管理、トラブル時の対応判断まで担っていた場合はその旨を記載します。ベンダーとの契約内容の整理や見直しに関与した経験があれば、IT調達・コスト管理の観点から評価されます。

また、開発ベンダーに対して要件を伝え、成果物のレビューや品質確認を担っていた場合は、「開発経験なしでも開発案件のベンダー管理が可能な人材」として評価される可能性があります。自分が担っていたのが技術的な開発ではなく要件整理・品質確認・折衝側であることを明示することが、この評価を引き出す書き方になります。

経歴書の構成を案件要件に合わせて組み直す

社内SEとしての経験は多岐にわたるため、経歴書を時系列で書くと「何でもやっていた人」という印象になりがちです。案件獲得に向けた経歴書は、狙う案件カテゴリの要件に合わせて組み直す必要があります。運用・保守系案件を狙うなら管理対象の規模と対応範囲を前面に出し、改善・導入系案件を狙うなら課題の発見から定着まで関わった経験を具体化します。一つの経歴書で全方向をカバーしようとすると、どの案件にも刺さらない内容になります。

使うエージェントと案件媒体の選び方

社内SE・情シス系の案件は、フリーランス向けエージェントと直接案件を持つ媒体の両方に掲載されています。エージェント経由は、案件先との条件交渉や経歴書の調整をサポートしてもらえる点が、初めて業務委託に出る場合には特に有用です。自分の経験をどう伝えるかの整理も、エージェントとの対話の中で行いやすいため、候補の確認と並行して経歴整理を進めることができます。

稼働条件と案件選定の軸を先に決める

週何日稼働できるか、常駐かリモートかどちらを優先するか、関東のどのエリアまで通勤できるかを先に整理しておくことで、候補案件の絞り込みが早くなります。リモート可の案件は情シス系でも増えていますが、常駐を条件とする案件のほうがまだ多い傾向があります。条件の優先順位を自分の中で決めておかないと、複数の案件を比較する際に判断が遅くなります。

初回案件の選定で注意する点

業務委託で最初に受ける案件は、単価よりも自分の経験と要件の合致度で選ぶほうが、参画後のミスマッチを避けやすくなります。「少し背伸びすれば対応できる案件」を狙う判断は、実績がない段階では慎重に行います。エージェントに現在の経験を正確に伝え、要件との適合度を確認した上で応募先を決めることが、継続案件につながる初回参画の条件になります。