Hazimeさん
こんにちは。いつもブログ拝見させていただいてます。

ドロップダウンの自動更新はメリットになるときもあれば、デメリットに働くときもありますね。

少し手間な運用にはなりますが、ドロップダウンに関してですと
kintoneUIComponentなどで自作し、選択値は文字列1行またはドロップダウンに格納。
これでしたらレコードを直接（またはCSV）編集しない限り、情報の上書きは防げると思います。

私も標準ドロップダウンと自作ドロップダウンを使い分けています。

いつかkintone標準でアプリ環境が自動バージョン管理されて、切り戻しできるようになると良いですね。
皆様おっしゃるように教育・ルール作り・リスク管理も大切と思います。

西村さん アンデスさん

とても参考になります！ありがとうございます！

ポイントとしては…
・定期的＆アプリ改修時のバックアップ
・アプリ開発者、ユーザーへ階層ごとの教育訓練
・社内の開発・改修時のルールづくり
・アプリ毎に重要度とリスクの整理
といったところでしょうか。僕もイメージができました！！

特に、お二人が触れられているkintoneへの理解に対する教育訓練や説明会などの取り組みも、やはり重要ですよね！
教育は大変ですが、避けては通れない道なので、前向きに取り組んでいこうと思います！！

たいへん有益なアドバイスありがとうございます！！

参考になるかわかりませんが、kintoneを触り始めた当初は前任者が作成したアプリを修正していたのもあり「既にあるフィールドを変更をする時は月一のバックアップとは別にcsvに書き出す」を自分ルールにしています。
あとまだ対策できていないのですが、kintone利用者の大半が「フィールド=Excelのセル」と勘違いしてることが多く簡単に「フィールドの書式？変えて」とか自分たちで文字列フィールドを変更したのに「この項目日付で絞れない！」とか言ってくるので「これは一度各フィールドについての説明会をしなければ…」と思っています💦

Hazimeさん

kintoneの社内活用おめでとうございます！

Hazimeさんの自分でつくりたいお気持ちわかります。
上司からの「サポートに徹する」という指示も納得性がありますので、Hazimeさんの言うとおりココは良い機会と前向きに考えるのが良いですね。

相談の件、おっしゃる通りドロップダウンで項目内容を変更した場合に起こりえる事象ですね。

もっというと、例えばドロップダウンに「A」と「B」という項目を設定してた場合、アプリの設定で、ドロップダウンの項目をそれぞれ「A→B」「B→A」と変更したら、項目の入れ替えができてしまいます。さらにコレ変更履歴にも反映されません。^^;

じゃこれを防止するという方法があるのかというと

ドロップボタンの項目を文字列 (1行)の自動計算で取得しておくという簡易的な方法を思いつきましたが、ドロップダウンの項目の変更を防止することにはならないし。。。

んんー、おもいつかないですね。
いわゆる「それは仕様です」になってしまいます。

kintoneのドロップダウンの仕様として、項目の変更時、削除＆追加と同じく、既にあるレコードに変更が影響しない仕様や、既に利用している項目がある場合は変更を禁止にする仕様も実装可能だったとは思いますが、そうしなかった事には何からの理由があるのでしょう。

たとえばドロップダウンの項目が会社名などで、常に最新の表記に変更できた方が都合がよい場合などが考えられます。また単に項目の誤記訂正ができた方がメリットありと考えられたのかもしれません。

想像の範囲ですが、おそらくドロップダウンの項目変更は項目の本質的な意味は変わらないケースを想定しているのではないでしょうか（本質的な意味が違う項目変更は追加＆削除をする）。

で、色々考えてみましたが、現時点の私の考えとしては

・「開発」にたずさわるのであれば「仕様の理解」は避けて通れない

に行き着きました。

うちで実際あった話ですが、kintoneアプリ開発担当者が、運用中のアプリの文字列 (1行)フィールドを、文字列 (複数行)フィールドに変更しようと、既存の文字列 (1行)フィールドを削除した事がありました。

たまたま私の目の前で行われましたので、ストップをかけられましたが、アプリを更新してしまったら、文字列 (1行)フィールドのデータは帰ってこないところでした。

はたしてこれを防止する方法があるかというと、、思いつきません。

これはkintoneが、「フィールドデザインとフィールドデータを分離していない仕様」だからです。これは仕様を理解するしかなく、また仕様の理解無くして対応できません。

これが結局「開発」ということなんじゃないですかね。

JSカスタマイズの是非はよく話題になりますが、標準機能でも「アプリ開発」という意味では根本的な部分はいっしょだと思います。

kintoneは、ノーコード、ローコードを売りにした簡単にシステム開発ができるツールですが、あくまでそれは簡単になっただけで「開発」はやっぱり「開発」。それなりに学習は必要ですし注意すべきポイントは注意するしかないのかなと思います。

じゃーやっぱりkintoneアプリ「開発」はシステム経験者など限られた人しかできないの？
というとそんなことはありません。だれだって最初は初めてですし、やってみなくちゃわからないことはたくさんあります。

そこで「開発」においてもうひとつ配慮することがあるとしたらそれは、

・「最悪の事態」にならないように対策をする

ではないでしょうか。
例えば、「元のデータが消えてなくなる」などは、一般的に最悪の事態ですよね。^^;

具体的な対策としては、

データのバックアップを取る
データのリストアが可能な事を確認する
リカバリのできる状況で変更を行う

などなど。

kintoneのCSV入出力ではコメントが再現できなかったりしますが、少なくともフィールドデータが復旧できないという「最悪の事態」は避けられます。

あとは対策にどこまでかけるかですが、それはそのアプリの重要度と対策コストのバランスを考えることになります。

方法については、定期的なバックアップを取るのか、アプリ変更前のバックアップガイドラインをつくるのか、関連サービスのバックアップツールを導入するのかなどなど。

検討の結果、アプリの重要度が低い場合やリカバリが容易な場合、kintoneの仕様上安全な変更対応ならそれらを理解したうえで対策をとらないというのもありです。大事なのは、そういう視点で「開発」を考えることで、それだけでも意味があると思います。

で、ちゃんとリカバリ対策や教育（基本的な仕様の理解）などの手順を踏んでアプリ開発をお任せする。多少のリスクはつきものですし、ちょっとしたトラブルならクリティカルでなければまあ良しとする勇気を持つことも必要なのかなとも思います。^^

長くなってしまったうえに、解答になってなかったかもしれませんが、私の考えたことを共有します。

もちろん正解はなく、考え方は100人100通りでよいとおもいます。

応援します。^^