「業務システムを作りたいが、kintoneとスクラッチ開発のどちらがよいのか分からない」
このような悩みを持つ企業担当者は少なくありません。
kintoneは、顧客管理や案件管理、申請管理などの業務アプリを比較的短期間で構築できるクラウド型の業務改善プラットフォームです。
一方、スクラッチ開発は、自社の業務に合わせてプログラムを設計・開発する方法です。
結論からいうと、どちらが優れているというものではありません。
標準的な管理業務を早くシステム化したい場合はkintoneが有力であり、独自業務・複雑な処理・高度な外部連携・将来的な拡張性を重視する場合はスクラッチ開発が向いています。
特に重要なのは、
「今の機能を作れるか」
だけではなく、
「3年後、5年後まで運用しやすいか」
という視点です。
この記事では、kintoneとスクラッチ開発を、費用・開発期間・拡張性・運用負荷・権限管理・外部連携などの観点から比較し、どちらを選ぶべきか分かりやすく解説します。
kintoneとスクラッチ開発の違いを比較
まずは、それぞれの特徴を整理してみましょう。
| 比較項目 | kintone | スクラッチ開発 |
|---|---|---|
| 初期開発 | 比較的小さく始めやすい | 要件に応じた開発費が必要 |
| 開発スピード | 速い | 要件によって長くなる |
| 自由度 | 中程度 | 高い |
| 画面設計 | 用意された仕組みが中心 | 自由に設計可能 |
| 業務ロジック | 標準的な処理に向く | 複雑な処理にも対応しやすい |
| 権限管理 | 標準機能の範囲では構築しやすい | 独自ルールまで設計可能 |
| 外部連携 | APIや連携サービス等で拡張可能 | 必要に応じて独自実装可能 |
| 機能追加 | kintoneの仕組みの範囲で行う | 自由度が高い |
| インフラ管理 | 基本的にサービス側 | 自社・開発会社側で設計 |
| 保守 | 基盤部分の管理負担が小さい | アプリ・インフラ双方の管理が必要 |
| ランニングコスト | 利用人数・プラン等に応じて発生 | サーバー・保守などが発生 |
| ベンダーロックイン | kintoneへの依存がある | 採用技術による |
kintoneは「早く作れる」「運用基盤を自前で構築しなくてよい」という強みがあります。
スクラッチ開発は「自由に作れる」代わりに、設計・開発・保守について考える範囲が広くなります。
したがって、
シンプルな業務を素早く改善するならkintone、システムを自社業務に深く合わせるならスクラッチ
というのが基本的な考え方です。
kintoneとは？業務システムを比較的短期間で作れる
kintoneでは、業務に必要なデータ項目や一覧、ステータスなどを組み合わせてアプリを構築できます。
例えば、Excelで次のような管理をしている企業があるとします。
- 顧客一覧.xlsx
- 案件管理.xlsx
- 問い合わせ一覧.xlsx
- 月次売上集計.xlsx
このような情報をkintone上へ移すことで、
顧客情報を登録
↓
案件情報を紐付ける
↓
担当者がステータスを更新する
↓
管理者が一覧から確認する
といった業務フローを構築できます。
特に、
- 顧客管理
- 案件管理
- 問い合わせ管理
- 日報管理
- 申請・承認
- 備品管理
- 在庫の簡易管理
- タスク管理
など、「データを登録して、検索・更新・共有する」業務との相性がよい方法です。
また、必要に応じてプラグインや外部サービス、APIなどを利用して拡張することもできます。
ただし、拡張できるからといって、あらゆる業務をkintoneへ詰め込むことが最適とは限りません。
スクラッチ開発とは？自社向けに業務システムを設計する方法
スクラッチ開発とは、既存の業務プラットフォームだけに依存せず、必要な機能をプログラムとして個別に開発する方法です。
例えば在庫管理システムなら、
- 商品管理
- 入庫
- 出庫
- 返品
- 在庫引当
- 棚卸
- ロット管理
- 複数倉庫管理
- 発注
- 帳票出力
- 権限管理
といった機能を、自社の業務フローに合わせて設計できます。
画面についても、
「現場ではバーコードを読み込んだら即座に数量入力画面を表示する」
「倉庫担当者と管理者で表示する画面を変える」
「大量の商品を一覧上で高速に編集する」
など、業務に合わせたUIを設計できます。
その分、要求整理、要件定義、設計、開発、テスト、インフラ構築、保守などが必要になるため、kintoneより初期開発の規模が大きくなる傾向があります。
比較1．初期費用はkintoneのほうが抑えやすい
小規模な業務システムであれば、kintoneは比較的小さな費用からスタートしやすいのが特徴です。
例えば、
「これまでExcelで管理していた案件情報を10〜20人で共有したい」
という程度であれば、大規模なシステム開発を行わなくても業務改善できる可能性があります。
一方、スクラッチ開発の場合は、
- 要件定義
- 画面設計
- データベース設計
- プログラム開発
- テスト
- デプロイ
などが必要です。
そのため、一般的には初期費用が大きくなりやすくなります。
ただし、ここで注意したいのが「初期費用だけで判断しない」ことです。
比較2．長期コストは利用人数とカスタマイズ量で変わる
kintoneではサービス利用料が継続的に発生します。
そのため、
10人で利用するのか、
100人で利用するのか、
1,000人で利用するのか、
によって長期的なコストは変わります。
また、
- 有料プラグイン
- 外部連携サービス
- 個別カスタマイズ
- 保守サービス
などを利用すれば、それらの費用も考える必要があります。
一方、スクラッチ開発ではユーザー単位のライセンス料金が発生しない構成も可能ですが、
- サーバー費用
- データベース費用
- クラウド利用料
- 監視
- バックアップ
- 保守
- 障害対応
- 機能追加
などの費用が必要になります。
つまり、
kintone＝安い、スクラッチ＝高い
と単純に判断することはできません。
3年、5年程度利用することを想定し、TCO（Total Cost of Ownership：システムを保有・利用するための総コスト）で比較することが重要です。
比較3．開発スピードはkintoneが有利
kintoneの大きなメリットの一つが、開発スピードです。
例えば、
- 顧客名
- 担当者
- 電話番号
- メールアドレス
- 商談ステータス
- 最終対応日
- メモ
を管理する顧客管理アプリであれば、ゼロからWebシステムを開発するより短期間で構築できる可能性があります。
一方、スクラッチ開発では、入力フォームや一覧画面だけでも、
- フロントエンド
- バックエンド
- データベース
- 認証
- 権限
- バリデーション
- エラー処理
などを実装する必要があります。
「まず業務をデジタル化したい」
「Excel管理を早く卒業したい」
という目的なら、kintoneは有力な選択肢です。
比較4．拡張性はスクラッチ開発のほうが高い
kintoneとスクラッチ開発を比較するとき、特に差が出やすいのが拡張性です。
kintoneもカスタマイズや外部サービス連携によって機能を増やせます。
しかし、最終的にはkintoneというプラットフォーム上で動かす必要があります。
スクラッチ開発なら、
- データ構造
- API
- 画面
- 認証
- 権限
- バッチ処理
- AI機能
- 他システム連携
などを要件に合わせて設計できます。
例えば、最初は単純な顧客管理だったシステムが、
顧客管理
↓
商談管理
↓
見積管理
↓
契約管理
↓
請求管理
↓
売上分析
↓
AIによる営業支援
と成長していく場合を考えてみましょう。
将来的に会社の中核システムまで発展する予定なら、スクラッチ開発の自由度が活きやすくなります。
比較5．独自の業務ロジックはスクラッチ開発が向いている
kintoneは標準的な管理業務に強い一方、独自ルールが増えるほど設計が複雑になりやすくなります。
例えば料金計算で、
基本料金
＋
利用人数による料金
＋
契約期間による割引
＋
顧客ランクによる割引
＋
地域別料金
＋
オプション料金
という計算を行うとします。
さらに、
「特定顧客だけ旧料金体系を適用する」
「2027年4月以降の契約だけ新しい割引率を適用する」
などの例外が増えるかもしれません。
このような複雑な業務ロジックを継続的に変更していく場合は、プログラムとして管理したほうが保守しやすいことがあります。
重要なのは「kintoneで実装できるか」だけではありません。
今後も安全に変更し続けられる構造になっているかまで確認する必要があります。
比較6．権限管理は複雑になるほどスクラッチが有利
業務システムでは、権限設計が重要です。
例えば営業管理なら、
営業担当者
自分が担当する顧客だけ閲覧・編集できる。
営業マネージャー
所属部署の案件を閲覧できる。
経理担当者
請求情報は閲覧できるが、営業メモは編集できない。
経営層
すべての拠点・部署の情報を閲覧できる。
この程度であればkintoneの機能を活用できるケースもあります。
しかし、
- 項目ごとに閲覧権限が異なる
- 案件の状態によって編集権限が変わる
- 拠点・部署・役職を組み合わせて判定する
- 特定の条件を満たしたデータだけ閲覧できる
などの要件が積み重なると、設計が複雑になります。
権限が非常に複雑なシステムでは、スクラッチ開発で認可処理そのものを設計したほうが適している場合があります。
比較7．外部システム連携は内容によって判断する
業務システムでは、他サービスとの連携が必要になることがあります。
例えば、
- 会計システム
- 販売管理システム
- ECサイト
- Google Workspace
- Microsoft 365
- Slack
- メール配信サービス
- 決済サービス
- AIサービス
などです。
kintoneでも外部サービスとの連携やAPIを利用した拡張が可能です。
一方、
「1日数万件のデータを複数システム間で同期する」
「連携に失敗したデータだけ自動再実行する」
「複数システムから情報を取得して複雑な計算を行う」
といった処理になると、専用のバックエンドや連携基盤を構築したほうが管理しやすい場合があります。
外部連携があるからスクラッチ、という単純な判断ではなく、連携量と処理の複雑さを見ることが重要です。
比較8．画面の自由度はスクラッチ開発が高い
kintoneは業務アプリを効率よく作れる反面、完全に自由なWebアプリケーションを作るためのものではありません。
例えば、
- 独自デザインの管理画面
- 大量データを高速編集する表
- ドラッグ＆ドロップ中心の操作
- 地図を利用した特殊なUI
- 高度なグラフ・ダッシュボード
- タブレット専用の現場画面
- 一般消費者向けサービス
などは、スクラッチ開発のほうが設計しやすいケースがあります。
特に、
「社員が1日に何百回も操作する」
ような業務システムでは、画面の操作性が業務効率に直結します。
機能だけでなくUI・UXまで重視するなら、スクラッチ開発を検討する価値があります。
比較9．インフラの運用負荷はkintoneのほうが小さい
スクラッチ開発では、アプリケーション以外についても考える必要があります。
例えば、
- Webサーバー
- データベース
- バックアップ
- セキュリティアップデート
- 障害監視
- ログ管理
- 負荷対策
などです。
クラウドサービスを活用すれば運用負荷を減らすことはできますが、完全になくなるわけではありません。
kintoneの場合、サービス基盤そのものを自社で構築する必要がないため、インフラ運用の負担を抑えやすいのがメリットです。
専任のIT担当者がいない中小企業では、この違いは重要です。
kintoneが向いている企業・業務
ここまでを踏まえると、次のような場合はkintoneが向いています。
- Excelやスプレッドシート管理を卒業したい
- 顧客・案件情報を一元化したい
- 複数人で同じデータを共有したい
- 社内向けの業務アプリが中心
- 登録・検索・更新が主な処理
- 複雑な独自ロジックが少ない
- 早くシステムを導入したい
- サーバー管理をなるべくしたくない
- 現場担当者自身でも改善したい
例えば、
Excelによる案件管理
↓
kintoneへ案件を登録
↓
担当者がステータスを更新
↓
上司が案件一覧を確認
といった業務であれば、kintoneを検討しやすいでしょう。
スクラッチ開発が向いている企業・業務
一方、次のような場合はスクラッチ開発が向いています。
- 自社独自の業務ルールが多い
- 例外処理が多い
- 複雑な権限管理が必要
- 大量データを処理する
- 多数の外部システムと連携する
- 独自UIが重要
- 一般顧客も利用するサービスを作る
- 将来的に大幅な機能追加を予定している
- AIなど独自技術を組み込みたい
- 自社の重要な基幹システムとして利用する
例えば在庫管理でも、
商品を登録
↓
在庫数を記録
程度ならkintoneでも検討できます。
しかし、
発注
↓
入荷予定
↓
入庫
↓
ロット管理
↓
在庫引当
↓
出庫
↓
返品
↓
棚卸
↓
会計システム連携
まで管理する場合は、業務要件を詳しく確認する必要があります。
kintoneからスクラッチ開発へ切り替える目安
すでにkintoneを利用している企業でも、運用を続けるうちに限界を感じることがあります。
次のような状況が増えてきたら、スクラッチ開発を含めた見直しを検討するタイミングです。
カスタマイズが増えすぎている
最初は標準機能だけだったものが、プラグインやJavaScriptカスタマイズ、外部サービス連携だらけになっている状態です。
機能を追加できていても、変更時の影響範囲を把握しにくくなっているなら注意が必要です。
アプリ間のデータ連携が複雑になっている
顧客アプリ、案件アプリ、売上アプリ、請求アプリなどが増え、それぞれの情報を複雑に連携している場合です。
システム全体を一つのデータモデルとして設計したほうが管理しやすくなる可能性があります。
業務をkintoneに合わせ始めている
本来の業務要件ではなく、
「kintoneでできないので、この業務を変更しよう」
という判断が増えている場合も見直しポイントです。
もちろん、不要な業務を標準化するのは悪いことではありません。
しかし競争力につながる独自業務までツール側へ合わせてしまうと、本来の目的から外れる可能性があります。
処理速度やデータ量が課題になっている
データ量やユーザー数が増え、
「検索に時間がかかる」
「集計処理が複雑になった」
「外部連携処理が増えすぎた」
といった問題が発生している場合も、アーキテクチャを見直すタイミングです。
kintoneかスクラッチか迷ったときの判断基準
判断するときは、次の5つを整理すると分かりやすくなります。
1．何を管理するのか
顧客、案件、在庫、予約、申請など、対象となるデータを整理します。
2．どのような業務フローなのか
例えば、
問い合わせ
↓
見積
↓
受注
↓
納品
↓
請求
など、現在の業務を整理します。
3．どのような例外処理があるのか
通常フローだけでなく、
- キャンセル
- 差し戻し
- 修正
- 返品
- 特別価格
- 個別承認
などを確認します。
4．誰が何をできる必要があるのか
管理者・担当者・取引先など、利用者ごとの閲覧・編集範囲を整理します。
5．将来どこまで拡張するのか
現在必要な機能だけではなく、
- 他部署へ展開する
- 会計システムと連携する
- 顧客向け画面を追加する
- AI機能を追加する
- 数百人規模で利用する
など、将来像も確認します。
これらを整理してから開発方法を選ぶことで、「作った後に方式選定をやり直す」リスクを減らせます。
【コピペ用】kintone・スクラッチ開発を判断するヒアリングシート
開発会社などへ相談する場合は、次の内容をまとめておくと話を進めやすくなります。
現在の業務
- 現在使用しているもの：
- Excel・紙・既存システム：
- 利用人数：
- 利用部署：
- 月間のデータ件数：
解決したい課題
- 現在困っていること：
- 手作業になっていること：
- 二重入力している作業：
- ミスが起きやすい作業：
必要な機能
- 管理したい情報：
- 必要な画面：
- 検索条件：
- 承認フロー：
- 帳票：
- CSV入出力：
権限
- 管理者：
- 一般ユーザー：
- 部署別権限：
- 外部ユーザー：
外部連携
- 会計システム：
- 販売管理システム：
- メール：
- Slack・Teams：
- その他：
将来的に追加したいこと
- 利用人数の増加：
- 他部署への展開：
- 外部サービス連携：
- AI活用：
- その他：
すべてを決めておく必要はありません。
分からない項目があっても、現在の業務と困っていることが分かれば、そこから要求を整理できます。
「kintoneかスクラッチか」の二択にしないことも重要
実際のシステム開発では、
「すべてkintone」
または、
「すべてスクラッチ」
にする必要はありません。
例えば、
- 社内の簡単な申請はkintone
- 中核となる業務システムはスクラッチ
- kintoneと独自システムをAPI連携
- 定型作業は業務自動化ツール
- AI処理だけ独自APIとして開発
という構成も考えられます。
システムごとに特性が異なるため、適材適所で使い分ける考え方が重要です。
特に既にkintoneを利用している場合、すべてをスクラッチへ移行する必要があるとは限りません。
「どこまでkintoneに残し、どこから独自開発するか」
という境界を設計する方法もあります。
kintoneとスクラッチ開発に関するよくある質問
kintoneとスクラッチ開発ではどちらが安いですか？
小規模かつ標準的な業務であれば、kintoneのほうが初期費用を抑えやすい傾向があります。
ただし、利用人数、利用期間、追加プラグイン、カスタマイズ、保守などによって総コストは変わります。
数年間利用する場合は、初期費用だけでなくランニングコストを含めて比較しましょう。
kintoneでどこまで業務システムを作れますか？
顧客管理、案件管理、申請管理、問い合わせ管理など、データの登録・検索・更新・共有を中心とする業務は比較的構築しやすい領域です。
一方、複雑な独自ロジック、高度なUI、大量データ処理、特殊な外部システム連携などが増えると、個別に検討する必要があります。
kintoneで作ってからスクラッチへ移行できますか？
可能ですが、単純な移行になるとは限りません。
データを移行できても、kintone上で構築した画面・ワークフロー・カスタマイズなどは、新しいシステム側で再設計が必要になることがあります。
将来的な移行可能性がある場合は、データ構造や連携方法を意識して設計しておくことが重要です。
kintoneをカスタマイズすればスクラッチ開発は不要ですか？
必ずしもそうではありません。
カスタマイズによって対応できる範囲は広がりますが、カスタマイズが増えすぎると保守性が低下する場合があります。
カスタマイズ費用とスクラッチ開発費用の両方を比較して判断することが重要です。
Excelから移行するならkintoneがおすすめですか？
Excelで行っている業務が、データの登録・検索・共有を中心としている場合は有力な選択肢です。
一方、複雑なVBA、特殊な計算、帳票処理などを大量に利用している場合は、そのまま置き換えられるとは限りません。
Excelで何を行っているのかを整理してから判断しましょう。
hiro-dev-labではkintoneかスクラッチかを決める前の要求整理から相談できます
業務システムを検討するときに重要なのは、最初から開発方法を決めることではありません。
まず、
「現在どのように仕事をしているのか」
「何に困っているのか」
「どこまでシステム化したいのか」
を整理することが重要です。
hiro-dev-labでは、Webシステム・業務システム開発の観点から、
- 現在の業務フローのヒアリング
- As-Is（現在の業務）の整理
- To-Be（システム導入後の業務）の整理
- 要求整理
- 要件定義
- 必要機能の整理
- 画面一覧の作成
- データ構造の整理
- プロトタイプ作成
- Webシステム開発
- API・外部システム連携
- AIを活用した業務自動化
など、必要な段階から相談できます。
例えば、
「現在はExcelだが、kintoneで十分なのか知りたい」
「kintoneを使っているが、カスタマイズが増えて管理しにくくなった」
「スクラッチ開発へ移行すべきタイミングが分からない」
といった段階でも、まず現在の業務と今後必要になる機能を整理することで判断しやすくなります。
kintoneとスクラッチ開発は、競合する選択肢というよりも、それぞれ得意分野が異なる開発方法です。
短期間で標準的な業務をシステム化するならkintone、独自業務への適合や長期的な拡張性を重視するならスクラッチ開発。
この基本を押さえたうえで、初期費用だけではなく、運用負荷・将来の機能追加・利用人数まで含めて選択することが、長く使える業務システムにつながります。