ノーコード／ローコードで開発して思ったこと
コウノ工房のコウノです。
例話になっても絶賛コーディング中です。
「プログラミングの専門知識がなくても業務アプリが作れるツール」として、ここ数年でノーコード／ローコードという言葉が急速に注目を集めています。ノーコード／ローコードなら、速く開発できるだけでなく、エンジニアでなくてもアプリを作ることが強みです。
さまざまなツールを実際に使ってみた結果を、学びとしてまとめました。
ノーコード／ローコードとは
まず用語を整理します。
- ノーコードは、コードを書かずにアプリや業務自動化の仕組み構築します。
- ローコードは、標準機能をベースに少量のコードやスクリプトを加えて機能を拡張します。
- 共通点は、標準部品とテンプレートを直感的に使い、開発の生産性を高められる特徴があります。
主に以下のようなサービスがあります。それぞれのサービスに対応範囲があるので、用途に応じてサービスを選びます。
実際に使ってみたサービス
検証は実運用に近い環境で行いました。
施策するだけでなく、実際に運用してメリット・デメリット、課題を考察しました。
- 触った主なツール：Googleサイト、kintone、WIX、Uipath など
- 用途：ホームページ作成、データ管理、FAQ、業務自動化
- 権限や運用に併せて確認しました。
業種や規模、選ぶサービスにより差は出ますが、どのサービスを選んでも同じような傾向になると感じました。
メリット
試作品を短時間で作れました。
既成部品の品質が高く、バグが少ない開発を実現できました。
- 開発が速いです。アカウント登録後、すぐに開発できます。
- オシャレなUIが最初から使えます。
- 一覧・検索・決済が安定して使えます。
UI設計やバックエンド開発など、開発に時間がかかる機能を即座に使えるのが魅力でした。
デメリット
提供された機能以外のことは、何もできません。
- CSSやJavascriptでサイトをカスタマイズできません。
- Excelのような複雑な表計算
- データの結合はできません
- 部署や個人など複雑なアクセス制限はできません。
「利益に直結しない独自業務は捨てる」、「システムに業務を合わせる」という判断ができ、みんなが従う風土があれば、この問題は解決します。しかし、それは権限を持つ役職者のみ可能な技であり、現場担当者や情シス担当者が勝手に業務フローを変えることはできません。
さらに厄介なのは、例外業務に限って労働時間の４割に近い時間を占めてしまったり、その業務の支持者がなかなかの上職者だったりして、なかなか説得できなかったりします。このあたりのデメリットをどのように扱っていくのかが重要になります。
向いている業務
相性が良い領域は型が決まっています。業務のばらつきが少ない領域です。
- 稟議・休暇・経費などの申請系。
- 顧客・在庫・案件などの一覧管理。
- コーポレートサイトやLP。
- ECの標準フロー（登録・決済・在庫）。
これらは導入効果が出やすい最初の一歩です。小さく作って早く見せ、現場の合意を得ながら範囲を広げる進め方が適していると思われます。
向いていない業務
相性が悪い領域は例外が多いです。組織固有のルールが濃い領域です。
- 取引条件や承認が部署ごとに違う業務。
- 入力制御や並び順などの細かなこだわり。
- 配送や割引が複雑なEC。
- 既存ルールを一切変えられない領域。
- 高い自由度と独自UIを求める要件。
この場合は無理をしないことが安全です。範囲を狭める、別技術へ切り出す、運用で吸収するなど、複数の打ち手を比較します。
まとめ・学び
速度の効用は確実でした。一方で、例外が増えるほど費用対効果は落ちます。
できる部分は任せ、できない部分は外に出すかアナログで対応します。運用で吸収する判断も現実的でした。
- 80％はノーコードでシステム化できる
- 残り20％は「捨てる」か「アナログで補う」判断が必要
- システムに業務を合わせられる環境があれば非常に有効
ノーコード／ローコードは魔法の杖ではありませんでしたが、、正しい範囲で使えば確実に効果を発揮します。重要なのは「どの業務をシステム化するか」、「どこまで割り切れるか」を見極めることだと感じました。
