第1回 ローコードノーコードが失敗する理由

今までここのエントリのいくつかで「いずれ詳しく書きます」とか「詳しくは私のブログで」とか書いてそのまま放置していたネタがいくつかあります。

まずはこの辺の消化から始めたいと思います。と言うか、このカテゴリを作ろうと思った動機が、この辺をちゃんと消化しておかないとなぁと思ったからだったりします。

そんなわけで、まずは「オープンソースなローコード、ノーコードのサービスメニュー」の中で言っていた表題のことからやって行きましょう。

ローコードノーコードの歴史

元のエントリで書いていたように、「ローコードノーコード」は特に目新しい概念ではありません。

私がまだ駆け出しエンジニアだった頃から、こういった考え方はありました。

その頃は「仕様を何らかの定義文書で記述するとソフトウェアを生成する」というようなものでしたが、

• ロジックの詳細については考えなくて良い
• 外部のインターフェイスは既成のものがある
• 仕様の記述は利用者寄り

という点では、今のローコードノーコードと同じようなものです。

当時それらの多くは主にプログラマ向けに作られているものが多く、一応「システム開発用簡易言語」みたいな呼ばれ方をしてはいましたが、Excelのルーツとなる「簡易言語」とはちょっと方向が違います。私の近くにあった例だと、銀行のサービスを定義するとそれ用のCOBOLのコードを生成するといった感じのものです。まぁ直接使ったことがないので、話に聞いていただけではありますが。ここで紹介した「amplication」とかがそれに近い方向性のように思います。

そして、その後に「EUC(エンドユーザコンピューティング)」という言葉と共に、プログラマ向けのツールからだんだんエンドユーザ向けに方向が変わり、いろんなものが出ては消えました。MS-DOS時代にあった「カード型データベース」とかは、かなり近いものだったように思います。また、Macにあった「HyperCard」とかそのフォロワー達もそういったものだったとも言えます。

調べていて思い出したのですが、ちょっと前はこの手のツールは「RADツール」とか呼んでましたね。もっとも「RADツール」は主には技術者向けのツールという位置づけでしたが。

いろんな名作もあったと思いますが、今残っているものは皆無と言っても良いでしょう。「カード型データベース」の系譜の中にあると思われる、「MS Access」が辛うじて残っていると言えなくもありませんけど。「RADツール」は「GUIやDBのデザインツール」としては生きてますね。一般的なアプリケーションの開発環境という感じのものは廃れた感ありますけど。

何年か周期で、こういったものが流行ったり廃れたりする。それだけ「簡単にアプリケーションを作りたい」という欲求があるのでしょう。そう言えば、自分でもそんなものを作っていたことを思い出しました。画面定義してDB的なものに格納して... GUIなものではなくて、cursesを使ったCUIです。画面更新ロジックにはNg(Nihongo micro Emacs)のコードを流用して...

これらのものが生まれては消えるのはソフトウェア製品の常ですから、「そういったもの」と考えて対策を取るしかありません。その一つが「アフターサービス」です。他にもいろんなサービスのアイディアはあると思います。弊社では今のところ考えていませんが、別のツールへの移行とかをサポートするサービスとかもあって良いでしょう。

そう言えば、一々「ローコードノーコード」と書くのが面倒臭いので、以下は「LCNC」と略します。そこそこ使われている語のようです。

死屍累々のプロジェクト達

しかし、もっと残念に思うのは、「導入の失敗」が随分とあるということです。「今」使えるはずなのに使えない。これはちょっと残念です。

その大きな原因の一つが、

「システムを開発すること」と「プログラムを書くこと」は違う

ということに気がつかない、あるいは気がついていても無視あるいは軽視してしまうということです。

LCNCを使えば、プログラムを書かなくて済む、あるいはちょっとだけ書けば済む。これは程度の多少こそあれ、嘘ではありません。ですが、「プログラムが作られること」と「システムが作られること」は違うのです。

「システム開発」に必要なこと

「システムを開発すること」と「プログラムを書くこと」は違うと言いました。では、「システムを開発する」には何が必要か考えてみます。

システム要件の定義

いきなり面倒臭そうなことをタイトルにしましたが、要するに

何がしたいか

の整理ということです。

たとえば、「名刺管理システム」を作りたいとします。ここで「ゴール」とするべきは何でしょうか？

システム開発を永年やって来た者として言えば、ここの「ゴール」は

名刺が適切に管理されること

です。「名刺管理のソフトウェアが完成すること」ではありません。

こう書くと当たり前のように見えますが、システム開発に疎い人ほど、「ソフトウェアの完成」の方をゴールにしてしまいます。

システム開発を業としている人は、「名刺が適切に管理されること」をゴールとしてそれに必要なものを揃える... つまり、トップダウン的な思考をします。

その時に、

• 何のために管理するのか
• 誰が使うのか
• どう使われるのか

について考えますし、その結果として

• どう運用されるのか

ということなどを考えます。「ソフトウェアが完成する」というのは、そういったことの一部として捉えます。

そして、本当に優秀なシステム開発者は

適当な段ボール箱を用意すれば足りるのではないか？

という可能性も含めて検討をします。

これは「何もシステム開発が不要」という観点だけではなく、「適切に運用されている状態のイメージ」について考える一助になります。これは後に述べる「データベース設計」に対する考え方の糸口になるかも知れないのです。

いずれにせよ、「システムが完成した時のイメージ」を持つというのは、システム開発においてとても大切なことなのです。そして、必要に応じてソフトウェアの設計に反映させて行くわけです。

LCNCに限らずEUCの一部としてソフトウェアが作られる場合、往々にしてこういった思考がおろそかにされがちです。

システムの整理

ここで言う「システム」とはコンピュータの上で動いているものだけを指すのではなくて、運用とか業務とかも含めたものです。以下では「システム(広義)」と書きます。コンピュータ上で動いているものは「システム(狭義)」書きます。

元々「IT化」とは、システム(広義)を合理化するためのものです。

• 面倒臭い手間を省く(省力化)するとか、
• 大勢かかっていた人を減らすとか、
• 煩雑な書類への記入や転記を減らして間違いをなくすとか、
• 時間のかかる処理を早くするとか、

そういったことを目的として行われるものです。

軽微なものであれば、「あー、俺が楽になって良かった」ということだけでOKですが、システム(狭義)を使うことそれ自体は余分な手間ですから、全体としてはその手間をかける価値がある結果が出なくては成功とは言えません。

このため「システムエンジニア」は、システム(狭義)が完成した時のシステム(広義)を設計します。これが

システム(狭義)による業務改善

と呼ばれるものです。

このために行うもの多岐に上ります。

• システム化によって人が不要になれば、その人に振るべき仕事を考えたり、場合によってはリストラを(要請)します
• システム化によって業務手順が変われば、それに似合ったシステム(広義)を考えます
• システム化によって必要な資材が発生すれば、それを手当することを考えます

といったようなことをして、システム(広義)の完成となります。これらはどれを見ても、多かれ少なかれ「システム(広義)の変革」を要求します。

お金をかけてシステム(狭義)を購入する、あるいは開発をしてもらう場合、その影響範囲の考慮は当然されますし、場合によっては「システムコンサルタント」というような人達が登場することもあります。いわゆる「システムエンジニア」であっても、その辺のことは当然考えますし、導入する側に検討を依頼します。つまり、結構

大袈裟

なことになります。「大袈裟」なことになれば、いろんな「変革」についての根回しもしっかりされて「システム(狭義)を導入するんだ」という意識を持つことも出来ます。

しかし、LCNCは「手軽」に出来るのが売りです。それゆえ「システム(広義)の変革」についての覚悟や準備が足りないことがあります。これはLCNCの本質的な欠点ではありませんが、「真に役に立つシステム(狭義)」を作ったり運用したりすることの障害になりがちです。

データの設計

再び「名刺管理システム」を例にします。

「適切に名刺を管理する」ためには何が必要となるでしょうか？

当然「名刺」そのものを保持する必要があります。この時、どうすれば「適切」なのでしょう？

すぐに誰でも考えそうなことは、「名刺の内容を文字起こししてデータベースに格納」することです。こうすれば、後から検索したりするのに便利ですからね。この情報を使ってDMを出したりとかにも使いたいですし、部署で情報共有する時も便利でしょう。

しかしこの方法には問題があります。それは、

• 誰がそれを行うか
• その工数は確保できるのか
• それで「情報」として十分か

ということです。

まぁ実際にやってみればわかると思いますが、「名刺の内容を文字起こししてデータベースに格納」って、結構手間だし面倒臭いものです。てか、それが克服できるくらいだったら、多分とっくの昔に誰かがやってしまっているでしょう。おそらく、「今」作ろうとしてい「名刺管理システム」以前に、死屍累々の野良アプリが存在しては消えていたと思って良いです。

人手に余裕のあった時代であれば、「秘書」とか「書記」とか言われる事務雑用をやっている人がいて、「○○さん、この名刺をシステムに入れておいて」とお願いするだけで出来ただろうと思います。しかし、今時はそういった作業を専業とする職種の人はほぼ絶滅してしまい、「それぞれ」が行うのではないでしょうか？ そうなると、「名刺の内容を文字起こししてデータベースに格納」は面倒臭くてやってられないということになるだろうと思います。

そうなると、「文字起こしは諦めてスキャナで入れる」という案が出て来ます。そうなると、今度は「画像データベース」を扱うということになります。また、画像を保存するとなると、「文字情報」については「後から必要なものを必要な人が入れる」ことを考えないといけないかも知れませんし、あるいはOCR的なものが必要かも知れません。

「名刺」以外についても考えてみましょう。

その「名刺」について「誰がもらった」という情報は必要だと思います。では、「同じ人の名刺を複数でもらった」場合はどうなるでしょうか？ これは日本的なビジネスではよくある状態ですね。それぞれ別の「名刺」として扱うとなると、情報共有する意味はかなり減ると思います。とは言え、共有を考えないというのであれば、ここはある意味どうでも良いことになります(ゴール設定によっては、共有について考えなくても目的を達成できるかも知れません)。

このように、データの設計は結構いろんなことを考えないといけません。そして、それはあまり簡単なものではありません。

私が「駆け出しエンジニア」だった頃、「データベースの設計」とか「共有データ構造の設計」は、あまり「駆け出しエンジニア」の仕事ではありませんでした。なぜなら、考慮するべきことが多いので、経験の浅いエンジニアに任せることが出来ないからです。ここで間違えると、後々禍根を残しますから、簡単には行かないのです。もちろん今は当時とはいろいろ違いますから、多少のデータ構造の変更---たとえば項目の加除とか---についてはそんなに困難はありませんが、リレーションの変更はそこまで簡単ではありませんし、仮にデータベースの変更が簡単に出来たにしても、個々のプログラムへの反映はそうとは限りません。

残念なことに、この辺についてはLCNCは何も助けてはくれません(項目の加除については、いくらか助けになるかも知れませんが)。この辺もまた、「システムを開発すること」と「プログラムを書くこと」は違うということになります。

まとめ

このように、LCNCは「プログラムを書く」ことについては、大いに省力化してくれますし、技術者が不要になる可能性もあります。しかし、「システム(広義)を開発すること」については、それほど力になってくれません。

ここをはき違えると、せっかくLCNCを導入しても、「システム化(広義)」はうまく行きません。

なので、LCNCのプラットフォームを「導入する時点」でいろいろ仕組みを考えておく必要があるでしょう。