公開日：
こんにちは。システム開発グループの大澤です。
弊社の「キミノマホロ」にも「JavaScriptのカスタマイズをカスタマインに移行したい」というお問い合わせをいただくことが増えてきました。
kintone を長く運用していると、「JavaScriptで作り込んだカスタマイズの保守ができなくなってきた」「これ以上機能追加するのが難しい」という壁にぶつかることがあります。特に、開発を担当していた人が退職してしまったり、コードの内容がブラックボックス化してしまうと、その傾向はさらに強くなります。
こうした事情から、JavaScript カスタマイズをカスタマインへ移行したいと考える方は少なくありません。カスタマインならプログラム言語の知識が不要で、ドラッグ＆ドロップ中心にカスタマイズを作れるため、属人化を避けやすいという利点があります。
しかし、移行にあたって必ず押さえておくべき重要なポイントがあります。
今ある処理を「そのまま移行しない」ことが大事
JavaScript をカスタマインに置き換える際、多くの方がやりがちなのが 「今ある処理をそのままカスタマインで再現しようとする」 というアプローチです。
気持ちはとても理解できます。現状の業務を止めずにカスタマイズを移行したい、動いているものを変えたくない、というのは当然の感覚です。
ですが実は、この「そのまま移行」が落とし穴になります。
システム開発の世界では、プラットフォームが変われば“得意な処理の流れ”も変わる という前提を忘れてはいけません。JavaScript とカスタマインは同じ kintone をカスタマイズする手段ではありますが、アプローチや考え方がかなり異なります。
そのため、JavaScript で作られた処理を、構造やロジックまで含めて完全に同じように作ろうとすると、カスタマインの特性を活かせず、逆に複雑で保守しにくいカスタマイズになってしまうケースが多いのです。
カスタマインへ移行する前に、まずロジックを見直す
これはパッケージソフトなどの別システムから kintone に移行する時に必ず必要になるプロセスとよく似ています。パッケージソフトの仕組みをそのまま kintone に持ち込もうとすると、kintone の柔軟さを活かせず、複雑さだけが増してしまいます。だからこそ、業務フローを整理し、kintone に合う形へと組み替えることが必要になります。
JavaScript からカスタマインへの移行も、同様の考え方が必要です。
JavaScript のロジックをそのまま追いかけない
JavaScript は自由度が高いため、複雑な条件分岐やイベント制御を細かく記述できます。一方カスタマインは、設定画面で条件やアクションを組み合わせて処理を作るため、シンプルな処理の組み合わせが得意です。
そのため、移行時には次の2つを意識する必要があります。
- JavaScript の処理の本質が何かを整理する
- カスタマインではどの設定の組み合わせが最適かを考える
カスタマインらしい作り方に変換する
カスタマインはプログラミング言語ではありません。だからこそ、複雑なアルゴリズムや入り組んだ処理を再現しようとすると限界がある ということも理解しておくべきです。
「頑張れば再現できるかもしれない」
「細かく設定すれば JavaScript と同じ動作にできるかもしれない」
そう思って作り込んでいくと、設定画面の条件が大量に増え、後から見ても理解できない“ブラックボックス化したカスタマイン”が誕生してしまいます。これでは、JavaScript で困っていた頃と同じ状況に逆戻りです。
カスタマインで重要なのは「後から見て理解できる」こと
カスタマインを導入する最大の価値は、属人化をなくし、誰が見ても理解できるカスタマイズを作れるようになること です。
そのため、「プログラミング知識が不要だから大丈夫だろう」と油断してしまうと、逆に複雑な設定を大量に作ってしまい、保守しにくい状態になりかねません。
カスタマインへ移行する際は、次の2点を常に意識しましょう。
- 本当に必要な処理だけを残す（業務整理）
- カスタマインの得意な形で実装し直す（構造の見直し）
この2つを押さえておくことで、「動くけれど誰も触れない」カスタマイズではなく、「理解しやすく、将来の拡張にも強い」カスタマイズに生まれ変わらせることができます。
アールスリーがサポートできること
アールスリーのシステム開発メニュー「キミノマホロ」では、お客様のJavaScriptからカスタマインへの移行をサポートするためのメニューをご用意しています。自分たちだけで移行するのが大変だとお考えの方は、ぜひご相談ください。
カスタマイズを作成した当時とは業務も変わってきているところがあるかもしれません。既存システムを使ってどのような業務を行っているか、どういうところで困っているかを整理します。
お客様の要件に応じて、システム構成に合わせてどういった機能を用意する必要があるかを検討し、必要なもの、不要なものを整理・確認します。
業務の変更によってkintoneの画面側にも変更が必要になるかもしれません。実際にkintoneで画面を作成し、動くものをお見せしながら改善を加えていき、完成度を上げていきます。
「kintoneを使った実現イメージ検討」メニューで作ったアプリに対して、カスタマイズや帳票作成を行います。
お客さまがkintoneアプリを内製化したい場合に、アールスリーが成功に向けてアシストします。
アプリ構成の設計から始め、各アプリの作り方、gusuku Customineのカスタマイズ方法、運用に向けた相談など、内製化に向けた一連の流れをアシストさせて頂きます。
まとめ
JavaScript からカスタマインに移行する目的は、単なる技術の置き換えではありません。
本当に目指すべきなのは、業務に最適な形にカスタマイズを再設計し、保守し続けられる状態を作ること です。
そのためには
- JavaScript の処理をそのまま移すのではなく
- カスタマインに合わせて業務フローとロジックを見直し
- 将来の変更や拡張に強い形に整える
というプロセスが欠かせません。
カスタマイズの属人化に悩んでいる、今後の保守や拡張を見据えた kintone 運用をしたい、という方は、ぜひ「ただ置き換える」だけでなく「最適な形に作り直す」という視点を大切にしてください。
キミノマホロ for kintone
アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。
「キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。
【イ】業務改善の始まり：業務改善の方向性を決める
【ロ】業務改善に必要なkintoneアプリ作成：業務改善を実現するための仕組み（kintoneアプリ）を作る
【ハ】業務改善の実行サポート：業務改善を進める
システム開発グループではkintoneに関するお悩み相談をお受けする「kintone駆け込み相談室」を随時開催しています。kintoneのシステム開発でお悩みの方がいらっしゃいましたらぜひお申し込みください！
必要なものを、必要なだけ。
業務改善の新しいカタチ。
kintoneを活用した業務改善・システム開発サービス
kintoneを活用した業務改善・システム開発サービス
投稿者プロフィール
- システム開発グループ マネージャー
最新の投稿
kintone2025年12月19日JavaScriptカスタマイズをカスタマインに移行する時に大事なこと- kintone2025年11月14日kintone開発の仕様検討って何をするの？
- kintone2025年10月17日業務改善アシストをうまく使っていただくために必要なこと
- kintone2025年9月19日kintoneシステムの保守どうしてますか？
