トーク

ユーザー画像
2022/01/07 23:58

ドロップダウンリストフィールドのリスト変更に関する質問

ご無沙汰してます。いくつかの業務でkintoneの活用が決まり、ぼちぼち設計を始めています。僕はあくまで支援する立場で、主体ではやってはならないというのが課せられた条件で、「ゴリゴリ俺にやらせてよ~」っていうのが本音ですが、自分の視野を広げるためにも前向きに取り組んでいこうと思います。

さて、本題のドロップダウンリストフィールドについてなのですが、設定画面でリストの項目を削除せずに編集すると、登録済みレコードにおいて、同フィールドの値が編集された項目であった場合、その登録済みの値まで変更されてしまいますよね。
すでに登録済みの値を登録当時の値で残したい場合は、そのリストを削除してからあらたな項目を追加するやり方になると思いますが…これから自分以外のメンバーがアプリを開発していくことになるので、いつかはだれかが知らずに編集して失敗してしまいそうな気がして心配でなりません。

みなさんどのような対策をされているか教えてください。よろしくお願いいたします。


この投稿を共有する
閉じる
4件のコメント (新着順)
ユーザー画像
ユーザー画像
koichi
2022/01/11 12:30

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

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

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

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

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



ユーザー画像
ユーザー画像
Hazime
2022/01/11 20:11

koichi さん

ブログ見ていただけて嬉しいです。ありがとうございます♪

標準ドロップダウンと自作ドロップダウンを使い分けているんですね!
僕もアプリの性質によっては、ドロップダウンリストを自作したほうがいい場合もあるかなぁという考えを持っているので、実践されていることをお聞きできてよかったです!
kintoneUIComponentは知りませんでしたので、さっそくトライしてみようかと思います!教えていただきありがとうございます。

バージョン管理、kintoneのさらなる進化に期待ですね!


ユーザー画像
ユーザー画像
Hazime
2022/01/10 18:24

西村さん アンデスさん

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

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

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

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


ユーザー画像
ユーザー画像
アンデス
2022/01/10 10:48

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



ユーザー画像
ユーザー画像
Hazime
2022/01/10 19:58

アンデスさん

ありがとうございます。
西村さんのアドバイスと共通する部分があったので
https://kincom.cybozu.co.jp/chats/0hsu4geodras2jcp#jrv4hyumbybkojr5
に一度コメントとして返信しましたが、個別にも返信させていただきます。


「変更点でバックアップをとっておく」「変更点での予期せぬリスクに備えておく」というのは、kintoneに限らず多くの業務に共通することですね!基本の心得として忘れてはいけないことだなとあらためて感じました!その点を再認識できてよかったです!ありがとうございます!

Excelなど今まで社内のスタンダードツールで定着したユーザーの概念をほぐしてあげるのもkintone推進者の仕事のひとつですよね。僕もkintoneを展開をしていく中で、既存ツールとの考え方の違いや使用感の差をユーザーにどう理解してもうらうかは懸案事項でありますので、説明会などを地道にやっていくことは大切ですね!!


ユーザー画像
ユーザー画像
西村 志郎
2022/01/09 20:59

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通りでよいとおもいます。

応援します。^^



ユーザー画像
ユーザー画像
Hazime
2022/01/10 19:58

西村さん

ありがとうございます。
アンデスさんのアドバイスと共通する部分があったので
https://kincom.cybozu.co.jp/chats/0hsu4geodras2jcp#jrv4hyumbybkojr5
に一度コメントとして返信しましたが、個別にも返信させていただきます。

具体的にシチュエーションを考えてくださってありがとうございます!僕自身も頭の中でシミュレーションができました!

”これが結局「開発」ということ”はとても説得力がありますね!
アプリに開発に携わる担当者には「開発者」としての自覚に加え、やりがいや面白さなどを伝えていけたらと思います!!