はじめに:「kintoneでできない」が増えてきたら、見直しのタイミングかもしれません
kintoneは、サイボウズ社が提供するクラウド型の業務アプリ構築プラットフォームです。専門的なプログラミング知識がなくても、案件管理・顧客管理・日報・在庫管理などのアプリを作れるため、多くの中小企業のDX推進を支えてきました。
特に、Excelや紙で管理していた情報をkintoneに移すことで、情報の一元管理・リアルタイム共有・外出先からの確認がしやすくなります。導入しやすく、比較的低コストで始められることから、「まずはkintoneで業務を整える」という判断はとても合理的です。
一方で、会社の成長とともに業務が複雑になると、「kintoneではここが足りない」「この運用はもう限界」と感じる場面が出てきます。最初は小さな不便でも、放置すると現場の負担や管理コストがじわじわ膨らんでいきます。
重要なのは、「kintoneでできない」が増えること自体は、会社の業務が成長・高度化しているサインでもあるという点です。ツールが悪いのではなく、今の業務規模に対して、導入当初の仕組みが合わなくなってきている可能性があります。
この記事では、中小企業がkintone運用で直面しやすい「SaaSの限界」を7つのパターンに整理して解説します。あわせて、自社がどの状態にあるのかを確認できるチェックリストと、次に取るべき選択肢も紹介します。
【前提理解】なぜkintoneは「限界」を迎えるのか
kintoneは「広く使える」からこそ、深い最適化には限界がある
kintoneの強みは、業種や業務を問わず幅広く使える汎用性です。営業管理、問い合わせ管理、申請管理など、さまざまな用途に柔軟に対応できます。
ただし、その汎用性は裏を返せば「特定業務に深く最適化しすぎていない」ということでもあります。つまり、kintoneは“多くの会社にとって使いやすい設計”である一方、“自社独自の複雑な業務”には限界が出やすいのです。
たとえば、業種特有の計算ロジック、複雑な承認フロー、細かい権限制御、特殊な帳票レイアウトなどは、標準機能だけでは対応しきれないことがあります。これは欠点というより、SaaSとしての設計上の特性といえます。
SaaSには「できること」と「できないこと」の境界がある
kintoneに限らず、SaaSには必ず仕様上の制約があります。なぜなら、多数の企業が同じ基盤を共有して使うサービスだからです。
個別企業ごとの要望をすべて深く反映してしまうと、運用や保守が複雑になり、サービス全体の安定性や使いやすさが損なわれます。そのため、SaaSはあえて機能を絞り、「誰でも使いやすい」「低コストで始めやすい」ことを優先しています。
この構造は導入初期には大きなメリットですが、業務が複雑化した段階では制約として表面化します。つまり、SaaSの限界は不具合ではなく、ビジネスモデル上の前提なのです。
中小企業ほど影響を受けやすい3つの理由
kintoneの限界が見えたとき、大企業であれば専任担当者の配置や追加開発で対応できることがあります。しかし、中小企業ではそうした余力がないケースも少なくありません。
- IT専任者がいない:総務や経理などの兼務担当が運用しており、複雑な設定や保守に手が回らない
- 属人化しやすい:一部の担当者しか仕組みを理解しておらず、退職や異動で運用が止まりやすい
- コスト増の影響が大きい:ユーザー数やプラグイン費用の増加が、そのまま経営負担になりやすい
この3つが重なると、kintoneの小さな不便が、現場の大きなストレスや経営課題へと変わっていきます。
限界パターン①:カスタマイズが「壁」にぶつかる
アプリが複雑化し、使いにくさが目立ち始める
kintoneは手軽にアプリを作れる反面、業務の追加や例外対応を重ねるうちに、アプリ構成がどんどん複雑になりがちです。フィールドが増え、条件分岐が増え、サブテーブルも増えると、画面は見づらくなり、入力ミスも起きやすくなります。
その結果、「必要な情報がどこにあるかわからない」「入力項目が多すぎて現場が嫌がる」といった状態になり、せっかく作ったアプリが使われなくなることもあります。
特に、複数の業務を1つのアプリに詰め込みすぎている場合は要注意です。運用当初は便利でも、業務拡大とともに破綻しやすくなります。
プラグインで補うほど、管理が難しくなる
標準機能で足りない部分を補うために、プラグインを導入する企業は多くあります。帳票出力、カレンダー表示、集計、通知、外部連携など、便利な拡張手段が豊富にあるのはkintoneの魅力です。
ただし、プラグインが増えるほど、次のような問題が起きやすくなります。
- 月額費用が積み上がる
- アップデート時の不具合リスクが増える
- 設定内容を理解している人が限られる
- プラグイン同士の相性問題が起きる
「プラグインで何とかしている状態」が長く続いているなら、それは延命ではあっても根本解決ではない可能性があります。
「kintoneらしくない使い方」になっていないか確認する
kintoneは、シンプルな情報管理や業務の見える化に強いツールです。一方で、基幹システムのような複雑な処理や、細かい業務ロジックをすべて抱え込ませる使い方は得意ではありません。
もし今、kintoneで受発注・在庫・会計・承認・帳票・分析まで全部を無理に完結させようとしているなら、本来は別の仕組みで支えるべき業務を、kintoneに詰め込みすぎているかもしれません。
限界パターン②:ライセンス費用が業務拡大とともに膨らむ
ユーザー数課金は、成長企業ほど重くなりやすい
kintoneはユーザー数に応じて費用が増える課金体系です。導入初期は少人数で始められるため、コストを抑えやすいのが魅力です。
しかし、社員数が増えたり、現場スタッフや外部関係者にも使わせたくなったりすると、費用は比例して増えていきます。さらに、プラグインや連携ツールを追加すると、見えにくい形で運用コストが膨らみます。
| ユーザー数 | 月額費用の目安 | 年間費用の目安 |
|---|---|---|
| 10名 | 約15,000円 | 約180,000円 |
| 30名 | 約45,000円 | 約540,000円 |
| 50名 | 約75,000円 | 約900,000円 |
| 100名 | 約150,000円 | 約1,800,000円 |
※上記はkintone本体のみの目安です。実際にはプラグイン費用や連携費用が加わるため、50名規模でも年間200〜300万円規模になるケースがあります。
月額では安く見えても、長期では大きな差になる
SaaSは初期費用が低いため、導入時の心理的ハードルが低い一方で、長期的な総額が見えにくい傾向があります。月額数万円でも、5年・7年と使い続ければ大きな金額になります。
一方、オーダーメイドシステムは初期費用こそ必要ですが、ユーザー数に応じて費用が増えにくい構造にできる場合があります。つまり、「初期費用が高いから不利」とは一概に言えず、長期のTCOで逆転することもあるのです。
見落としがちな「隠れコスト」も確認する
費用対効果を正しく判断するには、ライセンス費用だけでなく、運用にかかる周辺コストも含めて考える必要があります。
- アプリ設計やメンテナンスにかかる社内工数
- Excelや紙で補完している作業時間
- プラグインや連携ツールの利用料
- 外部パートナーへの設定・改修依頼費用
- トラブル対応やデータ修正の手間
こうしたコストを合算すると、「思っていたより高い」と気づくことは少なくありません。
限界パターン③:既存システムとの連携が思うように進まない
API連携はできても、簡単とは限らない
業務が広がると、kintoneと会計ソフト、ECサイト、基幹システムなどをつなぎたくなります。kintoneにはAPIがありますが、実際の連携では認証方式やデータ形式の違い、例外処理など、専門知識が必要になる場面が多くあります。
そのため、「技術的には連携可能」でも、「現実的には外注しないと難しい」というケースがよくあります。しかも、連携先の仕様変更があるたびに保守対応も必要です。
連携できても、片方向や手動運用が残りやすい
ZapierやMakeなどのiPaaSを使えば、ある程度の自動連携は可能です。ただし、双方向同期や複雑な条件分岐を含む運用になると、設定だけでは対応しきれないことがあります。
結果として、「片方向だけ自動」「最終確認は手動」「定期的にCSVで取り込み」といった中途半端な運用が残りやすくなります。これは一見便利でも、業務全体で見ると非効率です。
二重入力が常態化しているなら、すでに危険サイン
kintoneと別システムの両方に同じ情報を入力している状態は、明確な非効率です。工数が増えるだけでなく、転記ミスや入力漏れ、データ不整合の原因になります。
「kintoneにも入力、会計ソフトにも入力、最後にExcelにも転記」という流れが残っているなら、DXが途中で止まっている状態です。連携の見直し、もしくはシステム全体の再設計を検討すべきタイミングです。
限界パターン④:帳票・出力形式が業務に合わない
標準印刷だけでは、実務の帳票要件に届かないことがある
見積書、納品書、請求書、報告書、点検票など、実務で使う帳票には細かなレイアウト要件があります。会社ロゴ、印影欄、指定位置への表示、複数明細の整形など、求められる水準は意外と高いものです。
kintoneの標準機能だけでは、こうした帳票を思い通りに出力できない場合があります。帳票プラグインで補えることもありますが、業種特有の複雑な帳票や独自フォーマットになるほど限界が出やすいのが実情です。
ツールを足すほど、仕組みが複雑になる
帳票の問題を解決しようとして、帳票プラグイン、PDF変換ツール、電子署名ツールなどを追加していくと、運用はどんどん複雑になります。
- どのツールで何をしているのか把握しづらい
- 担当者が限られ、属人化しやすい
- どれか1つ止まると業務全体に影響が出る
- 月額費用が積み上がる
この状態は、部分最適を積み重ねた結果、全体最適を失っている状態です。
Excel転記が残っているなら、出力まわりの見直しが必要
kintoneに入力したデータを、最終的にExcelで整形して提出している職場は少なくありません。しかし、それでは入力だけがデジタル化され、出力は旧来のままです。
入力がデジタルでも、出力のために毎回Excel加工が必要なら、業務全体はまだ効率化できていないと考えるべきです。帳票が業務の最終成果物である以上、出力まで含めて仕組み化する必要があります。
限界パターン⑤:権限管理・セキュリティ要件を満たしにくい
細かいアクセス制御が必要になるほど難しくなる
kintoneには権限設定機能がありますが、業務が複雑になると「誰に何をどこまで見せるか」の設計も細かくなります。部署ごと、役職ごと、担当案件ごと、取引先ごとに閲覧範囲を変えたいケースは珍しくありません。
しかし、特定フィールドだけ非表示にしたい、条件によって閲覧権限を動的に変えたいといった要件は、標準機能だけでは難しいことがあります。
業種特有のコンプライアンス要件に合わない場合がある
医療、介護、建設、金融などの業界では、法令やガイドラインに基づく厳格な管理が求められることがあります。
- 医療・介護:個人情報保護、アクセスログ、保存要件への対応
- 建設:工事台帳や協力会社との情報共有範囲の管理
- 金融・保険:操作ログの保全、不正アクセス対策、監査対応
kintoneは汎用SaaSであるため、こうした要件に完全一致するとは限りません。監査や取引先審査の段階で、見直しが必要になるケースもあります。
「使いやすさ」を優先して、セキュリティを妥協していないか
現場では、セキュリティを厳しくすると使いにくくなる場面があります。そのため、「少し不便だから設定を緩めよう」という判断が起きがちです。
しかし、本来必要なセキュリティ要件を満たせないから運用でごまかしているのであれば、それはシステム側の限界です。情報漏えいのリスクは、業務の不便さよりはるかに大きな損失につながります。
限界パターン⑥:処理速度・データ量の上限に近づく
データが増えるほど、検索や集計が重くなる
kintoneを長く使うと、レコード数は自然に増えていきます。数万件、数十万件と蓄積されると、検索・絞り込み・集計の速度に影響が出ることがあります。
「月次レポートの出力に時間がかかる」「条件検索で待たされる」「一覧表示が重い」といった症状が出てきたら、運用の問題ではなく、構造的な負荷の問題を疑うべきです。
高度な分析や横断集計は、単体運用では厳しくなりやすい
kintoneにはグラフ機能がありますが、経営判断に必要な高度な分析までカバーするには限界があります。複数アプリをまたいだ分析や、長期トレンドの比較、細かなクロス集計などは、外部BIツールやExcelに頼ることが増えます。
その結果、分析のたびにデータを出力する手作業が発生し、最新性や即時性が失われます。これは、意思決定のスピードにも影響します。
小さな待ち時間の積み重ねが、生産性を削っていく
1回あたり数秒の遅延でも、毎日何十回も操作する業務では大きなロスになります。ユーザー数が多いほど、組織全体の損失時間は無視できません。
「少し遅いけど慣れた」で済ませているうちに、現場の集中力と作業効率が確実に落ちていく点は見逃せません。
限界パターン⑦:業務固有のロジックをシステムに反映しきれない
独自の計算式や承認ルールが再現しづらい
企業ごとに、独自の見積計算、承認フロー、在庫判断、通知ルールなどがあります。こうした「自社ならではの業務ルール」をシステムに反映できるかどうかは、業務効率に直結します。
kintoneでもある程度の条件分岐や計算は可能ですが、複雑になるほど実装や保守が難しくなります。JavaScriptカスタマイズで対応できる場合もありますが、担当者しか理解できないブラックボックス化を招きやすい点には注意が必要です。
システムに合わせて業務を変えていないか
本来、システムは業務を支えるためのものです。しかし、kintoneで再現できないことが増えると、「できないから業務を変えよう」という逆転現象が起きることがあります。
たとえば、複雑な計算を手作業に戻したり、本来必要な承認を簡略化したりするケースです。こうした対応は一時しのぎにはなっても、業務品質の低下や、自社らしさの喪失につながる恐れがあります。
現場の不満が表に出なくなったときほど危ない
「kintoneでは無理だから手でやる」が当たり前になると、現場は不満を言わなくなります。経営層から見ると問題なく回っているように見えても、実際には非効率が固定化していることがあります。
競合がより自社業務に合った仕組みを使っているなら、その差は徐々に競争力の差として表れます。現場の“慣れ”に埋もれた課題こそ、定期的に掘り起こす必要があります。
「7つの限界」を放置すると何が起きるのか
現場のストレスが増え、属人化が進む
システムでできないことを手作業で補う状態が続くと、現場の負担は確実に増えます。しかも、そのやり方を知っている人が限られるほど、属人化も進みます。
その結果、担当者が休む、異動する、退職するだけで業務が止まるリスクが高まります。これは中小企業にとって非常に大きな経営リスクです。
経営に必要なデータが、必要なときに取れなくなる
データが分散し、集計に時間がかかり、分析のたびに手作業が必要になると、意思決定のスピードが落ちます。市場変化への対応が遅れれば、そのまま機会損失につながります。
データを持っているのに使いこなせない状態は、DXの失敗パターンのひとつです。
システムの限界が、会社の成長の限界になる
最も深刻なのは、「このシステムでは無理だから、新しい取り組みを諦める」という判断が増えることです。システムが事業の足かせになると、成長戦略そのものが制限されます。
本来、システムは経営に合わせて進化させるべきものです。現状のツールに経営を合わせる状態になっているなら、見直しが必要です。
自社は何パターン当てはまる? 限界度チェックリスト
まずは21項目で現状を確認してみましょう
| パターン | チェック項目 |
|---|---|
| ①カスタマイズの壁 | アプリが複雑化し、全体像を把握できる人が限られている |
| プラグインの数が増え、管理や更新が負担になっている | |
| 「kintoneでやり切るのは無理がある」と感じている | |
| ②コストの膨張 | ユーザー数の増加でライセンス費用が重くなってきた |
| 本体以外のプラグイン・連携費用がかさんでいる | |
| 導入当初より割高に感じている | |
| ③システム連携の限界 | 他システムとの連携が手作業になっている |
| CSVの出力・取込を定期的に行っている | |
| 二重入力・二重管理が解消できていない | |
| ④帳票出力の問題 | kintoneのデータをExcelで整形して帳票化している |
| 自社フォーマットの帳票をそのまま出せない | |
| 帳票プラグインでも要件を満たせない | |
| ⑤権限・セキュリティの限界 | 見せる・見せないの制御が細かくできていない |
| 業界要件や監査対応に不安がある | |
| 使いやすさを優先してセキュリティを妥協している | |
| ⑥速度・データ量の問題 | 検索や集計が遅くなってきた |
| 分析や経営報告に時間がかかる | |
| 今後のデータ増加に不安がある | |
| ⑦業務ロジックの未反映 | 独自の計算や承認フローを再現できていない |
| kintoneに合わせて業務を変えたことがある | |
| 現場から使いにくさや手作業の多さが指摘されている |
該当数ごとの目安
| 該当パターン数 | 状況 | 次のアクション |
|---|---|---|
| 1〜2個 | まだ局所的な課題 | kintone内での改善・再設計を検討 |
| 3〜5個 | 複数課題が重なり始めている | 再設計か他システム移行を本格検討 |
| 6〜7個 | 事業成長のボトルネックになっている可能性が高い | オーダーメイドシステムを含めて早急に相談 |
チェック結果は、現場担当者・管理職・経営層の3者で共有するのがおすすめです。「kintoneが悪いかどうか」ではなく、「今の業務に合っているかどうか」という視点で話し合うことが大切です。
kintoneの限界を超えるための3つの選択肢
選択肢①:kintone内で再設計する
課題が一部に限られているなら、アプリ構成の見直しや不要なプラグインの整理で改善できる場合があります。複雑なアプリを分割し、運用ルールを整理するだけでも、使いやすさは大きく変わります。
ただし、kintone自体の仕様上の制約は変わらないため、根本課題が大きい場合は再び同じ壁にぶつかる可能性があります。
選択肢②:他のSaaSへ乗り換える
課題が帳票、受発注、会計連携など特定領域に集中しているなら、その業務に特化したSaaSへ切り替える方法もあります。特化型SaaSは、その領域ではkintoneより使いやすいことがあります。
ただし、別のSaaSに移っても、また別の制約に悩まされる可能性はあります。無料トライアルやデモで、自社の実際の業務フローに合うかどうかを十分に確認することが重要です。
選択肢③:オーダーメイドシステムへ移行する
複数の限界が同時に出ている場合は、自社業務に合わせたオーダーメイドシステムが有力な選択肢になります。独自ロジック、権限設計、帳票、外部連携などを一体で設計できるため、根本解決につながりやすいのが特徴です。
- 自社独自の業務フローをそのままシステム化できる
- 複数システムとの連携を前提に設計できる
- 帳票や出力形式を自由に作れる
- 業種特有のセキュリティ・コンプライアンス要件に対応しやすい
- ユーザー数増加によるライセンス費用の影響を抑えやすい
初期費用は必要ですが、長期的なTCOや業務効率、人件費削減まで含めて考えると、十分に合理的な選択になることがあります。
3つの選択肢を比較する判断マトリクス
| 判断軸 | kintone再設計 | 他SaaSへ乗換 | オーダーメイド |
|---|---|---|---|
| 初期コスト | 低〜中 | 低〜中 | 高 |
| ランニングコスト | 中 | 中 | 低〜中 |
| 自社業務への適合度 | 部分対応 | 部分対応 | 高い |
| 外部連携の柔軟性 | 限定的 | 限定的〜中程度 | 高い |
| 帳票・権限・独自要件 | 制約あり | SaaS仕様に依存 | 柔軟に設計可能 |
| 向いているケース | 課題が軽微 | 特定領域だけ課題 | 複数の根本課題がある |
オーダーメイドシステムを検討すべき企業の特徴
判断基準は「会社の規模」より「業務の複雑さ」
オーダーメイドシステムは大企業向けと思われがちですが、実際には従業員10〜50名規模でも有効なケースがあります。重要なのは売上や人数ではなく、業務の複雑さです。
- 汎用SaaSでは再現できない独自フローがある
- 複数システム間で頻繁なデータ連携が必要
- ユーザー数増加でSaaSコストが重い
- 業界特有のセキュリティ・監査要件がある
- 今後さらに業務が複雑化する見込みがある
このような企業は、早い段階で選択肢に入れておく価値があります。
実際に業務改善につながった事例
実際に、オーダーメイドシステムによって業務改善を実現した企業もあります。
- アクティビティ予約・運営企業様:予約管理・スタッフシフト・精算処理を一元化し、日々の事務作業を従来比1/6に短縮
- タイヤリサイクル業の企業様:業種特有の引取・処理フローをシステム化し、業務自動化と作業時間短縮を実現
- コンサルティング企業様:分散していた顧客情報を一元化し、低予算で管理体制を整備
これらに共通するのは、「自社の業務にぴったり合う仕組み」を持つことで、現場の生産性が大きく改善したという点です。
「まだ早い」と思う今こそ、検討を始める価値がある
システム移行は、問題が深刻化してから始めるほど大変になります。データ量が増え、運用が複雑になってからでは、移行コストもリスクも高くなります。
また、今の非効率を放置している間にも、機会損失は積み上がっています。さらに、要件整理から開発、テスト、移行までは一定の時間が必要です。「必要になってから動く」のでは遅いことも多いため、早めの情報収集と相談が重要です。
まとめ:「できない」を我慢しないことが、次の成長につながる
kintoneは、多くの中小企業にとってDXの第一歩を支えてきた優れたツールです。導入当初の判断が間違っていたわけではありません。むしろ、kintoneで業務を整えたからこそ、今の課題が見えるようになったともいえます。
今回紹介した7つの限界パターンは、どれか1つだけで起きることは少なく、複数が重なって現れることが多いものです。
- ①カスタマイズの壁
- ②コストの膨張
- ③システム連携の限界
- ④帳票出力の問題
- ⑤権限・セキュリティの限界
- ⑥速度・データ量の問題
- ⑦業務ロジックの未反映
もし複数当てはまるなら、それは「kintoneが悪い」のではなく、「会社の成長に対して仕組みの更新が必要になっている」サインです。
「今のまま使い続けるか」「kintone内で再設計するか」「他SaaSへ移るか」「オーダーメイドシステムに進むか」。この判断は、現場の使いやすさだけでなく、今後の成長戦略にも関わります。
チェックリストで複数の課題が見つかった場合は、まず現状を整理し、どこに本当のボトルネックがあるのかを明らかにすることが大切です。「できない」を我慢しない経営判断が、次のDXを前に進める分岐点になります。
「kintoneを続けるべきか迷っている」「移行の費用感や進め方を知りたい」という場合は、現状の業務フローと課題を整理したうえで、早めに専門家へ相談するのがおすすめです。