「業務システムは kintone でいいのか、スクラッチで作るべきか？」 — 中小企業の経営者・情シス担当者から最も多いご相談のひとつです。本記事では、両者の特性を踏まえた 判断の 5 軸 を、第三者の立場で整理します。
結論を先に：「短期で動かしたい × 業務が定型」なら kintone、「自社の競争力に直結 × 業務が独自」ならスクラッチです。ただし、選択肢は二者択一ではなく 「kintone で 1〜2 年 → スクラッチに移行」 というハイブリッド戦略が現実的に最も成功率が高い、というのが現場感覚です。
なぜこの判断が中小企業にとって重要か
業務システムの選択は、その後 5〜10 年の 業務生産性・人件費・拡張余地 を左右します。中小企業の場合、間違った選択をしても「数億円の損失」までは行きませんが、「年間 300〜500 万円の機会損失 × 5 年」は十分起こり得ます。
そして両者の本質的な違いは「コスト」ではなく 「業務を道具に合わせるか、道具を業務に合わせるか」 の哲学の違いです。kintone は前者、スクラッチは後者。これを取り違えると、どちらを選んでも失敗します。
kintone の得意領域と苦手領域
得意領域
- 申請ワークフロー：休暇申請、稟議、経費精算など定型の承認フロー
- 案件管理 / 顧客台帳：営業の進捗、見積もり管理、顧客情報の集約
- 日報 / 議事録：テンプレ化された日々の入力業務
- 簡易な在庫 / 設備管理：件数が中規模（〜数千件）
苦手領域
- 顧客向け公開システム：EC、予約、会員サイトには UX が向かない
- 複雑な業務フロー：条件分岐が多い、リアルタイム連携が必要
- 大量データ処理：1 アプリ数十万件超でパフォーマンス低下
- 独自 UI 重視：kintone のレイアウトが業務に合わないケース
スクラッチ開発の得意領域と苦手領域
得意領域
- 自社サービスの中核機能：顧客向け Web アプリ、自社プロダクト
- 独自業務フロー：競合他社にない独自の業務プロセスをそのままシステム化
- 高負荷 / 大量データ：EC、SaaS、データ分析基盤など
- 外部 API・既存システムとの深い連携：会計、POS、製造機械など
苦手領域
- 短期立ち上げ：最短でも 2〜3 ヶ月、通常 4〜6 ヶ月
- 初期費用：100〜500 万円のキャッシュアウトが先にある
- 仕様変更コスト：動き始めた後の機能追加は kintone より重い
- 運用 / 保守の継続的責任：セキュリティパッチ、サーバー監視など
軸 1: 初期費用 vs 月額固定費
最初に効いてくるのが キャッシュフロー です。
| 項目 | kintone | スクラッチ |
|---|---|---|
| 初期費用 | 0 円（設計・導入支援を入れて 30〜80 万円） | 100〜500 万円（要件次第で 1,000 万円超も） |
| 月額 | 1,500〜3,000 円/ユーザー | 1〜5 万円（サーバー＋保守） |
| 3 年合計（10 名） | 約 50〜130 万円 | 約 140〜700 万円 |
| 機能追加 | 多くはノーコードで自社対応可 | 外注で都度開発費 |
3 年区切りで見ると kintone が圧倒的に有利。ただしユーザー数が増えると（50 人超）、月額が積み上がって 5 年でスクラッチに追いつくケースもあります。
軸 2: 業務フローの「揺らぎ」と「カスタム要求」
最も見逃されがちな判断軸が 業務フローの揺らぎ です。
揺らぎが大きい業務 → kintone 向き
- 毎月のように承認ステップが変わる
- 新規事業立ち上げで業務がまだ固まっていない
- 部署ごとに微妙にルールが違う
kintone なら情シス担当者が 1 時間で項目追加・ワークフロー修正 できます。スクラッチだと外注して 1〜2 週間、見積もり数十万円かかります。
揺らぎが小さい業務 → スクラッチ向き
- 業務手順が法規制で固定（医療、金融、製造の検査など）
- 5 年以上同じ業務フローで運用してきた
- 競合他社と差別化したい独自のフロー
揺らぎが小さい業務は「初期は重いが、その後は微変更で済むスクラッチ」が結果的に安く済みます。
軸 3: 既存システム連携の必要性
既に弥生会計、freee、Salesforce、楽天市場、自社 POS など 「核となるシステム」 がある場合、それらとの連携の深さで判断が変わります。
連携が「データの参照・転記」レベル → kintone OK
kintone は REST API、Webhook、kintone × 各種 SaaS 連携プラグイン（gusuku、Krewx 等）が豊富。「会計データを月 1 回 CSV で取り込む」「Salesforce の顧客マスタを参照」などの軽い連携は十分対応できます。
連携が「リアルタイム / 双方向 / 業務クリティカル」レベル → スクラッチ
EC で在庫がリアルタイム反映、製造機械の IoT データを 1 分以内に集約、決済処理を業務システム側で行う、といった 「失敗が許されない連携」 はスクラッチが安全です。kintone の API レート制限（1 アプリ秒間 数十リクエスト）がボトルネックになるケースもあります。
軸 4: 社内 IT 担当者の有無
意外と見落とされる軸が 「社内に kintone をいじれる人」がいるか です。
社内に IT 担当者あり（または育てる気がある）→ kintone がワークする
kintone の最大の強みは「現場が自分でアプリを作り、改善できる」ことです。これは 情シス担当者 0.5〜1 名分 の手間があってこそ実現します。外注に丸投げする運用だと、結局スクラッチと同程度のコストになります。
社内に IT 担当者なし → スクラッチ + 外注保守の方が破綻しない
「kintone を入れたが、社内で誰もいじれない → 結局外注頼み → 月額が嵩む」というパターンは中小企業で頻発します。社内体制が整わないなら、最初からスクラッチ + 月額固定の保守契約の方が予算管理しやすいです。
軸 5: 5 年運用コストのシミュレーション
意思決定の前に必ずやるべきが、5 年運用コストの両者比較です。Excel で十分なので、以下の項目を埋めて比較してください。
シミュレーション項目（両者共通）
- 初期費用
- 月額（× 60 ヶ月）
- ユーザー数増加見込み（年率 X%）
- 機能追加見込み（年 N 件 × 平均コスト）
- 保守 / 障害対応コスト
- サーバー / ライセンスのアップグレード費
- 社内担当者の人件費（IT 担当者が 0.5 名分稼働するなら、その人件費）
特に 社内担当者の人件費を計算に入れる ことが重要。これを忘れると kintone が過大評価されます。一方、スクラッチ側も 「外注頼みで急ぎの修正に 2 週間かかる機会損失」 を計算に入れる必要があります。
ハイブリッド戦略（最初 kintone → 後でスクラッチ）
現場経験上、最も成功確率が高いのが 「最初 kintone で 1〜2 年 → 業務要件が固まったタイミングでスクラッチに移行」 パターンです。
このパターンが効く理由
- 業務要件が固まる：kintone で運用して初めて「本当に必要な機能 / 不要な機能」が見えてくる
- 初期キャッシュアウトを抑えられる：最初の 1〜2 年は kintone の安いコストで済む
- 移行時にスクラッチ仕様書がほぼ完成：kintone のアプリ設計がそのまま要件定義書になる
- 段階移行が可能：核業務だけスクラッチ、周辺業務は kintone 継続、というすみ分けもしやすい
スグレルでも、お客様の最初の 1〜2 年は「kintone で骨格を作る → 業務要件が見えてきたら、コア機能だけスクラッチで作り直す」というご提案をするケースが多くあります。詳しくは 業務システム開発サービス も併せてご覧ください。
よくあるご質問
kintone はどんな業務に向いていますか？
案件管理、顧客台帳、申請ワークフロー、日報、在庫の簡易管理など『リストで持てるデータを、複数人で操作する』業務に向いています。逆に、外部公開する EC サイト・予約システム・自社サービスの中核機能はスクラッチが推奨。kintone は社内業務の道具として使うのが基本です。
kintone とスクラッチ、月額の総コストはどれくらい違いますか？
kintone は初期 0 円 + ユーザー数課金（月 1,500〜3,000 円/人）。10 人で月 1.5〜3 万円、年 20〜36 万円。スクラッチは初期 100〜500 万円 + サーバー / 保守費（月 1〜5 万円）。3〜5 年で総コストはほぼ拮抗、その後はスクラッチが安くなる傾向。
kintone でカスタマイズはどこまでできますか？
JavaScript / CSS カスタマイズ、プラグイン（gusuku Customine など）、API 連携、外部 BI 接続が可能です。ただし『kintone の枠組み内でのカスタマイズ』なので、根本的な UX 変更や複雑な業務フロー実装には限界があります。
最初 kintone でやって、後でスクラッチに移行できますか？
可能ですし、実際におすすめのパターンです。kintone で 1〜2 年運用して業務要件を固め、本当に必要な機能だけをスクラッチで作り直す。逆順（スクラッチ → kintone）は柔軟性が落ちるので避けるべきです。