フリーランスとして業務委託の案件を探し、打ち合わせの席に着きました。「OutSystemsで何本アプリを作りましたか」と聞かれると思っていたら、問われたのは「その申請画面の裏で、差し戻しや例外の扱いをどう決めましたか」でした。画面を組んだ記憶は鮮やかなのに、決めた中身は言葉になりません。「ツールが作ってくれた経験と受け取られるのでは」という不安の正体は、ここにあります。OutSystemsの経験は、ツールが作った部分と、自分が決めた部分に分けて話します。この記事では、その分け方と伝え方を順に整理します。

1. OutSystemsの経験が伝わりにくい理由

画面ができあがる速さが、判断の存在を隠す

ローコードの開発では、画面の部品を並べると動くものができあがります。作った本人にとっては大きな仕事でも、外から見ると「ツールが作った」の一言で片づけられやすい面があります。これは書き手の見立てですが、打ち合わせで聞き手が最初に思い浮かべるのは、完成した画面の数や作業の速さでしょう。

ところが、業務アプリの出来を左右するのは画面の数ではありません。申請が差し戻されたとき誰に戻るのか、例外の申請を誰が承認するのか。こうした取り決めは、画面の部品を並べる前に誰かが決めています。決めた人の経験は、完成した画面を眺めても見えてきません。

ツールが担う部分と自分が決めた部分

そこで経験を二つに分けます。画面の部品、コードの生成、配備のように、ツールが肩代わりしてくれる部分が一つ。業務の例外の整理、データの持ち方、外部システムとの連携の境目、誰に何を見せるかという権限のように、人が考えて決めた部分がもう一つです。分け方は書き手の見立てで、OutSystemsの機能の細かな区分を示すものではありません。

図の作成：Remogu編集部。経験の分け方を整理したもので、統計データではありません

右側の項目は、ツールを替えても求められる判断です。左側はツールごとに作法が違うため、別のツールに移ると使えなくなる部分が出てきます。打ち合わせで話す比重を右側に置くと、「ツールが作った」という受け止めから距離を取れます。

この記事の資料の範囲

先に断っておくと、次の節から使う資料は、ローコード一般の話です。OutSystemsにも、フリーランスにも直接触れていません。そのため、OutSystemsに関する記述と案件での受け止められ方は、すべて書き手の見立てとして書きます。資料から言えることと、見立てを混ぜずに読み進められるようにします。

では、現場の側ではローコードがどう受け止められているのでしょうか。まず、公的機関の報告書に載った寄稿から見ていきます。

2. ローコードで現場が自ら業務を変え始めた

すり合わせの力を、モデリング力として見直す寄稿

IPAのソフトウェアモダナイゼーション委員会が2026年3月に公表した2025年度の報告書には、委員の寄稿が掲載されています。この寄稿は、「すり合わせ」を、多様な要求や関係者の視点を整理し、矛盾や例外を含めて構造化していくモデリング力として再評価できる、と述べています¹。報告書に掲載された寄稿の見解であり、IPAや委員会としての結論ではありません。

一方、この寄稿はOutSystemsの経験に触れていません。ただ、例外を含めて業務を構造にする力という言い方は、前の節で見た「自分で決めた部分」とよく重なります。OutSystemsで業務アプリを作ってきた経験をこの言葉で語れるかどうかは、書き手の見立てとしてお伝えします。

現場が仮説検証を繰り返せる環境

同じ寄稿は、生成AIとノーコード・ローコードの進化によって、ユーザー企業の現場が自ら仮説検証を繰り返し、短期間で業務の在り方を変えられる環境を手にし始めている、とも述べています¹。主語は、ユーザー企業の現場です。外部のエンジニアやフリーランスの話ではありません。また、「手にし始めている」という書き方のとおり、すでに広がったという主張でもありません。

この見方に立つと、業務を変える作業の一部は、現場の人が自分でツールを触って進めることになります。そうなると、外から参画するエンジニアに期待される中身も、少しずつ変わってくるはずです。変わる先を考えるには、寄稿が挙げる二つの見方を並べて見ておくと整理しやすくなります。

寄稿が挙げる二つの見方の中身

表1は、寄稿が述べる二つの見方を並べたものです。上の段はエンジニアの側の力の見直し、下の段はユーザー企業の現場の変化で、見ている対象が違います。二つを並べて眺めると、現場が自分で動ける範囲が広がるほど、要求や例外を整理する力の置きどころが目立ってくる、という読み方もできます。もちろん、これは書き手の読み方です。

寄稿が挙げる見方	中身
すり合わせ	多様な要求や関係者の視点を整理し、矛盾や例外を含めて構造化するモデリング力として再評価できる
ローコードの進化	ユーザー企業の現場自らが仮説検証を繰り返し、短期間で業務の在り方を変えられる環境を手にし始めている

ここで注意したいのは、どちらの見方も、特定のツールの経験者が高く評価されると述べているわけではないことです。ツールの名前を使わずに、力と環境の変化を語っています。だからこそ、自分の経験を語るときも、ツール名より中身を先に出す形が合います。

3. 開発の代行から、改善を支える役へ

ソフト企業に求められる役割の移り

同じ寄稿は、これからのソフト企業の役割として、開発の代行だけでなく、ユーザー企業がAIやノーコードを使いこなし、継続的に改善を進めていけるよう支援する伴走者になることを挙げています¹。主語は、ソフト企業です。フリーランス個人の役割を述べたものではありません。この点は、読み違えやすいので繰り返しておきます。

言い換えると、作って渡して終わる関わり方から、現場が使い続けながら直していくことを支える関わり方へ、という流れです。寄稿が見ているのは、納品の瞬間ではなく、その後の改善が続く期間です。

図の作成：Remogu編集部。寄稿の記述を整理したもので、統計データではありません

フリーランスへの当てはめは見立てとして

寄稿の主語はソフト企業ですが、業務委託で参画するフリーランスにも似た場面があるかもしれません。ここからは書き手の見立てです。現場が自らツールを使い、改善を続けていく案件では、画面を作る速さだけでなく、現場が自分で直せる形に整えて渡せるかどうかが話題になりやすいと考えられます。

その場合、打ち合わせで役に立つのは「何本作ったか」より、「現場が直しやすいように何を決めて渡したか」を話せることです。決めた中身が言葉になっていれば、聞き手は改善を支える役を任せたときの姿を思い浮かべやすくなります。ただし、案件によって聞かれる内容は異なるので、あくまで一つの見立てです。

では、ローコードを現場で使う動きは、実際の自治体でどう進んでいるのでしょうか。総務省の事例集に、その一例が載っています。

4. 自治体でもローコードで内製が進む例

大分県別府市の事例

総務省の自治体DX推進参考事例集には、大分県別府市の事例が載っています。この事例では、ローコード・ノーコードツールを活用し、職員の手作りでプレミアム付商品券予約販売システムや避難所運営支援システムを構築したと記されています²。事例集に使ったツールの名前は書かれていないため、特定の製品と結びつけて読むことはできません。

また、これは別府市という1市の事例です。全国の自治体の傾向を示すものではなく、外部のエンジニアが関わったという記述もありません。作ったのは職員自身である点が、この事例の要点です。

市の側の評価

同じ事例では、内製することで、原課の要望をよく聞きながら作成し、都度修正するため、良いものができると記されています²。原課とは、業務を担当する課のことです。これは市の側の評価として書かれたもので、効果を測った数字ではありません。

表2に、事例の項目を整理しました。内製の場では、要望を聞いて直すやり取りが何度も繰り返される様子がうかがえます。

項目	内容
団体	大分県別府市（1市の事例）
作った人	職員（内製）
作ったもの	プレミアム付商品券予約販売システム、避難所運営支援システム
市の評価	原課の要望をよく聞きながら作成・都度修正できる

内製が進むと、業務を整理できる人の経験が問われる

ここからは書き手の見立てです。現場が自分でシステムを作り、要望を聞きながら直していく場では、画面を組む作業そのものより、要望のどこまでを作り、どの例外をどう扱うかという整理が問われやすくなると考えられます。内製が進むほど、そうした整理を経験として語れる人に目が向く場面が増えるのではないか、というのが見立ての中身です。

この事例は、フリーランスの案件を直接示すものではありません。それでも、自分の経験を言葉にするときの視点は借りられます。作ったものの数より、要望を聞いて何を決め、どう直したかを話せるようにしておくのです。そのために、次の節で経験を4つに分けていきます。

5. 棚卸しで分ける4つの経験

ツールを替えても同じ判断が要るか

経験を分ける物差しは、一つあれば足ります。ツールを替えても同じ判断が要るかどうかです。要るなら、その経験は持ち運べます。要らないなら、そのツールの中で完結する作法なので、打ち合わせでは補足にとどめます。これは書き手の見立てで、どの案件でも同じ線引きが通用するという意味ではありません。

たとえば、申請の差し戻し先を決める作業を考えます。別のツールで同じ業務アプリを作る場合でも、誰に戻し、例外をどこで受けるかは決め直しです。一方、画面の部品の並べ方は、ツールごとの作法に合わせて組み直します。前者が持ち運べる経験で、後者は補足として添える部分です。

4つに分けた経験と、伝える言葉

この物差しで残る経験を、4つに分けました。いずれも、ツールを替えても判断が要る領域です。図3には、それぞれを打ち合わせでどう言い表すかを添えています。

図の作成：Remogu編集部。経験の分け方を整理したもので、統計データではありません

4つ目の改善の支えは、第3節で見た「改善を支える役」と、第4節の別府市の事例にある「要望を聞いて都度直す」やり取りに対応します。書き手の見立てとして、現場の要望を受けて何を直し、どんな仕組みで直せるようにしたかは、打ち合わせで具体的に話しやすい材料だと考えています。

案件ごとに書き出して確かめる

棚卸しは、参画してきた案件を一つずつ取り出し、4つの経験のどれに当たる仕事をしたかを書き出すところから始まります。1つの案件に4つとも当てはまらなくてかまいません。当てはまった項目だけを残し、決めた中身を一文で書いてみます。スキル全体の棚卸しの進め方は、フリーランスエンジニアのスキル棚卸しの記事で整理しています。

一文で言えない項目は、当時の仕様の記録ややり取りを見返して、何を決めたかを思い出しておきます。決めた中身が書けて初めて、ツールでの実現を補足として添えられます。4つのうち、権限と情報の扱いには公的機関の資料があるので、次の節で取り上げます。

6. 権限と情報の扱いも経験に数える

IPAの紹介ページが述べるセキュリティリスク

IPAのサイト上の紹介ページによれば、「ローコード・ノーコードツール セキュリティビギナーズガイド」は、利便性の影に情報漏えいに繋がるような重大なセキュリティリスクが潜んでいるとして、ベストプラクティスをまとめたものと紹介されています³。ここで根拠にできるのは、紹介ページの記述までです。ガイドの本文を読んで要約したものではありません。

また、この紹介ページが扱うのは、ローコード・ノーコードツール全般の話です。OutSystemsにも、フリーランスの案件での評価にも触れていません。ガイドの個々の項目をここで説明することもしません。

権限と情報の扱いを棚卸しに入れる

ここからは書き手の見立てです。画面が動くかどうかとは別に、誰にどの情報を見せるかは、作る側が決めた中身です。紹介ページが重大なセキュリティリスクに触れている以上、その判断に関わった経験は、棚卸しの項目に入れておく価値があります。

表3は、権限と情報の扱いを棚卸しするときの項目と、書き方の例です。項目は書き手が考えたもので、ガイドの内容を写したものではありません。

棚卸しの項目	書き方の例
画面とデータの見せ分け	利用者の立場ごとに、見せる画面とデータを分けた経緯
外部連携の認証情報の置き場所	外部システムとつなぐ際の認証情報を、どこに置き、誰が触れるかを決めた経緯
公開範囲の確認	外部に公開する画面や情報の範囲を、公開前に確かめた手順
運用中の権限の見直し	担当替えのあとに、権限を見直した頻度と方法

書くときは、「権限を設定した」で止めず、誰に何を見せないと決めたかまで言葉にします。見せない範囲の決め方は、ツールを替えても同じ判断が要る部分だからです。次の節では、これらの経験を案件の相談でどの順に話すかを整理します。

7. 案件の相談で経験を伝える順番

課題から始めて、ツールは三番目に置く

打ち合わせで経験を話すときは、順番を決めておくと話が崩れません。業務の課題、自分が決めたこと、ツールでの実現、運用後の改善の順です。これは書き手の見立てで、聞き手によって質問の順は変わります。ただ、話の軸を自分が決めた中身に置いておけば、質問が前後しても戻ってこられます。

図の作成：Remogu編集部。話し方の一例で、統計データではありません

ツール名が三番目に来るのは、最初に名前から入ると、聞き手が「ツールが作った経験」という枠で聞き始めやすいと書き手が考えているためです。名前を隠す必要はありません。何を決めたかが先に伝わっていれば、あとから出るツール名は、決めた中身をどう形にしたかの説明として届きます。

冒頭の問いに、順番どおり答える

冒頭の打ち合わせで聞かれた「その申請画面の裏で、差し戻しや例外の扱いをどう決めましたか」にも、この順で答えられます。「（業務の課題）の場面で、（自分が決めたこと）を、現場と話して決めました。ツールでは（実現のしかた）で形にし、運用が始まってからは（直した点）を改めました」という流れです。かっこの中には、自分の案件の中身を入れます。

かっこの中が埋まらない項目があれば、そこが棚卸しで言葉にし切れていなかった部分です。打ち合わせの前にその項目だけ見返しておけば、聞かれたときに詰まる場面を減らせます。

分けて話すという結論

冒頭の場面で答えに詰まったのは、画面を組んだ経験と、決めた中身が一つに溶けていたからでした。分けて持っておけば、聞かれる角度が変わっても、話すものを取り出せます。OutSystemsの経験は、ツールが作った部分と、自分が決めた部分に分けて話します。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。決めた中身を言葉にできたら、リモートで参画できる案件の中から、その経験を活かせる場所を探してみてください。

8. よくある質問

OutSystems以外のローコードの案件でも経験は通じますか

書き手の見立てでは、通じる部分と通じない部分があります。物差しは、ツールを替えても同じ判断が要るかどうかです。例外の整理やデータの持ち方、権限の決め方は、ツールが変わっても決め直しが要るので、持ち運べる経験として話せます。画面の部品の扱いのようにツール固有の作法は、補足として添えるのが現実的です。

コードを書く経験がまだ少なくても、フリーランスの案件は受けられますか

案件によって求められる内容が異なるため、断定はできません。書き手の見立てとして言えるのは、連携や拡張のために自分でコードを書いた部分があれば、ツールが担った部分とは分けて伝えておくと、聞き手が経験の範囲をつかみやすいということです。書いた量を競うより、何のために何を書いたかを話します。

内製化を進める企業の案件では、何を聞かれやすいですか

書き手の見立てでは、現場に何をどう渡したか、現場が直せる形にどう整えたかが聞かれやすいと考えられます。第3節と第4節で見た、現場が自ら改善を続ける流れと重なる論点です。内製化の支援で外部のエンジニアに何が求められるかは、内製化支援の一人目の外部エンジニアの記事で詳しく扱っています。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 ソフトウェアモダナイゼーション委員会「2025年度 ソフトウェアモダナイゼーション委員会報告書」（2026年3月24日・2026年10月確認）
＊2 総務省「自治体DX推進参考事例集」（2026年7月27日・2026年10月確認）
＊3 情報処理推進機構「ローコード・ノーコードツール セキュリティビギナーズガイド」（2025年8月29日・2026年10月確認）