kintone 勤怠管理は向くのか｜自作と専用システムの線引き

kintoneを使っている会社から「勤怠もkintoneでできますか」と聞かれることがよくあります。 すでに顧客管理や案件管理のアプリが動いていて、社内にkintoneを触れる人もいる。 アプリはもう1つ増やせるので、わざわざ別のシステムを契約するより早いのではないか—— という発想です。順番としては自然だと思います。

ただ、この記事の結論は「作れるが、向かない領域がはっきりある」です。 当社は普段、道具の乗り換えより先に業務の構造を決めるほうを勧めていますが、 勤怠については構造の問題より、維持を誰が引き受けるかのほうが先に効いてきます。 どこまでをkintoneに載せて、どこから先を専用のシステムに任せるのか。 その線を引くための材料を整理します。

なぜ「ついでに勤怠も」になるのか

kintoneを導入した会社は、たいてい1つのアプリでは終わりません。 問い合わせの管理、案件の管理、日報。使えることが分かると、 「この形式で管理できるものは他にもある」と考えるようになります。 勤怠はそのリストの上位に来ます。全社員が毎日触るのに、 いまは紙のタイムカードかExcelで、集計は月末に総務が手作業でやっている—— という状態の会社が多いからです。

そして実際に、出退勤を記録するアプリは作れます。 日付、社員名、出勤時刻、退勤時刻、休憩、備考。この程度のフィールドを持ったアプリを作り、 1日1レコードで登録していけば、誰がいつ働いたかの記録は残ります。 一覧で絞り込めるし、グラフも出る。紙のタイムカードと比べれば、 「見える」という点では確実に前に進みます。

ここまでを見て「できた」と判断してしまうのが、いちばん多い入り方です。 記録が残る状態と、勤怠管理が回っている状態は別なのですが、 作っている最中はその差が見えません。

「アプリを増やせる」は「同じ設計でいける」ではない

サイボウズのdeveloper networkでは、kintoneのデータ設計について 「kintone の1つのアプリがリレーショナルデータベースの1つのテーブルに相当するように思えますが、別物として考えることが重要です」 と説明されています。案件管理や顧客管理でうまくいった作り方が、 そのまま勤怠に転用できるとは限らない、ということです。

案件管理は「1件ずつの状態を追う」仕事で、kintoneの形に素直に乗ります。 これは「kintone 案件管理アプリ」でも書いたとおりです。勤怠は違います。1件ずつの記録を残すだけでなく、月という単位でまとめ、判定して、次の月に持ち越す仕事だからです。 この違いが、次の章の話になります。

勤怠は「記録」ではなく「判定」の仕事

出退勤の時刻を集めるのは記録です。ここは難しくありません。 難しいのは、集めた時刻を給与に渡せる形にするところです。 同じ「9時5分に出勤」という記録でも、その会社の所定の始業が何時か、 猶予をどう扱うか、遅刻とみなすのか、といった判断が入って初めて意味を持ちます。

給与に渡すために必要になるのは、たとえばこういったルールです。

この一覧を見ると分かりますが、どれも時刻の記録ではなく解釈です。 そして解釈のルールは、自社の就業規則と、労務に関する制度に紐づいています。 つまり勤怠アプリを作るというのは、実質的に自社の就業規則をロジックとして書き起こす作業になります。

判定ルールは「一度作って終わり」にならない

就業規則をロジックにできたとしても、そこで終わりません。 労務の制度は改定が入る領域です。具体的にいつ何がどう変わるかは本記事では扱いませんが、 「改定が入る」という事実だけで、判定ロジックの扱いは変わります。作った人が、その後もずっと見ていなければならないものになるからです。

ここが自作の分かれ目です。自社で作ったアプリは、改定を誰が追いかけて、 いつ直すのかを自社で決めておくことになります。専用の勤怠システムであれば、 その追従を提供元が担う範囲を含んでいるのが一般的です （どこまでを含むかは製品ごとに違うので、契約前に必ず範囲を確認してください）。 自作は初期の費用を抑えられますが、この追従の工数が読みにくいのです。

しかも厄介なのは、追従を怠ってもすぐには壊れないことです。 アプリはこれまでと同じ数字を出し続けます。間違っていることに気づくのは、 指摘を受けたときか、遡って計算し直すことになったときです。 この「静かに間違い続ける」性質が、自作の判定ロジックでいちばん怖い部分だと考えています。 当社が支援の現場で見てきた傾向で、統計ではありません。

kintoneで組むときに当たる2つの壁

制度の追従という運用面の話とは別に、技術面でも当たるところがあります。 作り始めてから気づくと手戻りが大きいので、先に2つ挙げます。

壁1：レコードをまたいだ計算が素直に書けない

1日1レコードで打刻を記録する設計にすると、 その日の実働時間のように1レコードの中で完結する計算は素直に置けます。 一方で勤怠に必要な計算は、そこで終わりません。

月の残業時間の合計、有給の残数、翌月への繰越。 これらは複数のレコードを横断して、月という単位でまとめる計算です。 さらに繰越は、前の月の結果を次の月の初期値として引き継ぐ必要があります。 こうした「レコードをまたいで数字を持ち回す処理」は、 標準の機能を組み合わせるだけでは素直に書けないことが多く、 集計の仕組みや外部連携、カスタマイズを前提にすることになります。

関連して、サイボウズのdeveloper networkでは、ルックアップは参照元が変わっても参照先のデータが自動では更新されない（取得ボタンを押し直すか、APIで更新する必要がある）、関連レコード一覧は参照元の変更が自動的に反映されると説明されています。またルックアップでコピーしたフィールドは編集できません。 社員マスタの所定労働時間を勤怠アプリに持ってくるような設計をすると、 マスタを直したときに過去のレコードがどうなるかを、 この性質の違いを踏まえて決めておく必要があります。

壁2：打刻のために全社員のライセンスを持つことになる

勤怠は、営業や管理部門だけが使うアプリと違って、全社員が毎日触るものです。つまり全社員がkintoneのユーザーになります。 ここで費用の前提が変わります。

サイボウズが公表している料金（2026年8月時点の掲載）は次のとおりです。

ここから2つのことが言えます。1つは床があることです。 最低契約ユーザー数が10ユーザーなので、実際の利用者が5人でも ライトで月10,000円、スタンダードで月18,000円が下限になります（いずれも税抜）。 この計算は当社が「最低10ユーザー×月額」で出したものです。

もう1つは床の上に人数ぶんが乗ることです。 これまで一部の部門だけがkintoneを使っていた会社が勤怠を載せると、 対象が全社員に広がります。10ユーザーの床の話だけで済まず、 人数に比例して費用が増えていきます。

さらに、壁1で書いた月次の集計や繰越をやろうとすると、 外部サービス連携（API・プラグイン・JavaScriptカスタマイズ）が必要になります。 これはライトコースでは使えず、スタンダード以上になります。 つまり「安く済ませるつもりで自作したのに、上位コースが前提になる」という順番になりやすい。ここは先に確かめてください。 打刻のためだけに全社員のライセンスを持つのが妥当なのか、という問いです。

それでもkintoneが向くケース

ここまで「向かない」寄りの話をしてきましたが、kintoneを勤怠まわりから 完全に外すという話ではありません。載せる部分を選べば、素直に効きます。 当社が見ている限り、うまく回っているのは次の2つの使い方です。

向くケース1：打刻ではなく「申請と承認」を置く

有給の申請、残業の事前申請、直行直帰の連絡、シフト希望の提出。 これらは打刻とは別の仕事です。必要なのは「誰が出して、誰が承認し、いつ確定したか」を残すことで、 時間の判定ロジックは要りません。

この形はkintoneの得意な範囲に近いです。紙の申請書や口頭の依頼を kintoneに移すだけで、「誰に止まっているか」が見えるようになります。 打刻と給与計算は専用側に任せ、申請と承認だけをkintoneに置く。 この分担が、いちばん破綻しにくい形だと考えています。 承認フローの設計は「kintone 稟議 申請の承認フロー」で詳しく書きました。

向くケース2：「時間を案件に紐づける」記録を持つ

もうひとつ相性がいいのが、勤怠システムでは持ちにくい自社固有の記録です。 現場ごとの作業時間、案件ごとの工数、担当者が1日をどの仕事に使ったか。 これは給与のための勤怠ではなく、原価と採算のための時間の割り当てです。

目的が違うので、判定ロジックも制度改定への追従も要りません。 必要なのは「案件番号と時間が紐づいて残っていること」だけです。 そして案件のアプリがすでにkintoneにあるなら、 その案件と時間を結びつけるのはkintoneの得意な形に近い。 案件別の集計まで持っていく話は「kintone 原価管理」、Excelでの限界のほうから見た整理は「原価管理をエクセルで回し切る現場の型」にあります。

判定表：どちら側に置くか

ここまでを1枚にまとめます。この表は製品の優劣ではなく、その仕事の性質がどちらに向いているかの整理です。

先に決めること：打刻か、集計か、申請か

最後に、道具の選定より前に決めることを書きます。 「勤怠をなんとかしたい」という相談は、実際には3つの別の困りごとが混ざっています。

この3つは原因も打ち手も別です。それなのに「勤怠アプリ」という1つの箱にまとめようとすると、必ず破綻します。 入口を整えるつもりで作り始めたのに、途中で判定の話が出てきて、 そこから集計と繰越の実装に入り、最後まで作りきれずに紙が残る。 当社が見てきた止まり方の典型です（統計ではなく、支援の現場での観察です）。

なので順番はこうなります。3つのどれで困っているのかを先に1つ選ぶ。 困りごと3なら、kintoneに申請と承認を置くところから始められます。 困りごと1と2なら、専用のシステムを見るほうが素直です。 その上で、案件への時間の割り当てのような自社固有の記録が必要なら、 そこだけをkintone側に持たせる。この分け方で組んだ会社は、 作り直しになりにくい印象があります。

そして、どの道を選ぶにしても、先にやることは同じです。 いまの勤怠が誰の手で、どの順番で、何を見て処理されているのかを書き出すこと。 やり方は「業務の棚卸しのやり方」にまとめています。道具の比較から入ると、 自社が何を決めていないのかが分からないまま機能表を眺めることになります。 これは勤怠に限らず、CRMでも同じです（「不動産会社にSalesforce・HubSpotは合うのか」「中小企業向けCRM比較」）。

kintoneをどこまで自社の管理基盤に使うか、という広い話は 「不動産会社がkintoneで顧客管理・物件管理を始める方法」や「kintone 在庫管理はどこまでできる？」でも扱っています。構造を決めてから道具を選ぶ——順番はそれだけです。

※ 本記事は公開されている資料をもとにした一般的な整理です。 引用した料金と仕様はサイボウズの公表値（2026年8月時点の掲載）で、 コースの内容や価格は改定される可能性があります。導入前に必ず提供元の最新の情報を確認してください。 「月10,000円」「月18,000円」は、上表の最低契約ユーザー数10ユーザーに月額を掛けて 当社が算出したものです（いずれも税抜）。労働に関する法令の条文、記録の保存期間、 勤怠システムの製品名・価格、kintone側の勤怠向け機能の有無については、 確認できていないため本記事では扱っていません。 向く／向かないの整理と、困りごとを3つに分ける切り方は、 当社が支援の現場で見てきた傾向であり、統計的に検証された区分ではありません。