ESSAY2026.05.148 min read

kintone ガバナンス劣化が始まる 3 つのサイン——全社展開 3 年目の経営論点

kintone を全社展開して 3 年目、アプリ数が 200 を超えたあたりで顕在化するガバナンス劣化。経営層が見るべき 3 つの兆候と、内製化と外部支援の判断軸を整理します。

便利すぎて、ガバナンスが追いつかない——kintone を全社展開した中堅企業で、導入から 3 年目あたりに必ず顕在化する現象があります。営業部門経由で入った kintone が部門横断で広がり、誰でもアプリを作れる状態が定着した頃、運用責任者の机に「このアプリ、誰が作ったか分かりますか」という問い合わせが日々積み上がり始めます。

アプリ数 200 を超えたあたりから、運用責任者の負荷は指数関数的に伸び、最終的には「触れる人がいなくなる」状態に至ります。本記事では、私たちが過去 5 年間で関わった kintone 案件 40 件あまりから抽出した、ガバナンス劣化の 3 つの兆候を、経営層の投資判断の論点として整理します。

ガバナンス劣化は技術ではなく組織設計の問題として現れる

kintone のガバナンス劣化は、技術問題ではなく組織設計の問題として現れます。経営層が早期に検知すべき兆候は 3 つです。1 つ目は命名規約の不在によるアプリ検索コストの増大、2 つ目は権限設計の場当たり化による情報漏洩リスクの顕在化、3 つ目は業務スコープの肥大化による「本来 kintone でやるべきでない処理」の混入です。

この 3 つは独立して現れるのではなく、アプリ数の伸びに連動して同時並行で進行します。アプリ数 100 までは現場の創意工夫として歓迎される現象が、200 を超えた瞬間に運用責任者の手に負えない負債に転化します。投資判断としては、200 アプリの壁が見えた時点で、内製ガバナンスチームの組成か外部のリアーキテクト支援のいずれかに踏み切る必要があると整理しています。放置した場合、リプレース費用は当初導入費の 3〜5 倍に膨らむ事例が複数あります。

ガバナンス劣化は「アプリが増えすぎたから」ではなく、「増え方のルールを決めなかったから」起きる。技術の問題ではなく、組織が決めるべきことを決めなかった結果である。

アプリ数 200 が分岐点になる構造的理由

kintone のアプリ数とガバナンス劣化には、明確な相関があります。アプリ数 100 までは部門最適化の恩恵が大きく、現場の創意工夫として機能します。ところが 200 を超えると、依存関係の把握コストが運用責任者 1 名の処理能力を超え、300 を超えると棚卸し自体が事実上不可能になります。

アプリ数

状態

運用責任者の負荷

〜100

部門最適化が機能している段階

把握可能

100〜200

依存関係が複雑化し始める

部分的に俯瞰できる

200〜300

影響範囲が読めなくなる

個人の認知限界を超える

300〜

棚卸し自体が困難

触れる人がいなくなる

これは技術的な制約ではなく、人間の認知限界に起因する現象です。アプリ間の参照関係、ルックアップ、プロセス管理が網の目状に絡み合い、1 つのアプリを変更する際の影響範囲が把握できなくなります。

経営層は「アプリが増えている = DX が進んでいる」と誤読しがちです。月次の経営会議で「kintone のアプリ数が前年比 50% 増」と報告されると、ポジティブな指標として受け取られます。しかし実態は、ガバナンス負債の蓄積である場合が多いと感じています。アプリ数の増加は、健全な拡大なのか負債の累積なのか、別の指標で見極める必要があります。

サイン 1:命名規約の不在とアプリ検索コストの増大

最初の兆候は、アプリ名から用途が判別できなくなることです。「営業管理_v2」「営業管理_新」「営業管理_最新版」「営業管理_2024」のような命名が並び始めたら、ガバナンス劣化の入り口にいると見て間違いないでしょう。

命名規約の不在は単なる見た目の問題ではありません。新任担当者が既存アプリを検索しても用途が分からず、結局「同じようなものを新規作成する」という選択に流れます。結果として 重複アプリが量産され、データの分散と整合性の崩壊 につながります。同じ顧客マスタが 5 か所に存在し、どれが最新か誰も分からないという状態は、棚卸し現場で頻繁に遭遇します。

打ち手としては、3 階層の命名規約を最初に決めることが基本です。

  • 部門コード(例:SAL HR ACC
  • 業務カテゴリ(例:案件管理 経費精算
  • バージョンまたは年度(例:v2 2026

これに加えて、廃止アプリのアーカイブ運用 を必ず設計します。アプリ一覧から消すのではなく、Z_archive_ プレフィックスを付けて視覚的に分離する運用が現実的です。完全削除は監査証跡の観点でリスクがあるため、論理削除に倒すケースが多いです。

サイン 2:権限設計の場当たり化と情報漏洩リスク

2 つ目の兆候は、権限設定が「とりあえず全員に閲覧権限」になっている状態です。導入初期は試行錯誤のために広い権限が設定されますが、人事異動や組織改編を経るたびに権限の見直しが追いつきません。

最も危険なのは、退職者の権限が残ったまま放置されるケース です。退職処理が情シスに連携されず、退職後数ヶ月にわたって元従業員のアカウントが有効なままだった事例は、現場で何度も見てきました。さらに、本来見えてはいけない人事情報や経営指標が、別部門から閲覧可能になっているケースもあります。

これは情報セキュリティ監査で指摘される典型パターンであり、経営層にとっては投資判断以前のリスク管理の論点 となります。一度監査指摘を受けると、その後の対応コストはガバナンス整備を先にやっていた場合の数倍に膨らみます。

最低ラインとして 2 つの仕組みを推奨しています。1 つは役職ベースの権限テンプレート化で、個別ユーザーに権限を直接付与せず、必ずグループ経由にする運用です。もう 1 つは半期に 1 回の権限棚卸しサイクルで、人事マスタとの突合を必ず行います。この 2 つを回せていない組織では、退職者アクセスのリスクが常時存在していると考えてよいと思います。

サイン 3:業務スコープの肥大化と「やるべきでない処理」の混入

3 つ目の兆候は、本来 kintone で扱うべきでない業務が乗り始めることです。会計の補助計算、勤怠の二重管理、顧客への自動メール送信、契約書の保管などが「便利だから」という理由で実装され、基幹システムや SFA の代替として機能し始めます

一見すると効率化に見えますが、複数の問題を引き起こします。

問題領域

具体例

監査証跡

会計補助計算の根拠が kintone に分散し、決算監査で説明できない

法令対応

電子帳簿保存法・インボイス対応が基幹側と二重管理になる

データ不整合

顧客情報が SFA と kintone で乖離し、営業現場が混乱する

属人化

カスタマイズした担当者が異動した後、誰も触れない

経営層が見るべき問いは「kintone で何を実装しているか」ではなく、「kintone で実装すべきでないものが何件あるか」 だと整理しています。前者はポジティブな指標として誤読されますが、後者はリスクの可視化になります。

打ち手としては、スコープ定義のリセットが必要です。具体的には、業務カテゴリごとに「kintone で完結してよい」「基幹に巻き戻す」「SaaS に切り出す」の 3 分類を行い、巻き戻しのロードマップを引きます。一度に全部やる必要はなく、リスクの高いものから順に基幹システムへ戻していく判断が現実的です。

内製化と外部支援の判断軸

3 つのサインが揃った段階で、経営層が選ぶ打ち手は大きく 2 つに収斂します。内製ガバナンスチームの組成か、外部によるリアーキテクト支援か。判断軸は次の 3 点だと考えています。

  1. 社内に kintone 設計を俯瞰できる人材がいるか
  2. 業務部門と情シスの政治的距離
  3. 投資回収の時間軸

内製は中長期的には強い選択肢ですが、立ち上げに 1 年以上かかり、その間にガバナンス負債は積み上がり続けます。一方、外部支援は 3〜6 ヶ月で棚卸しと再設計が進みますが、引き継ぎ設計を最初から組み込まないと外部依存が残り、契約終了後にまた同じ状態に戻ります。

私たちは中立の立場から、両者の組み合わせを推奨する場面が多いです。具体的には、最初の 3〜6 ヶ月で外部が棚卸しと再設計の型を作り、並行して社内のガバナンス担当者を 1〜2 名選任して伴走する形です。型ができた後は内製チームに移管し、外部は四半期に 1 度のレビューに役割を変えます。この移行設計を最初から契約スコープに入れておくことが、依存を残さないための最低条件だと感じています。

ある専門商社で 280 アプリを 110 に圧縮した事例

ある専門商社の事例を匿名で紹介します。従業員 500 名規模、kintone 導入から 4 年、アプリ数は 280 まで膨れ上がっていました。導入当初は営業部門の案件管理として始まりましたが、3 年目には経理、人事、総務、品質管理と全社に広がり、情シス 2 名では運用が回らない状態でした。

顕在化したきっかけは、退職者のアカウントが半年間放置され、その間に元従業員が外部から閲覧可能だった ことが判明した監査指摘でした。経営会議で初めて kintone がリスク要因として議題に上がり、私たちに棚卸しと再設計の相談が来ました。

6 ヶ月かけて 280 アプリを棚卸しした結果、内訳は次のようになりました。

分類

件数

機能が重複するアプリ

90 件

半年以上利用実績のないアプリ

60 件

本来基幹システムで処理すべき業務

30 件

継続利用するアプリ

100 件

最終的にアプリ数を 110 まで圧縮 し、命名規約と権限テンプレートを再設計、業務スコープの線引きを明文化しました。運用責任者の月間工数は 40% 削減、新規アプリ申請のリードタイムは 2 週間から 3 日に短縮されました。

この案件で印象的だったのは、現場が「使いにくくなった」と反発しなかった点です。アプリ数が増え続けることへの疲弊は現場が一番感じており、整理されることへの歓迎の声が経営層の予想を上回りました。ガバナンス整備は現場の敵ではなく、むしろ現場が待っている施策 だったというのが、終わってみての気づきでした。

200 アプリの壁が見え始めた組織への相談窓口

kintone の全社展開が 3 年目を迎え、アプリ数が 200 に近づいてきた——その兆候が見え始めたタイミングが、ガバナンス整備に踏み切る最後のチャンスだと考えています。300 を超えてからの対応はリプレース費用が膨れ上がり、現場の疲弊も限界に達します。

私たちは、kintone の棚卸し・再設計から内製ガバナンスチームへの引き継ぎ設計までを、3〜6 ヶ月のスコープで支援しています。中立の立場から、内製化と外部支援の最適な組み合わせを提案できる点が、私たちの関わり方の特徴です。

200 アプリの壁が見えてきた経営層・情シス責任者の方は、営業強化コンサルティング のページから棚卸しの初期診断についてご相談ください。

関連記事:

論点があれば、
議論から始めましょう

書いていることに反論・疑問・取材依頼があれば、お気軽にお寄せください。