投稿者: 沼田 勇作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「システム開発の闇」という動画を見ました。

動画では、新たに就任した上場企業の社長から、長年にわたるシステム開発費について相談を受けたという事例が紹介されています。

巨額の費用を支払っているにもかかわらず、出来上がったシステムが費用に見合っているように見えない。同じ技術者の月額費用が途中から何倍にも変わっているのに、開発会社が理由を説明できない。最終的には裁判にまで発展した、という内容です。

この事例が第三者によって検証されたものかは分かりません。しかし、動画が提起している問題そのものは、システム開発を発注する企業にとって非常に重要です。

私は、外注そのものが悪いとは考えていません。

外注してはいけないのは、プログラムを書く作業ではなく、「自社にどのようなシステムが必要なのか」を判断する仕事です。

高いか安いかを判断できないことが、最初の問題である

システム開発の見積額だけを見て、高いか安いかを判断することはできません。

同じような画面に見えても、処理するデータ量、利用人数、権限の複雑さ、セキュリティ、障害対策、既存データの移行、外部サービスとの連携、保守範囲によって費用は大きく変わります。

問題は金額そのものではなく、発注企業が「なぜこの金額になるのか」を説明できない状態です。

技術者一人当たりの費用が変わるのであれば、担当範囲、役割、必要な能力、投入時間などの根拠が必要です。開発期間が延びるのであれば、当初の想定と何が変わったのか、どの変更にどれだけの作業が発生したのかを確認できなければなりません。

人月による見積もりが、直ちに悪いわけではありません。

しかし、支払った人月と、完成した機能、確認できる成果物、解決された課題が結びついていなければ、発注企業は人数と期間に対してお金を払い続けるだけになります。

発注者が「何を作るか」を決めなければ、丸投げになる

システム開発会社は、発注企業の業務を最初から知っているわけではありません。

どの情報が会社にとって重要なのか。誰が入力し、誰が確認し、誰が承認するのか。どの出来事によって請求や在庫や会計が変化するのか。間違えたときに、どこまで元へ戻せなければならないのか。

これらは、発注企業側が決めるべきことです。

専門家へ相談しながら決めることはできます。しかし、判断そのものまで開発会社へ預けてしまえば、開発会社が変わるたびに、会社の業務を最初から説明し直すことになります。

IPAも、システム開発の取引構造を透明化するため、各開発段階におけるユーザー企業とITベンダーの責務、仕様、プロジェクト管理方法、検収方法などについて共通理解を持つことを重視しています。情報システム・モデル取引・契約書

システム開発は、発注書を渡して完成を待つ買い物ではありません。

自社の業務を分解し、開発会社と共同で、機械が処理できる形へ変換していく仕事です。

発注企業が最低限保持すべきもの

開発作業を外部へ委託する場合でも、次のものは発注企業側で把握し、継続して利用できる状態にしておく必要があります。

• システムの目的と対象業務
• 用語の定義とデータ構造
• 権限、承認、変更履歴の設計
• 現在の仕様と未完了事項
• ソースコードとリポジトリへのアクセス
• 本番環境、ドメイン、データベース、外部サービスの管理権限
• 成果物の検収条件
• 著作権、利用許諾、改変、再利用に関する契約
• 他社へ保守や開発を引き継ぐための手順

重要なのは、「資料を納品してもらった」という事実ではありません。

担当する開発会社が明日変わっても、自社の判断で運用と開発を継続できるかどうかです。

この状態を作らないまま特定企業へ依存すると、改修のたびに提示された金額を受け入れるしかなくなります。これは技術的な問題というより、経営上の統治の問題です。

お金を払えば、著作権も自動的に移るわけではない

動画では、外注して作られたプログラムの著作権は、基本的に開発会社側へ帰属するという問題も取り上げられています。

ここは、少し丁寧に整理する必要があります。

著作物の制作を外部へ依頼した場合、制作費を支払ったという理由だけで、著作権が自動的に発注者へ移転するわけではありません。文化庁の資料でも、他社へ制作を委託した場合、実際に創作した受注者側が著作者になることが原則として説明されています。文化庁「著作権制度の概要」

ただし、「外注したプログラムは必ず開発会社のものになる」と断定するのも正確ではありません。

著作権をどちらへ帰属させるのか、発注企業がどの範囲で利用・改変・再委託できるのかは、契約で定められます。既存の共通部品、今回新たに作る部分、オープンソースソフトウェア、第三者製品について、権利関係を分けて確認する必要があります。

経済産業省のモデル契約でも、知的財産権の帰属について、契約締結前の提案・見積段階から条件を説明することが重視されています。経済産業省「情報システム・モデル取引・契約書」

契約書に「成果物一式」と書くだけでは不十分です。

ソースコードを受け取れるのか。自社で修正できるのか。別会社へ保守を依頼できるのか。開発会社が事業を停止した場合にどうするのか。これらを契約前に決める必要があります。

内製化とは、社員だけで全コードを書くことではない

動画では、給与計算ソフトのように市販品を使えばよいものと、自社サービスの根幹として自ら作るべきものが区別されています。

この区別は非常に重要です。

メール、給与計算、一般的な会計処理など、企業間で大きな違いがない部分は、実績のある製品を利用した方が合理的です。

一方で、顧客へ提供するサービス、独自の業務手順、価格決定、承認、会社資産を変化させる処理などは、会社の競争力や責任に直接関係します。この部分の設計を外部へ丸投げしてはいけません。

ただし、内製化とは、すべてのコードを社員だけで書くことではありません。

外部の技術者、税理士、社会保険労務士、中小企業診断士などの知見を取り入れながら開発してもよいのです。大切なのは、会社自身がシステムの目的、構造、判断基準を保持し、外部の専門家を選び直せる状態にすることです。

外部へ任せるのは「手」であり、「脳」ではありません。

動くものを早く見せてもらい、重要な処理は改めて設計する

進捗を「現在70％です」という言葉だけで確認してはいけません。

実際に動く画面、登録されたデータ、実行できる処理、テスト結果を小さな単位で確認する必要があります。試作品を早く作り、利用者から意見を集めれば、発注者側も本当に必要な仕様を発見できます。

受付や業務報告の試作であれば、CMSや表計算サービスから始めても構いません。

しかし、会計、請求、在庫、給与、権限、会社資産を変化させる処理は、試作品の延長で本番化してはいけません。要件を整理し、データモデル、承認、取引の一貫性、変更履歴を改めて設計したうえで、人間が把握できるコードとして実装する必要があります。

試作では、動くものを見ながら仕様を発見する。
本番では、会社が責任を持てる構造へ作り直す。

この境界を管理することも、発注企業側の仕事です。

外注してはいけないのは、経営判断である

システムは、単なる業務効率化の道具ではありません。

誰が、いつ、何を行い、その結果として会社の情報や資産がどう変化するのかを決める仕組みです。言い換えれば、会社の脳や神経に近い存在です。

プログラムを書く作業は外注できます。デザインも、テストも、保守も、専門家へ依頼できます。

しかし、なぜその仕組みが必要なのか、何を正しい状態とするのか、どこまでを自社の責任として管理するのかという判断は外注できません。

システム開発の闇を避ける方法は、すべてを社員だけで作ることではありません。

自社のシステムを、自社の言葉で説明できる状態を保つことです。

会社の手は外部から借りてもよい。
会社の脳まで外部へ渡してはいけないのです。