L-SHIFTは、SES事業を行う当社が、自社の業務課題をもとに開発した業務管理システムです。
常駐先ごとに異なる勤務ルールに対応し、勤怠管理・経費精算・請求書発行から、社労士による給与計算に必要なデータの出力までをひとつにまとめています。
2026年4月1日から当社で本稼働し、同業のSES企業にも提供しています。
導入企業の運用に合わせたカスタマイズや、一部機能を用いた専用システムの提供にも対応しています。
常駐先ごとに勤務時間や休憩などのルールが異なり、勤怠の確認に手作業が必要でした。現場都合の休みや早上がりを記録する区分がなく、給与計算の前に本人へ事情を確認していました。請求に必要な書類や提出方法も案件ごとに異なり、担当者が個別の対応を把握していました。
現場ごとの違いを設定や記録に反映できるよう、自社のSES業務に合わせたシステムを開発しました。「現場都合休」「会社都合休」を設け、欠勤控除や有給休暇の消化をせずに処理できるようにしました。勤怠・経費・請求のデータを一元管理し、社労士が給与を最終確定するためのデータ出力まで整えました。
導入前に5日かかっていた勤怠確認が、導入後は1日になりました。記録された休みの種類から処理できるようになり、本人へ都度確認する作業が不要になりました。勤怠や経費のデータを後続の処理に使えるようになり、転記や再計算の作業が不要になりました。
常駐先の創立記念日で、現場が休業になる。案件への参画初日にPCを受け取り、現場の指示で15時に退勤する。次の案件の面談や自社の社員総会のために、勤務時間中に現場を離れる。SESでは、社員本人の意思とは関係なく、勤務時間が短くなったり、現場で勤務しない日が生じたりします。
しかし、勤務表に「休み」や退勤時刻だけが記録されていても、その事情までは分かりません。本人都合の欠勤なのか、現場が休業していたのか。私用で早退したのか、現場の指示で退勤したのか。給与計算での扱いが異なるため、当社ではバックオフィスが本人に確認していました。
当社が利用していた既製の勤怠管理サービスには、こうした勤務実態を記録し、そのまま給与計算に反映するための区分がありませんでした。現場都合の休みも、欠勤として処理すれば給与から控除され、控除を避けるために有給休暇を使えば、社員の残日数が減ります。社員が自分の意思で取得する有給休暇を、現場の事情で生じた休みに充てることになっていました。
さらに、社員が常駐する企業によって、勤務時間・休憩の取り方・残業の数え方も異なります。同じ会社の社員であっても、ひとつの勤務ルールでは処理できません。現場ごとの条件と、その日に起きた事情の両方を確認しなければ、給与計算に必要な情報が揃わない状態でした。
請求業務でも、案件ごとに勤務表の様式や提出方法が異なります。どの書類を回収し、どの形式で提出するかを担当者が把握し、未提出の社員には個別に連絡していました。担当者が変わる際には、操作方法だけでなく、案件ごとの対応も引き継ぐ必要がありました。
システムで扱いきれない違いを、人が確認して補う。その作業が毎月、社員と現場の数だけ発生し、勤怠確認だけで5日を要していました。
既製サービスの設定変更や、複数サービスを組み合わせる方法も検討しました。しかし、当社が確認した範囲では、現場ごとの勤務体系と、現場都合・会社都合による休みの種別まで、必要な条件を設定できるサービスは見つかりませんでした。対応できない部分を人が確認する運用が残るため、サービスを導入するだけでは課題を解消できないと判断しました。
自社開発を選ぶ後押しになったのが、当社で開発したLAFの存在です。LAF（LEGAREA AI Framework）は、AIを使って設計から実装までを進める当社独自の開発フレームワークです。これを用いることで、SESの複雑な業務条件に対応するシステムも、自社で開発できると考えました。
構想段階から、対象は勤怠管理・経費精算・請求業務までとしました。勤怠の確認だけを効率化しても、その後の給与計算や請求で転記・再計算が必要であれば、業務全体の負担は残ります。入力した情報を後続の処理にも使えるよう、ひとつのシステムとして設計しました。
現場ごとの勤務ルールは設定として登録し、休みや早退などの事情は勤怠とともに記録します。「現場都合休」「会社都合休」は、欠勤控除や有給休暇の消化をせずに処理する区分として設けました。毎月担当者が確認していた条件をシステムに持たせ、記録された内容に基づいて処理できるようにしたのが、L-SHIFTの基本的な設計です。
開発は代表がLAFを用いて、業務ルールの整理から設計・実装までを主導しました。社員1名も一部のUI設計とテストに参加し、約3ヶ月で開発しました。
設計では、勤怠の登録方法に加え、交通費や経費、福利厚生の申請・承認フローを整理しました。申請の種類によって支給上限が異なり、インボイス登録の確認が必要なものもあります。システムで処理するには、申請時に必要な情報と、承認時に確認する条件を明確にする必要がありました。
その過程で、支給条件や確認事項を改めて整理し、社員にも申請方法を再周知しました。開発は、申請を受け付ける画面を作るだけでなく、本社の管理体制や運用を見直す機会にもなりました。
検証には、過去の勤務表を使用しました。労働時間が正しく集計されるかに加え、長時間労働に対するアラートや、有給休暇の年間5日取得に向けたアラートが、対象となる条件で表示されるかを確認しました。日々の入力から集計、管理者による確認まで、実際の業務に沿って動作を検証しながら開発を進めました。
導入前に約10日を要していた勤怠確認は、導入後には1日になりました。
現場ごとの勤務条件と、休み・早退などの事情を記録できるようになり、バックオフィスが本人に理由を確認してから処理する作業が減りました。
「現場都合休」「会社都合休」は、記録された区分に基づき、欠勤控除や有給休暇の消化をせずに処理されます。担当者がその都度事情を確認して補正していた扱いを、システムに反映できるようになりました。
勤怠や経費のデータは、給与計算用のデータ出力や請求書作成にも使用します。業務ごとの転記・再計算が不要になり、給与は出力したデータをもとに社労士が最終確定する運用になりました。
新しい現場についても、勤務条件を設定として追加できます。現場ごとのルールを担当者が毎月確認し直すのではなく、登録した条件を継続して処理に使えることが、運用上の変化です。
Contact
お問い合わせ
