ノーコードアプリ開発で業務システムを内製化する実践ガイド｜情シスがいなくても進められる手順

結論から書きます。ノーコードアプリ開発がうまくいくかどうかを分けるのは、選んだツールの機能の多さではありません。作り始める前に、次の3つをどこまで具体的に決めておけるかで決まります。

 

1. 最初に作る1本として、どの業務を選ぶのか。具体的には、途中で作り直しになっても本業が止まらない範囲かどうかで判断します
2. 画面に置く入力欄の名前と、そこに入るデータの型（文字列なのか、整数なのか、日付なのか）を、どこまで事前に固めておくのか
3. 現場の担当者が自分の判断で変更してよい範囲と、情報システム部門の確認が必要な範囲を、どの線で区切るのか

 

反対に、避けたい失敗も3つあります。1つ目は、いきなり受注管理や在庫管理といった基幹業務に手を出してしまい、決めるべき条件が多すぎて途中で止まってしまうケースです。2つ目は、作った本人が異動や退職でいなくなり、なぜその設定にしたのかを誰も説明できなくなる状態です。3つ目は、使っているツールでは実現できない仕様に後から気づき、作ったものを一から作り直すことになる展開でしょう。

 

独立行政法人情報処理推進機構（IPA）が公表した「DX動向2026」を見てみましょう。2026年7月に公表された調査です（出典：独立行政法人情報処理推進機構（IPA）「DX動向2026」）。

 

この調査では、紙や口頭でやり取りしていた情報のデジタル化や、日々の業務の効率化については成果が出ていると報告されました。一方で、新しい商品やサービスを生み出すといった、企業価値の創出につながる領域では成果が限られるとされています。つまり、申請書の電子化や管理表のデータベース化は、取り組んだ企業が成果を実感しやすい領域だといえます。

 

最初に作る業務アプリは、この成果が出やすい領域から選ぶほうが、社内の理解も得やすくなります。ここから先は、何が作れて何が作れないのか、そして何を決めておけばよいのかを、具体的に見ていきます。

最初に、ノーコードで何が作れて何が作れないのかを整理します。この線引きを曖昧にしたまま社内で話を進めると、「あれもこれもノーコードで置き換えられるはずだ」という期待だけが先に大きくなります。後から実現できないと分かったとき、提案した担当者が社内での信頼を失うことになりかねません。

ローコードとの違いは、作る人にどこまでの知識を求めるかで分かれます

ノーコードは、あらかじめ用意された部品を画面上で並べ、設定を選ぶだけで業務アプリを組み立てる方式です。ローコードにも、設定だけで作れる範囲は同じように用意されています。そのうえで、標準の設定では足りない部分を、プログラムで補えるようになっているのです。両者の違いは、機能の多さや価格ではなく、作る人にプログラムを書く知識を求めるかどうかにあります。

 

したがって、社内にプログラムを書ける人がまったくいない場合は、ノーコードで完結できる範囲に業務を寄せる進め方が現実的です。反対に、プログラム書ける人が1人でも社内にいるのであれば、標準の設定では届かない部分を補えるローコードも選択肢に入ります。

 

ノーコードそのものの考え方や、クラウド上のデータベースで何ができるのかをもう少し詳しく知りたい方は、ノーコードとはもあわせてご覧ください。

向いている業務かどうかは、次の4つの条件で見分けます

ノーコードで作りやすいのは、次の4つの条件に当てはまる業務です。

 

1. 紙かExcelですでに回っていて、入力する項目（日付、金額、担当者名など）がおおむね決まっている
2. 関係者が一部門で数えられる範囲におさまり、複数の部門をまたいだ複雑な承認を必要としない
3. 毎月または毎週、ほぼ同じ形で繰り返し発生し、そのたびに様式を作り直す必要がない
4. 金額の確定や在庫の引き当てといった重い計算は、既存の基幹システム側に任せられる

 

具体例を挙げると、稟議書やトラブル報告書などの社内申請、備品や契約の管理表、案件ごとの進捗管理などが当てはまります。いずれも入力する項目が現場ですでに固まっており、誰が見て誰が承認するのかという関係者の範囲もはっきりしているはずです。だからこそ、設定を選ぶだけの範囲で作り切れます。

 

反対に向かないのは、基幹システムが持っている計算そのものを置き換える用途です。たとえば、会計処理や、在庫の引き当て（受注した分の在庫を確保して他の注文に使われないようにする処理）が当てはまります。この領域まで踏み込まず、基幹システムとデータをやり取りする役割にとどめておくと、後からの手戻りを最小限に抑えられます。

 

総務省が公表した「令和7年通信利用動向調査の結果」も見ておきましょう。2026年5月29日に公表された資料です（出典：総務省「令和7年通信利用動向調査の結果」）。

 

クラウドサービスを一部でも利用している企業の割合は83.5％でした。この数値はメールやファイル保管なども含めた全体の利用率ですが、業務の道具をクラウドに置くこと自体は、すでに特別な選択ではなくなっているといえます。

 

 

出典：総務省「令和7年通信利用動向調査の結果」

導入前検証で実際に突き当たった2つの制約を紹介します

当社は2026年に、9社と導入前検証（PoC）を進めています。PoCとは、この導入前検証を指す略語です。実際に作った設計書には、ツールの制約に突き当たり、当初の想定どおりには作れなかった記録が残っています。

 

1つ目は、消費税の計算方法をめぐる制約でした。従業員約150名のソフトウェア開発業では、税抜金額に税率を掛ける四則演算で消費税額を自動計算しようとしたところ、計算式では小数を扱えないことが分かりました。そこで設計書には、消費税額の欄を自動計算ではなく手入力に変更した旨が記録されています。

 

2つ目は、自動計算に使える項目数の上限です。正社員約520名の食品製造業では、燃料費の申請画面を組んでいく途中でこの上限に達しました。そこで設計書には、計算用の項目を別に追加して上限を回避したこと、そしてこの問題は解消済みであることが記録されています。

 

どちらも、事前の打ち合わせでは見えず、実際に作り始めてから初めて表面化した制約です。制約はどのツールにもあると考えておくほうが安全です。問題は制約の有無ではなく、本番運用を始める前に見つけられるかどうかにあります。ここまでを踏まえると、自社の業務のうちどれをノーコードで作り、どれを既存システムに残すのかを仕分けられるようになります。

最初に作成する業務アプリは、紙かExcelで回っている小さな業務から選びます

最初に作るものは、仮に途中で作り直すことになっても本業が止まらない範囲から選ぶと安全です。具体的には、部門内で完結している紙の申請書か、担当者が数名で共有しているExcelの管理表が向いています。関係者が少ないほど、仕様を変更したときに説明する相手も減り、作り直しの負担が小さくなるからです。

 

いきなり全社導入を目指す必要はありません。申請書1枚、管理表1つという単位で始めれば、「まずこの範囲で試してみたい」という説明の方が業務アプリの導入が社内で通りやすくなります。

 

判断に迷ったときは、いま社内で一番よく紙をコピーして回している業務を探してみてください。コピーして回覧するという手間は誰の目にも見えているため、電子化したときの変化も関係者と共有しやすくなります。

着手前に決めておく4項目を、紙に書き出します

ツールを触り始める前に、次の4項目を紙に書き出して確定させます。ここが冒頭で触れた「作る前に決めておくこと」の中身です。

 

1. 項目名：画面に置く入力欄の名前を、現在の帳票を見ながらすべて書き出します
2. データの型：書き出した入力欄1つずつに、文字列・整数・小数・日付・選択肢・ファイルのどれで扱うかを割り当てます
3. 帳票：出力する書類の様式と、出力したファイルをどこに保存するのかを決めます
4. 承認：誰が申請し、誰が承認し、差し戻しの操作が必要かどうかを決めます

 

この4項目は、いったん運用を始めてから変更すると、影響する範囲が広くなります。とくにデータの型は後から効いてきます。金額を文字列として登録してしまうと合計を集計できず、日付を文字列にすると期間で絞り込めないため、登録済みのデータをすべて入れ直す事態になりかねません。先ほど紹介した消費税の例も、計算式で扱える値の制約から生じた出来事でした。

 

書き出した4項目は、A4用紙1枚にまとめておくと後々まで役に立ちます。ツールを試すときには「この項目がこの型で作れるか」という確認表になり、上司や情報システム部門に相談するときには、そのまま説明資料として使えるからです。

 

要件の書き方をもう一段詳しく知りたい方は、要件定義書の必要項目と書き方｜実案件のサンプルと未決事項の管理法（テンプレート付）が参考になります。

要件は4つの種別に分け、満たすべき条件を1行ずつ書き出します

当社が従業員約150名のソフトウェア開発業と作成した設計書では、要件を4つの種別に分けて整理していました。自動採番、データ入力、帳票の出力と保存、起案申請と承認の4つです。

 

種別ごとに、満たすべき条件を1行ずつ書き出す形にしていました。たとえば自動採番であれば、「見積番号や請求番号として、重複しない値を自動で振れること」という1行になります。ここまで粒度を細かくしておくと、ツールの試用期間に何を確かめればよいかがそのまま決まるため、試用が「なんとなく触ってみた」で終わらずに済みます。

 

項目の定義そのものも、見積・納品書・請求書という3つのデータの保管先について、合計304項目を1行ずつ並べました。ノーコードであっても、この整理の手間がなくなるわけではありません。逆にいえば、整理さえ終わっていれば、画面上で組み立てる作業自体は短時間で終わります。

 

整理を始めるときは、いま実際に使っている帳票を1枚手元に置いてください。その帳票の記入欄をそのまま項目名として書き写し、実務で使われていない欄を後から外していくほうが、白紙から考えるより早く終わります。この段階まで進めば、着手前に何を決めておけばよいかが自社の言葉で説明できる状態になります。

導入前検証では、業務部門の担当者が中心の会社が目立ちました

当社が2026年に進めている導入前検証9社のうち、4社は情報システム部門が検証に加わらず、業務部門の担当者が中心となって進めています。内訳は次のとおりです。

 

・従業員約100名の建設業 情報システム部門はなく、業務部門の数名が担当
・従業員約150名のソフトウェア開発業 情報システム部門は本件に加わらず、総務部の2名が中心
・従業員15名の製造業 営業部の1名が担当
・従業員約220名の学習塾運営 デジタルシステム部の1名が担当

 

こうした体制は、けっして珍しいものではありません。情報システム部門が前面に立たない状態からでも、実際に検証の準備まで進んだ会社が複数あります。担当者の人数の少なさは、内製化に着手できない理由にはなっていません。

現場に渡す範囲と、情報システム部門が握る範囲を先に分けます

現場が自由にアプリを作れる状態は、そのまま放置するとシャドーITに近づきます。シャドーITとは、会社が把握しないまま現場の判断でツールが使われ、どこにどんなデータが置かれているのかを管理できなくなった状態のことです。そうならないための線引きの目安を挙げます。

 

現場が自分の判断で変えてよい範囲	情報システム部門が握る範囲
画面上の項目の並び順、入力欄の追加、一覧画面の絞り込み条件	利用者の登録と権限の付与、他システムとのデータ連携、社外へのデータ持ち出し

 

企業会計審議会が公表した意見書も参考になります。令和5年4月7日に公表された資料です（出典：企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」令和5年4月7日）。

 

この資料には、統制活動に権限と職責の付与、そして職務の分掌が含まれると書かれています。職務の分掌とは、1人の担当者に権限を集中させず、作る人と承認する人を分けておく考え方です。この考え方をノーコードに当てはめると、誰にどこまでの操作を許すのかを先に決めておく形になります。

 

現場にどこまで開発を任せてよいのかという考え方は、禁止するほど増える「シャドーIT」を対策：情シス部門の管理下で現場が自由に開発できる「管理された自律」で詳しく扱っています。

 

線引きは、最初から細部まで決めきる必要はありません。まずは利用者の登録と権限の付与を情報システム部門に残し、社外へのデータ持ち出しなど影響の大きい操作を順に足していく形でも始められます。運用しながら、現場から出てきた変更要望を「これは現場で対応」「これは相談が必要」と1つずつ振り分けていけば、自社に合った線引きが形になっていくでしょう。ここまで進めば、誰に何を任せるのかを自社の言葉で説明できるようになります。

 

情報システム部門が前面に立てない会社でも、業務アプリの内製は始められます。最初に作成する業務アプリを決める材料が手元にあると、社内での相談も進めやすくなります。具体的な内容が知りたい場合は、お問い合わせページからご連絡ください。

1社目は、従業員約150名のソフトウェア開発業です。見積の作成から請求書の発行までを、Excelのマクロ（決まった操作を自動で実行させる仕組み）で処理していました。ただし、そのExcelブックは支店ごとに分かれており、設計書には「統合が難しい」という課題が記載されています。担当者からは「ファイルが壊れるリスク」という言葉も出ました。

 

運用上の制約もありました。マクロが組み込まれたブックを1人が使っている間は、ほかの担当者は作業を待たなければなりません。また、見積番号が重複した場合に警告は表示されるものの、誤って上書きされてしまう可能性が残っていました。総務部の2名が中心となり、この状態をノーコードで置き換えられるかを検証する予定です。

 

設計では、見積番号や請求番号の自動採番を最初の要件に置きました。番号の重複という業務上のリスクを、担当者の注意力ではなく仕組みの側で防ぐという判断です。帳票の出力と保存、起案と承認についても、同じ設計書の中で一続きの流れとして整理しました。なお、この会社の検証はこれから本格化する段階であり、導入後にどれだけの効果が出たかはまだ測定していません。

 

2社目は、正社員約520名の食品製造業です。有給休暇の申請ワークフローは、利用者数が無制限の別のツールで動いています。費用は月額10万円です。この使い勝手に不満があったところに、私有車を業務で使った際の燃料費を申請する仕組みを新たに作りたいという要望が重なり、検証が始まりました。

 

既存のツールでは、申請者の所属や職位によって承認ルートを分岐させることができません。さらに、申請画面に出したい入力欄を必要な形で配置することもできませんでした。

 

そこでデモでは、管理部・営業部・SCM（供給網の管理）事業部という3つのグループを作りました。このうち管理部と営業部には、一般社員から部長までの職位を用意しています。所属するグループと職位に応じてルートが変わるかどうかを、実際の画面で試している段階です。

 

この会社の検証も進行中で、導入後の効果はまだ数字にしていません。ただし、既存のツールで満たせない要件が承認ルートの分岐と入力欄の2点であることは、設計書に記録として残っています。2社に共通しているのは、道具の乗り換えそのものを目的にしていない点です。どちらも、いまの業務のどこで手が止まっているのかを先に言葉にしたうえで、試す範囲を決めています。

Q1 ローコードとの違いは何ですか

プログラムを書かずにどこまで作れるかという範囲で分かれます。ノーコードは、用意された設定の組み合わせだけで作り切る方式です。ローコードは、設定でまかなえない部分に少量のプログラムを書き足して補えます。社内にプログラムを書ける人がいるかどうかで選ぶと、判断がぶれません。

Q2 作った人が異動したら、誰も分からなくなりませんか

その危惧は確かにあります。防ぐ方法は2つです。1つは、入力欄の名前とデータの型を一覧表にして、アプリとは別に残しておくことです。もう1つは、設定を変更できる管理者を最初から2名以上にしておき、1人が抜けても操作できる人が残る状態にしておくことでしょう。

 

当社が実施した調査をもう1つ挙げましょう。営業事務の経験が3年以上ある221人に聞いた結果です。前任者が残したマクロや関数の解読に苦労した経験がある人は64.2％でした（出典：【2026年調査】営業事務のExcel属人化の実態｜221人中64.2%が「前任者の謎マクロ・関数」に苦労）。

 

 

Excelで起きてきたことは、ノーコードでも同じように起こり得ます。引き継ぎの決めごとを先に置いておけば、同じ道をたどらずに済みます。

Q3 いまの基幹システムとつなげられますか

つなげ方は、大きく2つあります。1つは、基幹システムからCSVなどのファイルを書き出し、それを取り込む方法です。もう1つは、API（システム同士がデータをやり取りするための接続口）を使って自動で連携する方法になります。どちらを選べるかは、基幹システム側がどこまで外部との接続を許しているかによって変わります。

 

具体的な進め方は、ノーコードで始めるAPIデータ連携入門：開発不要の範囲と失敗しない進め方が参考になります。

Q4 情報システム部門や上司には、どう説明すれば話が進みますか

最初に作る1本の範囲と、権限の線引きをA4用紙1枚にまとめると伝わりやすくなります。記載するのは、対象の業務、関係者の人数、扱うデータの種類、現場が変更してよい範囲の4点で足ります。効果の見込みについては、まだ測定できていない削減時間を並べるより、実際に運用してから測って示すほうが安全です。

Q5 ツールを試す前に、社内で何を用意すればよいですか

いま実際に使っている帳票やExcelファイルを、記入済みの状態で1つ用意すると話が早く進みます。あわせて、誰から誰へ承認がまわるのかが分かる資料も添えてください。当社の導入前検証でも、この2つをいただいた時点で、試す範囲と作る順番を決めています。

ノーコードアプリ開発の成否は、ツール選びよりも、着手する前にどこまで決めておけるかで決まります。最初に作る1本は、紙かExcelで回っている部門内の小さな業務から選ぶと、失敗しても本業が止まりません。着手前には、入力欄の名前とデータの型、出力する帳票、承認の流れという4項目を書き出しておきます。

 

あわせて、現場が自分の判断で変えてよい範囲と、情報システム部門が握る範囲も先に分けておきましょう。専任の担当者がいない会社であっても、この順番で進めれば着手できます。

 

ノーコードでどこまで作れるかは、実際の画面と要件の細かさを見比べると判断しやすくなります。具体的な内容が知りたい場合は、お問い合わせページからご連絡ください。