（７月３０日通信）ノーコードを学ぶのが危険なのではない。「ノーコードだけ」を仕事にするのが危険なのだ

「今からノーコードを学ぶのは危険です」という動画を見ました。

動画で挙げられていたのは、ノーコードだけを身につけて仕事にしようとする場合の、三つの問題です。

一つ目は、誰でも扱いやすいため、作業単価が上がりにくいこと。
二つ目は、参入しやすいうえにAIの支援まで加わり、競争相手が増え続けること。
三つ目は、簡単なWebサイトなど、初心者が受けていた案件そのものを、発注者がAIで処理できるようになってきたことです。

この見方には、私もおおむね賛成です。

ただし、危険なのはノーコードそのものではありません。ノーコードツールの操作方法を覚えることと、価値のあるシステムを作れることを、同じだと考えてしまうことが危険なのです。

「誰でも使える」は、ツールとしては長所、職業としては弱点になる

ノーコードツールの最大の長所は、専門の技術者でなくても扱えることです。

ところが、その操作自体を商品にしようとすると、この長所がそのまま弱点になります。依頼者自身でもできる作業であれば、当然ながら高い報酬はつきにくくなります。AIによって操作や制作がさらに簡単になれば、価格競争は一層激しくなるでしょう。

これはノーコードに限った話ではありません。

テンプレートに文字と画像を入れるだけのWeb制作、指示どおりに生成AIへ入力するだけの文章作成、決められた項目を表計算ソフトへ転記するだけの作業も、同じ方向へ進みます。

「そのツールを使える」だけでは、専門性を維持しにくい時代になりました。

それでもノーコードはなくならない

では、ノーコードは不要になるのでしょうか。

私は、むしろ利用範囲は広がると考えています。

CMSの管理画面や表計算ソフト、業務アプリの設定画面も、広い意味では複雑な処理を画面操作で扱えるようにした仕組みです。ノーコードとは、コードが消えた状態ではありません。誰かが書いたコードを、利用者が意識せずに使えるようにした状態です。

この仕組みは、業務の試作に非常に向いています。

まず画面を作り、実際の担当者に触ってもらう。業務報告を入力してもらい、不足している項目や承認の流れを確認する。関係者から「あの項目も必要」「この順番では使いにくい」といった意見を集める。

言葉だけで要件を決めるより、動くものを見ながら仕様を発見する方が早い場面は多くあります。その段階で、CMSや表計算サービスを使うことには大きな意味があります。

つまり、ノーコードは「完成したシステムを作る魔法」ではなく、「業務を見える形にして、必要なシステムを発見する道具」として使えばよいのです。

AI時代に価値が上がるのは、作業ではなく判断である

生成AIは、HTMLやCSSだけでなく、プログラムのコードも書けるようになりました。

その結果、コードを一文字ずつ入力する速さの価値は下がっています。一方で、AIが出したものを読み、目的に照らして正しいかを判断する価値は上がっています。

Webサイトであれば、スマートフォンで崩れないか、表示が遅くないか、入力チェックが機能しているかを判断する必要があります。

業務システムであれば、さらに重要な判断が加わります。

• 誰が、どの情報を見られるのか
• 誰が、どの処理を実行できるのか
• データをどの単位で管理するのか
• 変更前の状態を後から確認できるのか
• 複数の更新を一つの取引として矛盾なく処理できるのか
• エラーが起きたときに、どこまで元へ戻せるのか

画面が動くことと、会社の業務を任せられることは別問題です。

生成AIにコードを書かせることはできます。しかし、会社の資産や責任の境界までAIへ丸投げすることはできません。何を正しい状態とするのかは、会社側が設計しなければならないからです。

試作はノーコード、本番の責任は設計とコードで持つ

私は、ノーコードとコードを対立させる必要はないと考えています。

たとえば、受付、業務報告、アンケート、簡単な進捗確認であれば、CMSで入力画面を作り、表計算サービスへ情報を蓄積するところから始めてもよいでしょう。まず使ってもらい、現実の業務に合う形へ直していけばよいのです。

しかし、その情報を請求、会計、在庫、給与、権限管理などへ結びつける段階では、試作品の延長で作ってはいけません。

会社の資産を変化させる処理では、データの構造、権限、承認、取引の一貫性、変更履歴を整理し、必要に応じて様々なオープン・ソース・ソフトウェア（公開されているソフトウェア）などを使って、人間が把握できるコードとして実装する必要があります。

ノーコードで画面を作りながら仕様を見つける。
コードで業務上の責任と整合性を保証する。

この二段階を分けることが、AI時代の現実的な内製化だと思います。

学ぶべきなのは、ツール名ではなく「境界線」である

今からノーコードを学ぶこと自体が危険なのではありません。

危険なのは、特定のツールの操作方法だけを覚え、そのツールで対応できない問題まで解決できると思い込むことです。

学ぶ際には、少なくとも次の点を意識する必要があります。

• そのツールで安全に扱える業務はどこまでか
• どの段階からデータベースや権限設計が必要になるか
• AIが生成した結果を自分で検証できるか
• 将来ツールを変更するとき、データを取り出せるか
• 自社の業務と会社資産の構造を説明できるか

ノーコードの操作だけを売る人の仕事は、AIによって減るかもしれません。

しかし、現場の業務を理解し、ノーコードで素早く試作し、必要な部分を設計とコードへ移せる人の仕事は、むしろ増えるはずです。

AIとノーコードが省いてくれるのは、制作にかかる手間です。設計者の責任まで省いてくれるわけではありません。

これから学ぶべきなのは、特定のノーコードツールではなく、ノーコードをどこまで使い、どこから先をコードで管理するのかという「境界線」なのです。