会社情報
採用情報
お問い合わせ
Article

SESエンジニアの勤怠・評価管理：外部人材を適切にマネジメントする方法

高田晃太郎
SESエンジニアの勤怠・評価管理：外部人材を適切にマネジメントする方法

経済産業省の公表資料では2030年に国内IT人材が最大79万人不足すると予測され、外部人材を活用した開発体制はもはや例外ではありません¹。SES（準委任契約で時間単価ベースの提供形態）では、月次請求は勤怠×単価で決まり、わずかな記録のズレが粗利を侵食します。例えば単価90万円・稼働目安180時間の契約で未申請5時間が出ると約2.5％の請求漏れに相当し、粗利率30％の現場なら粗利ベースで0.75％以上の毀損につながります。公開資料や一般的な実務事例を踏まえると、勤怠の正確性と評価の透明性を同時に設計することが、外部人材マネジメントの損益を左右する主要因です。労働時間の把握義務や時間外上限規制といった基本²をおさえつつ、データで運用を平準化することが経営と現場の双方に効きます。ここでは、SESの契約と現場の実務をつなぐために必要なデータモデル、実装例、評価設計、そしてROIまでを、実装可能なレベルで解説します。

なぜSESの勤怠・評価は難しいのか：契約、現場、データの三層問題

難しさの根は、契約条件の粒度と現場の実績粒度の非対称にあります。契約書では人月（1人×1カ月の稼働を単位化）、精算幅（請求可能な時間の上下限）、控除・超過の単価、稼働場所やセキュリティ条件が条文化されます。一方、現場で発生する実績は日単位・15分単位・作業種別単位のように細かく、途中でバックログの優先順位や障害対応が割り込むため、予定と実績は常にズレ続けます。このズレを人の目だけで突き合わせると、承認のリードタイムが長くなり、締め処理で修正依頼が多発します。さらに、評価は請求と並走しづらいという構造問題があります。評価軸が成果物の品質やチーム行動（ルーブリック＝評価基準のこと）に寄るのに対し、請求は稼働時間に依存するため、両立のためにはルーブリックの分解とデータの連結が必要です。労務リスクの観点でも、長時間労働の兆候を週次で把握する仕組みがなければ、精算幅の活用より先に安全配慮義務が先行します³。結局のところ、契約・勤怠・評価を同一のスキーマで結ぶことが最短距離になります。

リスクの正体を数値化する：ズレがもたらす経済影響

最も起こりやすいのは、未申請や丸め誤差による1〜3％の請求漏れと、精算幅の上限を意識しない過稼働による逸失利益です。1名あたり月180時間の基準で、日々の5分単位の丸めが1日20分の未申請につながると、月8時間のギャップになります。単価90万円・精算幅140-200h・超過単価5,000円/hという設定なら、月4万円以上の差分が生まれ、複数名のアサインでは累積が膨らみます。評価側では、PRのリードタイムやレビュー密度のデータが取れていないと、見込みの価値貢献が伝わらず、単価改定交渉で不利になります。

ガバナンスと自律性の両立：過度な手作業をやめる

週次のエビデンスチェックを人手でやる限り、締め前の駆け込み修正が常態化します。APIで収集したエビデンス（勤怠、コードレビュー、チケット処理、カレンダー、セキュリティログ）を正規化し、閾値を越えたときだけレビューする仕掛けに切り替えると、承認リードタイムは大幅に短縮できます。標準化されたスキーマとイベント駆動のワークフローが鍵です。

勤怠の正確性を担保するデータ設計と実装：スキーマ、整合性チェック、可視化

まずは構造を決めます。契約、アサイン、勤怠、エビデンス、評価の五系統を分離し、キーで疎結合に保ちます。単一の attendance_logs に集約するのではなく、境界づけられたコンテキスト（領域ごとの責務分割）の間をビューで橋渡しするのが保守性に優れます。次のDDLは、請求計算と監査を両立する最小構成です。難しく見えても、要点は「テーブルは役割ごとに分け、月次集計はビューで再計算する」だけです。

-- PostgreSQL: 契約・アサイン・勤怠・監査の最小スキーマ
CREATE TABLE projects (
  project_id SERIAL PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE contracts (
  contract_id SERIAL PRIMARY KEY,
  project_id INT REFERENCES projects(project_id),
  vendor TEXT NOT NULL,
  engineer_external_id TEXT NOT NULL,
  unit_price_month INTEGER NOT NULL,       -- 人月単価（円）
  min_hours INTEGER NOT NULL,              -- 精算下限
  max_hours INTEGER NOT NULL,              -- 精算上限
  over_rate INTEGER NOT NULL,              -- 超過単価（円/時）
  under_rate INTEGER NOT NULL,             -- 控除単価（円/時）
  start_date DATE NOT NULL,
  end_date DATE NOT NULL
);

CREATE TABLE assignments (
  assignment_id SERIAL PRIMARY KEY,
  contract_id INT REFERENCES contracts(contract_id),
  start_date DATE NOT NULL,
  end_date DATE NOT NULL,
  role TEXT,
  work_location TEXT
);

CREATE TABLE attendance_logs (
  attendance_id BIGSERIAL PRIMARY KEY,
  assignment_id INT REFERENCES assignments(assignment_id),
  work_date DATE NOT NULL,
  start_at TIMESTAMPTZ NOT NULL,
  end_at TIMESTAMPTZ NOT NULL,
  task_type TEXT,
  source TEXT NOT NULL,                    -- form, api, manual
  source_ref TEXT,
  created_at TIMESTAMPTZ DEFAULT now(),
  CHECK (end_at > start_at)
);

CREATE TABLE evidence (
  evidence_id BIGSERIAL PRIMARY KEY,
  attendance_id BIGINT REFERENCES attendance_logs(attendance_id),
  evidence_type TEXT NOT NULL,             -- git, jira, calendar, vpn
  evidence_ref TEXT,
  score NUMERIC(5,2),                      -- 一致度スコア
  captured_at TIMESTAMPTZ DEFAULT now()
);

CREATE MATERIALIZED VIEW monthly_billing AS
SELECT c.contract_id,
       date_trunc('month', a.work_date) AS month,
       SUM(EXTRACT(EPOCH FROM (a.end_at - a.start_at))/3600)::numeric(10,2) AS hours,
       c.unit_price_month, c.min_hours, c.max_hours, c.over_rate, c.under_rate
FROM attendance_logs a
JOIN assignments s ON a.assignment_id = s.assignment_id
JOIN contracts c ON s.contract_id = c.contract_id
GROUP BY 1,2,3,4,5,6,7,8;

整合性はビューだけでは守れません。予定と実績、カレンダー、ソースコードの活動ログを突き合わせ、閾値未満の一致は承認保留にします。次のSQLは「エビデンスの薄い勤怠の抽出」と「月次の精算幅に基づく調整額の算出」です。どちらもSESの勤怠管理と請求管理を自動化するうえでの基本チェックです。

-- エビデンスのない勤怠を抽出（監査キュー）
SELECT a.attendance_id, a.work_date, a.assignment_id
FROM attendance_logs a
LEFT JOIN evidence e ON e.attendance_id = a.attendance_id
GROUP BY a.attendance_id, a.work_date, a.assignment_id
HAVING COALESCE(SUM(CASE WHEN e.score >= 0.6 THEN 1 ELSE 0 END), 0) = 0;

-- 月次請求時間と精算幅の差分を計算
SELECT contract_id, month, hours,
       CASE WHEN hours > max_hours THEN (hours - max_hours) * over_rate
            WHEN hours < min_hours THEN (min_hours - hours) * under_rate
            ELSE 0 END AS adjustment_amount
FROM monthly_billing;

CSVやSaaSのAPIから取り込む際の正規化は、データ品質の首根っこです。タイムゾーンを統一し、丸めルールを固定するだけで請求の安定度が上がります。以下はPythonで入力差異を吸収する例です。

import pandas as pd
from datetime import datetime
import pytz

JST = pytz.timezone('Asia/Tokyo')

def normalize_timesheet(df: pd.DataFrame) -> pd.DataFrame:
    try:
        df = df.copy()
        df['start_at'] = pd.to_datetime(df['start_at'], utc=True).dt.tz_convert(JST)
        df['end_at'] = pd.to_datetime(df['end_at'], utc=True).dt.tz_convert(JST)
        df['work_date'] = df['start_at'].dt.date
        -- 5分単位で丸め
        def round5(ts):
            minute = (ts.minute // 5) * 5
            return ts.replace(minute=minute, second=0, microsecond=0)
        df['start_at'] = df['start_at'].apply(round5)
        df['end_at'] = df['end_at'].apply(round5)
        df['hours'] = (df['end_at'] - df['start_at']).dt.total_seconds() / 3600
        df = df[df['hours'] > 0]
        return df
    except Exception as e:
        raise ValueError(f"Timesheet normalization failed: {e}")

if __name__ == '__main__':
    raw = pd.read_csv('timesheet.csv')
    normalized = normalize_timesheet(raw)
    normalized.to_csv('timesheet_normalized.csv', index=False)

ソースコードやチケットの活動と勤怠の一致を擬似的にスコア化して保存すると、監査の粒度を保ちながらレビュー作業を削減できます。以下はGitHubのPRを取得し、PRの滞留時間とレビュー密度を計算して評価に供する例です。

import { graphql } from '@octokit/graphql';
import dayjs from 'dayjs';

const client = graphql.defaults({
  headers: { authorization: `token ${process.env.GITHUB_TOKEN}` },
});

async function fetchPrMetrics(owner: string, repo: string) {
  try {
    const query = `
      query($owner:String!, $repo:String!) {
        repository(owner:$owner, name:$repo) {
          pullRequests(last:50, states:MERGED) {
            nodes {
              number
              createdAt
              mergedAt
              reviews(first:50) { totalCount }
              additions
              deletions
            }
          }
        }
      }`;
    const data = await client(query, { owner, repo });
    const prs = data.repository.pullRequests.nodes;
    return prs.map((pr: any) => {
      const leadHours = dayjs(pr.mergedAt).diff(dayjs(pr.createdAt), 'hour');
      const churn = pr.additions + pr.deletions;
      return { number: pr.number, leadHours, reviews: pr.reviews.totalCount, churn };
    });
  } catch (e) {
    console.error('GitHub API error', e);
    return [];
  }
}

fetchPrMetrics('your-org', 'your-repo').then(console.log);

カレンダーやVPNログを活用した在席のエビデンス化も、過度にならない範囲で検討できます。Google Apps Scriptで日次報告フォームの未提出者にリマインドを送り、二重申請を防ぐ仕掛けは軽量かつ効果的です。

function remindMissingDailyReports() {
  const ss = SpreadsheetApp.getActive();
  const sheet = ss.getSheetByName('daily_reports');
  const data = sheet.getDataRange().getValues();
  const today = Utilities.formatDate(new Date(), 'Asia/Tokyo', 'yyyy-MM-dd');
  const header = data[0];
  const idxDate = header.indexOf('date');
  const idxName = header.indexOf('name');
  const idxSlack = header.indexOf('slack_id');
  const submitted = new Set(
    data.filter((row, i) => i > 0 && row[idxDate] === today).map(row => row[idxName])
  );
  const roster = ss.getSheetByName('roster').getDataRange().getValues().slice(1);
  roster.forEach(row => {
    const name = row[0];
    const slack = row[idxSlack];
    if (!submitted.has(name)) {
      UrlFetchApp.fetch('https://hooks.slack.com/services/xxx/yyy/zzz', {
        method: 'post',
        contentType: 'application/json',
        payload: JSON.stringify({ text: `未提出: ${name} さん、本日の報告をお願いします。` })
      });
    }
  });
}

ダッシュボードでは、承認までのリードタイム、エビデンス一致度、精算幅の超過・未達、月次の請求調整額、長時間労働の兆候を時系列で並べ、週1回のレビューで異常のみを見る運用が狙い目です。内部の標準記事として、評価ルーブリックの定義や契約条項の辞書を公開し、ベンダー間のバラつきを吸収すると立ち上がりが早まります。

評価の透明性を高める：ルーブリック、DORA指標、請求との接続

SESの評価は、請求の根拠である勤怠だけでは語り尽くせません。コードの変更量、レビュー密度、PRの滞留時間、チケットのスループットといった行動の代理指標を用いながら、成果物の品質とチームへの貢献を定義します。これらの指標はベンダーや個人差の影響を受けるため、絶対値ではなく、契約開始からのトレンドやチーム中央値との偏差を重視すると、不公平感を抑えられます。ルーブリックは、行動（例：レビューの丁寧さ、論点の明確さ）、アウトカム（例：欠陥の再発率の低下）、プロセス遵守（例：セキュリティルールの遵守）に分け、契約更新や単価改定の根拠に結びます。DORA（DevOps Research and Assessment）の研究知見を活用すると、デリバリーの健全性を業界標準の物差しで捉えやすくなります⁴。

評価ルーブリックをデータ化する：JSON Schemaで合意を固める

曖昧さを避けるため、ルーブリックそのものをスキーマ化し、レビューのたびに機械可読な形で記録します。次の例は最低限の形です。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "EngineerEvaluation",
  "type": "object",
  "properties": {
    "assignment_id": { "type": "integer" },
    "period": { "type": "string", "pattern": "^\\d{4}-\\d{2}$" },
    "scores": {
      "type": "object",
      "properties": {
        "code_quality": { "type": "number", "minimum": 1, "maximum": 5 },
        "review_depth": { "type": "number", "minimum": 1, "maximum": 5 },
        "delivery": { "type": "number", "minimum": 1, "maximum": 5 },
        "collaboration": { "type": "number", "minimum": 1, "maximum": 5 }
      },
      "required": ["code_quality", "delivery"]
    },
    "evidence_refs": { "type": "array", "items": { "type": "string" } },
    "comment": { "type": "string" }
  },
  "required": ["assignment_id", "period", "scores"]
}

スキーマに合わせて、GitHubやJiraからのデータを正規化し、評価時の参照リンクを自動添付します。エビデンスの所在が明確になると、レビュー会の議論は「感じ」から「根拠」に移り、外部人材との期待値調整が容易になります。

ビジネスと接続する：請求と評価の両利き運用

請求処理は締めに間に合うことが最優先ですが、評価の反映は四半期に一度のペースでも十分です。短期は勤怠の正確性、長期は価値貢献の可視化と位置づけ、四半期末にルーブリックのスコアとDORA系のトレンドを添えて、単価の見直しやアサインの調整案を用意します。これにより、現場の体感と契約交渉の材料をひとつのパッケージにできます。

運用を回す仕掛け：SLA、アラート、リードタイム短縮のための自動化

承認リードタイムの短縮は、請求の安定化と労務リスクの低減に直結します。目標値として、日次入力の当日中率95％、週次承認の翌営業日完了率90％、締め前の修正依頼率を5％未満といったSLA（サービス水準）を置きます。これらは高いように見えても、正規化された取り込みとアラートの自動化があれば到達可能です。技術的には、例外のみを人間が見る形に寄せていくのがコツです。

例外検知の実装例：勤怠×カレンダー×Gitの突合

軽量なバッチで良いので、複数ソースの差分を突合し、閾値を越えた件だけレビューキューに積みます。以下はPythonでの突合例です。

import pandas as pd
import numpy as np

def detect_anomalies(timesheet: pd.DataFrame, calendar: pd.DataFrame, commits: pd.DataFrame) -> pd.DataFrame:
    df = timesheet.copy()
    cal = calendar.groupby('date').size().rename('calendar_events')
    git = commits.groupby('date').size().rename('commit_count')
    df = df.merge(cal, how='left', left_on='work_date', right_index=True)
    df = df.merge(git, how='left', left_on='work_date', right_index=True)
    df['calendar_events'] = df['calendar_events'].fillna(0)
    df['commit_count'] = df['commit_count'].fillna(0)
    df['evidence_score'] = np.where(df['commit_count'] > 0, 0.6, 0) + np.where(df['calendar_events'] > 0, 0.4, 0)
    return df[df['evidence_score'] < 0.6]

検知後の通知は、チャンネルを分けると騒音を抑えられます。緊急はチャット、通常は週次のレポートに集約し、承認権限者だけが即時対応すべきものに限定します。ルールはシンプルにし、変更履歴をドキュメント化すると運用負債が溜まりません。

クラウド台帳にまとめる：監査と経理の両立

経理と監査の観点では、変更履歴と根拠の可視化が最重要です。クラウドの台帳に全変更をイベントとして書き込み、差分を復元可能にします。以下はNode.jsで監査ログを安全に格納する最小例です。

import crypto from 'crypto';
import { Firestore } from '@google-cloud/firestore';

const db = new Firestore();

async function appendAudit(event) {
  const hash = crypto
    .createHash('sha256')
    .update(JSON.stringify(event))
    .digest('hex');
  try {
    await db.collection('audit_events').add({
      ...event,
      hash,
      created_at: new Date().toISOString(),
    });
  } catch (e) {
    console.error('audit write failed', e);
    throw e;
  }
}

appendAudit({ type: 'attendance_update', attendance_id: 123, actor: 'approver@corp', from: '8.0', to: '7.5' });

この仕組みを入れると、締め処理や後追い監査での説明責任を果たしやすくなります。可観測性の高い運用は、ベンダー側の信頼にも直結します。

数字で語る運用改善：目標値、ROI、経営への説明

改善の効果は、誰に説明しても通じる言葉に翻訳する必要があります。請求漏れ率、承認リードタイム、精算幅超過の発生率、四半期ごとの単価改定成功率を継続的にトラッキングし、投資対効果（ROI）を示します。仮に月20名体制のプロジェクトで、初期は請求漏れ率1.5％、承認リードタイム平均3.2営業日、修正依頼率12％だったとします。データモデル標準化と例外アラート運用に切り替え、三か月で請求漏れ率0.3％、承認リードタイム1.1営業日、修正依頼率4％まで改善できれば、月額2,000万円規模の請求で年間約240万円の増分効果が見込めます。これにかけたSaaS費や開発稼働を加味しても、回収期間は半年以内に収まるシナリオが現実的です。評価面では、PRリードタイムの中央値が25％短縮し、レビュー密度の上昇によって欠陥再発率が低下したなら、チームのスループット向上として経営に説明できます。

現場導入の壁を越える：最小習慣とガードレール

習慣の変更が最大の難所です。入力は当日中、承認は翌営業日、例外は自動検知という三つの行動だけを徹底し、他はツールに任せます。細かな規則を増やすより、ガードレールを置いて逸脱時だけ強く通知する方が、外部人材が混じるチームでは持続します。オンボーディング資料を共通化し、短い動画とサンプルデータを配布して、初回の心理的負荷を下げる工夫も効果的です。

契約条項との整合：精算幅、立替、障害対応

最後に、運用は契約条項と不可分です。精算幅の定義、障害対応の待機や夜間作業の扱い、交通費やアカウント費の立替可否などをデータ項目として持ち、請求時のロジックに織り込みます。スキーマに入っていなければ、運用では永遠に吸収されません。逆に、スキーマ化された条項は監査と説明の根拠になります。

まとめ：データで揺らぎを減らし、人に集中する

外部人材を前提にした開発は、関係者が多く、期待も役割も揺らぎます。だからこそ、勤怠・評価・契約を貫く共通スキーマと、例外だけを見る運用へ寄せることが、現場の負担を減らし、経営の再現性を高めます。ここで紹介したデータモデル、SQL、API連携、ルーブリックのスキーマ化は、どれも明日から始められる現実解です。まずは既存の勤怠データを正規化し、エビデンスの突合と承認SLAの目標値を置いてみてください。三か月後に検証のレビューを入れれば、改善の手応えが言葉ではなく数字で立ち上がるはずです。あなたのチームは、どの指標から整えていきますか。次のスプリントの計画に、ひとつだけでも組み込んでみましょう。

参考文献

  1. 日刊工業新聞. 経産省、IT人材不足の推計を発表（需要増と国内労働人口減少の見通し）. https://www.nikkan.co.jp/articles/view/00388679
  2. 厚生労働省. 働き方改革関連法の施行（時間外労働の上限規制、年5日の年次有給休暇付与、勤務間インターバル制度の努力義務 ほか）. https://www.mhlw.go.jp/stf/newpage_05319.html
  3. 厚生労働省. 違法な長時間労働や過労死等が認められた企業への指導及び企業名公表について. https://www.mhlw.go.jp/kinkyu/151106.html
  4. Google Cloud. Announcing the 2023 State of DevOps report (DORA research). https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report?hl=en