【kintone複数選択系フィールド】選択肢を削除してもファイル書き出しデータ、言語ごとの名称設定で残っている

 kintoneアプリのフォームに選択系フィールド(ラジオボタン、チェックボックス、複数選択、ドロップダウン)を使っている場合のTips

ブログの記事として書いていましたが、kintoneのヘルプ等関連ドキュメントにも記載がないようなので、こちらでも共有します。
※タイトルの内容を修正しました(2017/12/6)

0. まとめ

(2017/12/6追記・修正)

対象:選択系フィールド(ラジオボタン、チェックボックス、複数選択、ドロップダウン)

  1. 一度運用を開始した選択肢は、その後削除しても、内部的にはデータが残ってしまう。
  2. ファイル書き出し時のデータや「言語ごとの名称」設定時に削除した選択肢が現れる。(既存の登録データが無い場合も同様)
  3. ファイル書き出し時、1つを選択するフィールド(ラジオボタン、ドロップダウン)では影響がないが、複数選択系フィールド(チェックボックス、複数選択)では列が増えるため、ファイル出力を想定した業務においては注意が必要。
  4. 選択肢の見直しが終わったところで、新たに複数選択フィールドを設置し、データの引っ越しをするしかなさそうだ。

 

1. 現象の確認

複数選択フィールドの選択肢として以下の3つが登録されています。

  • 選択肢A
  • 選択肢B
  • 選択肢C

 

このアプリのデータをファイルに書き出すと、次のように現在登録されていない選択肢のデータが書き出された。また、言語ごとの名称設定画面のフォーム情報にも項目が現れることが確認できます。

  • レコード番号
  • 文字列(1行)
  • 複数選択[選択肢A]
  • 複数選択[選択肢B]
  • 複数選択[選択肢C]
  • 複数選択[選択肢D]・・・設定にないデータ
  • 複数選択[選択肢E]・・・設定にないデータ
  • 複数選択[選択肢F]・・・設定にないデータ

 

 

2. どのようなときに起こるか検証

運用開始後、選択肢を削除した場合

最初にフィールドに配置した複数選択フィールドには、あらかじめ4つの選択肢がサンプルとして登録されています。通常はこのサンプル選択肢の名称を書き換えて選択肢を設定すると思います。

一旦この状態で保存し、アプリの運用を開始します。

その後、再度設定画面から、フィールドの設定を編集し、保存・運用開始します。

  • sample4を削除
  • sample1-3の名称を変更

 

今度は、「言語ごとの名称」設定のフォームタブで確認してみます。

図のように、削除したはずの「sample4」が設定項目として見えています。

 

kintoneでは一度アプリを作ったら、運用しながら実態に合わせてアプリを修正しながら、スパイラルアップで業務を改善していく、という手法がよくとられます。

複数選択フィールドを使う際は、一度保存して運用開始した選択肢は、名称の書き換えは問題ありませんが、削除した場合は内部データが残ってしまいます。選択肢の追加・削除を繰り返して行っていると、どんどん削除データが溜まっていくことになります。

 

3. なぜこうなっているか考察

(2017/12/6追記)

一度アプリが運用状態になるということは、すでにデータが登録されることを想定しなければなりません。

その選択肢を選ばれたレコードがすでに登録されている場合、 アプリのフィールド設定を操作したことで、既存のデータには影響を与えない という思想となっていることが想定されます。

データの保持に関連している、ファイル出力時のフォーマットや言語ごとの名称設定において表示されるのも同様の考え方。

(フィールドの削除については、削除操作時にデータも削除されるというアラートが表示されます)

 

でもちょっと・・・?なところ

「既存のデータを保持」することはこれでできていますが、「活用」については以下の点を意識しておくことが必要です。

関連レコード一覧やルックアップで参照するときの絞り込み条件や、一覧表示の絞り込み条件については、現役の選択肢しか使えない ようです。アプリデータを活用するときに必要な選択肢は、ちゃんと現役で残しておかないといけないということですね。

「既存のデータとしては保持しておきたいが、新たに入力をさせたくない」という考え方で使うこともできますが、注意が必要です。

 

4. なんとか消せないか頑張ってみた

残ってしまっているデータをなんとか削除できないかと、いろいろ試してみました。以下の方法で検証してみましたが、いずれもダメでした。なかなかしつこいです。

  1. アプリをテンプレート化して、新規にアプリ作成
  2. アプリの再利用で新規にアプリ作成

 

5. 今のところできる対策

通常、画面からアプリを使う際には特に大きな問題になることはないと思います。

しかし、 ファイル出力を想定した業務 でこのようなアプリを使う場合は、毎回不要なデータが出てくるのは困ります。既存データも無いのでちゃんときれいにしたい!という要望も出てくると思います。

現状できる対策としては、
_ アプリの設定内容が固まったところで、新規に複数選択フィールドを作り、そこに最新の選択肢をセットする 。_

というやり方で逃げるしかないと思います。シンプルな手順は以下。

  1. 既存データをファイル出力
  2. 最新選択肢を持ったフィールドを新規で設定し、既存フィールドは削除(フィールド名は既存フィールドに合わせておく)
  3. ファイル読み込み

既存データに消そうとしている選択肢が含まれていると、3のファイル読み込み時にエラーがでます。

 

 

:arrow_forward:もうちょっと詳しい解説記事:

https://pj.asunote.jp/ghost-in-the-app/

 

▼2017/12/6

  • rex0220さん、大田浩さんのコメントを参考に追記・修正を行いました。
  • developer network > kintone API > 共通仕様 > フィールド形式のドキュメントの注釈に以下の記載がありました。
    「※1 「value」に指定する値は、kintoneのアプリのフォーム設定で、「項目と順番」で設定した値を指定します。
    また、 これらのフィールドは削除済みの選択肢についてもAPI及びCSVで指定することができます。

 

Shotaro Matsuda さん

共有ありがとうございます。

こちらで確認した内容も共有させていただきます。

>3. なんとか消せないか頑張ってみた

フォームの設定の変更 APIで、消しても消えない
結果として、マニュアル操作で消した時と同じになります。

 

・その他の項目

チェックボックス、ラジオボタン、ドロップダウン でも、選択肢を消すと言語ごとの名称設定で見えてしまいます。

・なぜ、選択肢が残ってしまうのか?

これは、私の想像なんですが、下記のような既存データとの整合性のためだと思われます。

設定上の選択肢を削除しても、既存レコードの項目の選択肢は残ったままになります。

既存レコードの詳細画面を開くと、消した選択肢が表示されます。

既存レコードの編集画面を開くと、消した選択肢が表示され、未選択に変更できます。

消した選択肢を選択状態のまま、保存もできます。

 

矛盾をなくすためには、設定変更時に全既存レコードを変更する必要がありますが、

かなりのリスクがあり、またそういう設計方針かなんかで、出来ないのではないかと思います。

 

 

rex0220さん

補足ありがとうございます。

この辺の選択肢系のフィールドは、『フィールドの選択肢を削除した場合でも既存のレコードのデータは残す』という方針ということですね。

確かにそれを前提に考えたら、現仕様もうなずけるところがあります。

既存データが無い場合でも選択肢が残ってしまう、というのを回避したいところですが、フィールドの引っ越しで逃げるしかなさそうですね。

https://developer.cybozu.io/hc/ja/community/posts/115020257863

私が質問したこの件のフォローをしてくださったのですね。

ありがたいです。

本件は複数選択フィールドの場合の問題ですが、「既存のレコードのデータを残すが、参照専用にしたい

(レコードの登録には使用禁止)」という要件に、kintone 全体としてどう応えているか、設計思想が知りたいですね。

満期日を設定すると参照もできなくなるとか、登録されたアプリ自体では見えるが他アプリからのルックアップでは見えない、とか。

 

 

大田さん

以前経験してなんとなくわかってはいたのですが、ちゃんと検証していなかったので、いい機会になりました。

rex0220さんの補足にもありますように、同様の現象は選択系フィールド全体についての共通思想のようですね。

ただし、大田さんが言われるように、「既存のデータは残すが、新規登録させたくない」という用途においては注意が必要ですね。

関連レコードとルックアップにおいても、設定時の絞り込み条件としては設定できなくなるようです。

当方、現在、「ルートセールス営業日報」「SE工数管理日報」「商談報告書」のサンプルアプリ3個を、
カスタマイズ使用していて(JavaScript未導入)、これからSFAパック(「顧客情報」+「案件情報」)と
連携させようとしています。
「顧客情報」+「案件情報」には、もともと関連レコード一覧やルックアップが含まれていますが、
カスタマイズ(JavaScript未導入)により、さらなる関連レコード一覧やルックアップを含めています。
※いずれのアプリにも、利便性を上げるためにJavaScriptを導入する検討をしています。

この状況下で、「既存のレコードのデータを残すが、参照専用にしたい(レコードの登録には使用禁止)」と
いう要件に遭遇しました。

たとえば、
・会社の全喪
・会社の改名
・所属(組織)の廃止
・所属(組織)の改名
・担当者の退職
が発生したとき、「顧客情報」のレコードを深く考えずに削除したりや変更したりしてしまうと、
関連レコード一覧やルックアップが影響を受けるのでは?と思いました。

本件の選択系フィールドの問題とあわせて、
https://developer.cybozu.io/hc/ja/articles/217964263
のようなデータ連携上の留意点だと悟りました。

もともと私が遭遇したような問題を回避するためには、サンプルアプリからカスタマイズして使用している
ものも、ゼロからつくりなおすべきなのかもしれません(フィールドコードもすべて自前で付与するとアプ
リ連携がしやすくなりますし)。

大田さん

アプリの連携を前提とするのでしたら、サンプルアプリはレイアウト等の参考として、構成を見直すのもアリだと思います。

上記の情報から推察すると、顧客情報を営業日報や商談報告と連携させるような構想を持たれているということでしょうか。

営業活動の中で、お客さんの情報が変更になることを入手することは多いので、その都度顧客情報アプリをどのように更新するか、という課題でしょうか。

 

顧客情報アプリを、他のアプリから連携して使う際は、顧客の会社名だけではなく、何かコード(通し番号のようなもの)を別途作って、それもルックアップで取得しておき、関連レコードの表示等では名称ではなくコードを使う、というのはよく行います。

この場合、レコード番号を使ってもいいのですが、アプリの引っ越し(別アプリへのデータ移行)等を行ったときにコントロールできなくなるので、レコード番号とは別にコードを採番する、というやり方です。

 

あとは、顧客情報変更時は、アプリのデータを直接変更させるのではなく、変更情報として書き込んでもらい、マスターは管理者が変更するというやり方もあるかと思います。

 

ありがとうございます。
ヘルプやTipsにははっきりとは書かれていないノウハウ(奥義?)があるのですね。
#オンプレミス等のシステム設計だと割とあたりまえのことですが、ユーザフレンドリな
kintone なので、コード化等はそんなに意識しなくてよいのだろうと思っていました。

今後のカスタマイズ(JavaScript対応を含む)の参考になりました。