ノーコード・ローコード外注の落とし穴

開発会社との打ち合わせで「フルスクラッチだと予算的に厳しいので、ノーコード・ローコードで作りましょう」と提案された。費用が抑えられ、開発期間も短いと聞いて前向きな気持ちになったものの、契約書を前にしてふと不安がよぎる——「これは普通のシステム開発の発注と、契約の中身も進め方も同じでいいのだろうか」。ノーコード・ローコードという言葉は知っていても、それを「外注する」場合に何が変わるのかは、実はあまり語られていません。

この記事は、開発会社にノーコード・ローコードツールでの構築を依頼しようとしている担当者に向けて書きました。自分でツールを操作するのではなく、あくまで「開発会社に発注する」という外注の文脈に焦点を当てています。フルスクラッチ発注との違いを整理したうえで、契約・見積もり・検収の各段階で見落としやすい落とし穴と、事前に確認しておくべき点を解説します。

結論を先に言うと、ノーコード・ローコードでの外注は「安くて早い」というメリットの裏側に、フルスクラッチとは異なる種類の注意点を抱えています。特に「ツールのライセンス費用が誰の負担か」「作ったアプリの権利関係がどうなるか」「開発会社が撤退したときにどうなるか」という3点は、フルスクラッチの契約書にはあまり登場しない、ノーコード・ローコード特有の論点です。この記事では、これらを中心に、発注前に確認すべきことを一つずつ整理していきます。

この記事で分かること

ノーコード・ローコードは、プログラミングをほとんど、または全く書かずにアプリや業務システムを作れる開発手法です。開発会社がこの手法を使って構築を請け負う場合、フルスクラッチ発注とは異なる論点がいくつも発生します。この記事では、次の流れで整理します。

• ノーコード・ローコードでの外注が、フルスクラッチ発注と何が違うのか
• 「安い・早い」の裏側にある構造的な落とし穴
• ツールのライセンス費用・アカウントの所有権をめぐる注意点
• 契約形態(請負か準委任か)の選び方
• 見積書で確認すべきポイント
• 開発会社の見極め方(ノーコード案件特有の視点)
• 検収・納品時に確認すべきこと
• 開発会社が撤退・倒産した場合のリスクと備え方

すでに自分でノーコードツールを操作して業務を置き換える方法に関心がある場合は、別記事「ノーコードツールでExcel業務を置き換える選択肢比較」で解説していますので、そちらをご覧ください。また、ノーコードツールにAI機能を組み合わせる話については「ノーコード×AIでできる業務自動化」で扱っています。本記事は、それらとは異なり「開発会社に発注してノーコード・ローコードで作ってもらう」場面に絞った内容です。

ノーコード・ローコード外注は何が違うのか:フルスクラッチとの比較

まず整理しておきたいのは、ノーコード・ローコードでの外注が、フルスクラッチ発注の「安い版」ではなく、いくつかの点で構造そのものが異なるという点です。

フルスクラッチ発注では、開発会社は要件定義から設計・実装・テストまで、すべてを自社の技術とコードでゼロから組み立てます。納品されるのはソースコード一式であり、動作環境も基本的に自由に選べます。

一方、ノーコード・ローコードでの外注は、開発会社が「Salesforce」「kintone」「Microsoft Power Platform」といった特定のプラットフォーム上で、既存の部品(パーツ)を組み合わせてアプリを組み立てる方式です。開発会社が作り込むのは、あくまでそのプラットフォームの上に乗る「設定」や「構成」であり、プラットフォームそのものは開発会社の資産ではありません。

この違いは、次の表のような形で発注者側の実務に跳ね返ってきます。

この表からも分かる通り、ノーコード・ローコード外注では「開発会社が何を作ったか」だけでなく、「そのアプリがどのプラットフォームのアカウント上で、誰の名義で動いているか」という論点が新たに加わります。これがフルスクラッチ発注にはない、ノーコード・ローコード外注特有の落とし穴の出発点になります。

具体的な場面で考えてみます。たとえば「取引先ごとの案件進捗を管理する社内アプリ」を、開発会社にkintoneで構築してもらったとします。フルスクラッチであれば、納品後は自社のサーバー(あるいは自社契約のクラウド環境)の上でシステムが動き、開発会社との関係が切れても、システム自体は動き続けます。一方、kintoneで構築した場合、そのアプリはkintoneというプラットフォームのアカウント契約が続いている限りでしか動きません。契約が誰の名義になっているか次第で、開発会社との関係が切れたときに何が起きるかがまったく変わってくる、という違いがここに表れています。

この違いを理解しないまま「フルスクラッチと同じ感覚」で発注してしまうと、契約書のひな形もフルスクラッチ向けのものをそのまま流用してしまい、プラットフォームの存在を前提とした条項が抜け落ちる、という事態が起こりがちです。ノーコード・ローコードの外注を検討し始めた時点で、まずはこの「第三者のプラットフォームが間に入る」という構造を意識しておくことが、以降の落とし穴を理解する土台になります。

「安い・早い」の裏側にある構造的な落とし穴

ノーコード・ローコードでの外注が選ばれる最大の理由は、費用と期間の見通しが立てやすいことです。既存の部品を組み合わせるため、フルスクラッチのようにゼロから設計・実装するよりも作業量が少なく、結果として開発会社への支払額も抑えられる傾向があります。この点自体は事実であり、否定するものではありません。

しかし、この「安い・早い」という印象だけで発注を決めてしまうと、次のような落とし穴に気づかないまま契約してしまうことがあります。

• プラットフォームの月額利用料が、開発会社への支払いとは別に、継続的にかかり続ける(初期の開発費だけを見て予算化してしまい、後から運用コストが想定より膨らむ)
• プラットフォームの機能制限にぶつかったとき、フルスクラッチのように「作り込んで解決する」ことができない場合がある(要件が複雑化すると、途中で行き詰まる)
• 開発会社独自の「テンプレート」「フレームワーク」を使われている場合、そのプラットフォームの標準機能だけでは同じものを再現できず、実質的にその開発会社への依存が生まれる
• 納品後の軽微な変更(項目追加や画面のレイアウト変更など)を、発注者側で本当に自分たちだけで行えるのか、契約時の説明と実態がずれていることがある

実務上の視点: 「ノーコードだから発注者側でも簡単に触れる」という説明を営業段階で受けたとしても、実際に納品されたアプリの構造が複雑に組み上げられていると、結局は開発会社に頼らないと変更できない状態になることがあります。この状態は、フルスクラッチのベンダーロックインとよく似た構図です。ベンダーロックインは特定の開発会社やツールへの依存度が高まりすぎて、乗り換えが困難になっている状態を指しますが、ノーコード・ローコードの外注でも、プラットフォームの選定や設定の複雑さ次第で同じ状態に陥ります。

このように、「安い・早い」というメリットは事実である一方、それを実現するために「何を発注者側が引き受けることになるのか」を発注前に確認しておかないと、後から想定外のコストや制約に直面することになります。

落とし穴1: ツールのライセンス費用は誰が、どのアカウントで契約するのか

ノーコード・ローコード外注で最初に確認すべきなのが、プラットフォームの利用料契約の名義です。ここには主に2つのパターンがあります。

パターンA: 発注者(自社)が直接プラットフォームと契約する 自社名義でプラットフォームのアカウントを開設し、その利用料を自社が直接プラットフォーム提供元に支払う形です。開発会社は、そのアカウント上でアプリを構築する作業だけを請け負います。

パターンB: 開発会社がプラットフォームと契約し、発注者はその開発会社に利用料相当額を支払う 開発会社が保有・管理するプラットフォームのアカウント上でアプリを構築し、発注者はその利用料を、開発会社への支払いの一部として(あるいは別立てで)支払う形です。

この2つは、一見すると支払う金額に大きな差がないように見えても、実務上の意味が大きく異なります。

• パターンAであれば、開発会社との契約を終了しても、プラットフォームのアカウントとその中のデータ・設定は自社の手元に残ります。別の開発会社に運用・保守を引き継ぐことも技術的には可能です。
• パターンBの場合、開発会社との契約を終了すると、アプリが動いているアカウントごと失う可能性があります。「開発会社を変えたい」と思ったときに、それまで運用してきたアプリとデータをそのまま引き継げない事態が起こり得ます。

• 契約前に「プラットフォームのアカウントは誰の名義で契約するのか」を明確に確認する
• パターンBを提案された場合は、それを選ぶ理由(初期設定の簡便さなど)と、将来の乗り換え時にどうなるかを開発会社に確認する
• 可能であれば、自社名義のアカウントを用意したうえで発注する(パターンA)ことを基本方針とする

この論点は、データポータビリティの考え方とも重なります。ノーコード・ローコードで構築したアプリであっても、自社のデータをいつでも自社の手元に持ち出せる状態を保っておくことが、将来の選択肢を狭めないための基本になります。

落とし穴2: 作ったアプリ・設定の「権利」は誰にあるのか

フルスクラッチ発注では、納品されたソースコードの著作権が発注者に帰属するのか、開発会社に留保されるのかが、契約書上の重要な論点になります。ノーコード・ローコード外注でも、これに相当する論点が存在しますが、その中身は少し異なります。

ノーコード・ローコードでは「ソースコード」そのものが存在しない(あるいは、あってもプラットフォームが自動生成する内部的なものに過ぎない)ことが多く、代わりに「アプリの設定・構成」「業務フローの定義」「画面レイアウト」といったものが、実質的な成果物になります。この成果物の権利をめぐって、次のような点を契約時に確認しておく必要があります。

• 開発会社が構築した設定・構成一式を、自社が自由に閲覧・編集・複製できる権利があるかどうか
• 開発会社が独自に作成した「テンプレート」「共通部品」を、他の開発会社が触れる形で開示してもらえるかどうか(開発会社によっては、自社のノウハウとして開示を渋る場合がある)
• 契約終了時に、設定・構成一式のエクスポート(書き出し)や引き継ぎ資料の提供を、追加費用なしで受けられるかどうか

実務上の視点: フルスクラッチにおける契約不適合責任や著作権の帰属条項に相当する内容を、ノーコード・ローコードの契約書でも同様に定めておくべきです。ただし、成果物が「コード」ではなく「設定・構成」であるため、契約書の文言をそのまま流用すると実態と合わない場合があります。「本契約における成果物とは、プラットフォーム上に構築されたアプリの設定・構成一式、および関連するドキュメントを指す」といった形で、成果物の定義を具体的に書き込んでもらうことが望ましいです。

これらを曖昧にしたまま契約すると、後になって「開発会社に見せてもらった設定画面はあるが、それをそのまま別の担当者が引き継げる状態か分からない」という事態に陥りやすくなります。特にひとり情シスや総務兼任の担当者は、自分が異動・退職した後の引き継ぎも見据えて、この点を初期段階で確認しておく価値があります。

落とし穴3: 契約形態は請負か準委任か

システム開発の契約形態には、大きく分けて請負契約と準委任契約があります。この選び方も、ノーコード・ローコード外注ならではの注意点があります。

請負契約は、決められた成果物の完成を約束する契約です。フルスクラッチのように要件がある程度固まっている開発であれば、請負契約になじみやすいとされています。一方、準委任契約は成果物の完成ではなく、業務の遂行そのものを目的とする契約で、仕様が固まりきっていない開発や、継続的な改善が前提の開発でよく使われます。

ノーコード・ローコードでの外注は、次のような理由から準委任契約が選ばれるケースが少なくありません。

• プラットフォームの標準機能を組み合わせる性質上、「完成」の定義があいまいになりやすい(どこまで作り込めば完成なのかが、フルスクラッチほど明確に線引きしにくい)
• 実際に画面を触りながら「ここはこう変えてほしい」という細かい調整が発生しやすく、最初から厳密な仕様書を固めきれないまま進行することが多い
• 短期間・低コストである分、詳細な要件定義工程を省略し、プロトタイプを見ながら進める(アジャイル的な)進め方を採用する開発会社が多い

このこと自体は悪いことではありませんが、準委任契約は「完成の保証」がない契約形態である点を理解しておく必要があります。請負契約であれば、完成しなければ代金を支払わない(あるいは修補を求める)という交渉力が発注者側にありますが、準委任契約では、開発会社が定められた業務を遂行してさえいれば、期待した成果物が出来上がらなくても契約上の義務は果たされたことになる場合があります。

• 「小さく試しながら進めたい」「要件が固まりきっていない」場合は準委任契約が合理的だが、その分「完成の保証がない」ことを理解して発注する
• 途中まで準委任契約で進め、要件が固まった段階で請負契約に切り替える、という2段階の進め方を開発会社に相談してみる
• どちらの契約形態でも、進捗確認の頻度・報告方法を契約書または覚書に明記しておく

請負契約と準委任契約の違いについては、別記事「請負契約と準委任契約の違い」でさらに詳しく解説しています。

見積書で確認すべきポイント

ノーコード・ローコード外注の見積書は、フルスクラッチの見積書と項目立てが似ていても、中身の意味が異なる箇所があります。見積書を受け取ったら、次の点を確認してください。

プラットフォームの利用料が、見積もりの中に含まれているか、別立てになっているか。 初期費用の合計だけを見て「安い」と判断すると、翌月から発生する月額利用料に気づかず、年間の総コストで想定より高くつくことがあります。

「構築費用」の中に、テンプレートの流用がどの程度含まれているか。 開発会社が過去の案件で作った共通テンプレートをそのまま流用する場合、ゼロから設計する場合と比べて工数(作業量)は少なくなります。これ自体は効率的で悪いことではありませんが、その分の費用が適切に反映されているか、逆に流用部分にまで過大な設計費用が計上されていないかを確認する価値はあります。

保守・運用フェーズの費用感が、見積もりに含まれているか。 ノーコード・ローコードのプラットフォームは、提供元の都合でアップデートされることがあり、それに伴って画面の一部が動かなくなる、といったことも起こり得ます。納品後の保守対応が、見積もりの範囲に含まれているのか、別途契約が必要なのかを確認しておきます。

「ライセンス数」に応じた費用体系になっていないか。 多くのプラットフォームは、利用するユーザー数(アカウント数)に応じて料金が変動する体系を採っています。見積もり時点の利用人数だけで計算されていると、将来的に利用者が増えたときの費用増を見落としがちです。「あと何人増えたら、いくら費用が上がるのか」を発注前に確認しておくと、後からの想定外を防げます。

初期の「構築費用」と、その後の「カスタマイズ費用」の境界がどこにあるか。 ノーコード・ローコードは、納品後も画面の項目を追加したり、通知のルールを変えたりといった軽微な変更が発生しやすい開発方式です。この軽微な変更が、当初の契約に含まれる範囲なのか、その都度追加費用が発生する範囲なのかが見積書に明記されていないと、納品直後から「これは追加費用です」という説明が続き、想定より支払いが膨らむことがあります。

引用: 見積書全体の読み方(工数・単価・バッファの考え方)については、別記事「システム開発の見積書、この内訳の見方で損を防ぐ」で解説しています。本記事で挙げたノーコード特有の確認点は、その一般的な見方に上乗せして確認してください。

開発会社の見極め方:ノーコード案件特有の視点

開発会社の見極め方の基本(実績・対応の丁寧さなど)は、フルスクラッチ発注と共通する部分が多くあります。それに加えて、ノーコード・ローコード案件では次のような視点も確認しておくとよいでしょう。

• そのプラットフォームの「認定パートナー」や公式の技術者資格を保有しているか。 多くの主要プラットフォームには、開発会社向けの認定制度が用意されています。必須条件ではありませんが、プラットフォームへの理解度を測る一つの目安になります
• 過去の構築実績を、実際の画面や設定を見せてもらいながら確認できるか。 フルスクラッチと違い、ノーコード・ローコードは「どこまでプラットフォームの標準機能で、どこから独自に作り込んだのか」の境界が分かりにくいため、実物を見せてもらうことで開発会社の技術力を判断しやすくなります
• 「このプラットフォームでは対応できません」と、正直に言ってくれるか。 ノーコード・ローコードには構造的な制約があります。無理に作り込もうとせず、「この要件はこのプラットフォームの範囲を超えているので、フルスクラッチや他の方法を検討したほうがよい」と提案してくれる開発会社は、中立的な視点を持っている可能性が高いといえます

開発会社の選び方全般については、別記事「開発会社の選び方: 規模別・得意分野別の見極め」もあわせてご覧ください。また、契約前に見ておきたい危険なサインについては「危険な開発会社のサイン10選」でまとめています。

検収・納品時に確認すべきこと

検収の段階でも、ノーコード・ローコード外注ならではの確認事項があります。フルスクラッチであれば、仕様書通りに動作するかをテストして確認しますが、ノーコード・ローコードでは、次の点も合わせて確認してください。

• 発注者側のアカウントで、実際にログインして操作できる状態になっているか(開発会社のテスト用アカウントのままになっていないか)
• 管理者権限が、発注者側の担当者に正しく付与されているか
• 設定・構成の一覧、および簡単な操作マニュアルが、追加費用なしで提供されるか
• 想定していた業務フロー(申請から承認まで、など)を、実際に一連の流れで操作して確認できたか

これらは検収書にサインする前に、実際に操作しながら確認することをおすすめします。書面上のチェックリストだけで判断すると、権限設定の不備やアカウントの帰属といった、後から気づきにくい問題を見落とすことがあります。

開発会社が撤退・倒産した場合のリスクと備え方

最後に、あまり考えたくないものの、確認しておくべき論点です。開発会社が事業を縮小・撤退したり、万一倒産したりした場合、ノーコード・ローコードで構築したアプリはどうなるのでしょうか。

これは「落とし穴1」で触れたプラットフォームのアカウント名義の話に直結します。

• 自社名義のアカウントで運用していた場合(パターンA)、開発会社がいなくなっても、アプリと設定はそのまま自社の手元に残ります。別の開発会社に運用・保守を依頼することも、技術的なハードルはあるものの可能です
• 開発会社名義のアカウントで運用していた場合(パターンB)、開発会社の連絡が取れなくなると、最悪の場合アプリそのものにアクセスできなくなるリスクがあります

このリスクへの備えとして、次のような対応が考えられます。

• 発注段階でパターンA(自社名義のアカウント)を基本方針として交渉する
• パターンBを選ばざるを得ない場合は、契約書に「契約終了時・開発会社の事業継続が困難になった場合の、データエクスポートとアカウント引き継ぎに関する条項」を盛り込んでもらう
• 定期的に(半年に1回など)、設定・構成の書き出しやバックアップを取得できる状態にしておく

こうした備えは、ノーコード・ローコードに限らず、フルスクラッチ発注を含むすべての外注に共通するベンダーロックイン対策の一環でもあります。開発会社との関係が良好なうちに確認しておくことが、いざというときの選択肢を残すことにつながります。ベンダーロックインの典型パターンと脱出の考え方全般については、別記事「ベンダーロックインとは？中小企業が陥る典型パターン」で詳しく整理していますので、あわせて確認しておくことをおすすめします。

それでもノーコード・ローコード外注が向いている理由

ここまで落とし穴を中心に解説してきましたが、これはノーコード・ローコードでの外注を否定するものではありません。これらの注意点を踏まえたうえで契約すれば、フルスクラッチと比べて次のようなメリットを享受できます。

• 短期間で業務システムを立ち上げられる
• 初期費用を抑えやすい
• プラットフォームの標準機能に沿っている分、開発会社が変わっても他社が引き継ぎやすい素地がある(自社名義のアカウントであれば)
• 小さく始めて、業務に合わせて機能を追加していく進め方がしやすい

特に、要件がまだ固まりきっていない、あるいは予算に制約がある場合、いきなりフルスクラッチで大きく発注するのではなく、ノーコード・ローコードで小さく始めてみるという判断は合理的です。この考え方は、PoC（概念実証）的な発注の考え方とも重なります。

相見積もりを取るときに意識したいこと

ノーコード・ローコード外注でも、複数の開発会社から相見積もりを取ることの重要性はフルスクラッチと変わりません。ただし、比較の視点に一つ加えるべき点があります。

フルスクラッチの相見積もりでは、各社の提示する工数や単価を横並びで比較すれば、ある程度の妥当性を判断できます。ノーコード・ローコードの相見積もりでは、それに加えて「各社が前提としているプラットフォームが同じかどうか」を確認する必要があります。A社はkintoneを前提に、B社はMicrosoft Power Platformを前提に見積もりを出してきた場合、単純に金額だけを比較しても意味がありません。それぞれのプラットフォームの月額利用料、機能の制約、自社の既存システム(Microsoft 365を使っているか、Googleワークスペースを使っているかなど)との相性まで含めて比較する必要があります。

• 各社にどのプラットフォームを前提にしているかを明示してもらう
• プラットフォームが異なる場合は、月額利用料も含めた数年単位の総コストで比較する
• 同じプラットフォームを前提にしている会社が複数あれば、その会社同士でまず比較し、構築費用の妥当性を見極める
• 自社ですでに契約しているMicrosoft 365やGoogleワークスペースがあれば、それと親和性の高いプラットフォーム(前者ならPower Platform、後者ならGoogle AppSheetなど)を前提にした提案から優先的に検討する

このように、ノーコード・ローコードの相見積もりは「金額の比較」の前に「前提となるプラットフォームの比較」という一段階が加わる点を意識しておくと、より的確な判断がしやすくなります。相見積もりの取り方全般については、別記事「相見積もりの取り方と比較の観点」もあわせてご覧ください。

発注前チェックリスト

ここまでの内容を、発注前に確認するチェックリストとしてまとめます。

• プラットフォームのアカウントは、自社名義と開発会社名義のどちらで契約するのか確認したか
• 相見積もりを取る際、各社が前提とするプラットフォームを明示してもらい、月額利用料まで含めた総コストで比較したか
• プラットフォームの月額・年額利用料が、見積もりに含まれているか、別立てなのかを確認したか
• 成果物(設定・構成一式)の権利関係、および契約終了時のエクスポート可否を確認したか
• 契約形態(請負か準委任か)を理解したうえで、完成の保証があるかどうかを把握しているか
• 開発会社が、そのプラットフォームの要件的な限界を正直に説明してくれるか確認したか
• 検収時に、発注者側のアカウントで実際に操作して確認する予定を組んでいるか
• 開発会社が撤退・倒産した場合の対応(データ引き継ぎ等)について、契約書や覚書に触れられているか

すべてに「確認済み」と答えられる状態で契約に進めれば、ノーコード・ローコード外注特有のトラブルの多くは事前に回避できます。

まとめ

ノーコード・ローコードでの外注は、フルスクラッチ発注と比べて「安く・早く」システムを立ち上げられる有力な選択肢です。ただし、それは「フルスクラッチの縮小版」ではなく、プラットフォームという第三者の存在を前提にした、構造の異なる発注方式です。ライセンス費用の負担者、成果物(設定・構成)の権利関係、契約形態、開発会社が撤退した場合の備え——これらはフルスクラッチの発注ではあまり意識されない、ノーコード・ローコード特有の論点です。

契約前にこれらを一つずつ確認しておけば、「安さ」と「早さ」というメリットを、後からのトラブルに変えることなく活かせます。逆にこれらを確認しないまま発注すると、フルスクラッチとは違う形のベンダーロックインに陥るリスクが残ります。

外注全体の準備・流れをまだ整理できていない場合は、次の記事もあわせてご覧ください。社内での準備の進め方から、外注全体の流れを解説しています。