kintoneのフィールドを削除する前に確認すること｜計算式・ルックアップ・連携への影響

kintoneの使っていないように見えるフィールドを削除する前に、画面の表示だけでなく、計算式・別アプリの参照・プラグイン・外部連携で使っていないかを確認しましょう。フォーム上では目立たなくても、帳票や連携のキーになっている場合があります。

この記事では、項目整理の前に残す情報と、変更後の確認範囲を整理します。アプリ情報出力とER図作成は調査の補助として使い、自動で影響をすべて検出する機能として扱わないことが大切です。

項目1つの削除前確認票を作る

例として、文字列フィールド「旧顧客コード」（説明用コード：old_customer_code）を廃止したい場合を考えます。次の表は確認先の一覧であり、ツールを実行すれば全行が自動的に確認済みになるものではありません。

確認状態は「未確認」「要修正」「確認済み」に分け、確認日・確認者・証跡の保存先を添えます。アプリ情報出力は設定の資料、ER図は参照関係の確認を補助しますが、外部システムや独自コードの利用箇所まで自動で網羅するとは限りません。

項目を画面で目立たせたくないだけなら、配置やグループ、表示の整理で対応できる場合があります。フィールドを削除すると、その項目に登録されたデータも削除されます。公式のフィールド数の見直しに関する注意点も確認してください。

また、フィールド名の変更と、フィールドコードの変更は別です。名前は利用者向けの表示、コードは計算・カスタマイズ・帳票などが参照する識別子です。「名前を変えるつもりでコードを変えた」という作業にならないよう、変更する対象を明確にします。

アプリ情報出力プラグインで、フィールド名・コード・種類・計算式・参照先・権限設定などをExcelにまとめられます。変更前の確認資料として、取得日と対象アプリを付けて保管します。

ただし、設定一覧の出力は、レコードの実データを含むバックアップや復元機能ではありません。必要なレコードデータの退避は別に行います。出力できなかった設定の案内も確認し、空欄だから未使用と判断しないでください。

ER図作成プラグインはアプリ間の関係を確認する補助になります。参照先への権限や取得範囲があるため、図に出ないものが存在しないとは限りません。業務担当者にも、どのアプリから値を使っているかを確認します。

標準設定の一覧だけでは、JavaScriptのソース、帳票テンプレート、外部サービスのマッピングをすべて把握できません。使用中のプラグイン設定と、連携を管理する資料を確認します。

例えばExcel帳票の差し込み記号、検索対象の項目、条件付き入力制御の対象、マスタ更新の照合キーなどです。外部連携では、受信側・送信側のどちらがコードを指定しているかも確認してください。

「フォームから見えない」と「誰も使っていない」は別です。データの持ち主、入力者、参照者、連携の管理者を決めてから変更を判断します。

重要な変更は検証用の構成で試し、新規追加・既存編集・検索・帳票・申請・外部連携など、関係する操作を確認します。別アプリの参照先を複製した場合は、検証用のアプリを見ていることも確かめてください。

問題がなかった項目だけを、本番へ反映する手順にします。削除後に同名のフィールドを作り直しても、元データがそのまま戻るわけではありません。戻し方まで含めて、作業を決めておきます。

変更した日、項目名・コード、理由、確認した操作、担当者を記録します。「削除した理由」が残ると、後から似た項目が再作成されるのを防ぎやすくなります。

調査資料の持ち方はアプリ引き継ぎのチェックリストも参考にしてください。今回は削除の可否を判断するための調査手順です。実際の削除を自動で実行する案内ではありません。