打刻から採算まで、承認と締めの境界を決める。

この事例の根拠と読み方

根拠：AMELA名義のTakumiCloud開発事例と公開デモ、移行されたケース記録を照合しました。資料に記載された課題、担当範囲、機能構成と、デモで確認できる画面の流れに限定しています。

対象期間：公開資料には開発期間、利用規模、処理の速さに関する記載がありますが、算定根拠や本番導入後の測定期間は確認できません。そのため、期間、人月、利用人数、工数削減、確定日、ペーパーレス率を実績値として掲載しません。

確認できること：スマートフォンの打刻・写真日報、勤怠の承認、給与計算の処理、現場別の原価・売上表示、請求につなげる設計です。

確認できないこと：給与計算の法令適合性、実際の計算精度、現場数や職人数、処理時間、事務工数、利益、請求回収、GPSの測位精度、本番運用の継続状況です。

公開上の扱い：機密保持のため企業・プロジェクト・作業者の名称は仮名です。カバーとデモの氏名、現場名、時刻、金額、写真、集計値は匿名化またはモックであり、実績値として扱いません。

現場と事務所の情報を一つの基準で扱いたい企業様

対象は、複数の現場と職種を持ち、職人が現場で勤怠・日報を入力し、事務所が承認・給与・請求を担う建設事業者様です。経営者は現場ごとの採算を見たい一方、現場と事務所の情報が紙、チャット、表計算に分かれると、同じ事実を何度も転記することになります。

このケースでは、現場で入力した記録を勤怠の基準データとし、承認後に給与、原価、請求へ渡す境界をどう置くかが中心的な論点でした。給与の計算式や締め日など、会社ごとに異なる条件も受入時に合意する必要があります。

打刻から採算までの流れを設計

AMELAのケース資料は、React NativeとNestJSを中心に、現場アプリと事務所・経営向け画面をつなぐ構成を示しています。公開デモでは、現場の打刻・写真日報、勤怠の承認、現場別の採算表示へ進む画面の流れを確認できます。

現場で保存された入力を、そのまま給与や請求の確定値にしてはいけません。承認、締め、修正履歴、再計算の権限を分けて、どの時点のデータを原価と請求に渡すかを明確にします。給与の計算結果は会社の規程や法令確認が必要であり、公開デモだけで正確性を判断できるものではありません。