ノーコード・ローコード開発者のフリーランスがつまずきやすい点と対策

フリーランスのノーコード・ローコード開発者がつまずきやすいのは、完成と修正の範囲があいまいなまま作り始めること、「すぐ作れる」ことに押されて要望を受けすぎること、標準の機能で足りない部分の扱い、ツールの契約の名義と費用の負担です。どれも、作る作業が速く、目に見える形になりやすいこの職種ならではの起こり方をします。

対策の基本は、作る前に範囲と完成の形を言葉にし、作った後に誰が直すかまで決めておくことです。この記事では、契約・現場・技術・お金の順に、よく起きる場面と対策を整理します。契約前に確かめる項目の一覧は案件の選び方の記事で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

「完成」の定義がないまま請負で受ける

アプリを作って納める請負の契約では、何をもって完成とするかが報酬の受け取りに直結します。ところがノーコード・ローコードの案件は、画面を見ながら要望が変わりやすく、「使ってみたら違った」という声で手直しが続くことがあります。完成の条件が契約に書かれていないと、どこで区切ればよいかが分からなくなります。

対策：請負で受けるなら、作るアプリの数と主な機能、受け入れの確認の方法、確認の後に直す範囲を、参画前に言葉で決めておきます。要望が動きやすい案件は、稼働時間で報酬が決まる準委任のほうが合う場合もあります。違いは準委任契約と請負契約の違い、契約に合わない点が見つかったときの扱いは契約不適合責任の記事をご覧ください。

契約書の「業務改善支援」と現場の期待がずれる

契約書には「業務アプリの構築支援」とだけ書かれ、現場では業務の聞き取り、マニュアルの作成、利用者への説明会、問い合わせへの対応まで期待されていた、という食い違いはよく起きます。フリーランス法では、業務を委託したときに業務の内容や報酬の額、支払期日などを書面やメールで直ちに明示することになっています（2026年10月時点、公正取引委員会の案内による）。明示の中身は取引条件の明示の記事で解説しています。

対策：自分が担う成果物（アプリ、設計の記録、手順書など）と、担わないもの（利用者からの日々の問い合わせ、データの入力作業など）を参画前に確かめます。範囲の外の依頼が来たときは業務範囲が変わったときの記事と追加の依頼の断り方を参考にしてください。

作ったアプリやコードの扱いを決めていない

拡張のために書いたコードや自作のプラグインを、別の案件でも使い回したい場合、契約の権利の定めによってはそれができないことがあります。逆に、発注側が「納品後は自分たちで直したい」と考えているのに、権利や中身の扱いが決まっていないと、後から揉めることがあります。考え方は著作権の記事をご覧ください。

現場でのつまずき

「すぐできます」で要望を受けすぎる

ノーコード・ローコードは、その場で画面を直して見せられるのが強みです。ただ、打ち合わせのたびに小さな要望を受けて直していると、項目や一覧が増え、アプリの構造が少しずつ崩れていきます。利用者ごとの細かな要望に合わせた結果、かえって使いにくくなることもあります。

対策：要望はその場で直さず、一覧にして、業務の目的に照らして優先度を決めてから反映します。「すぐ直せる」と「直すべき」を分けて話すことが、作り手としての信頼につながります。

業務部門と情報システム部門の板挟みになる

業務部門は早く使いたい、情報システム部門は権限やデータの管理を整えたい、と考えが分かれることがあります。外部の作り手は、どちらの言い分も分かる立場にいるため、間に挟まれて判断を求められがちです。

対策：参画の初期に、アプリの作成や変更を最終的に承認するのは誰か、権限や外部連携の判断は誰がするかを確かめておきます。自分は選択肢と影響を示す役に回り、決めるのは発注側の責任者、という線を引いておくと動きやすくなります。

作って終わりになり、使われない

アプリを公開しても、現場の手順が変わらなければ、表計算や紙での管理が残り続けます。利用が広がらないと、作り手の評価も上がりません。

対策：公開の前に、誰がいつから使い始めるか、古いやり方をいつやめるかを、業務部門の責任者と決めておきます。公開後しばらくは、使われ方を見て直す期間を計画に入れておくと安心です。

技術でのつまずき

標準の機能の限界に、後から気づく

設計を進めてから、「この集計は標準の機能ではできない」「この件数だと動きが重い」と分かることがあります。そこからコードや外部のサービスで補おうとすると、予定外の作業が増え、保守できる人も限られてしまいます。

対策：要件を聞いた段階で、標準の機能で済む部分、プラグインや設定で補う部分、コードが要る部分を分けて示します。kintone の場合、開発者向けサイトで JavaScript API や REST API の仕様に加え、カスタマイズの際に守るコーディングガイドラインが公開されています（2026年10月時点）。案件の前に目を通しておくと、どこからがコードの領域かを説明しやすくなります。

自分しか直せない仕組みを残す

拡張のコードや複雑な処理の流れを、記録を残さずに作ると、契約が終わった後に誰も直せなくなります。発注側にとっては大きな負担になり、次の案件の紹介にも響きます。

対策：アプリの分け方とつながり、拡張した部分の目的と場所、変更するときの手順を、引き継ぐ相手が読める形で残します。作りながら少しずつ書いておくと、最後にまとめて書くより負担が小さくなります。

個人情報や権限の設定を甘く見る

顧客や従業員の情報を扱うアプリで、閲覧の権限が広すぎたり、外部のサービスとの連携でデータの流れ先を確かめていなかったりすると、大きな問題になります。発注側から預かったデータの扱いは、契約上の責任にもかかわります。考え方は個人情報の取り扱いを任されたときの記事をご覧ください。

お金でのつまずき

ツールの契約名義と費用の負担があいまい

検証のために自分の名義でツールの契約を始めたり、有料のプラグインや外部サービスを立て替えたりしたまま、費用の扱いを決めていないことがあります。契約が終わった後に、アプリやデータが誰の名義の環境にあるのかが分からなくなるおそれもあります。

対策：ツールの契約、有料のプラグイン、外部サービスは、原則として発注側の名義で用意してもらうよう参画前に確かめます。やむを得ず立て替える場合は、精算の方法を書面やメールで残しておきます。

修正の依頼が続き、稼働が報酬に見合わなくなる

請負で受けたあとに小さな修正の依頼が続くと、実際の稼働が見込みを大きく超えることがあります。準委任でも、稼働の上限と超えたときの精算の方法が決まっていないと、同じことが起きます。

対策：修正をどこまで含むかと、超えた場合の扱いを契約で決めておきます。超えそうだと分かった時点で早めに発注側に伝え、追加の契約にするか、範囲を絞るかを相談します。

よくある質問

公開した後に「やっぱり違う」と言われ、修正が終わりません。どうすればよいですか？

まずは、契約で決めた範囲と完成の条件に照らして、どこまでが約束の内側かを整理します。そのうえで、残りの要望を一覧にし、優先度と必要な稼働を示して、追加の契約にするか範囲を絞るかを発注側に判断してもらうのが基本です。契約の解釈に迷う場合は、専門家にご相談ください。

コードが書けないのに、拡張が必要な要件が出てきました。どうすればよいですか？

無理に自分で書こうとせず、標準の機能やプラグインで代わりになる方法がないかを先に探します。それでもコードが要る場合は、その部分を誰が作り、誰が保守するかを発注側と相談し、担当を分けるのが安全です。どこまで身につけるかはスキルの記事を参考にしてください。

発注側の社員に作り方を教える役割まで求められています。引き受けるべきですか？

教える役割は、内製化を目指す案件では価値の大きい仕事です。ただ、作る作業と教える作業の両方を同じ稼働で担うと、どちらも中途半端になりやすくなります。教える範囲と時間を契約に含めるかどうかを確かめたうえで引き受けると、無理なく進められます。