はじめに
kintoneを長く使っていると、
いつの間にかこんな状態になります。
- 誰が作ったのか分からないアプリがある
- 何に使っているのか説明できない
- でも消すのは怖い
いわゆる 「野良アプリ」 です。
この記事では、
kintoneがもともと持っている情報を使って
野良アプリを見つけ、管理していく考え方をまとめます。
野良アプリとは何か
まず定義を整理します。
この記事でいう野良アプリとは、
- 作成者が不明、またはすでに退職・削除されている
- 最終更新が古く、誰も触っていない
- 用途や責任者を説明できない
といった 「管理の意思が存在しないアプリ」 です。
重要なのは
「悪いアプリ」ではなく
「管理されていない状態」 である点です。
技術的に確認できるメタ情報
kintoneのアプリには、運用判断に使える
メタ情報がいくつかあります。
- アプリ作成日時
- アプリ作成者
- アプリ更新日時
- アプリ更新者
これらは普段あまり意識されませんが、
棚卸しでは非常に強力な材料になります。
① 作成者が消えているアプリ
まず一番分かりやすいケースです。
- アプリ作成者がアカウント削除済み
- 作成者情報が空、または辿れない
この時点で
管理主体が存在しない可能性が高い。
最優先で棚卸し対象になります。
② 日時・更新情報から「怪しさ」を見る
作成者がまだ存在していても、
管理されているとは限りません。
ここで見るのが以下の組み合わせです。
- 作成日時がかなり古い
- 更新日時が数年単位で止まっている
- 更新者が不明、または一貫性がない
これらが重なると、
「誰も責任を持って触っていない」
状態である可能性が高くなります。
③ それでも残るアプリは「分類」で管理する
上記だけでは判断しきれないアプリも残ります。
そこで有効なのが
アプリを意図的に分類することです。
例としては、
- 業務アプリ
- 検証用
- 一時利用
- 野良アプリ
といった具合です。
重要なのは
「正しい分類」ではなく
判断を保留せず、状態を明示すること。
これにより、
- 一覧で抽出できる
- 定期的な見直し対象にできる
という運用が可能になります。
一覧ではなく「構造」で見ると分かること
ここまでの話は、
一覧で見ても十分に意味があります。
しかし、アプリ同士の関係（参照・連携）を
構造として可視化すると、
もう一段深い気づきが得られます。
- 野良アプリが特定の業務領域に集中している
- あるアプリ群の周辺だけ管理が弱い
- 境界が曖昧なところに野良アプリが溜まる
つまり、
問題のあるアプリ
ではなく
問題が生まれやすい構造
が見えてきます。
まとめ
- 野良アプリは突然生まれるものではない
- メタ情報を組み合わせれば兆候は見える
- 最後は「削除」よりも「管理の意思」を作ることが大事
kintoneのアプリ棚卸しは、
技術というより 運用設計の話です。
完璧なルールを作るより、
あとから意味を持つ余白を残す。
それだけで、
野良アプリは「把握できる存在」になります。