今、流行の「ノーコード」は有効なのか
今、システム開発を行う環境に「ノーコード」を選択する企業が増えています。確かに「ノーコード」や「ローコード」は、システム開発の経験がない方でも簡単にシステムを作る事ができます。そして、システム化された業務の生産性は、一見高くなったように見えます。
ここで、「一見」と言ったのは、今から３０年以上前に流行った「エンドユーザコンピューティング（EUC）」を思い出したからです。
その昔、IBM が販売していた「NOTES」というグループウエアーがありました。コンセプトは、文書をデータベースにするという画期的なシステムです。ここで重要な点は、文書をデータベース化するためには、プログラミングが不要であるという、今の「ノーコード」と同じメリットがあると言われていました。実際、業務日報やマニュアルなどを電子化して、それらを検索するなどのシステムは、簡単に作る事ができました。
しかし、業務に使える仕組みを構築する場合、かなりの「NOTES」の内容を理解しないと構築できず、結局、専門家に任せるなければなりませんでした。
つまり、簡単な仕組みであれば、誰でも簡単に構築する事が出来ので、個人レベルで使用する仕組み（あえてシステムは呼びません）が、アッという間に何百と作られました。中には、専門家と同等の機能を有した仕組みもあり、特定部門内で利用されて業務の生産性向上にそれなりの成果を生みました。
同様に、最近のIT関連の報道では、「ノーコード」システムによる業務効率化が企業成長の原動力になっていると盛んに語られています。
しかし本当でしょうか？
「ノーコード」に死角は無いのか
ここで問題が発生します。その一つが、「誰がその仕組みの維持管理するか！」です。仕組みを作った人は、人事異動で他部門に移籍すると仕組みを維持管理できる人が居なくなります。その仕組みが組織内で機能している場合、とても大きな問題となます。仮に不具合や変更する必要が発生した場合、すでに転籍した作成者に仕組みの変更作業を依頼しなければならなくなります。つまり、仕組みを作った人は、新たな職場での仕事の他に、前の職場で作った仕組みの維持管理の仕事も追加されていきます。果たしてこのような状況は、本当に組織にとって良い事なのでしょうか。
もう一つの大きな問題は、データに統一性を維持できず「ごみデータ」ばかり蓄積してしまう点です。個人レベルで開発した「仕組み」は、個人の業務の範囲でしか考慮されておらず、隣接する部門とのデータ連携を考えない（られない）のです。よって、特定の部門では有効なデータであっても、全社レベルでは「ゴミデータ」となってしまうのです。
「ノーコード」「ローコード」は、確かに局所的な現場のIT化において即効性がありますが、前述の通りの保守性に難があったり、データの正確性に問題があったりするために、企業成長のためのIT化という観点からの効果が出ないばかりか、逆に阻害する結果となる可能性があります。
その点を考慮して利用する事が大切です。
使う側と作る側は分離すべきである
岡目八目とでも言いましょうか、立場立場で同じ事象でも見え方が全然違うという事が日常茶飯事に発生します。特に、システム化は、この傾向が強いと思います。
現場の合理化ニーズは、会社全体で俯瞰すると生産性を損なう愚策である場合も多々あるのです。例えば、入力の合理化を図るという目的で、あれもこれも一つの画面で行えるようにする要望があったとします。確かに、データ入力をする担当からすると、全ての作業を一つの画面で済ますことが出来れば楽になるかもしれません。
しかし、どのような機能開発をする場合でも、データの整合性を保つための機能を備えておくことが大変に重要です。しかし、現場の担当者は、そのような事を考慮せずに仕組みを作ってしまいます。その結果、データが蓄積された後になって、データの整合性が無いこと（例えば同じ事・藻に対して違うコードを割り振るなど）が発覚して、せっかく蓄積したデータが単にゴミデータである事が発覚して、全社的な目的を達成できない事が発生します。
私は、このような事例を沢山見てきました。このような事態を回避するんは、使用する現場と開発する者を分離する必要があると考えます。もっと詳しく言うと、
現場 ⇔ 経営者（CEO） ⇔ システムアーキテクチャー（CIO) ⇔ 開発者
の４層構造が望ましいと考えます。よくあるパターンで、経理部門が直接ベンダーに経理システムを発注し、人事部門も直接ベンダーに発注する。その結果、「経費関連のコードが社内的に統一されていない」や、酷い場合は「経理システムと人事システムの社員コードが統一されていない」などの根本的な問題が存在したりします。
こうなると、せっかくIT投資を行い社内リソースの適切な利用・活用を目指していても結局は目的を達成できない羽目に陥るんです。
IT投資は基盤システムから投資せよ
過ちは、何度も繰り返すのが常です。「ノーコード」や「ローコード」の流行は何度も起こりました。今、一番問題となっているのはエクセルシートではないでしょうか。これも「ローコード」の一種だと思います。担当者の業務効率を上げる為にマクロを駆使して自動計算させたり、自分専用のコードマスタを作成したり、好き放題に仕組みを作った結果、だれもメンテナンスできなくなっていないでしょうか。
エクセルが悪い訳ではなく、少なくとも社内の情報を整理して、「社員マスタ」などマスタ化しなくてはならないものは、ちゃんとしたシステム上に構築する必要があります。経理部門でAさんの社員番号が「１０」なのに、別の部門では、Aさんの社員番号すら存在しない様では、全社的に整合性があるシステムは構築できません。
まず最初に、IT基盤を整備するために投資を行うべきです。
セキュリティーもIT基盤
IT化を進めると問題になるのは、やはりセキュリティーです。つまり、情報が漏洩すると社会問題になり企業の存続自体が危機に直面します。セキュリティー対策には、様々なアプローチがありますが、一番大切な事は、システム全体にセキュリティー維持のための仕組みが組み入れられているかが問題です。
「ノーコード」や「ローコード」で全社統一のセキュリティ基準を満たす事は至難の業だと思います。やはり全社的な統制を行う必要があり、そのためにもIT基盤の整備が必要です。
結論
昔から「ノーコード」や「ローコード」に対するニーズは沢山あり、前述の「NOTES」や「ACCESS」などEUC（End User Computing）ツールが沢山出回っています。しかし、それらのツールはどんどん市場から消えていきました。
未来も「ノーコード」や「ローコード」の仕組みを使うのではなく、ちゃんとしたIT基盤上にプログラムをコーディングして運用する事が大切だと考えます。
プログラミング自体も、現在、脚光を浴びている「生成AI」の進化により一から言語を学ぶ必要が薄れ、「チャットGPT」にソースコードを教えてもらえば何とかなる時代が来ています。
現場は、正しいデータの入力と、システムから得られる正しいデータを活用する事に専念し、システム開発は経営者の経営判断であるという基本事項を念頭に、全体最適を実現する基本設計を行ったうえで、その基盤上に個別のシステムを開発すべきであると考えます。
統制がとれていないシステム（野良システム）が蔓延すると、後々収拾がつかなくなることを肝に銘じておくべきです。
終