ローコード開発入門｜業務アプリを1本作り切る進め方

ノーコードのツールで申請フォームと一覧までは作れた。ところが「申請が承認されたら、次の人に回す」の一手間を足そうとした瞬間、設定する場所が見つからず手が止まる——情報システムを兼任しながら現場の「これをシステム化したい」に応えていると、こういう壁にぶつかります。外注すれば費用と納期が読めず、自分で全部を組むのは無理。結局 Excel に逆戻り、というのもよくある光景です。

この「あと少しのロジック」を足して、外注待ちでも Excel 放置でもなく、自分で業務アプリを作り切る開発スタイルがローコードです。要るのはコードを書く力ではなく、作る業務を1つに絞り、型に沿って組み立てる力です。本講座は「ローコードとは何かを理解し、自分の業務アプリ1本を、データ → 画面 → ロジック → 公開の流れで作り切る」ところに絞ります。ロジックを書かず部品を並べるだけの範囲やノーコードツールの選び方はノーコードツール入門、特定ツールの具体的な画面操作はkintone入門、人手の繰り返し操作そのものの自動化はRPA入門が、それぞれの正本です。本講座はそこには深入りせず、製品横断の「ローコード開発の型」だけを扱います。

この講座を終えると、次の3つができるようになります。ノーコードとローコードの違いと使い分けを自分の業務に当てはめて説明できること、対象業務を1つ選んで業務アプリを1本作り現場に公開できること、そしてローコードで抱える範囲と開発部門へ引き渡すべき範囲の境界を判断できることです。覚えて帰る型は「違いを見極める → データを決める → 画面とロジックを組む → 公開し引き渡す範囲を見極める」。全章を通して、「金額が一定以上なら部長承認に回す」という少しの分岐を含む備品購入申請アプリを1本、ローコードツール（例）で作り切る場面を追いかけます。

ローコードとは何か、ノーコードとどう違うか

ローコードは「部品配置」に少しのロジックを足す開発スタイル

まず言葉を整理します。ノーコードはプログラムコードを一切書かずにシステムを開発すること、ローコードは最小限のプログラムコードで開発することを指します。これらと対比して、従来のプログラミングによる開発をハイコード（フルスクラッチ）と呼びます（出典：IPA DX SQUARE「ノーコード／ローコード開発とは？」）。どちらも、画面・帳票・データベース定義・ワークフローの作成を、あらかじめ用意された部品をマウスで配置する操作で進められるのが共通点です（出典：IPA DX SQUARE）。

違いは「少しのロジックまで踏み込めるか」です。ローコードは本質的にはノーコードと同じくGUIで作りますが、必要に応じて最小限のコードや設定を加えることで、他システムとの連携や機能拡張など、より柔軟で拡張性の高いアプリを作れます（出典：第一生命経済研究所「DXを推進するノーコード/ローコード開発」）。ノーコードで作り始めて「複雑になると詰む」のは、まさにこの境目です。部品を並べるだけで足りるならノーコード、そこに条件分岐・計算・連携という「少しのロジック」が要るならローコードの出番、と覚えてください。

ノーコード・ローコード・フルスクラッチの線引き

3つの位置づけは、求められるスキル・開発コスト・柔軟性のすべてで「ノーコード（低）→ ローコード（中）→ ハイコード（高）」と並びます（出典：IPA DX SQUARE）。フルスクラッチはゼロからコードを書くため必要な機能をすべて盛り込める一方、高度なスキルとコストがかかり、導入までに最短でも1年以上かかることも少なくありません（出典：NTTデータ関西「ローコード開発の基本とメリット・デメリット」）。ローコードやノーコードは、その手書きコードをゼロ〜最小限に抑え、専門知識がなくても短期間・低コストで作れるようにした手法です。ただし、ツールが提供する機能の範囲に制約されるため、何でも作れるわけではありません（出典：NTTデータ関西）。

こうした内製を担うのが市民開発（シチズンデベロッパー）です。市民開発とは、専門的なプログラミングスキルを持たない業務部門の担当者が、ローコード・ノーコードツールを使って業務アプリやプロセスを自ら設計・開発する取り組みを指します（出典：GRANDIT「市民開発とは？」、第一生命経済研究所）。あなたが現場の依頼を受けて自分でアプリを作ろうとしている、その立場がまさに市民開発者です。なお、こうした手法が広がっている背景には市場の拡大があり、国内のローコード/ノーコード開発市場は拡大が続いています（市場規模の金額は出典：ITR調査）。実際の活用状況も、ノーコード/ローコードを活用している日本企業は約21.6%にのぼります（出典：IPA「DX白書2023」）。何をデジタル化・改善するかという見立てそのものはDXの基礎が正本なので、本講座は「改善対象が決まった業務を形にする」実装側に絞ります。

「ローコード＝難しいプログラミング」「何でも作れる」というつまずき

ここでのつまずきは2つです。1つは「ローコード＝難しいプログラミング」と身構えること。実際は部品配置が土台で、足すのは少しのロジックだけです。もう1つは逆に「ローコードなら何でも作れる」と過信し、基幹システム級まで抱え込むこと。ツールの機能の範囲という制約は必ずあり、何でも作れるわけではありません（出典：IPA DX SQUARE）。等身大に言えば、ローコードは「ノーコードの一歩先の少しのロジックを、抱える範囲を見極めて使う」もの。全部は作らない、少しのロジックだけ自分で足す、という距離感が出発点です。

この章の確認（演習）

自分の担当業務から1つ選び、それを「部品の配置だけで足りる部分」と「条件分岐・計算・連携という少しのロジックが要る部分」に分けて書き出してください。後者が1つでもあれば、それがローコードの出番です。最後に、ノーコードとローコードの違いを、その業務を例に一言で説明してみましょう。

作る業務を選び、データの形を決める

最初の一手は「スモール＆シンプルな業務を1つに絞る」

作り始める前に、対象を絞ります。最初は「スモール＆シンプル」な業務から着手するのが定石で、申請・承認フロー、チェックリスト管理、簡易的な集計・報告のように、個人が持っていて繰り返し行う手元の業務が向いています（出典：GRANDIT）。ローコード/ノーコードは、必要最小限の機能に絞ったアプリ（MVP）の開発が特に向くからです（出典：第一生命経済研究所）。

絞る効果は実例にも出ています。ある製造業の後継者は、タブレットを配っても「紙のほうが見やすい」と現場に使われず悩んだ末、「使っても使わなくてもいいものは使われない。絶対に使わなくてはいけない業務からシステム化しよう」と考え、検査成績書のシステム化という1業務に絞って着手しました（出典：J-Net21「AIを活用し業務アプリ内製化【岡田研磨株式会社】」）。共通例でも同じです。「備品購入申請」という、毎月必ず回る1業務に絞ります。複数の業務を1つのアプリに詰め込まないことが、最初の分かれ道です。

画面より先に「何のデータを貯めるか」を決める

ローコード開発でつまずきやすいのは、いきなり画面から作り始めることです。設計では、画面レイアウト・データモデル・ワークフローをツールの機能でビジュアルに設計していきますが（出典：NTTデータ関西）、順番として先に決めるべきは「何のデータ（項目）を貯めるか」です。データの構造や特性を把握して行うデータベース設計は、一歩進んだ難易度として位置づけられており（出典：第一生命経済研究所）、ここを曖昧にすると後で画面もロジックも崩れます。

共通例で具体化します。備品購入申請アプリなら、貯める項目は「申請者／品名／金額／希望日／承認ステータス」（いずれも例）といった形になります。各項目について、文字なのか数値なのか日付なのか選択肢なのか、そして入力が必須か任意かを決めていきます。承認のように後から状態が変わるものは「申請中／承認済み」のような選択肢で持たせます。注文明細のように1件の申請に複数行ぶら下がるデータがあれば、それは分けて持ちます。なお、テーブル・項目・リレーションといったデータの箱の設計を体系的に深掘りしたい場合はデータベースの基本が正本です。本講座はアプリを作るのに必要な範囲だけ触れ、正規化などの各論には踏み込みません。

1アプリに詰め込みすぎ・項目を無計画に増やす、というつまずき

ここでのつまずきは2つです。1つは1つのアプリに複数業務を詰め込むこと。申請も在庫も経費も、と欲張ると、どの画面も中途半端になり完成しません。1業務＝1アプリに徹します。もう1つは、走り出してから項目を無計画に足していくこと。最初に「貯める項目」を洗い出しておかないと、途中で増やすたびに画面と集計が崩れます。最初から完璧を目指す必要はなく、まず作って動かしながら直していく姿勢が大切ですが（出典：GRANDIT）、それは「項目を決めずに始める」こととは違います。土台のデータだけは先に決める、と押さえてください。

この章の確認（演習）

選んだ業務（共通例なら備品購入申請）について、貯める項目を一覧にしてください。各項目に、型（文字・数値・日付・選択肢）と必須/任意を割り当て、表の形にします。後から状態が変わる項目は選択肢で表現し、明細のように繰り返し増えるデータがあれば分けて書いておきましょう。

画面とロジックを組み、動かす

データに対して入力画面・一覧・検索を部品で配置する

データの形が決まったら、画面を組みます。ローコードツールでは、画面の作成・帳票の作成・データベース定義の作成・ワークフローの作成が、用意された部品をマウスで配置する操作で進められます（出典：IPA DX SQUARE）。具体的には、現場の担当者が必要な機能を選び、データベースとの連携やワークフローの設定を行うことで、専門知識がなくてもシステムを構築できます（出典：NTTデータ関西）。

共通例なら、第2章で決めた「申請者／品名／金額／希望日」を入力する申請画面、申請を並べて見る一覧画面、品名や申請者で探す検索を、部品を置いていく感覚で組みます。ここまでは、ノーコードでも届く「部品配置」の領域です。

少しのロジック——条件分岐・自動計算・通知で業務の流れを再現する

ローコードの本領はこの先です。段階を踏んで、慣れてきたら「条件分岐や繰り返し処理のような入力チェック処理、外部システムとの連携といった、複雑な仕様の理解が求められる業務ロジック開発」に進みます（出典：第一生命経済研究所）。これが「少しのロジック」の正体です。

共通例で言えば、まず業務の流れを1本書きます。「申請者が出す → 金額が基準額（例）未満なら課長が承認、基準額以上なら部長が承認 → 承認されたら発注担当に回る」。この流れを、(1) 金額で承認者を切り替える条件分岐、(2) 申請が来たら承認者に通知、(3) 明細の合計金額を自動計算、として設定していきます。順番としては、入力画面と一覧を置く → 業務の流れを1本書く → その流れを分岐・通知として設定する → 計算が要る項目を式で設定する、と進めると迷いません。なお、特定ツール（kintone）での一覧・絞り込み・通知設定の具体的な画面操作はkintone入門が正本です。また、すでにある手作業の操作そのものを自動で動かしたい場合は、業務アプリを作るのとは目的が違うのでRPA入門へ。本講座は「データを入れて回す器を作る」側に絞ります。

分岐を複雑にしすぎ・例外を全部詰め込む、というつまずき

ここでのつまずきは、分岐や例外を作り込みすぎることです。ツールの制約をカスタマイズで無理に埋めようとすると、かえってハイコード開発よりコストが高くなる可能性があり、本来のメリットはコードを書かない点にあるので、カスタマイズは最小限にとどめるのが鉄則です（出典：IPA DX SQUARE）。「金額が基準額以上なら部長、ただし部長不在なら本部長、さらに海外案件なら……」と例外を全部アプリに抱え込むと、自分でも追えなくなります。まずは主たる流れだけを組み、完璧を目指さず「作ってみて、動くものを触ってフィードバックする」のが近道です（出典：GRANDIT）。例外は運用しながら必要な分だけ足します。

この章の確認（演習）

選んだ業務の流れを1本、言葉で書き出してください（誰が出して、誰が何を承認し、最後に誰へ回るか）。そのうち1か所だけ、条件分岐・通知・自動計算のどれか1つを取り上げ、「どんな条件で・何が起きるか」を言葉で設計してみましょう。例外は今は書かず、主たる流れに絞るのがコツです。

公開し、引き渡す範囲を見極める

作って終わりではない——テスト → 公開 → 運用までが1セット

組み上がったら、すぐ全員に配るのではなく、まずテストします。設計・開発が完了したらテストとリリースのフェーズに入り、単体の動作確認だけでなく、業務シナリオに沿った結合テストや性能テストも行います（出典：NTTデータ関西）。共通例なら、試しの申請データを使って「基準額未満は課長、以上は部長に回るか」「通知が届くか」「合計が正しく出るか」を一通り動かして確かめます。ローコードで作ったアプリは、少ない手順で素早くユーザーに公開できるのが強みですが（出典：第一生命経済研究所）、その手軽さゆえにテストを飛ばして公開すると、現場で止まって信頼を失います。

権限を割り当てて現場に公開する

公開時には、使う人ごとに何ができるかを割り当てます。個人情報や業務機密を扱うアプリを現場主導で作る場合、使用可能なツールの選定・アクセス権限の管理・利用ログの取得といった統制機能をあらかじめ準備しておく必要があります（出典：GRANDIT）。共通例なら、一般社員は申請の入力と自分の申請の閲覧、承認者は承認の操作、というように権限を割り当て、必要な人に必要な範囲だけ渡します。あわせて、公開後に「ここを直してほしい」という改善依頼を受ける窓口を1つ決めておくと、運用が回り始めます。

ローコードで抱える範囲と、開発部門へ渡す範囲の境界を見極める

最後に、最も大事な見極めです。ローコード/ノーコードは、特定の部門だけで使う必要最小限のアプリ（MVP）には向きますが、基幹業務システムのように大規模で複雑な機能が求められる開発には適用しづらく、既存の大規模システムを作り変えることも向いていません（出典：第一生命経済研究所）。IPAのDX白書も「他のさまざまな機能と接続する大規模な業務システム開発には向かない場合がある」とし、パイロットには「部内における案件・物品管理や、簡易な承認システム」を候補として挙げています（出典：IPA「DX白書2023」「DX白書2021」）。

これが境界線です。共通例の備品購入申請アプリは自部門で抱えてよい範囲。一方、後から「外部の会計システムと連携して自動で仕訳したい」「全社の基幹データとつなぎたい」という要望が出たら、それは開発部門（IT部門）へ引き渡すサインです。さらに、影響度の大きいシステムを業務部門主導で作る場合は、情報システム部門やCIO・CDOが連携し、ガイドラインの提示やツール評価、セキュリティ面の支援を受けながら進めるべきとされています（出典：IPA「DX白書2023」）。運用についても、ビジネス部門に任せきりにするよりIT部門が担当するほうが人員・コストの面で有利な場面があります（出典：IPA「DX白書2023」）。

抱え込みすぎの行き着く先が、いわゆるシャドーIT（野良アプリ）です。各自が自由に作ったアプリが社内に乱立すると、文書が残らず作った本人以外がメンテできず、最悪は情報漏洩につながります。これを防ぐには、IT部門に参画してもらい、開発者の登録・研修やアプリの一元管理、社内共通の開発・品質管理基準を設けるガバナンスが欠かせません（出典：第一生命経済研究所）。具体的には、開発ガイドラインの策定や、アプリ公開時のITレビューの実施が有効です（出典：GRANDIT）。全部を自分で抱えない、手に余る範囲は早めに渡す——この線引きができて初めて、ローコードは現場の武器になります。

この章の確認（演習）

作ったアプリ（または第3章までの設計）について、公開前のチェックリストを作ってください。「試しデータでテストしたか」「誰に何の権限を渡すか」「改善依頼の窓口は誰か」を1行ずつ書きます。最後に、自分で抱える範囲と開発部門へ渡す範囲の境界を1つ、「この要望が出たらIT部門へ」という形で書き出してみましょう。