「kintoneを導入したのに、承認フローの分岐や外部システムとの連携ができず、結局Excelに戻ってしまった」——kintoneを使いこなせていない現場では、よく聞く話です。標準機能で対応しきれない要望が出てきたとき、選択肢は大きく「JavaScriptカスタマイズを外注する」「プラグインを導入する」の2つですが、サイボウズもkintone公式サイトも費用相場を公開していません。とはいえ、判断基準がまったく無いわけではありません。金額そのものより「何を確認すれば見積もりが妥当と判断できるか」を知ることが近道です。この記事では、費用感を考えるための3段階の目安、見積書に出てこない隠れたコスト、外注につきまとう3つのリスクと回避策、発注前に準備すべき要件、失敗しない依頼先の選び方、発注後の保守体制までを順番に整理し、実際に見積もり依頼に進める状態を目指します。
kintoneの標準機能で対応できないこと——カスタマイズが必要になる典型パターン
kintoneには、レコード登録・添付ファイル・計算式といったデータベース機能に加え、コメント、プロセス管理、グラフ集計、キーワード検索、絞り込み一覧、アクセス権制御、通知、変更履歴、ルックアップ・関連レコード、ポータルやスペースといった機能が標準で搭載されています。多くの業務は、この標準機能の組み合わせだけで運用できます。
一方で、次のような要望は標準機能だけでは実現できず、カスタマイズやプラグインが必要になる典型パターンです。
- 承認フローを条件によって分岐させたい(部署や金額によって承認者を変えるなど、プロセス管理の設定だけでは表現しきれない分岐)
- 入力内容に応じて画面の表示・入力項目を動的に切り替えたい
- 独自のレイアウトでレコード一覧や詳細画面を表示したい
- 外部システム(会計ソフト・在庫管理システムなど)とkintoneのデータを連携させたい
サイボウズの公式ページでも、パッケージ製品が存在しない自社独自の要件に対応する手段として「カスタマイズ(JavaScript/CSSによるオーダーメイド開発)」と「プラグイン・連携サービス(複数のカスタマイズを1つの追加プログラムとしてまとめたもの・カスタマイズの知識は不要)」を分けて説明しています。プラグインストアには400種類以上のサービスが公開されており、帳票出力や営業・顧客管理、経費精算など幅広いカテゴリをカバーしています。まず既存のプラグインで要望が満たせないかを確認し、それでも満たせない独自要件だけをカスタマイズとして絞り込むのが、外注コストを抑える最初の一歩です。
社内にJavaScriptを書ける人材がいない場合、この絞り込みまでは自社でできても、実装そのものは外注が現実的な選択肢になります。
上の画面は、アプリの設定からJavaScript/CSSを追加適用する箇所です。外注先が作成したコードは、この画面を通じてアプリに組み込まれます。
カスタマイズ外注の費用相場と「隠れたコスト」——規模別の考え方
サイボウズやkintone公式サイトは、カスタマイズ外注の費用相場を公開していません。ネット上で見かける「◯万円〜」という数字は、各開発会社が自社の見積もり実績を紹介しているものであり、公式な統計ではないため、本記事では断定的な金額はお示ししません。金額は要件の複雑さによって大きく変わるため、以下の3段階で自社の要望がどの規模に近いかを整理しておくと、見積もり依頼がスムーズになります。
| 規模イメージ | 典型的な要望 | 見積もり時に確認したいこと |
|---|---|---|
| 小規模 | 入力補助・表示条件の分岐・簡易な計算表示 | 既存プラグインで代替できないか |
| 中規模 | 承認フローの分岐・複数アプリを跨いだ集計・独自レポート表示 | 開発範囲とテスト工数の切り分け方 |
| 大規模 | 外部システムとのAPI連携・大量データの処理 | kintone.proxy経由の技術的制約、利用コースのAPIリクエスト上限 |
大規模な連携を検討している場合は、REST APIの日次リクエスト上限(1アプリごとにスタンダードコースで10,000件、ワイドコースで100,000件)が設計の前提になります。また外部APIへの通信はkintone.proxy()という専用の関数を経由する必要があり、Cookieの自動送信不可・画像などのバイナリデータの取得不可・レスポンス上限10MBといった制約があるため、想定する連携がこの制約内で実現できるかを外注先に確認しておくべきです。
見積書の「開発費」だけを見て安さを比較すると、後から追加費用が発生することがあります。典型的なのは次のような工数です。
- 要件を固めるための打ち合わせ・要求整理の工数
- 完成後の動作確認(検収)にかかる工数
- 依頼した後に「これも欲しい」と要望が増えた分の追加開発
これらは開発費の内訳に含まれていない場合があるため、見積もり依頼の段階で「打ち合わせや検収は見積もりに含まれているか」を確認しておくことが、想定外の費用を防ぐ最初の一歩です。
外注につきまとう3つのリスクと回避策
カスタマイズ外注では、費用面以外にも次の3つのリスクに注意が必要です。
- 想定外の追加費用: 要件を大まかに伝えたまま発注すると、実装が進む中で「この分岐も必要だった」と要望が膨らみ、追加費用が発生しやすくなります。回避策は、実現したい動作を書面で具体的に整理し、後から追加する要望は別見積もりとする合意を発注前に取っておくことです。
- 認識のズレによる手戻り: 発注側は業務の言葉で要望を伝え、開発側は技術の言葉で実装します。この翻訳がずれると、完成物が「動くが業務に合わない」ものになりやすくなります。回避策は、画面イメージや操作手順を具体的に共有し、開発の途中で一度動作を確認するタイミングを設けることです。
- 外注依存: プラグイン開発では、更新のたびに同じ秘密鍵ファイル(.ppk)を使う運用になっているため、依頼先を変更しようとしたときに、この鍵を引き継げるかどうかが実務上の論点になります。回避策は、秘密鍵やソースコードの引き継ぎ条件を契約時に明記しておくことです。
外注前に準備しておくべき要件——現状整理からRFP・相見積もりまで
見積もりを依頼する前に、次の3点を整理しておくと、外注先とのやり取りがスムーズになります。
- 現状のアプリ構成の整理: 対象アプリのフィールド一覧、現在のプロセス管理の設定、すでに使っている連携サービスやプラグインを一覧にします。
- 実現したい動作を業務の言葉で書く: 「承認が2段階になる場合と3段階になる場合を分けたい」のように、技術用語ではなく業務の言葉で具体的に書きます。
- 優先順位をつける: 「必須」と「あれば良い」を分けておくと、見積もりが予算を超えた場合に削る部分を判断しやすくなります。
整理した内容は、依頼内容をまとめた提案依頼書(RFP)として1〜数ページにまとめ、複数の開発会社に同じ内容で見積もりを依頼します。同一の要件で相見積もりを取ることが、公式な相場が存在しない中で実質的に「妥当な金額かどうか」を確認する方法になります。
なお、kintoneには開発目的専用の「開発者ライセンス」があり、申込から12か月間無料で利用できます(ユーザー数5人・容量25GB固定、本番運用は不可)。本番環境に手を入れる前に、この開発者ライセンスの環境で動作確認をお願いできるか、外注先に相談してみるのも一つの方法です。
ここでつまずいたら、無料相談で画面を見ながら一緒に確認できます。
失敗しない依頼先の選び方——認定パートナーと受託開発会社、どちらが向くか
kintoneのカスタマイズを依頼できる先は、大きく「サイボウズの認定パートナー」と「一般の受託開発会社(SES=技術者を契約ベースで確保する形態の会社を含む)」に分かれます。
サイボウズには「Cybozu Partner Network」という認定制度があり、実績2件以上や資格要件などの条件を満たした企業が「オフィシャルパートナー」として認定されます。認定後は詳細な技術情報や研修、マーケティング支援などを受けられますが、継続には年会費(税抜10万円)や活動報告の提出が必要です。この認定維持コストが個々の見積もり価格にどう反映されるかは会社ごとの経営判断によるため、認定の有無だけで価格の高低を判断することはできません。
認定パートナーであることは、kintoneの技術力が一定の基準を満たしている外形的な証明になります。ただし、認定が証明するのは技術力であって、発注側の業務(承認・請求・原価管理など)への理解までは保証しません。技術的には正しく動くのに現場の運用に合わず使われなくなる、という失敗はこのギャップから生まれやすくなります。
依頼先を比較するときは、次の観点で確認すると判断しやすくなります。
- 実績: 自社と近い業種・規模での構築実績があるか
- 提案力: 業務の要望を技術要件にどう翻訳して提案してくるか
- 保守運用体制: 発注後の保守契約に何が含まれるか(次章で詳しく整理します)
発注後を見据える——保守契約とkintoneバージョンアップへの追随
カスタマイズは「作って終わり」ではありません。実は、kintone導入が失敗する原因の多くは、このような発注後の体制準備不足から生まれます。kintone側の仕様変更に追随できる体制を、発注前に確認しておく必要があります。
例えば、プラグインやカスタマイズの開発に使うコマンドラインツールは、複数の個別ツールから統合ツール(cli-kintone)への移行が進められており、旧ツールのメンテナンスは終了予定と案内されています。このように、開発・運用に使う仕組み自体が時間とともに変わることがあるため、「作った後、誰が追随してくれるのか」を契約時に確認しておくことが大切です。
保守契約を結ぶ際は、次の3点がどこまで含まれるかを確認します。
- 不具合対応: 動作不良が起きたときの対応範囲と応答目安
- バージョンアップ時の影響確認: kintone側の仕様変更でカスタマイズが動かなくなった場合の対応
- 軽微な修正: 表示文言の変更など、小さな修正が保守契約の範囲に含まれるか、都度見積もりになるか
pullieのカスタマイズ外注支援——標準機能で足りない部分の補い方
私たちは認定パートナーではありません。その代わりに大切にしているのが、業務の言葉のまま要望を聞き取り、kintoneの仕組みに翻訳しながら、現場と直接やり取りをして小さく作り、定着まで伴走するという進め方です。認定という外形の証明の代わりに、無料相談の場で実際の構築物や進め方をお見せすることを、確認していただく手段にしています。
標準機能とカスタマイズの間には、プラグイン導入という選択肢もあります。例えば、自社で開発した「フィールド棚卸し」というプラグインは、アプリ内のフィールドが実際に使われているかどうかを一覧で可視化します。JavaScriptカスタマイズをゼロから外注する前に、こうした既存プラグインで要望の一部が満たせないかを確認する価値はあります。
大規模で多拠点の組織体制を重視するなら、組織力のあるパートナー企業や大手SIerが向く場面もあります。一方、現場への定着を最優先に小さく始めたい場合は、依頼先が自社の業務をどこまで理解してくれるかを、選定基準の一つに加えてみてください。
まとめ
kintoneカスタマイズの外注費用に公式な相場は存在しないため、まずは自社の要望を小規模・中規模・大規模のどれに近いか整理し、見積書に「打ち合わせ」「検収」「追加開発」の工数が含まれているかを確認することが、妥当性を判断する実質的な方法になります。想定外の追加費用・認識のズレ・外注依存という3つのリスクには、それぞれ書面化・画面イメージの共有・引き継ぎ条件の明記という回避策があります。発注前には現状整理とRFP作成、相見積もりまで進め、依頼先は認定の有無だけでなく実績・提案力・保守運用体制で比較し、発注後の保守契約でバージョンアップへの追随体制まで確認しておけば、見積もり依頼に進める状態が整います。
