残業ルール対応のタイムシートアプリ：週次提出と承認

このタイムシートアプリが解決すべきこと

残業ルール付きのタイムシートアプリは単に時間を記録するためのものではありません。混乱を防ぎ、支払いミスを減らし、誰にとっても予測可能なプロセスを提供することが目的です。

タイムシートがスプレッドシートやチャットに散らばっていると、小さな問題がすぐに積み重なります。人によってテンプレートが違ったり、休憩を記録し忘れたり、後から誰にも気づかれずに編集されたりします。マネージャーは時間の抜けを追いかけるのに忙しく、週の内容が妥当かどうかを確認する時間がなくなります。給与処理の日には、部分的な情報をつなぎ合わせて、従業員の記憶と合っていることを祈ることになります。

残業は紛争が始まるポイントです。ルールが一貫していなかったり、誰もが従える形で書かれていないと、同じ勤務スケジュールの2人が異なる支払いを受けることになります。皆が善意で動いていても、曖昧なルールは手直しや事後修正、気まずい会話を生みます。

承認は、お金が動く前の安全ゲートです。マネージャーによる承認ステップは、その週が完了していること、もし使うならジョブやプロジェクトコードが妥当であること、残業が正当化されていることを確認します。また“これが最終”という明確な瞬間を作るので、給与が編集中のドラフトから数字を引っ張ることがなくなります。

週次提出は一つの簡単な習慣にするべきです。全員が定められた就業週（例：月〜日）内で作業し、明確な締切（例：月曜10:00）までに提出し、締切前にリマインダーを受け取る。提出後は編集をブロックするか再承認を必要にし、状態は一目でわかるようにします（Draft、Submitted、Approved、Rejected）。

コア要件と境界

この種のアプリは、最初に全員が基本を合意している場合にのみ機能します：いつ提出するか、誰が何を変更できるか、何が残業とみなされるか。早めに境界を決めないと、アプリは毎週の議論の場になります。

まずは提出のリズムから始めましょう。週次の提出は多くのチームでシンプルです：週の間に時間を入力し、最後に一度提出する。重要な境界は提出後に編集を許すかどうかです。一般的なルールは、週次の「Submit」ボタンが押されるまでエントリは編集可能にしておくことです。

残業ルールは曖昧さを排除する必要があります。残業が日ごとの上限（例：1日8時間超）、週ごとの上限（例：週40時間超）、またはその両方で発生するか決めてください。両方を適用するなら、重複して残業が二重計上されないように優先順を明示してください。

マネージャーの承認は短く閉ざされたループにして、素早く使えるようにします：承認（時間が確定）、差し戻し（従業員が編集して再提出）、却下（従業員が修正して再提出）。

承認されたら期間をロックします。ロックは突発的な編集を防ぎ、給与処理の一貫性を保ちます。修正が必要な場合は、“理由付きで解除”アクションを使い、誰がなぜ解除したかを記録します。

給与エクスポートには承認済みの時間のみを含めること。これを厳格な境界にしてください：未承認のものは、見た目が完成していてもエクスポートから除外します。

取得すべきデータ（過度に複雑にしない）

目標はすべてを追うことではなく、時間を計算し、ポリシーを適用し、誰が何を承認したかを証明するのに十分な情報を取ることです。

まず役割から。ほとんどのチームは3つで足ります：時間を入力する従業員、承認するマネージャー、そしてエクスポートや設定を行う給与（または管理者）。権限はシンプルにして、人がブロックされないようにします。

最低限保存すべきレコード

人、週次タイムシート、個別タイムエントリの3層で考えてください。

各人については基本情報（名前、社員IDまたはメール、役割、マネージャー、チームやコストセンター）を保存します。各タイムシートには所有者、週の開始日、その週に使われたタイムゾーン、ステータス（Draft、Submitted、Approved、Rejected）を保存します。各タイムエントリには日付、開始時刻、終了時刻、休憩分、プロジェクトやタスク、短いメモを記録します。

また、週の開始曜日（Mon または Sun）やルールで使うタイムゾーンなどのカレンダー設定も必要です。給与が必要なら、ロケーションや部門といったオプションのコンテキストを追加します。

記録しておくと便利な承認・監査フィールド

承認は意見の相違が起きやすい箇所なので、退屈で明確な監査トレイルを残しておきましょう：

• Submitted at、submitted by
• Approved at、approved by
• Rejected at、rejected by、rejection reason
• Last edited at、last edited by
• Locked フラグ（承認後の編集を防ぐ）

例：ベルリンの従業員が日曜夜に提出した場合、その週に使用したタイムゾーンを保存しておくと、ニューヨークのマネージャーから見ると提出時刻が月曜に見えるという古典的な問題を避けられます。

これらのフィールドだけを取れば、残業ルールを実行し、承認をルーティングし、給与にクリーンな合計をエクスポートできます。HRシステムのように複雑にする必要はありません。

まずは平易な言葉で残業ルールを定義する

ポリシーは誰でも読める簡単な文章で書いてください。明確に説明できないなら、アプリは給与で驚きを生みます。

どのトリガーにするかから始めましょう：1日8時間を超えたら残業、週40時間を超えたら残業、または両方か。両方を使うなら順序を決めます。一般的には日次残業を先に計算し、残りの通常時間に対して週次残業を適用する選択が多いです。

何が時間としてカウントされるかを明示してください。無給の休憩は全てを変えるので、はっきり書きます：「ランチは無給で労働時間に含めない」など。丸め処理をするならそれも書きます。例：「各打刻を最も近い5分に丸める」。月単位で見ると小さな丸めの差が積み重なります。

次に特別日について触れます。週末、祝日、移動時間は別の支払ルールになることが多いです。追加支払いがなくても、明確な文言が必要です：「土曜の時間は週40時間を超えない限り平日と同じ扱い」など。

コピーして使えるポリシー文章例：

• 「残業は1日8時間を超える労働時間とする。」
• 「週次残業は、すでに日次残業としてカウントされた時間を除く通常時間が40時間を超えた場合に適用する。」
• 「無給休憩は労働時間に含めない。給与が支払われる休憩は含める。」
• 「祝日の時間は1.5倍で支払われ、週次残業には含めない。」
• 「現場間の移動時間はカウントするが、自宅からの通勤はカウントしない。」

これらの文章に合意できれば、ロジックを組む作業は議論から翻訳作業になります。

手順：週次提出ワークフロー

「この週」に何が含まれるか、いつ提出しなければならないかが全員に分かっていると週次フローはうまく回ります。週の開始曜日（多くは月曜）と明確な締切（例：従業員のタイムゾーンで月曜10:00）を選んでください。遅延提出は可能にしておきつつ、見えるようにしておくこと。

1) 週の期間と締切を設定する

週を固定の日付範囲として定義し、タイムシートに保存します。これで誰かが週の途中でアプリを開いたり、出張しているときの混乱を避けられます。最初からステータスフィールド（Draft、Submitted、Approved、Rejected）を含めてください。

2) 従業員のタイムシート画面を作る（追加／編集）

入力はシンプルに：日付、開始時刻、終了時刻（または合計時間）、休憩時間、プロジェクトや費目コード（必要なら）、短いメモ。従業員が前日のエントリをコピーして編集できるようにすると、週次の作業が大幅に楽になります。

3) 自動合計（通常 vs 残業）を表示する

エントリを追加すると、週の合計を上部に表示します：総時間、通常時間、残業時間。分割は週が完了するまでは推定でも構いませんが、リアルタイムで更新されることで従業員が早めにミスに気づけます。

必須フィールドが足りない場合は、合計が「おかしく」見える代わりに明確な警告を出してください。

4) 提出して週をロックする

Submit は3つのことを行うべきです：入力の検証（負の時間なし、重複なし、必須メモあり）、ステータスを Submitted に変更、編集のロック。変更が必要な場合は「Draftへ戻す」（通常はマネージャーの差し戻しや却下でトリガー）経由にします。

5) マネージャーへ通知し、保留キューを表示する

提出されると、マネージャーにはシンプルなキューが必要です：従業員名、週の範囲、総時間、フラグ付きの問題（メモがない等）、高速レビュー用画面。これはタイムシートが Submitted に移るときの自動通知を出すのに最適な場所です。

手順：マネージャー承認フロー

マネージャーは一つの画面を開けばすぐに注目すべきものが分かるべきです。提出された週の短いキューを表示し、各行に従業員名、週範囲、総時間、残業時間（あれば）、メモの有無を示すインジケーターを付けましょう。これでいちいち全日分を開かずに問題を見つけられます。

マネージャーが週を開いたとき、決定は一貫しているべきです：

• Approve：週をロックし、給与エクスポートの準備完了にする。
• Send back：従業員に返して必須のコメントを付けさせる。
• Reject：ポリシー違反（欠勤、誤ったプロジェクト、重複疑い）に使う。
• Delegate：マネージャー不在時にバックアップ承認者へ回す。

コメントは重要です。差し戻しや却下には短い理由を必須にし、その記録を残して従業員が何を直すべきか分かるようにしてください。

各決定後に何が変更できるかを明確にします。差し戻しや却下の後は従業員が編集して再提出できます。承認後はデフォルトで編集をブロックします。変更を許す場合は「週を再開する」アクションを用意し、新たな承認サイクルを開始させます（必要なら二重承認も）。

欠席への対策も計画してください。チームごと（または従業員ごと）にバックアップ承認者を割り当て、休暇中にHRや管理者が承認割り当てを再設定できるようにします。

監査トレイルは残してください：誰が提出し、誰が承認（または委譲）したか、タイムスタンプ、簡単な変更ログ（どのフィールドがいつ変わったか）など。

残業計算ロジックとエッジケース

残業は単純そうに聞こえますが、最初の混乱した週が来るまでは問題が表に出ません。計算の唯一の真実の源を決め、それが従業員の画面、マネージャーの承認画面、給与エクスポートで一致するようにします。

まず何から計算するかを決めます：日次合計、週次合計、または両方。多くのポリシーは1日の最初の8時間を通常時間とし、それを超えた分を残業とします。別の方針では日次を無視して週40時間超だけを見る場合もあります。両方使うなら二重計上にならないよう順序を明確にしてください。実用的な方法としては：日次残業を先に計算し、残りの通常時間に対して週次残業を計算する、という順序がよく使われます。

事前に扱うべきエッジケース

以下の状況は合計を壊したり紛争を生み出しやすいです：

• 分割シフト：1日に複数の別々のエントリがある場合は日次合計にまとめる。
• 日跨ぎシフト：開始と終了は単なる時刻ではなく、完全な日付時刻として保存する。
• 終了時刻がない：提出をブロックするか、そのエントリを未完了として扱い合計を膨らませない。
• 重複や負の時間：重複や終了が開始より前になるエントリは防ぐ。
• 丸めルール：エントリごとに丸めるか（日次合計に対して丸めるか）を決める。

人は明確な内訳が見えると自分で修正しやすくなります。各日の通常時間、残業時間、無給休憩を表示し、週のサマリと合わせて見せてください。問題がありそうな場合は、その原因となるエントリをハイライトします（例：「14:00〜16:00 と重複しています」）。

計算はどこでも一貫させてください。従業員画面、マネージャー画面、レポート、給与エクスポートで同じ残業ロジックを再利用します。

承認済み時間の給与エクスポート

給与チームは通常、アプリが追うすべての情報ではなく、予測可能なファイルを必要とします。必要なのはフィールドリストと列名が決まっていて、スケジュールどおりに渡せることです。早めにこれを決めないと、毎週やりとりが発生します。

まずエクスポート形式に合意します。CSV が一般的ですが、重要なのはフィールド名と列名です。給与側が列名を EmployeeID にしろと言えば、それに正確に合わせてください。

実用的なエクスポートファイルには通常、社員ID（名前だけでなく）、週の終了日（または週の開始・終了）、通常時間と残業時間を別列で、労務配分が必要ならコストセンターやプロジェクトコード、承認タイムスタンプと承認者IDを含めます。

完全に承認された週だけをエクスポートしてください。承認がゲートです：承認なしでのエクスポートはしない。

修正はチームが詰まる部分です。クリーンな方法は、エクスポート済みのレコードをその場で編集しないことです。代わりに、給与が取り込めるデルタとして調整行を作ります。例えば、週42が5.0時間の残業でエクスポートされたが実際は4.0時間であるなら、-1.0残業の調整行を元の週と社員に紐づけて作ります。

エクスポートはバッチとして保存し、給与が安全に再実行できるようにします。各バッチにエクスポートID、生成日時、使用したフィルタ（例：「Approved weeks ending 2026-01-18」）を付けておきます。同じバッチを二重に取り込まれたときに重複を検出するためです。

よくあるミスと注意点

この種のアプリは単純な理由で失敗します：最終状態が不明確、時間の境界が不明確、エクスポートが給与の期待と一致しない、など。

最初の落とし穴は、週が承認された後に人が時間を編集できることを許すことです。柔軟性がありそうですが、数字への信頼を壊します。Approved はロック済みと扱ってください。本当に変更が必要なら、修正リクエストを要求して週を再開させ、誰がなぜ変えたかの監査を残します。

残業ルールを期間途中で変えることも紛争の大きな原因です。もしポリシーが水曜に変わるなら、各週でどのバージョンを使ったかの発効日を記録してください。そうしないと、同じ時間でも異なる残業結果になることがあります。「Policy v2 effective Jan 15」のような簡単な注記でも議論を避けられます。

タイムゾーンの決定は静かに合計を台無しにします。従業員のローカルタイムを使うか、会社の給与タイムゾーンを使うか一つ選んで徹底してください。何もしないと、深夜シフトが別の日にずれて日次合計や残業に影響します。

コメントなしの承認は時間を無駄にします。マネージャーが却下や差し戻しをするときは短い理由を必須にして、従業員が何を直すべきか分かるようにしてください。

強制すべきいくつかのルール：

• 提出された週はマネージャーが差し戻すまでロックする。
• 承認済みの週は修正フローを通じてのみ解除する。
• 残業ポリシーはバージョン管理し、発効日を保存する。
• タイムゾーンのルールを決め、タイムシート上に表示する。
• 完全に承認された週だけをエクスポートする（Submitted や部分承認は含めない）。

ロールアウト前の簡単チェックリスト

誰かが時間を記録する前に、公平で予測可能に感じられる設定に合意しておいてください。

カレンダールールを固めます：週の開始日（Monday vs Sunday）と提出締切（例：「前週は月曜10:00までに提出」）。それを文書化し、UI 上にも繰り返して表示して推測をさせないでください。

残業ポリシーを平易な文章で書き、現実の例でテストします。1つの“普通の”週だけでなく、遅いシフト、食事休憩の抜け、分割シフトなど3〜5のシナリオで試してください。

ロールアウトチェックは実用的に：

• 週開始日と提出締切が設定され、周知されている。
• 残業ルールが文章化され、3〜5の例でテストされている。
• マネージャーが承認前に合計と従業員メモを確認できる。
• 給与エクスポートは承認済みデータのみで再現可能。

ロックには特に注意を払うこと。Submitted は編集を止め、Approved は追跡された修正フローを除き事実上不変にする。そうでないと給与が動く標的になります。

給与エクスポートは“退屈”であるべきです。同じ期間に対して同じ数字を出力し、承認済み時間のみを含める。先月のエクスポートを再実行して結果が変わるようなら、ローンチを止めてまずそれを直してください。

現実的な例

倉庫チームは月曜〜日曜の週で週40時間を超えた分を残業と支払うルールで、支払えるのは承認済みの時間だけです。各作業者は週に一度提出し、マネージャーは月曜正午までに承認します。

Jordan は早番で金曜までに38時間ログしています。土曜に急ぎの出荷対応で6時間残業し、日曜夜に週を見直して土曜のエントリに短いメモを付け、合計44時間で提出しました。

月曜朝、マネージャーが提出を確認します。アプリはシンプルな内訳（通常40時間、残業4時間）を示します。マネージャーは土曜のエントリがシフト終了後に作成されていることに気づき、詳細を求めます。Jordan は開始時刻が30分ずれていることに気づき修正が必要です。

タイムシートは既に提出済みなので、修正は再提出フローを通ります：マネージャーは「土曜の開始時刻を修正して再提出」と理由をつけて差し戻します。Jordan は土曜のエントリを編集して再提出し、残業は3.5時間に再計算されます。

マネージャーが承認すると、その週のクリーンなエクスポートが給与に渡ります：社員IDと名前、週の開始・終了日、承認済みの通常時間と残業時間、任意でコストセンターやロケーション（Warehouse A）、承認タイムスタンプと承認者名など。

ローンチ後、チームは簡単な指標を追います：遅延提出（日曜以降）、差し戻し率（どれだけマネージャーが返しているか）、提出から承認までの平均時間。これらが上がると多くの場合はルールが不明瞭かリマインダー不足を示します。

次のステップとシンプルなローンチ計画

最初のバージョンはコントロールされたテストとみなし、全社切り替えにしないでください。通常の残業が混ざる1チームをパイロットに選び、まずは1つの明確な残業ポリシーで始めます。こうするとフィードバックが集中し、ワークフローを端から端まで検証できます。

パイロットは2〜4週サイクルで実施します。本番の提出が数件あれば、どこで人が戸惑うか、マネージャーが詰まるか、給与エクスポートが財務の期待に合うかが分かります。

実用的なローンチ計画：

• 1チーム、1ポリシーでパイロット開始（週目は特殊ケースは除く）。
• 最も多い5つの質問を集め、それを引き起こした画面やラベルを直す。
• 所有権を明確に：誰が残業ルール、支払コード、承認設定を更新できるか。
• 給与エクスポートのスケジュールに合意（例：承認終了後の月曜9:00）。
• マニュアルエクスポートが2回の支払期間で正しければ、1つの連携を追加する。

UIの小さな文言変更が多くのサポートチケットを減らします。提出フローを短く保ち、人が本当に困る場所にだけヘルプテキストを追加してください。

ポリシー更新の所有者を早めに決めます。残業定義はHR、エクスポート形式は給与、承認はマネージャーが持つ、など。これを明確にしておかないと、善意の管理者が支払期間途中で設定を変えてしまうことがあります。

コードを書かずにこれを作りたい場合、AppMaster (appmaster.io) はプロトタイピングとリリースの一つの選択肢です。視覚的なデータモデル、提出と承認のドラッグ&ドロップワークフロー、Web/モバイルのUIビルダーで構築できます。まずは最小ワークフローから始め、パイロットで残業ロジックと給与エクスポートが合っていることを確認してから機能を拡張してください。