日々の業務をつなぎ、
管理をひとつに。
勤怠・請求・顧客管理・SES・商品在庫を、共通の業務基盤で。日々の記録や申請、月次の確認、商談から請求までの流れを、業務に沿って整理した自社開発のプラットフォームです。要件定義から画面設計・実装・運用までを社内で行っています。
日々の記録から、月次の確認まで。
勤怠の記録・申請・承認をまとめて確認
社員は打刻と日報の提出、勤怠連絡・休暇申請・残業申請を同じ画面から行えます。管理側は当日の出勤状況と、承認を待っている申請を 1 画面で確認できます。
月締め・集計・法定帳簿の出力を一連の流れに
本人確認の進捗と未処理の修正申請を見ながら締め処理を進められます。労働者名簿・出勤簿・賃金台帳・有休管理簿と、Excel・CSV の出力まで同じモジュールで完結します。
顧客・商談情報を見積・請求へつなぐ
顧客・見込み客と商談を段階ごとに管理し、共通の取引先マスタを介して、見積書・納品書・請求書・領収書の作成へ引き継げます。
毎日使う画面と、月に数回使う画面を分けて設計する
社員と管理担当では目的が逆になるため、同じ設計思想では作っていません。UI 設計書に 3 つの原則として書き、全画面でこれを守っています。
社員画面は「迷わない」、管理画面は「見落とさない」
社員は 1 日 2 回・数秒の利用。開いた瞬間に押すべきものが分かることを優先する。管理画面は情報密度を上げてよいが、異常だけは必ず前面に出す。
打刻ボタンは常に 1 つだけ
4 つのボタンを並べず、いまの状態で押すべき操作だけを出す。確認ダイアログは置かず、記録後 5 秒だけ取り消せる窓を出すことで押し間違いに対応する。
状態は色・文字・記号の三重で示す
色覚の多様性と、屋外の明るさでの可読性に対応する。数値・時刻・金額は等幅書体で揃え、列を縦に読み下せるようにしている。
誰が使い、どこへつながるのか
業務管理プラットフォームの全体像です。実装済みのつながりだけを線で示しています。業務モジュールは共通基盤の上に載り、取引先・権限・監査ログは全モジュールで共有します。利用できるモジュールは会社ごとに設定します。
勤怠から請求への自動連携は行っていません。勤怠の集計結果がそのまま請求金額になる仕組みは持っていません。
詳細図を見る(拡大しても崩れないベクタ図)
提供範囲・上限値は、料金資料および契約書の別紙で確定します。
5 つの業務モジュールと、共通の基盤
社員・取引先・権限といった共通マスタを 1 つ持ち、その上に業務モジュールを載せる構成です。利用者は画面左のサイドバーからモジュールを切り替えます。表示されるメニューは権限コード単位で絞られ、同じコードで API 側の許可も判定します。
勤怠管理
/attendance打刻・日報から月締め、法定三帳簿の出力までを 1 本の流れにしています。打刻の抜けや勤怠連絡は管理画面の「対応トレイ」に 1 列で積まれ、どれから手を付けるか迷わない形にしました。
請求管理
/billing見積書・納品書・請求書・領収書を同じ帳票として扱い、見積から請求への変換や複数納品の合算ができます。帳票は下書き・発行済・無効の 3 状態で、発行後は内容を変更せず理由を残して無効化します。買掛側の発注書はメニュー上も別グループに分けています。
顧客管理(CRM)
/crm顧客と見込み客を 1 つの一覧で扱い、リード・商談・問い合わせ・タスク・営業活動を同じ取引先に紐づけます。取引先マスタは請求管理と共通なので、商談が決まった時点でそのまま帳票側へ引き継げます。
SES マッチング
/ses案件と候補者を左右に並べ、選定・提案・面談・契約までを 1 画面で追えるようにしています。不採用や辞退も履歴として残し、案件は失注後も一覧から消しません。案件は取引先マスタに紐づくため、SES 担当が請求側に登録を依頼する必要はありません。
商品・在庫管理
/inventory現物在庫から引当済みを差し引いた数量を「使える在庫」として扱い、仕入発注から入庫、商品受注・引当、出荷までを 1 本の流れにしています。品目は請求管理と共通で、出荷した数量と受注単価から納品書の下書きを作成できます。入庫・引当・出荷・棚卸の増減はすべて履歴に残り、確定済みの記録は上書きせず、取消は逆の在庫移動として記録します。
実際の画面
以下は実際の画面構成をそのまま再現した表示です。氏名・部署・取引先・金額・日付はすべて架空の値に置き換えています。
打刻ホーム(社員・スマートフォン)
/meホーム画面から起動すると最初に出る画面。勤務中は地色が濃紺に変わり、経過時間と所定時間に対する進捗が出ます。押せる打刻は常に画面下端の 1 つだけで、通信が切れている間は端末に保存して自動で再送します。
出勤状況(管理・PC)
/attendance全社の当日の状況と、対応が必要な項目を 1 画面に置いています。右側の「対応トレイ」は打刻の異常と社員からの勤怠連絡を 1 つの待ち行列にまとめたもので、種別はチップで示します。並び替えや検索・部署の絞り込みはサーバー側で処理します。
枠の中を横にスクロールすると全体を見られます請求書一覧(管理・PC)
/billing/invoices帳票の状態(下書き・発行済・無効)と入金の状態を別の列として持ち、支払期限を過ぎた発行済の行は日付を赤で示します。複数行を選んで請求書に合算したり、まとめて送付したりする操作は、件数を添えて見出しの行に置いています。
枠の中を横にスクロールすると全体を見られます商談管理(管理・PC)
/crm/deals商談を段階ごとの列に並べ、カードをドラッグして段階を更新します。列の見出しには件数と金額の合計が出ます。受注予定日を過ぎた商談は左端に赤い印が付き、成約へ移すと受注情報の入力に進み、そのまま請求管理で請求書を発行できます。
枠の中を横にスクロールすると全体を見られます止まらないことを前提に組む
打刻は 1 日 2 回、全社員が必ず通る操作です。そこだけは他の機能の不調に巻き込まれないよう、経路とデータベース接続を分けて設計しています。
バックエンド
- FastAPI / SQLAlchemy 2.0
- PostgreSQL 16(Alembic で移行管理)
- Python 3.12 以上
- 打刻 API は専用の接続プールに分離
フロントエンド
- React / TypeScript / Vite
- Tailwind CSS(設計トークンを一元管理)
- TanStack Query でサーバー状態を扱う
- 社員画面は PWA。文字サイズは 4 段階
運用と品質
- 1 社 1 データベース構成
- 操作履歴(監査ログ)を全操作に付与
- ヘルスチェックは実際に DB へ問い合わせる
- CI で型・静的解析・テスト・移行を検査
実現計画書・UI 設計・データモデルと API 設計・権限ロール設計・操作手順書を文書として残し、設計上の判断は ADR(意思決定記録)として個別に記録しています。仕様の変更はまず文書側で決め、そのあとに実装しています。
導入と運用について
外部に販売しているサービスですか
自社の業務のために設計・開発したシステムです。同じような課題をお持ちの企業向けに、業務システムの開発のご相談は承っています。
いま使っている Excel の様式は使えますか
現行ファイルを分析し、列幅・結合セル・数式の扱いまで対応表に落としたうえで、同じ様式のまま出力する方式を採りました。様式を変えずに移行できるかどうかは、実物を見て判断しています。
システムが止まったときはどうしますか
打刻の経路を他の機能から隔離したうえで、停止の度合いに応じた代替手段を運用手順書に段階別で定めています。復旧後に管理者がまとめて代理打刻でき、誰がいつ代理したかは履歴に残ります。
権限はどこまで細かく分けられますか
権限コード単位です。サイドバーに出るメニューと API 側の許可を同じコードで判定するため、「開けるのに保存で拒否される」状態が起きないようにしています。
電波の悪い現場でも打刻できますか
送信できなかった打刻は押した時刻のまま端末に保存し、通信が戻り次第自動で再送します。記録される時刻は押した時点のものです。受付端末の QR を必須にする運用にも対応しています。
モジュールは別々に使えますか
同じ基盤の上のモジュールとして分かれており、利用できるモジュールと権限は会社ごとに設定します。切り替える先が 1 つしかない場合は、サイドバーに切替そのものを出しません。
重点の置き方が、それぞれ違います
業務システムは、どれが優れているかではなく、どの業務に重点を置き、どう組み立てるかが分かれます。代表的な 3 つの型と並べて、本製品の位置を整理しました。
業務管理プラットフォーム
勤怠管理・顧客管理(CRM)・IT人材業務(SES)・請求管理・商品・在庫管理。
業務ごとに作り込んだ画面を、共通の基盤の上で使います。複数の業務を、業務別の画面と共通基盤で扱える構成です。
取引先・権限・監査ログを全モジュールで共有します。CRM の商談、SES の契約、在庫の出荷から帳票・請求へつながる構成です。勤怠から請求への自動連携は行っていません。
複数の業務をまとめて見直したい。自社の業務に合わせて、相談しながら整えたい。
勤怠・人事労務型
勤怠・休暇・申請承認を中心に、人事労務や給与などの関連機能も提供されています。
勤怠を軸にした専用機能を、設定して使います。
外部サービスとの連携が用意されています。
勤怠と人事労務のまわりを、専用の仕組みで厚く整えたい。
請求業務型
見積・納品・請求・領収の帳票と、定期発行・送付、入金まわり。
請求業務に特化した専用機能を使います。
会計との連携や API が用意されています。
請求業務そのものを、専用の仕組みで整えたい。
汎用アプリ構築型
特定の業務に限定されません。必要な業務アプリを必要に応じて作ります。
データ管理・プロセス管理・権限・通知を組み合わせて自社で構築します。プラグインや外部サービスで拡張できます。
アプリ間や外部サービスとのつなぎ方を、自社の構成しだいで決められます。
自社の業務に合わせて、必要なものを自由に作りたい。
各社の公開情報をもとに、代表的な製品の範囲で主な特徴を整理したものです。各社の他製品やすべてのプランは比較の対象に含みません。機能の提供条件はプランにより異なります。(基準日:2026年9月15日)