kintoneには、いろいろなプラグインがありますよね。
僕も普段からお世話になっていますし、自分自身でもたくさんプラグインを作ってきました。
- クリックだけで設定できる
- ノーコードで扱える
- 作業者でも運用できる
やはり便利です。
ただ、長くkintoneに触れていると
「プラグインが増えるほど、なんとなく不安になる瞬間」
ってありませんか？
今日は、そのモヤモヤの正体と、
そこから僕が“JSテンプレート”に取り組み始めた理由を書いてみたいと思います。
プラグインは便利。でも「中身」を見る方法がない
プラグインは設定画面がとても分かりやすく、
現場の方でも安心して使えるのが魅力です。
一方で、こういう場面がよくあります。
- 「このフィールド削除してもいいですか？」
- 「このグループ名変えますね」
- 「サブテーブルを移動したいのですが…」
そのたびに、この変更でどのプラグインが影響を受けるんだろう？
と、一瞬だけ考えませんか？
（僕は毎回ひやっとします…）
なぜなら、プラグインの設定はプラグインの中にあり、
外から一覧できる仕組みがないからです。
GUIの裏にあるロジックを
“画面を開かないと見えない”構造になっているわけです。
もちろん、これは悪いことではなく
「ノーコードで扱える」ことと引き換えの特徴でもあります。
JSは可視化できる。でも毎回ゼロから書くのは大変
一方、JavaScriptカスタマイズは透明です。
- コードとして取得できる
- 履歴が残せる
- フィールド依存箇所を検索できる
変更に強いし、メンテナンスも容易です。
ただし、こちらは逆に
「ゼロから書く負担が大きい」という問題があります。
僕も何度も、「この処理、何度目だろう…」
と思いながら同じコードを書いていました。
プラグインとJSの“間”にあったら嬉しいもの
そんな経験が続くうちに、次第にこう思うようになりました。
プラグインほど閉じていなくて、
JSほどゼロから書かなくて済む、
その中間にある仕組みが欲しい。
- GUIのように導入しやすく
- JSのように構造が見える
- テンプレートとしてすぐ使える
- 履歴も残せる
そんな“第三の選択肢”がほしい。
そこで作ったのが Toolkit の JSテンプレートシリーズ
そうした試行錯誤の中で生まれたのが、
kintone App Toolkit の JSテンプレートシリーズ です。
- よく使う処理をテンプレート化
- コードは最小限で読みやすい
- カスタマイズしやすい構成
- GitHubで変更履歴も管理できる
- Toolkit から呼び出すだけですぐ使える
まさに「プラグイン」と「JSカスタマイズ」の“間”をつなぐような存在です。
プラグインを否定したいわけじゃない
むしろ、プラグインはkintoneの魅力のひとつですし、
僕自身もプラグイン開発が大好きです。
ただ、プラグインが増えるほど
「どこで何が使われているか」を見失いやすいのは事実です。
そこで“可視化できる形での再利用”を目指した結果、
テンプレートというスタイルにたどり着きました。
JSテンプレートを作ったら、「もう一つ必要なもの」が見えてきた話
JSテンプレートシリーズを作り始めた理由は、
前半で書いたとおり「プラグインとJSのいいとこ取りをしたかったから」なのですが、
作って使っていく中で、もう一つ気づいたことがあります。
JSテンプレートを入れると、運用が一気に“健全”になる
テンプレート化すると：
- コードが綺麗にまとまる
- 機能が一瞬で導入できる
- 修正しやすい
- GitHubで履歴が残る
- 現場が楽になる
すごくいいんです。
ただ、テンプレートが増えていくと、次第にこう思うようになりました。
「どのフィールドコードをどこで使っているのか、すぐ分かる仕組みも欲しいな…」
テンプレートは透明ですが、
“透明なもの同士の依存関係” を追いかけるのはやっぱり手間です。
特に、
- 大きめのアプリ
- JSファイル数が多い現場
- 誰かがちょっとフィールド変更する未来
こういう状況が当たり前のように発生します。
テンプレート化しても、結局最終的には
「このフィールド、本当に消して大丈夫？？？」
という確認が必要になるんですよね。
そこで "さらに” 作ったのが Field Scanner です
JSテンプレートだけでは不十分で、
「依存しているフィールドが一瞬で分かるツール」 が必要になる。
その“補完”として、自然に生まれたのが
Toolkit の Field Scanner（フィールドスキャナー） です。
テンプレートが“再利用の仕組み”だとしたら、
Field Scanner は“安全運用の仕組み”。
この2つはセットでこそ、最大の力を発揮するように感じています。
Field Scanner は「JSテンプレートを使う未来」を守るツール
新機能の Field Scanner は、
JSテンプレートと非常に相性が良い仕組みになっています。
▼ Field Scanner ができること
カスタマイズ JS/CSS の中で
「フィールドコードがどこで使われているか」を一括解析します。
操作はこんな感じでシンプルです：
- Target（desktop / mobile）を選ぶ
- Kinds（JS / CSS）を選ぶ
- Scan をクリックする
結果は、次の形式で出力できます。
- MD Copy（Markdown）
- MD DL
- CSV DL
- JSON DL
現場でよくある “仕様書づくりの時間” や
“フィールド削除前の安全チェック” にとても役立ちます。
JSテンプレ × Field Scanner で「見える開発」を目指す
僕が思っているのは、
テンプレートもフィールドスキャナーも、“答え”というより習慣の道具
ということです。
- プラグインは便利
- でも設定が見えない
- JSは見える
- でもゼロから書くのは負担
そこでテンプレを用意して、
運用のために Field Scanner もセットで作る。
この流れのほうが、長期的に使う上で
“現場が迷子にならない” と感じています。
まとめ：テンプレ＋Field Scannerで、もっと安全なkintone開発へ
JSテンプレートシリーズが 「再利用しやすい設計」 を提供するなら、
Field Scanner は 「依存関係の見える化」 を支えてくれる存在です。
- プラグイン
- JSテンプレ
- Field Scanner
この3つがそろうことで、
「人に優しくて、構造がクリアなkintone開発」が実現できると感じています。