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

「kintoneにJavaScriptカスタマイズを入れたら、アップデートのたびに動かなくなる」「開発会社に頼んだら想定の3倍の費用がかかった」——アクロネットにはこうした相談が絶えません。
Kintoneはノーコードで手軽に使えるイメージがありますが、カスタマイズ開発には独特の落とし穴があります。本記事では、現場で実際に見てきた失敗パターンと、それを防ぐための対策を解説します。

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

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

Kintoneは頻繁にアップデートされており、以前はカスタマイズが必要だった機能が標準機能に追加されているケースが多々あります。古い情報や経験則で「これはカスタマイズが必要」と判断してしまい、開発費用を余分に使ってしまうのは典型的な失敗パターンです。
特にフォームの条件分岐、計算フィールド、スペース間のデータ参照といった機能は、ここ数年で標準機能が充実しています。開発会社に依頼する前に、必ず最新のkintone機能一覧を確認する習慣をつけましょう。

対策

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

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

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

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

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

対策

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

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

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

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