見出し画像

ノーコード・ローコード導入のきっかけ

はじめまして。このブログ、ヴィップシステム株式会社「Kintoneにおまかせ!」ではKintoneや他のローコード・ノーコードツールの導入を検討されている皆さんに向けて、導入を決断するために必要な知識や情報、そして導入後の使い方を提供したいと思っています。皆さまに有用な記事をかけるよう努力しますので、これからよろしくお願いします。


ローコード・ノーコードとは?

まずはじめに、なぜ多くの団体や企業がローコード・ノーコードツールの導入を検討しているのでしょうか。おおよそ以下のようなニーズを抱えている企業・部門が導入を検討していると思われます:

  • 随分前に外部の開発会社に作ってもらったカスタムツールを社内の人員だけで運用しているが、時間が経ち誰もメンテナンスしてくれる人がいなくなった

    • 部門専用カスタムツールを利用するのは部門の人間だけであり、このツールの存在は会社は把握していない。今後障害が出た時の復旧やセキュリティ面の不安がある

      • →いわゆる「シャドーIT」問題を解決したい

  • 私達は部門専用で使うカスタムツールを利用しており、機能を追加したいが予算面で外部委託は不可能そうだ

    • 私達は中小企業またはIT部門が小さな会社であり、業務ツールを開発したいが、IT部門として専門のソフトウェア・エンジニアを雇用する予算がない

      • →社内の人間だけでメンテナンスしたい

    • カスタムツールに機能を追加したいが、外部の開発会社が提示してきた期間と予算では業務の変化に適応できない。私達の業務内容は常に変わり続けるので、それを外部の人間にいちいち説明して作らせていたのでは、いつまで経ってもツールは完成しない

      • →変化し続ける業務に対応するため、完成という概念のないツールが欲しい

このようなニーズに応えられるかもしれないのが、ノーコード・ローコードツールです。つまりIT専門の人員を常時雇用しなくても、最初に外部の業者に作ってもらえさえすれば、その後のメンテナンスは社内の人間だけで行えるかもしれません。その際、予算と納期は厳しいのでなるべく「短納期≒低予算」で作ってほしい、という要求に答えられる可能性があります。
それではノーコード・ローコードツールの導入に適している場面・適していない場面とはどのようなものがあるのでしょうか?個別に検討してみました。

ローコード・ノーコードツールの導入が適している場面

  • 導入後は社内の人間だけでメンテナンスしたい
    →Kintoneや多くのローコード・ノーコードツールは”SaaS”サービスと呼ばれ、システムのインフラ的な運用はすべてサービス提供会社が行っています。そのため、一度作ってしまえば専門的な作業がなくてもセキュリティ対応などが自動的に適用されます。

  • 導入後は社内の人間だけでカスタマイズしたい
    →Webブラウザだけで画面構築やデータモデリングができるローコード・ノーコードツールは、専門的な知識を持った人間がいなくても、社内の人間だけで仕様変更を行えます。

  • 10年以上前、外部の開発会社に委託した小規模な部門業務システムのリプレースをしたい
    →特にそれがオンプレミスで運用されるWebシステムであり、既に誰もメンテナンスしていないような昔のテンプレートエンジンを利用しており「入力フォームに項目を1つ追加したいだけなのに、一体どこを改修すればよいのか全くわからない」ようなケースには、Kintoneその他によるリプレースが有効です。
    従来のWebアプリケーションに軽微な項目の修正をしたいと思っても、データベースのどのテーブルにカラムを追加するのか?この画面はどのテンプレートファイルで表現しているのか?入力データを取得するビジネスロジックはどこに実装されているのか?どのようにデプロイすればよいのか?と、頭を抱えることになります。簡単なことをしたいだけなのに、なぜこんなに悩まなければならいのか?ツールのせいで業務の変更がおぼつかなくなってしまうような状態を「技術的負債」と呼びます。
    もしKintoneでリプレースできるなら、これら技術的負債が一度に解決する可能性があります:
    →インフラ運用コスト:オンプレミスからクラウドへ
    →改修コスト:Webブラウザの画面操作だけでフォームに項目追加が短時間で実装可能

ローコード・ノーコードツールの導入が適していない場面

  • 大規模開発
    →例:企業の基幹システムの構築など。 複雑なビジネスロジックを持つようなシステムは、Kintoneで提供される機能では実装が難しいと思われます。JavaScriptはあくまで画面上のイベントフック関数であり、そこに複雑なビジネスロジックを入れ込むのは設計として想定されていないような実装です。

  • 超・大規模データ
    →例:Kintoneはアプリのレコード数の上限を設定していませんが「100万行のレコードを使わせたい」といった場合は、そもそもデータを意味的に複数に分割できないか、データモデリング設計のレベルでの再検討が必要でしょう。

  • 大人数での開発
    →逆説的に聞こえますが、いくら予算が潤沢にあり人員を沢山確保できても、ローコード・ノーコードツールの方に大人数で開発するための仕組みが存在しません。例えばKintoneはWebブラウザのみで画面を構築できて便利ですが、これを複数人で同時に作成する仕組みもなければ、バラバラに作成した同じ画面を後で統合する仕組みもありません。

  • 本当に「ノーコード」で足りるの?
    →「フローチャートをつなぎ合わせるだけでコードの代わりになります」といった宣伝文句のツールは多いのですが、従来の複雑なビジネスロジック、それはコードで書くなら数千行以上のものを、フローチャートで表現できるか?というと、現実的に難しいと思います。

すぐに思いつくケースを幾つか挙げてみました。これら各項目の全体的な傾向としては「小規模開発はローコード・ノーコード開発が適している/大規模開発は適していない」と大まかにまとめることができると思います。
ローコード/ノーコードツールのメリットをまとめると「簡単なことを実現したいだけなのに従来の手法では実装手順が複雑すぎる」場合に効果を発揮する技術であると言えるでしょう。

お問い合わせ

Kintone導入検討時のご相談から、導入後の利活用・定着化に至るまで、私たちは、お客様と「伴走」しながら思いを込めてサポートいたします。ご相談無料ですので、ぜひお気軽にお問い合わせください。

記事作成
kintone推進チーム
Unsplashengin akyurtが撮影した写真