ミュートしたユーザーの投稿です。
製品に使う『材料マスター』の特定のレコードだけを更新したかったので、プラグインを使って一括更新しました(^-^)
すると、何という事でしょう💔…手順が間違っていたために、全てのレコードに更新がかかってしまいました。その数1600件ほど・・・💦
慌てて、項目ごとに再度更新をかけていき、調整していきました。 皆、一括更新には気を付けてね(;^ω^)✨
事務所の紳士さん…！失敗談のシェア、ありがとうございます🥺✨ （Xでの拡散もとっても感謝です(T_T)✨）
何という事でしょう... 。💔 更新後の一覧をみて、本当に心がポキっとなる音が聞こえそうな失敗談でした、、、(T_T)
一括更新は、やらねばならない瞬間が来る時は来てしまうものですが、 もしミスが起こると、多大な影響がでてしまいますよね…。 更新時は、ご安全にならぬ、ご慎重に…！！！！！を合言葉にしたくなりました…！！
( ´ ▽ ` )つｽｯ 座布団1枚 それぞれの投稿に合わせてコメントを頂けるなんて、ありがたき幸せ('ω')✨
なんとなんと、こうしてコメントいただけることのほうが、何倍もありがたき幸せでございます🥺 座布団、ﾔｯﾀ━ヾ(｡˃ ᵕ ˂ )ﾉﾞ━!!!✨✨
皆さんと比べるとかなりレベル低いハナシですが…(“失敗談”と聞いて久しぶりにコメントしちゃいます) 基本的なとこで「kintone導入時に必要に迫られてテキトーなアプリ作っちゃったけど、今の俺なら(もうちょっとノウハウとかテクニックあるし)もっとマシなアプリ作れるぞ！やり直したい！」って感覚ありませんか？
数年前にとある部署の為に作ったアプリを久しぶりに見てたら“人数”を入れるフィールドに数値じゃなくってドロップダウンフィールドを設定してました…💦 だから自ずと合計人数の欄も入力する人が暗算してドロップダウン入力することになる…💦💦
さすがに修正を提案しましたがこれに慣れてしまった皆さんは「今のままでいいから変えないで」って言ってきてしもうた…(さすがに合計欄だけは自動で算出されるよう無理くり関数組みました)
フツーの企業の健全な皆さんはこういうの常にメンテ修正しているんでしょうなぁ…なんかお恥ずかしい…
桃屋のり平さん…！！！！全くレベル低くないですし、すごくすごく共感できるテーマでした、、、、、、、。ありがとうございます。m(_ _)m （久しぶりのコメントもうれしすぎます！！）
kintone 初心者の頃って、なかなかフィールドの特性を理解しきれていなかったりで今ならもっと良いアプリが…！という感覚ほんとうに私もあります🥺 （いただいたコメントきっかけに、今「自分が作成したアプリ」の一覧をすこし眺めてみていて、 そういえばこんなアプリつくったな、通知設定全然イケてないな、 なぜそこをラジオボタンにしなかった？！！などなど見つかりました。。。笑 ※どれもシンプルなアプリばかりですが、、、。）
そして「ほんとだったらもっと良いフィールドあるのに」なアプリが、浸透することで、現場のユーザーの皆さんにとっては使い慣れたアプリなので「たとえ良いものだとしても、今のままが良い」という風に、なるケースがあるんだなあというのが新たな発見でした…！
データの管理のために、現場の使い心地を変えることなく対処された桃屋のり平さん、すばらしいです。 そして、（すべての特徴を網羅、は難しいかもですが。。。。）フィールドの特性をアプリを作るときにしっかり面倒でも知っておく、というのは語り継ぎたい教訓ですね…。
ーーーーーーーーーーー
このあたりのメンテのタイミングや頻度、気になりますね…！ もしご自身の状況シェアいただける方いたら、コメントお待ちしております〜！
基本やらかし案件は（ちゃんとリカバーしたら）記憶から抹消することにしているんですがw せっかくなので、記憶を呼び起こして。。。
★最初の頃よくやらかしたのは、ノーコードでサクサク作れるのを良いことに、（仕様書とか全く作らずに）調子に乗って思いつくままアプリを作るので、いざレコード登録！の場面で、あれ？アレ？これダメじゃん…！で作り直し（もしくは没）、というのはよくありましたね～(;^ω^) それからはある程度頭の中なり、書き出すなりして、全体のプロットを考えてからアプリ化出来るか検討して、行けそうならアプリ作って、テスト登録⇔リライト（繰り返す）という風にしています。 実物テストをちゃんとやる様になってから本番リリースで大幅な変更、というのはなくなりましたねー。
★あとよくやるのは「フィールドコード」登録。 弊社はカスタマイズすることが多いので、アプリを作る時は基本フィールドコードを必ず設定しています。日本語だと自動計算にしてもいちいち変換がだるいので（選択から探すのもマウス持ち替えるのだるい時ありません…？笑）という理由です。 でも似たようなフィールドがあると、フィールドコード名を考えるのが大変で...笑 例えば、 「契約金額(税込)=contractIntax」「契約金額(税抜)=contractNotax」 とかならそんなに迷うことないんですけど、 「契約金額(税込)=contractAmount」「契約金額(税抜)=contractNotax」 とかにしちゃうとどっちがどっちだったか混乱したり、うっかりコピペせずに書こうもんならスペルミスとかしちゃったり。笑
極めつけは、いざコード書く時に分かりづらいから、っていって、自分でコード書いてる途中でフィールドコード変更して、ここ変更したからこことこれも～、なんてフィールドごとのグループ分けを頭の中とそのコード上だけでしてしまったもんだから、その変更をどこにどうしたのか分からなくなってあれ動かねぇ！なんでだぁ！ってデバックがもう大変なことになって、chatGPTにデバック助けてもらうとか。笑 といっていわゆる一般名詞的なものを使うとグローバル変数に引っ掛かって（登録はできちゃうから）全く起動しない、そして気づかないで動かない！ってなることもありました。 複数のアプリでカスタマイズしてるとたまにコード内でケンカしちゃうので、アプリ名とか入れる時もあるんですが、フィールドコード名が長くなりすぎることもあるので、視認性としてどうなんだ？っつって略称とか作ると、これどういう意味？とか突っ込まれたりする。w
フィールドコードはよく「センスだ」と言われるのが良く分かった失敗談です。w
かなさん…！抹消した記憶の掘り起こし＞＜大感謝です。
・1つ目のしくじり これまた多くの方に響きそうな失敗談！！！ありがとうございます。 ノーコード！されど、システム開発。というのは土台にしっかり置いておきたいものですよね…！ ガチガチに、とまではいかなくても、目的整理して、仕様を起こしておいて、アプリ作成して テストして…というのを丁寧にやっておくことは、ある意味近道だし、未来の担い手さんの ためにもすごくなりそうです…！
・2つ目のしくじり フィールドコード！ かなさんからいただいた失敗談の中だけでも、かなさんの事例から学べる しくじりポイントが複数あってとても参考になります。
私は実はそこまでカスタマイズ経験が無いのですが、無い私でも 計算等するときのフィールドコード命名は慎重にせねば…！と思っていたのですが カスタマイズ経験者のかなさんのエピソードを聞いて、本当にここは「センス」が 問われる部分というその真意が初めてちゃんと分かった気がします！🥺 フィールドコード、ほんとうに奥が深いテーマですね…。
長文になりますが基本的にはしっかり情報収集と、勉強してから構築に入るべきだったと思います。
しくじったこと ・オンラインで無料で受けられるセミナーや、動画をあまり見ずに構築を始めてしまった。 ・社外の情報を収集してこなかった(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」
工場長さん、ありがとうございます…！ 工場長さんとkintoneのこれまでがわかる内容を併せて記載をいただき大変参考になります。
> しっかり情報収集と、勉強してから構築に入るべきだった
すごく多くの方が「うんうん」と共感されるのではないかなと感じる一文です。 ぜひこれからkintone を使い始める段階の方に届けたい内容だと思いました。
工場長さんの場合は、 ・Weekly kintone talk ・kintone Café 大阪 によって、ぐっと構築が進んでいったんですね！
Weekly kintone talkは偶然でてきた、ということですが、運命的なものを感じます... ！！ 同じようにkintone に向き合う方々から直接いただけるノウハウや元気！がもつパワーは本当にすごいですね。 改めて工場長さんのお話を通して、実感しました。 ありがとうございます…！
※リアルタイムでもしくじりが！🥺（カスタマイズのエラーでしょうか…？） 無事解決されたようでよかったです！
返信ありがとうございます。 Weekly kintone talkとの出会いは本当に運命的でした！それからは毎週欠かさず聴いています。kinotne以外にも人材育成についてや経営等についても勉強になりますね。サーバーの話を聞いた後は少しだけサイボウズさんのサーバー負荷の事も気にしつつアプリ構築しています(と言いながらフィールド数とレコード数が多くて申し訳ありませんが…)
ちなみにリアルライムのしくじりは結局直ってませんでしたので、一度元に戻している状況です。時間があるときに対処していきたいと思います。
そこから、ヘビーリスナーさんなんですね…！ 私も時たま拝聴しておりますが、本当に学びが多いです。 そしてなんとなんと、工場長さん、サーバー負荷へのご配慮まで…。とてもありがたいです。
（▽ Weekly kintone talk 2024って何？という方向けにリンクを残させていただきます🥺 https://www.youtube.com/playlist?list=PL8DaCbKrRBLiQTmdFSQXNgMv0WS9gwla0 ）
リアルタイムのしくじり、まだ継続していましたか…！(T_T) 無事に解決することを願って＆応援しております…！
絞込→一括削除のはずが、ぼーっとしていて絞り込まずに一括削除してしまった。 前の日になんとなくデータバックアップしてたので大事にならずに済みました……。
それ以降、定期バックアップに加え、できるだけ物理削除しないような 設計を心がけています。
sujiさん、ありがとうございます！
> 絞り込まずに一括削除
文字からだけでも恐怖で体が震えました…。 そんな中、しっかりバックアップをとっていたsujiさん、やはりさすが過ぎます‥！！！！！
「物理削除しない設計」←すごく大切ですね。 使う側も「物理削除はない」ことで、安心して使うことができそうです。
誰でも自由にアプリが作れるのが魅力的ですが、だからこそ「会社に合ったルール」を作りましょう。 後から作って是正もできますが、これが早ければ早いほど是正の労力がなくなり、ルールの浸透が早くなります。
とりあえず「Everyone」でアプリ一覧が不要アプリであふれる課題からルールを作りましたが、なかなか遵守とはいきません。
ザックリとですが、以下のような簡単なルールです。 ①アプリ名称ルール 【報告】日報（総務） ※テスト【記録】ヘルプデスク（情シス） ②稟議決裁が出るまで「非公式アプリ」 ⇒ アプリ名頭に”※テスト”とつける ③設定は各部で責任を持つ
#失敗談
はっしーさん、ありがとうございます！ やろうと思えば、「誰でもつくれる環境」にできるからこそ、 不要なアプリであふれないようなルールづくりはすごく大切ですよね…。
そして、実際のルールも大変参考になります…！ 担い手を増やす拡大の流れと、情報にアクセスしやすく使いやすい環境を 両立させる工夫、すごく参考になります！
このあたり、各社さま様々なルールで工夫をされていそうですよね。
何回も言ってますが、サブドメインはプラグインやJS書く前に変更！
ｲｼｲさん…！！！1コメ…！！！！ありがとうございます！！！ プラグインや開発をする場合は、事前にサブドメイン変更！大切ですね、、、、、、 ちなみに、こちらにまつわる失敗談（ご自身でも、他のユーザーさんの体験談でも）等ってございますか…？
もう変えれないという失敗が現在進行中でございます（おそらく未来永劫
ああ…！まさに現在進行形の失敗談の情報提供…！＞＜ ありがとうございます！！！！
ミュートしたユーザーの投稿です。
投稿を表示製品に使う『材料マスター』の特定のレコードだけを更新したかったので、プラグインを使って一括更新しました(^-^)
すると、何という事でしょう💔…手順が間違っていたために、全てのレコードに更新がかかってしまいました。その数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書く前に変更！