ノーコード開発（kintone）の限界と汎用性：システム屋が直面するジレンマ

お客様の社内システムのリニューアルや新規開発をお手伝いする中で
近年、ノーコードツール（kintone系）への開発サポートにシフトチェンジしてきました。

その背景には、オリジナル開発システムの維持コストや追加要望への対応の難しさ
リニューアルの頓挫、そして過去のしがらみによるシステム複雑化といった問題があります。

これらの問題は一企業に限らず、多くの企業が直面しており、その対応策の一つとして
ノーコード開発システムが注目されています。

ノーコード開発は、プログラミング言語を使用せずに画面操作のみでアプリケーションや
Webサービスを開発する手法であり、プログラミング知識不要、短期間での開発、IT人材不足解消
といったメリットがあります。

弊社も現在では開発案件をkintoneに全振りし、社員教育を行いながらお客様と共に開発を進めています。
システム屋の立場としても、ノーコード系ツール（主にkintone）は良くできており
人気があるのは理解できます。

しかし、現場に入ってお客様と一緒に開発（リニューアル）を進める中で
いくつかの課題も見えてきました。

汎用性と現場ニーズのせめぎ合い

システム屋としては、属人化を排除し、汎用性があり継承できる仕組みを提案したいと考えています。
一方、現場（ユーザー）としては、汎用性では譲れない部分があり、結果としてオリジナル仕様が
残ってしまうことがあります。

「仕組みとして譲れない現場意見 vs できる限り汎用性に舵切りして継承性を担保」

この相反する内容に日々悩まされています。

ユーザーの立場からは
「ユーザーニーズに応えられない仕組みはおかしい」
「現場の運用を変えるのは難しい」
「汎用品は現場の意見を尊重していない」
といった声が聞こえます。

一方、汎用化を推進したい立場からは
「属人化を可能な限りなくすことが将来に向けての使命」
「業務の見直しも含めて汎用化するべき」
「結果的に自社に開発ノウハウが残り資産になる」
といった意見になります。

これはまさに「現場改善 vs 未来思考」との並行線の議論であり、最終的にはパワーゲーム
（お金を出す方が優位）になってしまうこともあります。

これは非常に悩ましい問題であり、「結果は同じでも運用が異なる」というジレンマに陥っています。

理想型としては、基幹部分は汎用的なツールに統一し
細かなユーザーニーズには作り込み（VBAマクロ）で対応することが考えられます。

しかし、「今までできていたもの（オリジナル開発システム）がノーコード系（kintone）になって
機能抑制されるのは納得できない」という声も気になります。

現在の問題（課題）から脱皮するための新テクノロジー（ノーコード開発）の活用において、
ユーザー運用面での対応のためにオリジナル部分が残り、立場の違いで矛盾が生じています。

この矛盾を解消するための折衷案としては、

・割は汎用品に任せて、痒い所に手が届く残り部分に作り込みを残す
・ノーコード側に痒い所に手の届くプラグイン（有料、無料）で対応する
といった方法が考えられます。

汎用性という言葉には一見矛盾や誤解もあります。ノーコード系での開発システムは、自社オリジナルの
方向性だけでなく、他社でも同様に使えるような仕組みを作ることです。
例えば、各行政の仕組みはユーザーでの共通化が必要であり、銀行の仕組みも銀行独自ではなくユーザー
目線で共通化されるべきです。

閉ざされた世界（一企業内）だけの議論での仕組み開発には明確な解決策はないのかもしれません。
この問題について、皆様と一緒に議論させて頂ければ幸いです。