kintoneを数年使っていると、「このまま続けるか、別のものに移すか」を考える場面が来ます。改修の見積が届いたとき、在庫や原価が合わなくなったとき、他のシステムとデータをつなぎたくなったときが典型です。
このハブは、kintoneを否定するためのものではありません。そのまま使う、一部を外へ出す、段階的に移す——この3つを自分で選べるように、公開されている仕様と契約条件を並べます。
kintoneは、いつまで使い続けていいのか？
業務がkintoneの標準機能で回っている間は使い続けて構いません。判断が要るのは改修が積み上がってからです。
kintoneは、部門ごとの申請、案件管理、簡易な台帳のように「表とワークフローで表せる業務」を、情報システム部門がなくても組み立てられるところに強みがあります。ここで足りているなら、乗り換えを検討する理由はありません。
考え始める合図は、機能そのものではなく運用側に出ます。JavaScriptやプラグインでの作り込みが増えて、触れる人が社内に1人しかいない。毎月のようにベンダーへ改修を依頼している。標準機能でできないことを、担当者の手作業とExcelで埋めている。こうした状態は、kintoneの欠陥というより、業務のほうがkintoneの設計思想から離れてきたことを示しています。
どこから読み始めればよいのか？
困っている内容で選びます。全体像なら限界、在庫と原価なら専用記事、移行方法なら段階刷新から読んでください。
- kintoneの限界はどこか？レコード数・連携・改修費で判断する — 「なんとなく重い」「見積が高い」という段階で、まず何を測ればよいか分からない方向けです。公式の仕様上の上限と、運用上の判断材料を分けて整理しています
- 在庫・原価管理をkintoneで続けられるか？向く条件と限界 — 在庫数が合わない、原価が出せない、複数拠点で数字がずれる、といった具体的な症状が出ている方向けです
- kintoneを捨てずに移行できるか？API連携から始める段階刷新 — 移す方向はおおよそ決まったが、止められない業務があって踏み切れない方向けです
3本は独立して読めますが、「限界 → 在庫・原価 → 段階刷新」の順に読むと、測る・切り分ける・移す、の流れになります。
判断を始める前に、社内で集めておく情報は？
4つです。アプリごとの利用者、改修の依頼履歴、手作業で埋めている処理、そして契約コースを集めてください。
この4つが揃わないまま「kintoneは限界か」を議論しても、結論が人によって変わります。逆にここが埋まっていれば、続ける場合の費用と、移す場合の費用を同じ土俵に載せられます。
| 集めるもの | 具体的に見るところ |
|---|---|
| アプリごとの利用者 | 誰が毎日使い、誰が月1回しか開いていないか |
| 改修の依頼履歴 | 直近1年に何件、どの業務で発生したか |
| 手作業で埋めている処理 | kintoneの外でExcelや転記が発生している箇所 |
| 契約コースとユーザー数 | 現在のコース、契約ユーザー数、月額契約か年額契約か |
「手作業で埋めている処理」は見落とされがちです。システムの中では完結しているように見えても、実際は担当者が毎朝CSVを書き出して突き合わせている、というケースがあります。この作業は退職や異動で止まるため、判断材料として先に洗い出しておく価値があります。
kintoneの契約条件は、判断にどう関わるのか？
コースで使える機能と料金が変わります。契約単位と最低期間も、乗り換えの進め方を左右します。
サイボウズの料金ページでは、ライトコースが1ユーザーあたり月額1,000円、スタンダードコースが1,800円、ワイドコースが3,000円（いずれも税抜）と公表されています。最小ユーザー数はライトとスタンダードが10ユーザー、ワイドが1,000ユーザーです。年額契約の場合は1ユーザーあたりライト12,000円、スタンダード21,600円、ワイド36,000円（税抜）と示されています。
コースによる差はここだけではありません。同じ料金ページの比較表では「外部サービス連携、プラグインなどの拡張機能」がスタンダードコースとワイドコースの提供内容として示され、ライトコースは対象外と表示されています。1アプリごとのAPIリクエスト数は、スタンダードコースが1日1万、ワイドコースが1日10万と公表されています。つまり「他システムとつなぐ」という選択肢を取れるかどうかは、契約コースの時点で決まります。
契約の変え方も、移行の進め方に影響します。サイボウズのライセンスに関するご案内（クラウド版）によると、月額サービスの最低利用期間は1か月で、契約ユーザー数の追加は任意のタイミングで可能ですが、削減は変更発注日の翌月1日から適用されます。年額サービスでは、サービス期間の途中でできるのはユーザー数の追加とコースのアップグレードのみで、削減とダウングレードは契約更新時に限られ、期間途中の解約はできないと記載されています。
段階的に移す場合、kintoneのユーザー数をどの時点で減らせるかは、この契約形態で決まります。年額契約のまま「来月から半分に減らす」ことはできない前提で計画を立ててください。
乗り換えを決める前に、避けたい進め方は？
3つあります。全面刷新を前提に置くこと、現行の画面をそのまま作り直すこと、そして期限を先に決めることです。
全面刷新を前提に置く。kintoneで動いている業務のうち、困っているのは一部であることがほとんどです。全部を作り直す前提にすると費用も期間も跳ね上がり、実際には困っていなかった業務まで作り替えることになります。
現行の画面をそのまま作り直す。いまの画面は、kintoneでできる範囲に合わせて設計されています。その形を仕様として渡すと、kintoneの制約を引き継いだまま別の場所に移すことになります。移す前に、何のためにその項目を入力しているのかを確かめてください。
期限を先に決める。「年度内に切り替える」と決めてから中身を検討すると、確認が足りないまま並行稼働に入ります。止められない業務があるなら、期限より先に切り戻しの条件を決めるほうが安全です。
なお、移す場合に「誰へ頼むか」まで含めて考えるなら、エンジニア採用・SES・受託開発の違いは？外部開発チームを含む4つを比較で契約の型ごとの違いを整理しています。
自社の状況をどう測ればよいか整理したい場合は、お問い合わせからご相談ください。乗り換えありきではなく、続ける場合の条件から一緒に確認します。