kintone カスタマイズで失敗する組織に共通する 7 つの落とし穴

便利すぎて、ガバナンスが追いつかない——kintone を全社展開した組織で、3 年目あたりに必ず顕在化する現象があります。アプリ数が 200 を超えたあたりから運用責任者の負荷が指数関数的に伸び始め、最終的には「誰も触れない」状態に至るケースを、私たちはこれまで何度も見てきました。

失敗の原因を後から振り返ると、技術的な難しさではなく、組織が決めるべきルールを決めないまま 3 年走ってしまった点に行き着きます。本記事では、kintone カスタマイズで失敗する組織に共通する 7 つのパターンを、現場で見てきた具体例とともに整理してみます。導入前、もしくは展開初期に「これだけは決めておいたほうがよい」項目として読んでいただければと思います。

結論：失敗は技術ではなく組織設計に起因する

kintone カスタマイズで失敗する組織には、技術的な要因ではなく組織設計の要因があると私たちは見ています。具体的には、(1) 命名規約の不在、(2) 権限設計の場当たり化、(3) 業務スコープの肥大化、という 3 つの問題が連鎖して破綻に至るケースが多い印象です。

この 3 つに、後段で触れる「ライセンス費の暴走」「JavaScript カスタマイズの属人化」「マスタデータの重複」「廃止プロセスの不在」を加えた 7 項目が、私たちが現場で繰り返し見てきた失敗の共通点です。逆に言えば、この 7 項目を導入前または展開初期に決め切れた組織は、アプリ数が 500 を超えても運用が回ります。

失敗の原因は技術ではなく、組織が決めるべきルールを決めないまま 3 年走ってしまった点にある。

失敗の起点は「命名規約の不在」と「権限設計の場当たり化」

最も早く効いてくるのが命名規約の不在です。アプリ名・フィールド名の付け方を決めないまま部署ごとに自由に作らせると、3 年後にはアプリ一覧から目的のアプリが探せなくなります。「営業管理」「営業案件管理」「営業案件管理_新」「【新】営業管理_2023」のような名前が並び、どれが現役なのか作成者本人にしか分からない状態に至ります。フィールド名も同様で、同じ「顧客名」が「会社名」「取引先」「Client」と揺れていれば、後からアプリ間連携やデータ抽出をしようとした時に必ず詰まります。

対策としては、導入時に 部署プレフィックス + 業務名 + バージョン のような命名規約を決め、アプリ作成時にチェックする運用にするのが定石です。kintone のスペース機能を部署別フォルダとして使い、アプリの所属を明示する運用も有効です。

次に効いてくるのが権限設計の場当たり化です。「この人にもアクセス権を」という申請を都度承認していくと、退職者のアカウントに紐づいたアプリが残り続け、誰が何にアクセスできるかを誰も把握できない状態になります。私たちが棚卸しに入った組織では、退職済み社員のアカウントで動いている JavaScript カスタマイズが見つかったこともありました。

権限はロールベースで設計し、最低でも年 1 回の棚卸しを業務側責任者と一緒に実施する運用が必要です。情シスだけで判断せず、業務側の部門長に「このメンバーは今もこのアプリを使うか」を判定してもらう構造を作ります。

業務スコープの肥大化が招く「全社基幹システム化」の罠

kintone は小さく始められることが強みですが、その裏返しとしてユーザー側で次々と業務を載せていき、気付くと全社基幹システムになっている現象が頻発します。最初は問い合わせ管理だけだったはずが、営業案件管理、見積管理、受注管理、在庫管理、人事評価まで載せていき、3 年経つと「kintone が止まると会社が止まる」状態に至ります。

ここで起きるのは、まずパフォーマンス劣化です。レコード数が数十万件を超えるアプリでルックアップを多用すると、画面表示が数秒〜十数秒かかるようになります。次に整合性破綻です。本来 ERP や専用 SaaS が担保しているトランザクション制御・在庫引当・会計連携といった仕組みが kintone にはないため、二重登録や差異が発生し、業務が回らなくなります。

私たちが整理した「載せてよい業務」と「載せてはいけない業務」の線引き基準は、以下の 3 つです。

この 3 つに 1 つでも該当する業務は、kintone ではなく専用 SaaS や受託開発で組むべきです。導入時に「kintone に載せる業務の上限」を経営層と合意しておかないと、3 年後に剥がすコストが導入時の数倍になります。この論点は 生成 AI の業務実装で、最初に必ず躓く 3 つの設計判断 でも触れた「適用領域の線引き」と同じ構造です。

ライセンス費の暴走と JavaScript カスタマイズの属人化

3 年目に経営から指摘が入る論点がライセンス費の暴走です。スタンダードコース × ユーザー数の単純掛け算で、初期見積もりの 3 倍近くまで膨らんでいるケースが多くあります。原因は単純で、退職者のアカウントが残っている、月数回しかログインしないユーザーにフルライセンスを割り当てている、ゲストスペースの使い方が整理されていない、といった積み重ねです。

対策は地味ですが、ライセンス棚卸しを四半期に 1 回実施し、ログイン頻度ベースでライセンス種別を見直すことです。年に 1 回の予算編成タイミングでは遅すぎます。

並行して効いてくるのが JavaScript カスタマイズの属人化です。1 人の情シス担当が独自に書いた JavaScript が数十個のアプリに散らばっており、その担当者が退職した瞬間に全カスタマイズがブラックボックス化する、という事故を私たちは何度も見てきました。コードは kintone 管理画面に直接貼られており、Git にも上がっていない、コメントもない、という状態です。

優先度を付けて整理すると、以下の順で着手するのが現実的です。

1. カスタマイズ管理台帳の作成：どのアプリに何の JavaScript が動いているか、用途と作成者を一覧化する
2. コードリポジトリ管理への移行：Git 管理に移し、kintone-cli または kintone-customize-uploader でデプロイする運用にする
3. 属人化の解消：少なくとも 2 名がレビュー可能な体制にする

JavaScript カスタマイズの事故防止については、kintone カスタマイズ事故を防ぐ 3 つの構造的対策と JS 重複の盲点 でより踏み込んだ議論をしていますので、合わせて参照いただければと思います。

マスタデータの重複と「廃止プロセスの不在」

最後の 2 項目は、運用の長期化と共に静かに効いてきます。

マスタデータの重複は、顧客マスタ・商品マスタが複数アプリに散在し、同じ顧客の表記揺れが 5 通り発生するような現象です。営業部のアプリでは「株式会社○○」、サポート部のアプリでは「○○（株）」、経理のアプリでは「○○ Co., Ltd.」と登録されており、後から名寄せをしようとしても突合できません。ルックアップで参照元を 1 つに絞るルール、つまり「顧客マスタはこのアプリだけ。他は全てここを参照する」という設計を最初に決めておかないと、後から直すコストは膨大になります。

廃止プロセスの不在は、使われなくなったアプリを廃止する手順がないために、稼働アプリと死蔵アプリの区別がつかなくなる現象です。アプリを作るルールはあっても、消すルールがない組織が大半です。結果として、3 年経つとアプリ一覧の半分以上が「動いているのか分からない」状態になります。

対策は、年次棚卸し + 廃止フローのテンプレート化です。年 1 回、全アプリに対して「過去 6 ヶ月のレコード追加・更新がゼロ」「作成者が在籍していない」「業務側責任者が不明」のいずれかに該当するアプリをリストアップし、業務側部門長が「継続」「アーカイブ」「削除」を判定する運用を入れます。情シスが勝手に消すのではなく、業務側の意思決定として処理することが重要です。この点は kintone ガバナンス劣化が始まる 3 つのサイン でも詳しく扱っています。

ある製造業 800 名規模での 320 アプリ棚卸し

ある製造業 B 社（従業員 800 名規模）では、2019 年に kintone を導入し、3 年で 320 アプリまで展開しました。導入当初の運用責任者は情シス部門の 2 名でしたが、3 年目には申請対応・障害対応で月 80 時間を超え、本来業務が回らない状態に陥りました。

私たちが入って棚卸しを行ったところ、320 アプリのうち実稼働は 140 アプリ、残り 180 アプリは半年以上更新がないか、作成者が既に退職している状態でした。命名規約がなかったため、似た名前のアプリが 7 つ並び、どれが正なのか誰も判断できない領域もありました。

6 ヶ月かけて 7 項目のガバナンスルールを整備し、アプリを 140 に集約、ライセンスも 30% 削減しました。重要だったのは、技術的な作業ではなく「廃止判断の責任者を部門長に置く」という組織設計の変更です。情シスは判定基準を提示するだけで、廃止の意思決定は業務側に戻しました。結果として、運用責任者の負荷は月 80 時間から 20 時間に下がり、新規アプリの品質も安定しました。

このケースから得られる示唆は、kintone のガバナンスは情シス単独では成立しないということです。業務側に意思決定権を持たせる構造を作らないかぎり、3 年後に同じ状態に戻ります。

kintone 環境の棚卸しとガバナンス再設計のご相談

すでに kintone を全社展開していて、アプリ数が 100 を超えてきた組織では、本記事の 7 項目に 1 つでも当てはまる兆候があれば、3 年以内に運用責任者の負荷が破綻する可能性が高いと考えています。導入済み環境の現状棚卸しから、命名規約・権限設計・廃止フローを含むガバナンス再設計まで、私たちは システム受託開発 サービスの一環としてご支援しています。

新規展開時のルール整備、JavaScript カスタマイズのリポジトリ管理移行、ライセンス棚卸しの仕組み化など、組織の現在地に応じて入り口を変えられます。論点を持ち寄っての議論からでも歓迎します。

関連記事：

• kintone カスタマイズ事故を防ぐ 3 つの構造的対策と JS 重複の盲点
• kintone ガバナンス劣化が始まる 3 つのサイン——全社展開 3 年目の経営論点 関連サービス：
• システム受託開発