申請の種類ごとに用紙を作らず、1 つの申請と承認の流れにまとめる

休暇・残業・打刻の修正・稟議・購買と、申請の種類ごとに用紙や画面を作っていくと、承認を待っている申請がそれぞれの置き場所に散らばり、誰が何を止めているのかが見えなくなります。種類が違っても、申請は「出す・決める・取り下げる」の流れで共通です。共通の流れを 1 つ作り、種類ごとに違う中身だけを足せば、承認する人は 1 か所を見れば済みます。

当社の社内システムでは、2026 年 6 月に、稟議・購買・備品などの申請を 1 つの流れにまとめました。それより前の 4 月に、経営ダッシュボードの人事労務で、休暇や打刻の修正など 6 種類の申請を 1 つの表にする設計を書いていました。この記事は、その 2 つで決めたことの記録です。

4 月の設計で、勤怠の申請 6 種類を 1 つの表にしました

経営ダッシュボードの人事労務で扱う申請は、有給・欠勤・遅刻・早退・残業・打刻の修正の 6 種類です。種類ごとに表を作らず、1 つの表にまとめました。申請した人、承認する人、申請した日時、承認した日時、却下の理由、コメント、添付のファイルは、どの種類でも同じ欄に入れます。休暇の日付や残業の時刻のような種類ごとに違う中身は、1 つの欄にまとめて持たせました。

状態は、下書き・申請中・承認済・却下・取消の 5 つです。承認は 1 段にしました。残業の申請を 1 段の承認にした考え方と、代わりに承認する人の決め方は、残業の申請と承認の記事に書いています。

6 月、社内の稟議と購買と備品の申請を、同じ形で 1 つにしました

当社の社内システムでは、有給の申請と打刻の修正の申請が先に動いていました。6 月に社内システムの機能を分類ごとに見直したところ、管理と財務の機能が手薄でした。そこで、稟議・購買・備品・その他の申請を受ける仕組みを足しました。経費精算の画面は前からあったので、今回の仕組みは、あとで経費の申請もここに寄せられるよう、種類を足せる形にしています。

金額は空でもよい項目にしました。金額の無い稟議も、同じ流れで出せます。

状態は 4 つにし、誰がどの状態に変えられるかを決めました

承認と却下ができるのは管理者だけで、一般の社員が押しても状態は変わりません。申請した人ができるのは、まだ申請中の自分の申請を取り下げることだけです。ほかの人の申請は取り下げられません。

打刻の修正の申請では、一度承認や却下をした申請を、もう一度承認することはできない作りにしました。一度決まった申請の状態は、あとから変わりません。

申請した人と状態は、システムが決めます

申請の画面から送られてくる値のうち、申請した人・状態・承認した人は、そのまま使わずにシステムが決めます。画面の値をそのまま信じる作りだと、ほかの人の名前で申請したり、自分の申請を「承認」の状態で出したりする操作を止められません。承認の流れは、こうした操作を受け付けない作りがあって初めて意味を持ちます。

打刻の修正では、本人が勤怠の時刻を直接書き換えられないようにしました。打刻を間違えたら、打刻の画面にある「修正を申請」から申請し、管理者が承認したときに初めて勤怠の時刻が変わります。そのとき、変更の前と後の時刻を操作の記録に残します。変更履歴が残っていれば、あとで「誰がいつ直したか」を説明できます。

申請した人は自分の分だけ、管理者は全部を見ます

申請の一覧は、一般の社員には自分の申請だけを、管理者には全員の申請を出します。稟議には金額や取引の話が入るので、社員同士で見えない方がよい中身もあります。見られる範囲（閲覧権限）は、申請の流れを作るときに一緒に決めました。

承認する人が決まっていない申請は、管理者へ回します

4 月の人事労務の設計では、承認する人を社員ごとに登録する形にしました。登録が無い社員の申請は、管理者へ回します。申請を出したときは承認する人に、承認か却下をしたときは申請した人に知らせを送ります。

同じ設計で、承認待ちの申請は、知らせを送るだけでなく毎朝の画面にも一覧で並べます。知らせは読み流されることがありますが、毎朝見る画面に残っていれば、放っておかれた申請に気づけます。

1 つにまとめる前に、今ある申請の用紙を全部並べます

金額によって承認する人を変える会社では、いくらまでを誰が決めてよいかという決裁権限の決まりを先に書きます。当社の社内システムは、承認するのを管理者だけにした 1 段の形です。

当社の社内システムは、AI と作り、使いながら直してきました。作り始めて翌日から使い始めた経緯は事例に、追加の依頼を 1 件ずつ片づけた進め方は社内システムへの依頼の記事にあります。社内の申請や承認を仕組みにするところから手伝う形は、AI伴走支援で扱っています。