ノーコード・ローコードでシステム開発の内製化は進む？

システム開発においてノーコード・ローコードという潮流があります。GUI上でパーツを配置したり、マウスでポチポチ設定を行うだけで、プログラムコードを書かずにシステム開発ができるツールやプラットフォームのことです。私は実際にクラウドのノーコード・ローコードプラットフォームであるServiceNowで開発を行っています。そして、ノーコード・ローコードはしばしば内製化と同じ文脈で語られ、内製化を推進するツールとして紹介されます。このあたりについて考えを書きます。（なお、この記事はSalesforce, ServiceNowのようなある程度リッチなことができるプラットフォームを想定しています）

ノーコード・ローコードのメリット　開発及びテスト工数の大幅削減

まず、一般的に言われているメリットで合意できる点として、開発・テスト工数の大幅削減があります。ノーコード・ローコードではコードを書く部分が少ないor無いため、設計まで終わっていれば、実際に開発（設定）を行うことはすぐにできます。また、多くの機能がプラットフォーム側で保証されているため、テストすべき部分が少ないです。スクラッチ開発で例えると、動作保証済みのライブラリが大量にあり、ライブラリを呼び出して結果を橋渡しするコードだけを書けばよい、という状態になっています。

ノーコード・ローコードはシステム開発全体の難易度を下げるか？

（スクラッチだろうがノーコード・ローコードだろうが要件定義が必要なことは明らかだと思うので、ここではシステム開発を狭義に設計・開発・テストと定義し、これらの難易度が下がるかについて考えます）

コードを書かなくてよいことは、そのままシステム開発全体の難易度を下げることを意味するのでしょうか？私はNOだと考えています。開発はコーディングやテストだけではありません。実際のシステム開発では手を動かして開発をしたりテストをする時間よりも、どんな技術を使うか、どんなアーキテクチャにするか、何をテストすればよいか、という頭を使う時間のほうが長いです。ノーコード・ローコードを使っても、この時間を減らすことはできないのです。では、なぜ開発が簡単になるのに設計は簡単にならないのでしょうか。私は2点の理由があると思っています。

1点目は、システムの裏側のを理解していないと、無駄が多く、保守性の低いシステムになってしまうという点です。確かにノーコード・ローコードプラットフォームを使うことで、細かい設計をせずともとりあえずシステムを形にすることはできます。しかし、プログラミング、データベース、ネットワーク、セキュリティなどの知識を持たずに作ってしまうと、例外処理が甘くユーザが想定外の操作をしたときにシステムが停止してしまったり、CRUDの権限制御が甘くデータの不正な読み書きが可能になってしまったり、外部システムとの連携で基本認証の設定を選び企業のセキュリティ基準を満たさなくなってしまったりしてしまいます。

2点目は、ツールやプラットフォームによる機能の制約を考えて設計をするという別の難しさがある点です。例えば、スクラッチ開発では簡単にできそうな「この情報をこの画面に出したい」が、ノーコード・ローコードでは意外と難しかったり、場合によってはどうしても実現できなかったりします。このような場合は、存在する機能でどう代替するかを考えるといった工夫が必要になります。つまり、制約の多い状態でどのようにシステムを作り上げるか、という別の難しさが存在するのです。

もちろんこれは今の時点での状況であり、今後ツールやプラットフォームに従って作れば、誰がどのように作っても最適化されたシステムが出来上がる仕組みができてくるのかもしれません、しかし、ServiceNowを日々触っている私としては、まだこのレベルには到達していないと思っています。

誰でも開発ができることが内製化？市民開発者（シチズン・デベロッパー）による環境汚染

ノーコード・ローコードプラットフォームの台頭とともにキーワードになっているのが、市民開発者（シチズン・デベロッパー）です。これまではシステムを利用するだけだった業務部門のメンバなども含め、誰でも開発者になれるという考え方です。これにより、ユーザ企業のIT人材不足を解決し、内製でのシステム開発を推進していこうとしている企業もあるようです。

しかし、これまでITの理解を放棄し、これがしたいあれがしたいと要求だけを言ってきた業務部門の人間が開発能力だけを手にしたらどうなるでしょう。自分たちに都合の良い個別最適のシステムを作り、プラットフォームを荒らしていくことが容易に想像できます。これまでITの人間が何十年もかけ経験の中で失敗しながら学んできたことを、再び何十年もかけてなぞることになるリスクがあります。実際に、既にある企業では無秩序な開発によりServiceNow環境がカオス状態になっており、年に一回のバージョンアップ対応に莫大な費用をかけているという話を聞いたことがあります。

とはいえ、私は市民開発を否定しているわけではありません。業務を理解した人たちが秩序を乱さず開発ができるようになれば、開発者と利用者による対立や、無駄なコミュニケーションを減らすことができます。最後に、このようなローコード・ノーコードのメリットをうまく享受するために必要なことを考えます。

トレーニング、プラットフォームの統制強化が優先

ノーコード・ローコードプラットフォームを活用して非IT部門のメンバーも開発をできるようになると、個別最適化や再レガシー化が今まで以上に発生しくなるため、それをどのように回避していくかがカギになります。個人的には、ノーコード・ローコードプラットフォームでは、市民開発者を含む開発者のトレーニングと、利用ルールや開発規約整備といったプラットフォームの統制強化が重要だと考えています。

トレーニングという観点では、そのノーコード・ローコードプラットフォームの使い方だけでなく、一般的なITやシステム開発に関するトレーニングが必須になるでしょう。ノーコード・ローコードプラットフォームを活用していきたいと考える企業は、このような投資をしっかり行い、トレーニングを行うべきです。しかし、このトレーニングだけでは不十分です。開発方法だけを教えてしまうと、プラットフォーム上に個別最適ツールが乱立し、手が付けられなくなることが予想されます。

プラットフォームのガバナンスという観点で、利用ルールや開発規約を明確にすることも必要だと考えます。例えばカスタマイズ（コーディング）はどの程度許容するか、ネームスペース（スコープ）はどのように区切るか、プラグインの有効化や開発物のリリース作業、バージョンアップは誰がどのように対応するか、開発権限の管理などのアカウント管理はどうするか、などです。また、開発権限を非IT部門にも渡す場合には、IT部門のメンバがプラットフォーム全体を見て影響の確認や設計のレビューを行うプロセスを整備することも必須です。

このような事前準備を行った上で、実際にシステムを利用するエンドユーザや、そこにに近い人たちが直接開発、保守を行えるようになれば、DXレポートで指摘された「IT関連費用の80%が現行ビジネスの維持・運営に割かれている」というような現状を脱却し、ITのメンバはプラットフォームの管理や、ITを使って企業の競争力を高めるDXの推進などのより高度な業務に専念することができるようになるのではないでしょうか。