  |
厳密にいえば使いようはあるが、そういう組織では誤った使われ方しかしない。
「ノーコード/ローコードツールで大規模システムを組む」なんてのは正にそれだ。
もちろん、外注要因ではなく自社組織の人員が一通りノーコード/ローコードツールに習熟しており
プラットフォームの変化に即座に対応できるレベルなら大規模システム組んでもいいかもしれないが、
そんな人員が育つ環境があるなら、より自社ですべてを管理できる他の仕組みでシステムを組む方向に向かう。
そんな環境はもちろんなく、自社組織の人員にスキルが無いから「簡単に使えるツール」を探すわけで。
ただ前述の通り、そんな「ノーコード/ローコードツール」にも使い道はもちろんある。
既存のシステム構築プロジェクトで取りこぼされがちな各部署にたまっているちょっとした不満を解消するのには最適だ。
ちょっとした不満を抱えた各部署の人たちが自分たちの不満を自分たちで解消するための道具として生まれたものだから。
使う人たちが自分たちで作るから、プラットフォームが大幅に変わって既存のシステムに影響が出ても自分たちですぐ対応することが前提だから。
だから本来は、プログラマーこそ、システムエンジニアこそ、「ノーコード/ローコードツール」の積極的な採用を促して、
拾いきれない細かい問題を押し付けるべきなんだが、そういう真っ当な使い方をしている組織はまだあまり多くない。
これから先、この日本という国は労働人口がより一層減っていく。今まで通りの仕事量は今まで通りに回らなくなっていく。
じゃあ、拾いきれない課題はどうするのかというと、今まで提供されるシステムをただ使うだけだった人たちに、
文句をシステム担当に言うだけだった人たちに、自分たちの文句を自分たちで解決してもらうしかない。
現状の「ノーコード/ローコードツール導入プロジェクト」のうち、どれだけの割合でそれが行われているんだろうか。
何度も書くが、基本的に「ノーコード/ローコードツール導入」は自分たちで作ることが前提だ。
唯一の例外は「発注側がそのツールでのアプリ制作に習熟しているが、自分たちで作る余裕がないので外注する」場合ぐらいだ。
成果物をうけとった後自分たちだけでメンテできる自信があるなら、外注も問題ないと思う。
しかしながら、アプリ制作と導入後の運用も丸投げするようなプロジェクトの場合、
発注側、受注側両方共にプラットフォームの変化に振り回される未来しかない。
大規模な変化が来ないことを神に祈っても無駄だが、祈ることぐらいしか出来ないので祈ってもいいと思う。
「ノーコード/ローコードツール」の導入を検討している組織は、自分たちが変わる覚悟を持とう。
18
