「kintoneにJavaScriptカスタマイズを入れたら、アップデートのたびに動かなくなる」「開発会社に頼んだら想定の3倍の費用がかかった」——アクロネットにはこうした相談が絶えません。

kintoneはノーコードで手軽に使えるイメージがありますが、カスタマイズ開発には独特の落とし穴があります。本記事では、現場で実際に見てきた失敗パターンと、それを防ぐための対策を解説します。

なぜkintoneカスタマイズは失敗しやすいのか

kintoneの標準機能は非常によくできており、フォーム・集計・通知・ワークフローの多くは追加開発なしに実現できます。問題は「もう少し便利にしたい」という要望が積み重なり、気づけばJavaScriptカスタマイズが複雑に絡み合った状態になることです。

アクロネットがこれまで支援した案件の中でも、「前の開発会社が作ったカスタマイズが複雑すぎて誰も触れない」「kintoneのバージョンアップで動かなくなった」というリカバリー依頼は少なくありません。

標準機能で対応できる範囲を見誤る

よくある失敗パターン：「これはカスタマイズが必要」と思い込んで標準機能を使わない

kintoneは頻繁にアップデートされており、以前はカスタマイズが必要だった機能が標準機能に追加されているケースが多々あります。古い情報や経験則で「これはカスタマイズが必要」と判断してしまい、開発費用を余分に使ってしまうのは典型的な失敗パターンです。

特にフォームの条件分岐、計算フィールド、スペース間のデータ参照といった機能は、ここ数年で標準機能が充実しています。開発会社に依頼する前に、必ず最新のkintone機能一覧を確認する習慣をつけましょう。

対策

• 依頼前に公式のkintoneヘルプ・機能一覧を最新版で確認する
• 「標準機能で何ができるか」をベンダーに先に検証してもらうステップを必ず入れる
• 標準機能で70〜80%を実現し、残り20〜30%にだけカスタマイズを使う方針を原則にする

JavaScriptカスタマイズの保守コストを甘く見る

よくある失敗パターン：一度作ったJSカスタマイズが負債化し、誰も触れなくなる

JavaScriptカスタマイズは強力ですが、kintone本体のアップデートに追従するメンテナンスが永続的に発生します。特にkintoneのUIが変わったり、APIの仕様が更新されたりした場合、カスタマイズコードの修正が必要になります。

アクロネットが引き受けたリカバリー案件の多くは、初期開発時の担当者が退職・離任してドキュメントもなく、誰もコードを読み解けない状態でした。「動いているから触らない」という運用が続き、kintone本体のアップデートで突然壊れたというケースが最多です。

対策

• 開発依頼時に「ソースコードの納品・コメント記載」を契約に明記する
• kintoneのアップデート追従保守をセットで契約できる会社を選ぶ
• カスタマイズの複雑度をできる限り下げ、1ファイルに詰め込まず機能ごとに分割する
• 開発後に社内担当者がコードの概要を理解できるレベルの説明を受ける

要件定義なしに「なんとなく便利に」依頼する

よくある失敗パターン：要件が曖昧なまま開発がスタートし、手戻りが多発する

「今の業務フローをもう少し便利にしてほしい」という依頼は、開発会社からすると要件が何も決まっていない状態です。開発会社が独自の解釈で進めた結果、納品物が「思っていたものと違う」となり、追加開発費用が発生するのがよくあるパターンです。

依頼前に決めておくべき最低限の事項

プラグインの乱用・依存

よくある失敗パターン：プラグインを重ねすぎて動作が不安定になる

kintoneには公式・サードパーティ合わせて多数のプラグインが存在します。「このプラグインを入れれば解決する」という手軽さから複数導入した結果、プラグイン同士が干渉して動作が不安定になるケースがあります。

特に問題になるのが、開発・提供元が小規模なサードパーティプラグインのサポート終了です。突然メンテナンスが止まり、kintone本体のアップデートに追従されなくなる事例がありました。

対策

• プラグインは「これがないと業務が成立しない」ものだけに絞る
• 導入前に提供元の会社規模・更新頻度・サポート体制を確認する
• 同じ機能を複数のプラグインで重複導入しない
• プラグインの一覧・バージョン・用途をドキュメント化して管理する

運用・権限設計を後回しにする

よくある失敗パターン：「とりあえず動かしてから決める」で情報管理が崩壊する

kintoneはアプリを素早く作れる分、「まず使い始めてから細かい設定は後で」という運用になりがちです。その結果、全員が全データを閲覧・編集できる状態が続いたり、データ入力ルールが定まらずバラバラな形式のデータが蓄積されたりします。

特に、スペース・アプリの権限設定は後から変更すると既存のワークフローに影響が出るため、構築段階から設計しておく必要があります。

対策

• アプリ公開前に「誰が閲覧・誰が編集・誰が削除できるか」を役職・部署単位で設計する
• 必須項目・入力形式・ステータス定義を文書化したルール表を整備する
• アプリ管理者（IT担当者以外に業務担当者も含む）を明確にする
• 四半期に1回は権限設定・不要データの棚卸しを実施するサイクルをつくる

まとめ

kintoneカスタマイズの失敗の多くは「技術的な問題」ではなく、プロセスと設計の問題です。アクロネットでは要件定義から開発・保守まで一貫して対応しており、既存カスタマイズのリカバリー支援も行っています。現状に不安を感じている場合は、まずお気軽にご相談ください。