目次
  1. はじめに:「経歴書_最新_v3_修正済(2).xlsx」問題
  2. Excelスキルシート運用の4つの構造的な課題
  3. 設計判断①:自由記述をやめる — 選択式+タグで表記ゆれを止める
  4. 設計判断②:印刷様式はExcel原本から変えない
  5. 設計判断③:SQLite+Docker — 「サーバー1台で今日入れられる」こと
  6. 設計判断④:単金は管理者だけが見える権限設計
  7. 契約管理と提案支援:カレンダーとワンクリックコピー
  8. まとめ:Excelを捨てたのではなく、Excelの「出口」だけを残した

はじめに:「経歴書_最新_v3_修正済(2).xlsx」問題

SES・人材派遣の業界では、エンジニアの業務経歴書(スキルシート)は今も圧倒的にExcelで管理されています。取引先に提出する様式がExcelで決まっているのだから当然ではあるのですが、その結果として共有フォルダには 「経歴書_山田_最新.xlsx」「経歴書_山田_最新_v3.xlsx」「経歴書_山田_最新_v3_修正済(2).xlsx」 が並ぶことになります。どれが本当の最新版なのかは、更新した本人しか知りません。

弊社も例外ではありませんでした。そこで、Excelで管理していた業務経歴書をWebで一元管理する社内システムとして「スキルシートポータル」を開発し、従業員が自分のスキルシートをスマホから編集できる体制に切り替えました。本記事では、その際にどのような設計判断をしたのかを、実務目線で解説します。

単なる「ExcelをWebフォームに置き換えました」という話ではありません。むしろ設計の大半は、「Excelの何を捨てて、何を絶対に残すか」の線引きに費やされました。同じ課題を抱えるIT管理者・情シス担当の方、そしてSES・派遣会社で営業や稼動管理をされている方の参考になれば幸いです。

この記事で扱う範囲

本記事は弊社が自社開発した「スキルシートポータル」の設計判断を題材にしています。社内利用から出発したシステムを、現在は SES・派遣会社向け製品 として提供しています。

Excelスキルシート運用の4つの構造的な課題

まず、Excel運用の何が問題なのかを整理します。ポイントは、これらが「担当者の注意不足」ではなく仕組みの問題だということです。注意で解決できるならとっくに解決しています。

1. 最新版がどれか分からない

Excelファイルはコピーした瞬間に分岐します。エンジニア本人が持っている版、営業が提案用に手直しした版、共有フォルダの版。案件提案の直前に「これ最新?」の確認連絡が飛び交い、確認できないまま古い経歴で提案してしまうこともあります。ファイル名の命名規則をいくら整備しても、「コピーできる」という性質そのものが原因なので根絶できません。

2. 書式・表記がばらつく

「Java」「JAVA」「java」。「詳細設計」「基本設計・詳細設計」「設計」。書く人が違えば表記は必ずばらつきます。セルの結合を壊す人、行を勝手に増やす人、フォントを変える人も現れます。提出前に営業が全シートを目視で整える作業が発生し、これが提案のリードタイムを直接押し上げます。

3. 契約終了日の見落とし

スキルシートとは別に、誰がどの常駐先にいつまでの契約でいるかを管理する台帳(これもたいていExcel)があります。シートと台帳が別ファイルなので突き合わせは手作業になり、契約終了日が近い要員の把握が漏れると、更新交渉や次案件の提案が後手に回ります。SES事業では、これは単なる事務ミスではなく売上に直結する事故です。

4. 提案のたびに同じ手作業

案件提案のメールを書くたびに、経歴書を開いて要点を拾い、定型文に貼り込む。1通あたりは数分でも、提案数が増えるほど累積します。しかも元データの表記がばらついているので、貼り込むたびに手直しが入ります。

共通する原因

4つの課題はすべて「データと帳票が分離されていない」ことに帰着します。Excelはデータ置き場と提出帳票を1つのファイルが兼ねているため、コピー・改変・突き合わせのすべてが人力になります。Web化とは、この2つを分離する作業だと言えます。

設計判断①:自由記述をやめる — 選択式+タグで表記ゆれを止める

Web化するとき最初に決めたのは、「Excelのセルをそのままテキストボックスに置き換えない」ことでした。自由記述のまま入力欄をWebに移しても、表記ゆれはExcel時代と何も変わりません。フィールドの性質ごとに入力方式を分けています。

項目入力方式ねらい
担当(PG/SE/PL等)・開発フェーズ 固定の選択式(自由記述させない) 語彙が有限なので選択式で完全に統制できる
言語・DB・機種OS・資格 タグ入力(マスタ候補からサジェスト) 語彙が増え続けるので選択式にはできない。候補優先+新出語の事後統制で対応
案件の期間 年月ピッカー 経過期間・年齢・実務経験年数を自動計算(原本Excelと同じ「(2年12ヶ月)」表記)
案件名・業務内容 自由記述+書き方ガイドとプレースホルダ例 統制しきれない部分は「良い書き方の例」を入力欄に常時表示して寄せる

ここで実務上いちばん悩んだのが技術キーワードの扱いです。担当やフェーズと違って、言語・フレームワークは毎年新顔が出ます。完全な選択式にすると「候補にないから入力できない」が頻発し、かといって完全な自由入力に戻すと表記ゆれが復活します。

採用したのは「サジェスト優先+事後統制」の折衷案です。入力時はマスタ候補からのサジェストを優先しつつ、新出キーワードはその場で自動的にマスタへ追加して入力を止めません。そのうえで管理者が選択肢マスタの管理画面から、後で「JAVA→Java」のような表記ゆれを整理します。入力する従業員の手を止めないことと語彙が最終的に収束することを両立させる、地味ですが効きどころの設計です。

設計の教訓

表記ゆれ対策を「入力時に厳格化する」方向だけで考えると、現場の入力率が下がって元のExcelに戻ります。入力時はゆるく受けて、統制は管理者側の作業に寄せる方が、業務システムとしては長続きします。

設計判断②:印刷様式はExcel原本から変えない

Web化プロジェクトでありがちな失敗は、帳票のレイアウトまで「モダンに」作り直してしまうことです。しかしSES・派遣の実務では、スキルシートは取引先に提出する帳票であり、先方の担当者は長年見慣れた様式で読みます。「御社のシート、様式が変わりましたね」は、この業界ではほめ言葉ではありません。

そこでスキルシートポータルでは、印刷画面を従来のExcel様式をそのまま踏襲したA4レイアウトとして実装しました。ブラウザの印刷機能からそのまま出力でき、PDFとしての出力にも対応しています。年齢や実務経験年数の「(2年12ヶ月)」といった経過表記も原本Excelと同じ形式で自動計算されるため、提出物だけを見れば従来と区別がつきません。

つまりこのシステムの本質は「Excelをやめる」ことではなく、データの管理と入力をWebに移し、Excel様式は出口(帳票)として温存することです。社内のデータフローだけを入れ替えるので、取引先への説明も調整も一切不要でした。既存業務システムの刷新一般に通じる考え方だと思います。

技術的には、画面用のCSSと印刷用のCSSを分け、印刷時のみExcel原本の罫線・段組を再現するアプローチです。帳票専用のPDF生成ライブラリを持ち込むより、ブラウザの印刷エンジンに任せる方が、A4一枚ものの帳票では保守がはるかに楽です。

設計判断③:SQLite+Docker — 「サーバー1台で今日入れられる」こと

技術構成は Next.js 15(App Router / Server Actions)+ TypeScript、データベースは SQLite(better-sqlite3)、配布形態は Docker です。「業務システムなのにSQLite?」と思われるかもしれませんが、これは明確な意図を持った選択です。

なぜPostgreSQLやMySQLではないのか

スキルシート管理の負荷特性を考えると、書き込みは従業員が経歴を更新するときだけ、読み取りも社内の管理者と本人が中心です。数十〜数百名規模の名簿系システムに、DBサーバーという「運用しなければならないもの」を1つ増やす理由がありません。

  • 導入が1コマンド:DBコンテナの起動もユーザー作成も不要。docker compose up -d --build だけで、初回起動時にスキーマ作成とシード投入まで自動で走ります
  • バックアップがディレクトリコピー:データは ./data/ 配下のSQLiteファイルに永続化されるので、バックアップはこのディレクトリをコピーするだけ。専任の情シスがいない会社でも運用できます
  • 認証も自己完結:HMAC署名Cookie+scryptパスワードハッシュで実装し、外部のID基盤を必要としません。導入時に用意するのはサーバー1台だけです

中小のSES・派遣会社にとって、システム導入の最大の障壁は機能ではなく「面倒を見きれるか」です。可用性やスケールのための構成要素を足すほど、その障壁は上がります。SQLite+Dockerは「技術的に妥協した」のではなく、導入ハードルという要件に対して最適化した結果です。

マルチテナントは環境変数で切る

もう1つ、シンプルさを優先した判断がマルチテナントの実装です。1つのDBの中にテナントIDを持たせるスキーマレベルのマルチテナントではなく、会社ごとにコンテナとDBファイルを分離し、会社名は環境変数 COMPANY_NAME で切り替える方式にしました。会社名はログイン画面・タイトル・印刷帳票に反映され、別会社の環境は別ポート・別データディレクトリで並走します。

スキーマレベルのマルチテナントは、テナント間のデータ漏えいを防ぐ実装・テストのコストが恒常的にかかります。会社単位でプロセスごと分けてしまえば、漏えいの経路が構造的に存在しない。テナント数が数千になるSaaSなら別の解を選びますが、この規模感ではこちらが正解だと考えています。

設計判断④:単金は管理者だけが見える権限設計

SES・派遣の管理で最もセンシティブなデータは単金(月あたりの契約単価)です。Excel運用時代は「単金入りの台帳」と「単金なしのシート」を別ファイルで持つことで擬似的に権限を分けていましたが、ファイルの渡し間違い1つで崩壊する運用です。

スキルシートポータルでは、ロールを従業員と管理者の2段階に分け、単金(万円/月)は管理者ロールのみ閲覧可能としました。従業員は自分のスキルシートと経歴を編集できますが、単金のフィールドは画面上に存在すら現れません。管理者側では、全従業員のシート閲覧・代理編集・従業員マスタ管理(追加・停止・パスワード再設定)に加えて、単金の月次合計を確認できます。稼動中の契約から今月の売上規模がすぐ把握できるため、経営側の数字確認がExcel集計から解放されます。

権限設計で意識したのは「隠す」より「そもそも渡さない」ことです。画面で非表示にするだけの実装は、APIレスポンスに値が残っていれば意味がありません。単金はサーバー側で管理者セッションのときだけ応答に含める。当たり前のことですが、Excelの「ファイルを分けて運用でカバー」と比べたときのWeb化の本質的な利点は、まさにこの権限をコードで強制できる点にあります。

代理編集という現実解

権限を分けると「本人しか編集できないので更新が進まない」という新しい問題が生まれます。そこで管理者には代理編集を許可しました。スマホから自分で更新するのが基本線ですが、忙しい現場のエンジニアの分は事務側で代行入力できる。理想論だけの権限設計は現場で必ず破綻します。

契約管理と提案支援:カレンダーとワンクリックコピー

スキルシートを一元化すると、次に欲しくなるのは「その人が今どこで、いつまで稼動しているか」です。スキルシートポータルには契約管理の機能を組み込み、取引先・常駐先・稼動開始日・契約終了日を契約単位で登録し、履歴として蓄積できるようにしました。

契約カレンダー:終了日を「探す」から「目に入る」へ

契約情報は契約カレンダーとして時系列で一覧できます。Excel台帳との決定的な違いは、契約終了日を「フィルタして探す」のではなく「開けば目に入る」ことです。前述のとおり、契約終了日の見落としはSESの売上に直結する事故です。台帳の目視チェックという属人作業を、画面を開くだけの動作に置き換えました。終了が近い要員が見えれば、更新交渉を前倒しできますし、次の提案準備も「終了日から逆算」で動けます。

提案メールのテンプレ文をワンクリックコピー

提案業務の支援として、スキルシートのデータから提案メール用のテンプレ文を生成し、ワンクリックでコピーできる機能を用意しました。営業はコピーした文面をメールに貼り付けて、案件固有の内容だけ書き足せば提案が完成します。

これは機能としては小さいのですが、設計判断①〜②とつながっています。担当・フェーズが選択式で、技術キーワードがマスタ統制されているからこそ、機械的に生成した文面がそのまま使える品質になる。入力時の統制は、出力の自動化のための投資だったわけです。自由記述だらけのデータからテンプレ文を作っても、結局全文を手直しすることになります。

まとめ:Excelを捨てたのではなく、Excelの「出口」だけを残した

この記事のまとめ

  • Excelスキルシートの問題(最新版不明・表記ゆれ・終了日見落とし・提案の手作業)は注意不足ではなく、データと帳票が分離されていない構造の問題
  • 表記ゆれは「選択式+マスタ管理タグ+事後統制」で、入力者の手を止めずに収束させる
  • 取引先に出す帳票の様式は変えない。A4印刷はExcel原本を踏襲し、社内のデータフローだけを入れ替える
  • SQLite+Dockerは妥協ではなく、「サーバー1台・1コマンドで導入できる」という要件への最適化
  • 単金は管理者のみ閲覧。権限をファイル運用ではなくコードで強制できるのがWeb化の本質的な利点
  • 契約カレンダーとテンプレ文コピーで、契約更新と提案の初動を早くする

振り返ると、このシステムの設計判断はどれも「Excelの何が本当に必要だったのか」を切り分ける作業でした。必要だったのは取引先に出す様式であって、コピーで増殖するファイルでも、自由記述のセルでもなかった。この切り分けさえ間違えなければ、スキルシートのWeb化は現場の反発なく定着します。

このスキルシートポータルは弊社の社内利用から出発し、現在はSES・派遣会社向けに製品として提供しています。詳しい機能や画面は スキルシートポータル のページをご覧ください。

スキルシート管理に限らず、Excel運用の業務をWebシステム化する開発は Webシステム開発 として承っています。

/SES・派遣会社向けに提供しています\

スキルシートポータル|業務経歴書のWeb一元管理

本記事で紹介したシステムをそのままお使いいただけます。スマホからの経歴編集、Excel原本様式のA4印刷・PDF出力、契約カレンダー、単金の権限管理まで。Docker+SQLite構成でサーバー1台から導入できます。

よくある質問(FAQ)

スキルシートのExcel管理をやめてWeb化するメリットは?

最新版が常に1か所に集約され、「どのファイルが最新か」問題が消えます。従業員はスマホから自分で更新でき、担当・フェーズ・技術キーワードをマスタ管理することで書式や表記のばらつきも仕組みで防げます。契約終了日もカレンダーで一覧でき、更新漏れの防止につながります。

Web化しても取引先に提出するスキルシートの様式は維持できますか?

可能です。弊社のスキルシートポータルでは、従来使っていたExcel様式をそのまま踏襲したA4印刷レイアウトを実装しており、ブラウザの印刷機能からそのまま出力できます。PDF出力にも対応しているため、取引先への提出フローを変えずに社内管理だけをWeb化できます。

スキルシートの表記ゆれ(JAVAとJavaなど)を防ぐにはどうすればいいですか?

自由記述をやめるのが最も効果的です。担当(PG/SE/PL等)や開発フェーズは固定の選択式にし、言語・DB・OS・資格はマスタ候補からサジェストされるタグ入力にします。新しいキーワードは自動でマスタに追加し、管理者が後から表記ゆれを整理できる運用にすると、入力の手間を増やさずに統一できます。

中小のSES企業でもスキルシート管理システムを導入できますか?

できます。弊社のスキルシートポータルはDocker+SQLite構成のため、専用のDBサーバーが不要で、サーバー1台にコマンド1つで導入できます。バックアップもデータディレクトリのコピーだけで完了し、環境変数で会社名を切り替えられるため、小規模な体制でも運用負荷を最小限に抑えられます。詳細は スキルシートポータル をご覧ください。

次に読む|関連コンテンツ