kintoneのフィールドコードをメンテナンスするWebアプリを作りました！
この記事は「すごくない」kintone Advent Calendar 2024の参加記事です。
今日はクリスマスですね。kintoneを愛するみなさんに、ぼくからささやかなプレゼントを用意してみました！
いけてないフィールドコードを調べて、いい感じに修正できるWebアプリです。アクセスして使ってみてくださいね。
フィールドコードを変更すると、プラグインやサービスが動かなくなる可能性があります。このツールは「アプリを更新」しない限り、実際のアプリを変更しないように作ってあります。
運用中のアプリへの利用は慎重に。これから作るアプリにはぜひ、使ってみてください。
＊おすすめの利用法は、適当にフィールドを並べて、このツールで後からフィールドコードを変更する方法です。
きみのフィールドコードは大丈夫か？
kintoneのフィールドコードについて、考えたことはありますか？
ささやかだけど、とっても大事なフィールドコードについて、この記事では考えてみたいと思います。
フィールドコードとは
フィールドコードとは「フィールドを指し示す名前」です。
フィールドコードがなぜ必要なのかというと、kintoneでは同じフィールド名のフィールドを作ることができます。そのときに、ぼくたちが、どちらがどちらのフィールドかを識別できるのは、フィールドコードが違うためです。
フィールドを表すのはフィールド名ではなく、フィールドコードだということですね。
kintoneのフォーム設定画面でドラッグ＆ドロップして作成すると、フィールドコードはデフォルト値が設定されます。
この「デフォルトで付けられるフィールドコード」が問題を引き起こします。フィールドコードを適切に設定することで、アプリのメンテナンスがスムーズになるよ、というわけです。
フィールドコードで失敗した！
ぼくはこのフィールドコードの扱いで何度か失敗しています。具体的に紹介したいです。
では、この設定をみてほしい。
これは計算式が設定されたフィールドなのですが、まじで何をどうしているのか読み取れません。困ります。
どうやら、【分類】という名前のフィールドと【商品名】という名前のフィールドを"-"で結合しようとしているらしいです。やれやれ。
フィールドコードはkintoneフィールドの「もう一つの名前」とも言えます。なので、これが設定の折に単体で出てくることも多く、認識しやすい命名をしないとややこしいことになってしまいます。
フィールドコードは計算式のほかにも、プラグインの設定の多くで利用されています。
プラグインの設定画面によっては、フィールドコードを直接入力したり、検索して設定したりします。その時に、特にフィールドコードがデフォルトのままだと、何がどのフィールドなのか、まったくわからなくなります。
フィールドコードのつけかた
ぼくは「フィールドコード＝フィールド名」のルールを採用しています。
できるだけフィールドコードとフィールド名は一致させる
テーブルや関連レコードにもフィールドコードをつける
フィールド名がかぶる場合には、フィールド名のほうを変えることを検討する
（）などが入ってしまって一緒にできない場合は_などで代用
といったルールで設定しています。
フィールドコードの命名法については論争があると思います。詳しく知りたい方はこの記事の最後に、ぼくがなぜこのルールを採用するようになったかを解説していますので、読んでみてください。
フィールドコードにまつわる問題
★フィールドコードはあとで変えにくい
では、フィールドコードを変えようと思うと、プラグインや関連サービスで利用してしまっていて、変えると動かなくなるといったことが起こります。
関連サービスのどこでフィールドコードが使われているかを調べるのは困難だし、放っておくといろんなシステムがつながりはじめるので、傷口が広がります。
★フィールドコードの問題をみつけにくい
早めに正しく修正したい。でも、フィールドコードはアプリのフォーム画面を開かないと見られません。しかも、フィールドの設定まで開かないと見られません！ こまる！
最初にフィールドコードを付け忘れると、ずっとデフォルトのまま残り続けてしまいます。
フィールドコードの設定って大事
フィールドコードを設定し忘れると、アプリのメンテナンス性に影響が出てしまいます。できるだけ忘れないように設定して、設定忘れがないか、定期的に見回りたいものです。
でも、なかなか難しいんですよね。人間だもの。
www.pulsar-works.jpでは「kintoneアプリ定義書」もあるので、今回ご紹介したツールとあわせて、使ってみてください。
それでは、メリークリスマス！
【解説】フィールドコードの命名規約
（注意）この先の話はかなりマニアックなので、ここで読むのをやめてもらって構いません。
どんなフィールドコードをつけていますか？
かっこよく英字の名前をつける派
分かりやすく日本語の名前をつける派
ぼくはプログラマなので、最初のころはかっこよくつける派でした。大きな製鉄所のSEをやっていたので、kintoneに触れる前にはデータベースの項目ばっかりつけていました。(メインフレームとOracleを扱っていました。)
英数字6文字(大小なし)の【SEIKBN】みたいな名前です。これは製品規格区分コード。
なので、kintoneを触り始めたころは、【商品名：PRODUCT_NAME】みたいな大文字＋アンダースコアのフィールドコードをつけていましたね。
ただ、kintoneを触るうちに、このフィールドコードが、プログラム上に多くあらわれるようになってきました。これはカスタマイズをするとわかるのですが、オブジェクトのプロパティ名として現れるのですね。
なので、大文字のスネークケースが気持ち悪くなって、productNameのようなキャメルを書くようになりました。
さらに時間がたつと、複雑なカスタマイズをするようになったので、このキャメルケースが「変数なのかkintoneのフィールドなのか」分からなくなってきました。目視したときの認知の問題です。
そのころにはどんなアプリをサイボウズ社が作っているか、アプリストアの多くのアプリを研究するようになりました。
例えば、執筆現在で
「備品在庫管理」はフィールドコードがデフォルトのままです。
「To Do」はフィールドコードがパスカルケースです。
「案件管理パック」はフィールドコード＝フィールド名です。
アプリストアにあるので、みなさんも追加してみてください😊
注目したのは、サイボウズ社のアプリもばらつきがあるという点、そしてサイボウズ社のアプリは複雑なものはフィールド名とフィールドコードが同じだということです。
kintoneのアプリの構築案件をやっていると、どうしても複雑なアプリを最初にテンプレートとして導入することが多くて、フィールド名＝フィールドコードの規約を採用したほうが開発の手間がない、といったことが起こります。
実際、フィールド名とフィールドコードを同じにすることで、メンテナンス性がかなり上がりました。また、表示するフィールド名の重複を見つけることができるようになり、ユーザビリティも向上しました。
フィールドコード＝フィールド名の規約がかなり気に入ったので、ぼくはこの方法を採用しています。
ただ、この規約がマイナスになるケースもありました。それは「既存のデータベースとの連携」です。既存のデータベースは大文字のスネークケースが採用されている場合が多く、データベースとの相互連携を表すために、データベースのカラム名と一緒にした方がいい場合がありました。
いまもどんなフィールドコードをつけるべきかは、正しい答えは分かりません。
みなさん、どう運用されていますか？
この記事はおわりです。お読みいただき、ありがとうございました。