ノーコードとは何か。
ノーコードって何のため
では、ノーコードっていったい何を求めているのでしょう。
ノーコードは、簡単に結果を得られることを求めています。
プログラミングって難しくないですか？もちろん難しいの基準は人によると思いますが、ビジュアル操作でシステムを作るノーコードと比較して難しいという意味です。プログラミング言語はコンピューター用に作られているので人間にとっては読みづらいです。また、英語が主体で書かれている言語が多いので、比較的分かりやすいプログラミング言語でも英語に近いです。
さらに言語の種類が多く、よく使っている言語以外は扱うのに苦労したりします。
いま”よく使っている”といいましたけど、そうです。まさによく使っているか、使い慣れているかどうかなんです。
日常的に使っている言語であれば、すらすらと記述すべきコードが頭に思い浮かぶのでスムーズに目的に向かって進んでいくのですが、プログラミングを日頃行っていないと、1つの目的を達成するのに時間がかかりすぎるんですよね。（まあ日頃使っていてもスムーズにはなかなか行かないことは多いですが）
そこでノーコードが出てくるわけです。言ってみれば、楽をしようとしているんですね。
ビジュアルで簡単操作で作りたいなあって。
ノーコードで作れるツール
そこで、ノーコードで簡単実行できるツールに走るわけですけど、ここでは、積み木みたいなブロックで組み立てたら右に進む左に進むみたいなものは置いといて、パソコンの画面上での話をします。
例えば、WEBサイトを構築するHTMLやCSSもプログラミング言語の1つだとすると、WEBサイトをノーコードで構築できるツールにはどのようなものがあるでしょうか。
画面上でドラッグ＆ドロップでホームページを作れるツールには、Wix、JIMDO、ペライチなんかがあります。Wordpressでもプラグインを使えばできたりします。
ノーコードでデータ管理を行えるツールでいうと、Excel、Access、ファイルメーカー（FileMaker）、キントーン（kintone）などがそうですね。
例を挙げだすときりがないんですけど、まあ言語でコードを記述することなく目的を達成できればノーコードツールの1つと考えていいと思います。
目的を達成というより、一連の流れ、フローをスタートからゴールまで実行することを自動化する意味を差す場合が多いでしょうか。
いま思いついたんですけど、Outlookの仕訳ルールなんかは、ノンプログラミングで設定できるパターンの多さとプログラミングでいうif文に近く、個人的にかなり完成度が高いと思います。
ノーコードのメリットとデメリット
ここまでは、ノーコードとは何かってことについて話した訳ですけど、本題はここからです。ノーコードのメリットとデメリットについてです。
まず、メリットについてです。これは言うまでもなく、手軽さ、簡単さですね。言語を学習することなく直感的なイメージでプログラムを組める、フローを自動化できるという点です。
そして、デメリットについてです。ノーコードツールを紹介する際には、こちらについてはあまり語られないと思います。というより、エンジニアにとっては当たり前かもしれませんが、プログラミング言語を扱ったことがない場合、説明しても実感するのがなかなか難しいと思います。
デメリットは、整理がつかずカオスになる点です。
ノーコードでは、必ずどこかで目的を達成できない壁にぶち当たり、言語でなければ解決できないアプリやシステムの機能を改善する案が挙がります。そして、それを補うために言語を追記すると、言語で制御している箇所とノーコードで制御している箇所が混在し、複雑化したときには整理がつかなくなります。
どうですかね、イメージできますかね。
分かりやすくWEBサイトの話でいうと、サイトの構造をHTMLで記述し、整理するためにデザインや共通部分をCSSで記述し整理しますよね。
それを全てコードで記述している時は整理できているのですが、ノーコードつまりドラッグ＆ドロップ操作で構築した場合、実際にはバックエンドでコードを記述しているので、どこに何が記述されているか、どのように記述されているかが分かりません。
作り上げている過程に人の目が入らないため、あとで見たときにどこがどのように影響しているかが分かりにくいってことです。
WEBページを表示するだけの場合は、うまく反映されなかったとしても、見た目が違うだけでいいかもしれません。（内側の要素に書いたり、importantなんかで打ち消しちゃえばいんですけど、それは置いておきます。）
しかし、数値を計算したり、確実な結果を求めるプログラミングではそうはいきません。どこが間違っているかを洗い出し、コードを修正してエラーやバグを解決しなければいけません。そのような時、その原因を探すのに時間がかかっていては、結局効率が悪いんです。初めからノーコードでなく、コードを記述していた方が効率的というわけです。
Excelなんかでいうと、初めのうちはセルの設定や関数で管理しいて、次にマクロを使うようになり、最終的にVBAまで使うようになり、正常に動作している時はいいんですけど、エラーになった時どこを修正していいかわからないといった状態ですね。作った人がいなくなったときなんかはもう手の施しようがなかったりします。
まあこれがExcelを嫌う人の意見の1つです。
でもこれって、本当にExcelだからダメなんですかね。本質的には、ノーコードによる動きとプログラミング言語の記述による動きが混在して整理ができていないことが原因なんです。つまり、整理ができていなければ、Excelでなくても同じ問題にぶつかるってことです。
いや、Excelを使っていたら、コード記述（VBA）を使わずノーコードによる設定だけであったとしても、ごちゃごちゃになる問題が起こるよ？というような意見も分かりますが、それも整理ができていないことが原因です。
Excelはノーコードで行えることが多いため、整理することを心がけずに編集を続けていると、どこかで整理がつかなくなり問題が発生するというわけです。
ノーコードを突き詰めたツールとは
簡単操作で作れるにはノーコード。
ノーコードでできることには限界があり、コードと混在することもある。
混在する場合には、整理できていることが重要。
ノーコードが進化していくと、どんなアプリになるのでしょう。
お気づきになりましたか？
そうです、私たちはすでに代表的なノーコードツールの1つをよく使っています。Excelです。
Excelは長いパソコン創成期を経て完成された1つのノーコードツールなのです。しかし、現場ではExcelでデータ管理することで問題を抱えている場面をよく目にするため、Excelでデータ管理はよくないとなってしまうわけです。
これは、コンピューターやプログラミングの世界だけの話ではありません。皆同じような問題を抱えているのに、最も有名な人だったり代表的な企業だったりが、その問題を起こした代表として目を向けられることってありますよね？それと同じです。
話はそれましたが、本題に戻しますと、つまり2020年現在ノーコードノーコードってどのツールを選択するか盛り上がっていますが、ノーコードには、とっつきやすいメリットがある反面、突き進むと整理がつかなくなるデメリットがあるということです。
ノーコードを否定しているわけではありません。
まずは、小さなことでも成功しないと何も始まらないので、ノーコードのツールは必要です。
しかし、人間が求める、業務改善、生産性の向上には終わりがありません。目的を達成すると次の改善そしてまた次の改善と、永遠と改善アイデアが湧き出てきます。そうなった時に、ノーコードで構築されたシステムは、どこかでノーコードでは対応できなくなり、コードで記述する箇所と併用することとなり、ノーコードとコード記述している箇所を整理できていないと非効率な側面があるという話です。それが見えているエンジニアは、初めから全てコード記述の構想で設計するんですね。（モジュールなどを利用すればよいとか、整理できている場合は問題ないので、その話は置いておきます。）
ここで言いたいのは、ノーコードを求めることが目的になって、同じことを繰り返していることに気づかず、別のツールを使えば問題が解決すると誤解している点です。成熟したノーコードツールがあるにも関わらず、そのツールの問題点に直面したからと言って、それを避け、また別のノーコードツールに走り、そちらでは問題が解決すると思うことは、同じことを繰り返してるということです。
もちろん、新たなツールを使うことを全面的に否定しているわけではありません。新しい時代のツールの方が、より洗練された構造で作られているはずなので、効率的な部分もあると思います。ただ、ノーコードが抱える問題点を認識した上で次のツールを選択することができているかどうかってことです。
それでもまだExcelが抱える問題点について説明しきれていない気がします。
それは、データベースソフトがExcelの問題点を解決しているからです。
さらに進むと次はデータベースソフトの問題点の話になります。
カスタマイズするための自由と破損しない不自由
Excelは自由であるが故にデータの整列を壊してしまう恐れがあります。
データベースソフトは、データの整列を壊しません。
しかし、データベースソフトは、データの整列を壊さないことを引き換えに大きなメリットを失っています。
それは、ユーザーが手軽にカスタマイズするメリットです。
破損しないことは不自由であること。
カスタマイズする自由があるとは、破損の可能性をはらんでいること。（※破損とは、データファイルの破損の意味ではなく、データが整理できなくなる意味を指しています。）
Access、FileMaker、kintoneなどのアプリは、フォームを固定し、テーブルを非表示にし、その他細かい部分を管理者が設定することで、Excelで起こる問題を解決しています。
ユーザーは必ずフォームで編集操作することで、Excelと同じようなデータの整理がつかなくなる問題が起きません。
これがデータベースソフトのメリットの1つですね。
しかしながら、例えデータベースソフトであっても、もしユーザーが管理者の設定に侵入し誤った操作をすれば、データの整理がつかなくなります。
つまり、管理者が設定を行う部分と操作ユーザーが扱う部分をしっかりと分けていれば、Excelであっても状況は同じです。
破損しない状況を作ることの解決策が、フォームで入力することやテーブルを非表示にすることです。
そうすると、フォームの変更はできない、レポートのフォーマット変更はできない、となります。自分で変更できないとなれば、変更したい部分をエンジニアに依頼する。依頼すればコストがかかり、費用対効果と見合わなくなれば、改善案（カスタマイズ要望）が眠ってしまうわけです。
堂々巡りですね。
ユーザー側で設定できるように自由を与えれば破壊するリスクを伴う。
これらは、トレードオフであるということです。
まとめ
ノーコードには簡単に取り掛かれるメリットはあるが、行きつく先にノーコードでは満たせない改善案が出てくる。
ノーコードの部分とコード記述の部分が混在する場合は、整理する必要があり、整理できていない場合エラーの原因を探すのが大変だ。
ノーコードを追求したツールの1つがExcelである。
Excelでデータ管理することで様々な問題が出てくると、その解決策はデータベースソフトを利用することになるが、それはカスタマイズの自由を失うことと引き換えである。
（データベースソフトのカスタマイズには、開発を依頼するコストか新たな知識を習得する学習コストがかかる。学習したとしても、それはカスタマイズの自由を得たこととなり、複数人が自由を得てそれを共有する時にはガバナンスがきかない。）
ポイントは、何人で共有するか。
どんなデータを共有し、統率する必要があるか。
どの部分に自由さを求めるか。
新たな機能（改善）は、共通部分に必要か。
共通部分に必要ない改善案は、ボツ案なのか。自分だけには必要なのか。
必要な場合、どんな方法で自分で改善するか。
うまく説明できていない部分もあると思いますが、ここで書いたのは一つの見解です。ツールの選択はもちろん自由であり、場面に応じて異なると思っています。
今回はどのツールを使うかでなく、ノーコードを求めることによる話から、ユーザーが自由にカスタマイズできる事と統率をとる事は相反するということについて考えてみました。
アプリやシステムの細かい改善は、共通部分でなく各ユーザー毎に必要なケースがあります。
どれくらいの人数が何を求めているかによって、提案するツールは違うと思いますが、できるだけユーザーが発想した改善案を思い通りに実現できるツールを提供していきたいと考えています。
By 運営01