あるあるを書いておきますね。

導入初期は「選択」させる時に、すぐに反映できる「ドロップダウン」を使用することが多いのですが、10以上の選択肢が存在するor存在することになるであろう場合はマスター用アプリを作成し、それをルックアップで取り込むというのが正解だと思います。

ドロップダウン等で選択させていた場合、選択肢を削除したり変更したりすると広範囲に影響する可能性があります。
ルックアップの場合は、マスター用アプリのその時点の情報を取り込みますので旧型番であろうが、退職者であろうが「その時点」を使っているので安心です。

過去の情報に影響する可能性を極力排除しないと、過去のレコードが正しいまま保存されないという結果に・・・。

◆失敗談　NO2
（障害１）
　通信回線・ネットワーク・kintone自身が障害発生でkintoneのシステムが
利用できなくなったこともありました。時間的には障害箇所により復旧に
３０分～１時間かかり、業務停止がありました。

　特にバーコードで施設の入退館管理をやっていたシステムは
入館が多い、朝オープンしたころに発生し、入館手続きを手作業で
メモいただき、復旧後手入力いただいたこともありました。

　→障害発生後、代替のシステムでバーコード入力をExcelに登録してゆき
　　一括登録するプログラムをリリースしました。

（障害２）
　kintone拡張サービス（PDFレポート作成）のライセンスが切れ
　帳票が１日出力できなくなった障害もありました。

　　→メーカ連絡で至急手続きで１日のみで対応できましたが
　　　ライセンスが切れるのがどこの拡張ツールメーカも月末で
　　　翌月月初から利用できなくなるので大慌てでした。
　　　※利用している拡張ツールの利用期限・申込期限を管理する
　　　　マスタアプリを作成整理しました。

コメントやいいねくださったみなさま、通りすがりに読んでくださったみなさま
ありがとうございました。
いただいたコメント読んでて共感したりぞわっとしたり、とても勉強になり、
みなさんそれぞれ乗り越えられてがんばっているんだと励みになりました。

「○○に困っている」→「アプリ化して解決しよう」→「アプリ化して解決した！」
の解決の前にはさまざまなみなさんの「失敗した！」「困った！」があったと思います。
これからも「失敗した！」「困った！」はあるとは思いますが、できるだけ少なくなることを祈ります・・！

たくさんありすぎて、何を情報提供したらよいか迷います。
・多いのが、マスタのコード体系変更に苦労。
　作成当初は順番に採番（レコード番号）でやっておりましたが
　マスタコード＋識別項目で対応していたが、参照したい形式から
　識別項目が増え、整理の為体系見直しとなり、関連アプリが多く
　過去データ変更も大変でした。

・JavaScriptでアプリを少しづつ、機能強化していって
　アプリに設置したJSファイルが８つくらいまで増え、
　JS間の競合で、テスト動作検証にすべてのソースチェックが
　大変となったとか、特定のJSを修正してアップしたが
　JSファイルの順番を入れ替えると他のJSが正しく動作しないとか・・・
　※サイボウズパートナーの拡張ツールで開発をお勧め

・kintoneの機能強化アップデートでAPIプログラムが正しく動作しなくなったり
　※事前の機能強化情報が送付されてくるが、主な機能強化・改善内容で
　　細かな情報は無いので、アップデート後に動作しなくなり、各部門からの問合せ
　　に大わらわしたとか・・・

・あとは、Excelとkintone連携プログラムも作成しているが
　Windows、Excel、kintone各製品ごとにバージョンアップがあるので
　アップデートで動作しなくなった時の調査に多くの時間を費やすとか・・
　サイボウズパートナーの拡張製品の利用をお勧め
　
等々、まだまだありますが、このへんで止めておきます。

事務所の紳士さんの投稿を読んではっとしました。
システム化すると多かれ少なかれ必ず業務フローは変わるので、変わった後、を考えてツールの構成を考えるのですが、手順変更に対する激烈な抵抗に遭って譲歩出来るポイントを探す（ツールなので使って貰わないと絵に描いた餅）事を何回か繰り返しました。
うーん、でもそのうち慣れてしまえば反対したことすら忘れてしまうものなので、甘いものでも摘みながら話し合いをする、とか可愛いデザインにしたりマスコットキャラを作ったりキレイめ写真を付けて見た目だけ変えて”ビジュアルに訴える”（人は見た目が９割、第一印象が９割、らしいので...）とか、今考えると真正面から受け止めずにさらりと交わす技術、はスキルかなあ、と思いました。
天の時、地の利、人の和、の天の時、は皆感じていると思います。今は意見が合わなくても喧嘩さえしなければ後から共感は付いてくるので一緒に前に進みましょう。
（社内一般ユーザーにノーコードツールを解放して試行錯誤しながらリテラシーを高めて貰う、に賛成です。システム管理者は少し大変ですが、理解の輪が拡がりますよね）。

みやもさんの失敗も、あるある～と共感してしまいました。
①はフィールド100超えのアプリで、白目向いたことがあったのですが、
松田様作のktoolsで何とかなりました。多謝　https://pj.asunote.jp/ktools_download/

プラグインの管理や、ファイルの書き出しは私が行っていて、アプリ自体の作成・管理はほかの人が行っている時、
フィールドコードや一覧を変更されてエラー　→「動かないんだけど！」と色々な人から連絡が入る
ということがありました。
特に複数の人が使うアプリは、変更ルールを決めるか、仕様書大事と気づきました。
プラグイン動かない・動かなくなった系の失敗（？）は、初期のころはかなり多かったです。
学んだのは「就業時間中にアプリを変更しない」ですかね。
深夜にアップデートするのは正しいことだと知りました。

社内ルールも強制力がないと守ってもらえず難しいですよね。。
無駄かな？と思いつつ、アプリ管理アプリに、公開前のチェックボックス作成してます。
　□確認：権限は○○になってますか？
　□確認：一意のキーを設定しましたか？
　□テスト：色々なパターンでアプリに入力→保存しましたか？
みたいな感じで、自分の確認のためにも使用してます。

業務フローを見直さずに、現状のままkintone化したことで後悔したアプリがいくつかありますね。
そのまま作り込みが進んで改善のタイミングを模索しているアプリがいまだに残ってます😂

逆に一発で「完璧」に作れたことがない（常にトライアンドエラー。笑）ので改めて「失敗は？」と聞かれると困っちゃいますね！笑

みやもさんも遭われた「フィールドコード判別不能事件」もありますし（随時変えられるのでJS開発する段階で設定した方が楽(自分ルールで作れるから)説もありますけど。笑）
シュミレーションして行けそうだから作ろ！ってなって、作ったはいいが、実際にテストで動かしてみたらやっぱり無理だったってこともあります。笑

とはいえ、ノーコードだからこそハードル低く作れるのがキントーンの良いところでもあるので、「失敗しないように作る」のではなく、「失敗した場合のリカバリー方法」を用意しておくのが良いのかな、とは思います。

例えばうちではテストスペース作って、そこでならテストアプリはどんどん作って良いよ！ってして、実用化出来そうなら本番リリース。ダメだったらアプリを削除するか別のモノに再利用するか、1年以上弄らなければ削除という風にしてます。
変に厳しいルール作って作りたい意欲を削ぐのももったいないな、と思うので最低限のルール（名前は分かりやすく、とか、どんな意図で作るのか、とか、同じようなアプリはないか、とか。）でやるのが良いと思いますよ〜(^-^)