製品に使う『材料マスター』の特定のレコードだけを更新したかったので、プラグインを使って一括更新しました(^-^)

すると、何という事でしょう💔…手順が間違っていたために、全てのレコードに更新がかかってしまいました。その数1600件ほど・・・💦

慌てて、項目ごとに再度更新をかけていき、調整していきました。
皆、一括更新には気を付けてね(;^ω^)✨

皆さんと比べるとかなりレベル低いハナシですが…(“失敗談”と聞いて久しぶりにコメントしちゃいます)
基本的なとこで「kintone導入時に必要に迫られてテキトーなアプリ作っちゃったけど、今の俺なら(もうちょっとノウハウとかテクニックあるし)もっとマシなアプリ作れるぞ！やり直したい！」って感覚ありませんか？

数年前にとある部署の為に作ったアプリを久しぶりに見てたら“人数”を入れるフィールドに数値じゃなくってドロップダウンフィールドを設定してました…💦　だから自ずと合計人数の欄も入力する人が暗算してドロップダウン入力することになる…💦💦　

さすがに修正を提案しましたがこれに慣れてしまった皆さんは「今のままでいいから変えないで」って言ってきてしもうた…(さすがに合計欄だけは自動で算出されるよう無理くり関数組みました)

フツーの企業の健全な皆さんはこういうの常にメンテ修正しているんでしょうなぁ…なんかお恥ずかしい…

基本やらかし案件は（ちゃんとリカバーしたら）記憶から抹消することにしているんですがw
せっかくなので、記憶を呼び起こして。。。

★最初の頃よくやらかしたのは、ノーコードでサクサク作れるのを良いことに、（仕様書とか全く作らずに）調子に乗って思いつくままアプリを作るので、いざレコード登録！の場面で、あれ？アレ？これダメじゃん…！で作り直し（もしくは没）、というのはよくありましたね～(;^ω^)
それからはある程度頭の中なり、書き出すなりして、全体のプロットを考えてからアプリ化出来るか検討して、行けそうならアプリ作って、テスト登録⇔リライト（繰り返す）という風にしています。
実物テストをちゃんとやる様になってから本番リリースで大幅な変更、というのはなくなりましたねー。

★あとよくやるのは「フィールドコード」登録。
弊社はカスタマイズすることが多いので、アプリを作る時は基本フィールドコードを必ず設定しています。日本語だと自動計算にしてもいちいち変換がだるいので（選択から探すのもマウス持ち替えるのだるい時ありません…？笑）という理由です。
でも似たようなフィールドがあると、フィールドコード名を考えるのが大変で...笑
例えば、
「契約金額(税込)=contractIntax」「契約金額(税抜)=contractNotax」
とかならそんなに迷うことないんですけど、
「契約金額(税込)=contractAmount」「契約金額(税抜)=contractNotax」
とかにしちゃうとどっちがどっちだったか混乱したり、うっかりコピペせずに書こうもんならスペルミスとかしちゃったり。笑

極めつけは、いざコード書く時に分かりづらいから、っていって、自分でコード書いてる途中でフィールドコード変更して、ここ変更したからこことこれも～、なんてフィールドごとのグループ分けを頭の中とそのコード上だけでしてしまったもんだから、その変更をどこにどうしたのか分からなくなってあれ動かねぇ！なんでだぁ！ってデバックがもう大変なことになって、chatGPTにデバック助けてもらうとか。笑
といっていわゆる一般名詞的なものを使うとグローバル変数に引っ掛かって（登録はできちゃうから）全く起動しない、そして気づかないで動かない！ってなることもありました。
複数のアプリでカスタマイズしてるとたまにコード内でケンカしちゃうので、アプリ名とか入れる時もあるんですが、フィールドコード名が長くなりすぎることもあるので、視認性としてどうなんだ？っつって略称とか作ると、これどういう意味？とか突っ込まれたりする。w

フィールドコードはよく「センスだ」と言われるのが良く分かった失敗談です。w

長文になりますが基本的にはしっかり情報収集と、勉強してから構築に入るべきだったと思います。

しくじったこと
・オンラインで無料で受けられるセミナーや、動画をあまり見ずに構築を始めてしまった。
・社外の情報を収集してこなかった(kintone Cafe、kintone hive、Cybozu Daysなど)
・親会社、子会社の方がkintoneが進んでいたのにそれに気付いたのは構築後だった…。

その結果が下記の感じでしたが本当にkintone Caféに助けられたと思います。
(行っていなかった場合を考えるとぞっとします)

①2023年12月末よりkintone知識ゼロの状況からアプリ構築開始(2024年4月運用開始…)
②通常の営業業務を抱えた状態での構築で時間がない、進まない、うまくいかない…
③2月13日 に偶然Youtubeに出てきたWeekly kintone talk2024 Week07を初めて聴く
④そこでkintone Café大阪というイベントが2日後にあることを知り残り2枠、勢いで登録
④kintone Café大阪での事例発表に感動！懇親会でもノウハウと元気を貰って自信がつく
⑤ここから急ピッチで構築が進み3月上旬の社内説明会を経て、3月末に構築完了
　(結局他の部署が間に合わず運用開始は5月になりましたが…)

PS.ついさっきまで下記のエラーが出て保存ができなくなりリアルタイムでしくじってました。多分なんとかなったと思います。
「you cannot call kintone.app.record.set() in handler or during processing a handler」

絞込→一括削除のはずが、ぼーっとしていて絞り込まずに一括削除してしまった。
前の日になんとなくデータバックアップしてたので大事にならずに済みました……。

それ以降、定期バックアップに加え、できるだけ物理削除しないような
設計を心がけています。

誰でも自由にアプリが作れるのが魅力的ですが、だからこそ「会社に合ったルール」を作りましょう。
後から作って是正もできますが、これが早ければ早いほど是正の労力がなくなり、ルールの浸透が早くなります。

とりあえず「Everyone」でアプリ一覧が不要アプリであふれる課題からルールを作りましたが、なかなか遵守とはいきません。

ザックリとですが、以下のような簡単なルールです。
①アプリ名称ルール　【報告】日報（総務）　※テスト【記録】ヘルプデスク（情シス）
②稟議決裁が出るまで「非公式アプリ」　⇒　アプリ名頭に”※テスト”とつける
③設定は各部で責任を持つ

#失敗談

何回も言ってますが、サブドメインはプラグインやJS書く前に変更！