社内SE・情シス支援のスキルシートの書き方｜面談で評価される実績の見せ方

社内SE・情シス支援のスキルシートは、環境の規模、社内体制の中での立場、分野ごとの担当範囲の3つをそろえて書くと伝わります。読み手は「この人に、うちの環境のどこを任せられるか」を見ているため、何年いたかより、どんな環境で何を預かっていたかが判断の材料になります。

情シスの仕事は開発のようにプロジェクト単位で区切りにくく、日々の運用と、ときどきの導入や移行が混ざっています。この記事では、その経験を読み手が案件と照らし合わせやすい形にする書き方を、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本をご覧ください。

環境の規模を最初に書く

同じ「アカウント管理」でも、利用者が数十人の会社と数千人の会社では、仕組みの作り方がまったく違います。そのため、所属ごとの欄の冒頭に、環境の規模を書いておきます。

社名や、会社が特定できるほど細かい情報は書きません。利用者の数は、目安の幅で十分です。ネットワーク構成やサーバーの台数・設置場所、IPアドレスの体系といった構成の詳細は、規模を示す目的でも書かないでください。

社内体制の中での立場を書く

情シス支援の経験の重さは、社内に誰がいたかで大きく変わります。同じ作業でも、上司の判断のもとで行ったのか、自分で判断したのかで、任せられる範囲が違って読まれます。

• 「情報システム部門10名のうち、インフラ担当チーム（3名）のメンバー」
• 「IT担当は自分1名。総務部長に報告し、予算の範囲内での判断を任されていた」
• 「運用会社から常駐し、発注元の情シス課長の依頼を受けて作業」

一人で社内のITを担っていた方は、その事実自体が全体を見渡した経験として伝わります。報告先と、自分で決めてよかった範囲を添えると、より正確になります。

分野ごとに担当範囲を書き分ける

情シスの経験は、分野が多岐にわたります。分野ごとに、どの段階まで担ったかを書き分けると、読み手が案件と結び付けやすくなります。段階は次の3つで書くと伝わります。

1. 運用：決められた手順で作業した
2. 設計：手順や構成を自分で決めた、見直した
3. 計画：複数の分野をまたいで優先順位や予算を決めた、決裁者に説明した

分野の分け方は、情シス支援で求められるスキルの記事の6分野（ID・アカウント、端末、SaaS、ネットワークと拠点、セキュリティ、IT企画とベンダー管理）に沿うと整理しやすくなります。

記入例（架空）：分野ごとの書き分け

所属・期間：小売業の事業会社 情報システム課（約5年）
環境の規模：利用者約800名、本社と国内の店舗・物流拠点、クラウド中心（一部オンプレミスのサーバーが残る）
立場：情報システム課4名のうち、アカウントと端末の担当リーダー
分野ごとの担当範囲
・ID・アカウント：設計（入退社の流れを人事の情報と連携させる形に見直し）
・端末：計画（端末の更新計画と予算案を作成し、課長と部長に説明）
・SaaS：運用（利用者の追加・削除、ライセンスの割り当て）
・セキュリティ：設計（多要素認証の全社展開の計画と社内への周知）
・ネットワーク：運用（障害時の一次切り分けと委託先への連絡）
主な取り組みと結果：退職者のアカウントの停止漏れを防ぐため、人事の退職情報をもとに停止の作業を起こす流れに変更。停止までの日数を短くし、月次の確認作業を簡素にした

これは書き方を示すための架空の例です。業種、規模、分野の内容は、ご自身の経験に置き換えてください。

このように書くと、読み手は「アカウントと端末の領域なら設計から任せられる」「ネットワークの設計は経験が浅い」と判断できます。得意でない分野も正直に書いておくほうが、合う案件に早くつながります。

改善の実績は「前・変えたこと・後」で書く

情シスの仕事は、問題が起きないことが成果になりやすく、実績を書きにくいと感じる方が多い仕事です。そのため、改善の実績は「変える前の状態」「変えたこと」「変えた後の状態」の3つで書くと伝わります。

• 前：部門ごとにSaaSを導入しており、全社で何を使っているか把握できていなかった
• 変えたこと：請求の情報と各部門への聞き取りで棚卸しを行い、導入の申請の流れを作った
• 後：利用中のサービスの一覧ができ、使われていない契約を更新時に整理できるようになった

数字で示せる場合は、作業の時間、問い合わせの件数、契約の数などを書きます。ただし、費用の削減額のように会社の内部の情報にあたる数字は、書いてよいかを考えてから載せましょう。書いてよい範囲の考え方はスキルシートに書いてよいこと・いけないことで解説しています。

ベンダー管理の経験は「何を決めたか」で書く

情シスの経験の中でも、ベンダーとの関わりは、上流の経験として評価されやすい部分です。ただ、「ベンダー管理」とだけ書くと、窓口として連絡を取り次いでいたのか、選定や契約の判断に関わっていたのかが分かりません。

次のように、関わった場面と自分が決めたことを書きます。

• 見積もりの比較の観点を作り、複数社から選定の案をまとめて部長に報告した
• 保守契約の更新の時期を一覧にし、更新前に内容と費用の見直しを提案した
• 委託先の作業の報告の形式を決め、毎月の定例で確認した

外部の立場で参画した経験の場合も、発注元の判断をどう支えたかを書けば、同じように伝えられます。

製品名は「何に使ったか」と一緒に書く

情シスのスキルシートには、ディレクトリサービス、端末管理、グループウェア、SaaSなど、多くの製品名が並びがちです。製品名だけを並べると、触ったことがあるだけなのか、設計まで担ったのかが読み手に伝わりません。

製品名は、使った目的と担当の段階を添えて書きます。

製品の名前や機能の範囲は変わることがあるため、製品名より「何をどう管理したか」を中心に書いておくと、時間がたっても意味が通じます。

提出前の見直しポイント

1. 所属ごとに環境の規模（利用者の幅、拠点、主な環境）が書かれているか
2. 社内体制の中での立場と、報告先が分かるか
3. 分野ごとに、運用・設計・計画のどの段階かが書き分けられているか
4. 改善の実績が「前・変えたこと・後」で書かれているか
5. 社名、構成の詳細、事故の具体的な内容を書いていないか

古い情報のまま使い回さないよう、案件が終わるたびに書き足しておくと、提出のたびに慌てずに済みます。

よくある質問

日々の運用が中心で、書ける実績がありません。どうすればよいですか？

運用の中でも、手順を少し変えて手間を減らした、問い合わせの多い作業の手順書を作った、といった小さな改善は実績として書けます。「前・変えたこと・後」の形で振り返ると、当たり前にしていた工夫が見つかることがあります。

複数の会社の情シス業務を並行して支援していた場合は、どう書きますか？

支援先ごとに欄を分け、それぞれの環境の規模、立場、担当範囲を書きます。あわせて期間と稼働の割合の目安（週何日程度など）を添えると、関わりの深さが正確に伝わります。業種が同じで支援の内容も似ている場合は、まとめて書く方法もあります。

ヘルプデスクの経験も書いたほうがよいですか？

書いてかまいません。ただ、情シス支援の案件に応募する場合は、問い合わせ対応の件数より、問い合わせの傾向から手順や設定を見直した経験を前に出すと伝わりやすくなります。一次対応が中心の経験は短くまとめ、仕組みに関わった経験を詳しく書くことをおすすめします。