鈴木 裕太（すずき ゆうた）

多くの企業でDX推進がうまくいかない理由は大きく２つあると思います。

まず一つ目は技術のキャッチアップについての課題です。

システム開発のためには、フロント（UI/UX）エンジニア、バックエンドエンジニア、業務要件分析、インフラ整備などそれぞれの分野のスキルを持つメンバーからなる開発チームづくりが不可欠ですが、進化と変化の激しい昨今において、バランスのとれた開発チームを作るのが非常に難しい時代になっていると感じます。

フロント、バックエンド、インフラなどそれぞれの分野でエンジニアの専門化が進む中、全部の知識をバランスよく知っているエンジニアは少なく、何を使ったらいいのか、どう決めたらいいのか、変化をキャッチアップしていくのは手間がかかりすぎ、適切なツールやインフラの選定がとても大変な時代です。

2つ目は業務要件とスキル伝承に関する課題です。

昔のオンラインシステム黎明期、メインフレームでの大規模なシステム開発プロジェクトが普通だった時代は、ユーザー側にも業務要件を熟知している専任の担当者がいて、その方にヒアリング、ディスカッションすればだいたいのことは解決できる、というチームで構築するのが一般的でした。

しかし今や、PCやインターネット、クラウドベースでシステムのダウンサイジングが進み、システムやプロジェクトの規模はどんどん縮小傾向にあります。

特にリーマンショック以降はその傾向が顕著で、大きな予算を取れず大規模プロジェクトがどんどん減少している中、大規模システム構築に必要な知識、特に業務要件をシステムに落とし込むナレッジが伝承される場がないまま、企業の情報システム部門やエンジニアは経験の場を失っています。

このような問題は、システム開発会社もさることながら、特にユーザー企業で深刻かもしれません。

こまごましたメンテ作業はできても、大きなプロジェクトの経験がなく、上層部から言われたことをそのままSIerに丸投げするケースや、委託先のSIerにもそういった経験豊富な技術者がいない、というひずみがたくさん出てきている状況です。企業自ら業務要件を落とし込める人材がいない中、丸投げで全部やってくれとシステム開発をアウトソースしようとしても、ベンダにできるわけがありません。

数億～数十億規模のプロジェクトであっても、システム刷新に失敗した、といった話は昨今よく耳にします。

DXについての関心や需要は高まっているが、現実には作り手のスキルと経験が追い付かない時代、とも言えるでしょう。

企業のDX推進を全部ローコードでやろうとするのは、正直あまり得策ではないと考えます。

ローコードが流行っているからと「全部ローコードでできますよ」と思っていらっしゃる人は結構多いですが(笑)ローコードツールは万能なツールではなく、それぞれ特性や向き・不向きがあります。それをよく理解して、どこから手を付けどういうふうに使っていくかを見極めることが肝要で、やみくもな導入は危険です。

一番大きな間違いは「開発コストを抑えたいからローコードツールを導入したい」という考え方です。

ローコードツールはコストを抑えるための道具ではなく、スピードを優先する場合に有効なものです。ライセンス費用もエンジニアコストもそれなりにかかるので、トータルではコストがかかってしまうケースもあります。

私自身はOutSystems含めローコードツールの黎明期の頃から使っていてツールの特性や限界を良く知っているので、そういうことをお客様に最初にきちんと説明するようにしています。

ローコードツールは「技術的に優秀なエンジニアと、業務を良く知る顧客側が連携して短期間でシステムを作り上げるための道具」として非常に有効です。

ローコードツールの特性を熟知している優秀なエンジニアが、業務面の要件をしっかり吸収しつつ活用すれば、有効なシステムを非常に短期間で構築できます。しかし、優秀でないエンジニアが適当に使うと、ダメなシステムが量産されてしまうだけになります。

いきなり大規模システムで適用するのではなく、まずは小規模から始めるのが良いと思います。

小規模なPoC*開発（*Proof of Concept：アイデアの実現性・実効性を検証するための試験的な導入・運用検証のための開発）を繰り返し、課題フォーカスして少しずつ広げていくやり方には非常に向いています。

また、メインのERP（SAPなど）を導入する場合の周辺サブシステム（EXCELで運用しているものなど）をローコードで開発する、などの使い方も有効です。

逆にやってはいけないパターンとして、いきなり大規模なシステムを構築しようとしたり、コスト圧縮を目的にしてスキルの低いエンジニアを使って量産したり、というケースは失敗しがちです。

Javaやオープンソースをベースとした開発ならエンジニアは大勢いますしソースコードが資産として残りますが、ローコードだとツール前提のためローコードベンダに社内の重要システムがロックインされてしまう、といったリスクも考慮しておく必要があるでしょう。

いずれにしても、ユーザー企業としては、本気で社内のDXを推進しようとするなら、中途半端に社外の開発会社にアウトソースせず、可能な限り社内でエンジニアを抱え、業務にも詳しいチームを育てて対応するのが望ましいと考えます。

第1に「開発環境がすごく簡単に作れる」という点です。

Mendixモデラーをインストールするだけで、ローカルで実行環境まですぐ作れます。ワンクリック、ツークリック程度の操作でフルスペック開発ができてしまう環境を作れてしまう、というのはすごいところですね。

また、第2に「当初はライセンス不要」でスタートできるのもありがたいです。

要は、最初のとっかかりがすごくお手軽かつ簡単に始められる、というのが強みだと思います。本格導入した場合のライセンス価格も2021年に値下げされ、よりリーズナブルになりました。

第3に「構成管理バージョン管理機能が優れている」と言う点です。複数エンジニアが携わるシステム開発では、開発資産の世代管理が簡単にできることは必須の要件です。

他の某メジャーローコードツールではこの機能が貧弱で、ちょっと試してみるには向かなかったり、チームで分散開発に支障をきたしたりするケースもありました。Mendixは、マイクロサービスをローカル起点で試しながらの開発や分散開発に優れていますし、今後ますます重要となるUI/UX開発面でも「手元でちゃちゃっと試せる」ところが有利と思います。

第4に、Mendixなどの海外のメジャーなローコードツールは潤沢な資金をバックに開発競争が行われているため他と比べて開発や進化スピードが早く、１年半～２年でメジャーバージョンアップが行われるほか、マイナーバージョンアップでも結構機能追加されます。「ちょっと弱いな」と思っていた機能もどんどん改善されるので、そのあたりも大きなメリットですね。

当社にはオープンソース実装経験豊富な、スキルの高いエンジニア・チームがいます。

業務コンサル専任スタッフが要件をまとめるのではなく、エンジニア自身が上流で要件を理解してシステムを創り上げること、何より「いいものを創りたい」という思いを持って顧客や業務に向き合う姿勢がチームにあることが特長だと思います。

私自身も昔の8ビット16ビットのコンピュータ黎明期からスタートし、オープンソースベースでパーサなどの根本のしくみをつくってきたという技術ベースの上に、制御系・医療・薬局系などシステム開発の現場でお客様と直接コミュニケーションを取りながら仕様を取りまとめ提案するなど、ソフトウェア開発の源流から経験を積み重ねてきました。

そういったポリシーのもと、チームとしてMendixをはじめとするローコードツールの立ち位置、使いどころを熟知しており、開発会社としてあくまでお客様の目的達成のために最適のものを選んで提案できるところ、そして上流からお客様とともにチームで業務要件のとりまとめと付加価値の高い提案ができるところが強みだと思います。