ノーコードで作れば済むのか｜
既製のツールで足りる場合と、
足りなくなる場合

先に結論：ノーコードで足りるなら、それでいい

「自動化を考えている」というご相談をいただくと、すでにノーコードのサービスや既製の業務アプリを試されていることがよくあります。そして多くの場合、それで足りています。

利点は本物です。費用も期間も抑えられます。何より、作った本人があとから自分で直せる。これは外注したシステムには無い強みで、小さく始めて試すには一番速いやり方です。

ですので、まず試してみることをお勧めします。そのうえで、この記事が役に立つのは次のような場面です。

• 製品が想定した形から、自社の業務が外れはじめた
• 一人で使っていたものが、部署をまたいで使われることになった
• これから選ぶところで、どこまで自分たちでやれるかを見極めたい

はじめの2つが、線の引かれる場所です。順に見ていきます。

① カスタマイズの限界は「できない」ではなく「回避策が積み上がる」

ノーコードのツールは、製品が想定した形に業務が収まっているあいだは、とても速く動きます。項目を並べて、入力画面ができて、一覧が出る。ここまでは本当にあっという間です。

変わるのは、自社のやり方が想定から外れた瞬間です。といっても、たいていは「できない」と拒まれるわけではありません。回避策で何とかなってしまう——ここが見落とされやすいところです。

• うまく収まらない情報のために、別の置き場所を用意する
• ある画面の数字だけ、手で転記してから次に進む
• ツール側で止められないので、入力の順番を口頭のルールで決める
• 集計が合わないので、月末に表計算へ書き出して整える

一つひとつは小さな工夫です。実際、その場では回ります。問題は、これが積み上がったあとに起きます。

回避策は、組んだ人の頭の中にしか残らない

ツールの画面に残るのは結果の形だけです。「なぜこの項目が2か所に分かれているのか」「なぜここだけ手入力なのか」という理由は、どこにも書かれません。

これは、どこかで聞いた話に似ていませんか。Excelで起きていたことと同じです。数式は読めるのに、その数式がなぜその形なのかは分からない。だから触れない。

逆に言えば、回避策がほとんど無いなら、その業務はノーコードに向いています。製品の想定と自社のやり方が噛み合っているということだからです。判断の材料は、機能の数ではなく「いくつ回避策を入れたか」のほうにあります。

② 「作れる」と「設計できる」は、別のことです

もうひとつの境目は、使う人数です。

ノーコードが簡単にしたのは、「作れる」のほうです。ここは本当に簡単になりました。けれど業務の仕組みには、作る前に決めておくことがいくつかあります。それが「設計できる」のほうで、こちらは簡単になっていません。

具体的には、次の5つです。

1. 権限：誰が何を見てよいか。他部署の単価や、人事に関わる情報をどう扱うか
2. 入力規則：間違った値をどこで止めるか。空欄を許すか、重複をどう扱うか
3. マスタの持ち方：取引先や商品の名前をどこで一本化するか。表記ゆれが出たとき、どちらが正か
4. 集計の定義：「今月の売上」がいつからいつまでか。キャンセルや値引きをどう数えるか
5. 引き継ぎ：作った人が異動や退職をしたあと、誰がどこを見れば分かるか

一人で使うぶんには、どれも出てきません

自分用に作っているあいだ、この5つは問題になりません。見てよい範囲は自分だけですし、入力を間違えても自分で気づきます。名前の表記も自分の中で一貫していて、「今月の売上」の意味も自分は知っています。引き継ぐ相手もいません。

部署をまたいだ瞬間に、5つとも一度に出てきます。

そして厄介なのは、この5つが「あとから足せない」種類のものだということです。権限を後付けするにはデータの持ち方そのものを変えることになりますし、集計の定義を変えると過去の数字が動きます。作ったあとで気づくと、作り直しに近い手間がかかります。

ノーコードのツールにこれらの機能が無い、という話ではありません。多くの製品は備えています。要るのは知識のほうです。何をどう決めればよいかを知らないまま進むと、機能があっても使いどころが分かりません。

そして、業務フローが分かる人ほど、時間がありません

この5つを決められるのは、業務の流れを端から端まで分かっている人です。どこで情報が生まれ、誰の手を経て、どこで数字になるのか。それが見えていないと、権限の線も、集計の定義も引けません。

ところがその人は、たいていいちばん忙しい人でもあります。全体が分かっているからこそ、日々の判断も問い合わせもそこへ集まる。腰を据えて設計する時間が、いちばん取りにくい立場にいます。

結果として何が起きるか。設計は、手の空いている人か、「誰でも作れる」という道具のほうへ預けられます。預かった側は全体が見えないので、自分に見えている範囲で正しいものを作ります。部署ごとに少しずつ違う形のものが増え、つなぎ目が手作業になる。

ここは「ノーコードだから」という話ではなく、誰が設計するかという話です。社内でその時間を空けられるなら、道具は何であれうまくいきます。空けられないなら、外から業務の流れを聞き取って形にする人を入れる——どちらを選ぶか、という問題になります。

③ そして、使い始めてから変えたくなります

ここまでの2つは「当たった人だけの話」でした。最後に、どちらに当たっていなくても起きることを1つ書いておきます。

作る前に、要るものが全部分かることはまずありません。実際に動かして、何週間か使ってみて、はじめて見えてきます。

• 入れたはいいが、誰も見ていない項目がある
• 毎回メモ欄に手で書いていることがあって、それは項目にすべきだった
• 入力の順番が実際の作業と逆で、行ったり来たりしている
• 最初は一人で入れていたが、現場の人に直接入れてもらいたくなる

どれも、使う前には分からないことです。つまり最初に作ったものは完成形ではありません。そして、ここが肝心なところですが——使い始めて要望が出るのは、うまくいっている証拠です。使われていないものには、要望すら出てきません。

だから「直せるかどうか」が、機能の数より効いてきます

この点で、ノーコードにははっきりした強みがあります。思いついたその日に自分で直せる。見積りも待ち時間もありません。これは外注したシステムには無いもので、記事の最初に「利点は本物です」と書いたのは、主にこのことです。

注意したいのは、その強みが①の回避策で目減りすることです。回避策が積み上がると、1か所いじったときにどこへ影響が出るのかが読めなくなります。直せるはずなのに、怖くて直さなくなる。そうなると、せっかくの強みが使えません。

外注した場合は別の形でつまずきます。作って納めて終わりという契約だと、変更のたびに見積りと順番待ちが挟まります。金額ではなく、手続きの重さで小さな変更が通らなくなる——「これくらいなら言わなくていいか」が積み重なって、現場が手作業で埋め始めます。

道具を選ぶときは、できることの一覧だけでなく、「3か月後に、ここを直したくなったらどうなるか」を一度あてはめてみてください。自分で直せるのか、誰かに頼むのか、頼んだらどれくらいで戻ってくるのか。その答えが、使い続けられるかどうかをだいたい決めます。

どこで分かれるか（判断の目安）

ここまでの話を自分の状況に当てはめられる形にします。あてはまる数が多いほど、ノーコードのままで続けやすい状態です。

右側に寄ってきたとしても、すぐ乗り換えるべきだという意味ではありません。「いま組んでいる回避策について、この先も自分が説明できるか」を一度考えてみる、という程度のことです。

RECOGの立ち位置

RECOGは、Excelや手作業に頼っている管理業務について、使い慣れた操作感のまま貴社専用のWebアプリにする会社です。会計ソフトや基幹システムは置き換えません。その周辺だけを引き受けます。

そのうえで申し上げると、ノーコードで足りるなら、そう申し上げます。試してみて回っているものなら、わざわざ作り直す理由はありません。ご相談の場で「それは今のままで十分です」とお伝えして終わることもあり得ます。

作ってみたものがあるなら、それ自体が設計図として役に立ちます。どの項目を使い、どんな順番で入力し、どこで回避策を入れたか——これは要件そのものです。仮に別の形へ移すとしても、ゼロから聞き取りを始めるより早く進みますし、現場の操作感も引き継げます。試した時間は無駄になりません。

作って納めて終わりにせず保守を中心に置いているのも、③で書いたことが理由です。業務のほうが変わっていくので、最初にどれだけ正しく作るかより、変わったときに直せる状態かどうかのほうが効いてきます。「これくらいなら言わなくていいか」と現場が我慢を始めたら、そこから手作業が戻ってきます。小さな変更が、小さなまま通る形にしておく——そこを仕事の中心に置いています。

よくある質問

ノーコードのツールでは業務システムは作れないのですか？

作れます。試してみて足りるなら、それが正解です。費用も期間も抑えられますし、作った本人が自分で直せるのは大きな利点です。話が変わるのは、製品が想定した形から業務が外れたときと、一人で使っていたものを部署をまたいで使い始めたときです。この2つに当たっていなければ、別の手段を探す理由はありません。

ノーコードでカスタマイズできないと、具体的に何が起きますか？

多くの場合、できないのではなく回避策で何とかなります。問題はその先です。別の置き場所を用意する、ある画面だけ手で転記する、入力の順番を口頭で決める——こうした回避策が積み上がると、なぜその形なのかが組んだ本人の頭の中にしか残りません。Excelで起きた「あの人しか分からない」が、場所を変えて再発します。

「作れる」と「設計できる」は何が違うのですか？

ノーコードが簡単にしたのは「作れる」のほうです。設計できるというのは、誰が何を見てよいかの権限、間違った値を止める入力規則、取引先や商品といったマスタの持ち方、集計の定義、人が入れ替わったときの引き継ぎを決められることを指します。一人が自分用に作るぶんには出てきませんが、部署をまたいだ瞬間に全部出てきます。

ノーコードで作ったものは、あとから作り直しになりますか？

作り直しになるとはかぎりません。むしろ、作ってみたものは業務の設計図として役に立ちます。どの項目を使い、どんな順番で入力し、どこで回避策を入れたか——これは要件そのものです。仮に別の形へ移すとしても、ゼロから聞き取りを始めるより早く、現場の操作感も引き継げます。試した時間は無駄になりません。

作ったあとで変更したくなったら、どうなりますか？

変更したくなるのが普通です。作る前に要るものが全部分かることはまずなく、何週間か使ってはじめて「この項目は誰も見ていない」「毎回メモ欄に手で書いている」と見えてきます。むしろ要望が出るのは使われている証拠です。見ておきたいのは、そのとき自分で直せるのか、誰かに頼むのか、頼んだらどれくらいで戻ってくるのかです。回避策が積み上がっていると、直せるはずなのに影響が読めず触れなくなります。外注の場合は、金額ではなく見積りと順番待ちという手続きの重さで小さな変更が通らなくなります。