SIも知っておくべき、ローコード開発でトラブルが起こる理由：特集：“コーディングのプロに嫌われない”ローコード開発（2）

「ローコード開発」に対する企業の関心が高まっているが、どう捉え、導入を進めればよいのか。考慮しておかなければならない点は何か。ガートナー ジャパンのアナリストに、ローコード開発の市場動向や注意点、今後の展望などを聞いた。

[齋藤公二，＠IT]

ガートナー ジャパン リサーチ＆アドバイザリ部門 アプリケーション開発／近代化／アプリケーション・ガバナンス担当シニアディレクター アナリスト 片山治利氏（写真提供：ガートナー ジャパン）

　「ローコード開発」に対する企業の関心が高まっている。Amazon Web Services（AWS）やGoogle、Microsoftが新製品をリリースしたり、トヨタ自動車やマツダといった日本を代表する企業がローコード開発ツールを採用したりするなど、エンタープライズ市場も活発化している。

　ローコード開発は、最低限のコードだけであるいは全くコードを書かずにシステム開発が可能なため、開発のスピードアップや低コスト化が見込める。一方で、「コードや成果物をどう管理するのか」「システムにトラブルが発生した場合に誰が責任を取るのか」など、考慮しておかなければならない点も多い。

　ローコード開発をどう捉え、導入を進めればよいのか。今回は、ガートナー ジャパン（以下、ガートナー）のリサーチ＆アドバイザリ部門で、アプリケーション開発／近代化／アプリケーション・ガバナンスを担当するシニアディレクター アナリストの片山治利氏に、ローコード開発の市場動向や注意点、今後の展望などを聞いた。

なぜローコード開発が盛り上がっているのか

──ローコード開発の盛り上がりをガートナーではどう見ていますか？　現状の背景には何があるとお考えでしょうか。

　多くの企業で導入が進み、期待も高まっています。ユーザー企業自身が内製化の手段として利用するケースもあれば、企業を支援するSIerやパートナー企業が積極的に利用するケースもあります。ガートナーではこの背景には大きく3つの理由があると考えています。「ニーズが広がったこと」「利用のハードルが下がったこと」「製品が進化したこと」です。

　1つ目は、これまでIT部門やSIerの手が回らなかった領域まで、システム化のニーズが広がっていることを指しています。具体的には、現場での生産性を高める活動や、デジタル化の中で新しいサービスを作るといった、よりビジネスに近い領域での取り組みです。速く、スピード感を持ってアプリケーションを作ろうとすると、これまでのように要件定義や設計に時間をかけていては間に合わない。それを実現するためにローコード開発ツールに注目が集まっています。

　2つ目の利用のハードルが下がったというのは、主にSIerやパートナーについていえることです。人月単価の受託開発ビジネスでは、ツールを使うことで全体の工数が減少することが懸念されていました。それが制約となってユーザーにも広がらなかった。今はむしろ開発の生産性を高めるために、ツールベンダーと協力して積極的にSIerやパートナーが採用しています。

　3つ目の製品の進化はさまざま面で進んでいますが、大きな変化は、UX（ユーザー体験）と使い勝手の向上です。かつてのツールは社内向けだからUIも洗練されなくていいと考えられていた。今はコンシューマー向け製品のような使い勝手を実現できる製品が増えています。

──デジタルトランスフォーメーション（DX）の取り組みの中で、ユーザー企業での内製化が進んでいることもあるのでしょうか。

　それもあります。今までは、ユーザー企業のベテランのエンジニアは、こうした事業部門が使うツールに対して消極的でした。自分の方が業務も知っているし、自分でコードを書いた方が早いと。ただ、新しいサービスを新規に立ち上げる場合、速く作って改善するスタイルですから、自分でコードを書いていたら間に合わない。また、現場でも、これまで紙や「Microsoft Excel」でこなしていた業務をシステム化していこうという動きが生まれています。その中で、ビジネスニーズに合ったツールをその都度選択する流れが起きています。

ローコード開発が求められる理由、嫌われる理由

──そもそもガートナーでは、ローコード開発をどのように定義しているのですか？　これまでにもEUC（エンドユーザーコンピューティング）の流れの中で、さまざまなツールが提供されてきました。マルチクライアント／クロスプラットフォーム開発ツールや、「Force.com」「kintone」といったPaaS開発環境、最近では、RAD（Rapid Application Development）ツールや超高速開発ツールもあります。これらとの違いは何ですか。

　ローコード開発は、挙げていただいたツールを全て包含させる考え方です。コーディングをする必要があまりない開発の手法やアプローチのことで、コーディングを全く必要としない「ノーコード開発」も含みます。かつてはそれぞれの特徴ごとに特定のカテゴリーの製品として分類していました。しかし、今は、それぞれの境界がなくなってきています。Windowsアプリの画面を設計するツールでモバイルアプリを作ることができたり、データベース操作ツールで業務アプリの画面を設計できたりします。

──それら全てを含めてローコード開発ツールとして捉えた方が理解しやすいということですか。

　そうです。さらに広く捉えた「ローコードアプリケーションプラットフォーム（LCAP）」という考え方もあります。これはローコード開発ツールを使って提供されるプラットフォーム製品のことで、ツールだけではなく基盤までを含めたローコード開発環境全体を指しています。このように定義を広くして、厳密なカテゴリー分けをしていないのが現状です。注意してほしいのは、ローコード開発ツールと一口にいっても、ツールごとに特徴があり、使い方もそれぞれ異なるということです。

──どのように製品の特徴を把握して使いこなしていけばよいのでしょうか。

　どのツールも同じような機能を提供し始めていますので「これはRADツール」「これはデータベース操作ツール」といった分け方をすると、どのツールを使えばいいか分からなくなります。私がお勧めしているのは、まず「誰が、それを使って開発するのか」から考えるということです。

　例えば、「現場の担当者がExcelで行っている業務の延長線上にあるようなシステムを考えているから、使い勝手が良く、Excelと同じような操作性を持ったツールを選ぶ」という形です。「プログラミング経験のあるエンジニアが開発効率を高めたい」という場合なら、開発者にとって使いやすいGUIを備えているツールが望ましい。誰が使うかで選択するツールは全く変わってきます。

　まず「誰か」を考えたら、次は「何をどうしたいか」を考えます。Excelと似たツールであっても、SQLを発行してデータベースの処理までしたい、基幹系システムと連携させたい、といった要件によって、ツールがそれらを機能として提供しているかを見ていきます。

──ガートナーでは、ツールベンダーの特徴や位置付けを評価したマップのようなものは提供しているのでしょうか。

　それぞれの製品を評価したレポートは幾つか提供しています。たださまざまなツールがローコード開発ツールとして集約されてきているので、ローコード開発ツールとしての製品を分類することは難しい。ユーザーは自社の業務にどのツールが適しているのかを判断する「目利き力」を養っていく必要があるでしょう。

Gartner Magic Quadrant for Low-Code Application Platforms（出典：Gartner）

──ローコード開発に対してはネガティブな評価もあります。例えば「スパゲッティコードを生みやすい」「メンテナンスできない」「パフォーマンスが出ない」「設計能力が大事だが人材がいない」などです。ローコード開発ツールは、これらを解決しているのでしょうか。

　さまざまなツールがあり、それぞれ特徴に違いがあり、用途にも向き不向きがあることに注意しなければなりません。エンジニアによるネガティブな評価はある一面では確かに正しい。生産性を高めたいと思っているエンジニアにGUIプログラミングを強制すれば生産性はむしろ落ちてしまうでしょう。現状の課題をローコード開発ツールの導入によって全て解決しようとするのは、そもそも間違いなのです。

ツールベンダーとパートナーのエコシステムを活用

──企業はローコード開発をどう導入し、活用していけばよいでしょうか。

　例えば「コードがスパゲティ化してメンテナンスができない」という懸念があるなら、スパゲティ化しないような工夫を施すことが重要です。開発のガイドラインを策定してユーザーに提供し、それに沿わない場合に教えるといった取り組みです。

　またパフォーマンスについても、システム全体に影響を及ぼさないような仕組みを作っていきます。パフォーマンスの問題が出ることは実際にあるので、データの検索の仕方などは注意しないといけません。パフォーマンスの問題は深刻な障害につながる可能性もあるので、こうしたトラブルを起こさないようなシステム設計が必要です。

　設計能力を持った人材がいないという場合、ツールベンダーにサポートしてもらうことも必要です。ベンダーから正しい使い方を教えてもらい、それを社内のエンドユーザーにも伝えていく体制を作っていきます。

──ローコード開発では他にどのようなトラブルが起こりやすいのでしょうか。

　「使い勝手が突然悪くなる」ということが起こります。ツールが提供する標準的な機能の範囲内でやっていれば問題ないのですが、ツールで実現できない部分を周辺で別に構築したプログラムや既存の外部の別プログラムと連携させて実現しようとすると、開発の手間やメンテナンスの手間が増え、利用のハードルが一気に上がってしまう。「どの範囲の業務をどのツールでカバーするのか」をきちんと決めておくことが重要です。目的と異なる利用をするのなら、そのツールにこだわらず別のツールに切り替えるといった判断も必要です。

──「目利き力」という話がありましたが、そもそもそうした判断をユーザー自身か行うことは難しいのではないでしょうか。

　自分たちのビジネスや課題を理解してくれるツールベンダーやパートナー企業を見つける（選ぶ）ことがポイントです。例えばkintoneならサイボウズのサポートだけではなく、kintoneの機能を拡張するツールを提供しているさまざまなパートナーのサポートも活用する。「Web Performer」ならキヤノンITソリューションズやそのパートナー、「OutSystems」ならBlueMemeをはじめその他のパートナーといったように、エコシステムを活用することです。自身でスモールスタートしてサポートを受けるかたちでもいいですし、SIerに最初の導入部分を支援してもらい、コンサルティングを受けながら利用を広げていくのもいいでしょう。

ローコード開発時代を象徴するような2つの事例

──導入や活用に当たって、事前にすべきことはありますか。

　考え方や意識を変えていくことが大切です。使えそうだなと思ったらまず使ってみる、この分野にも適用できそうだなと思ったら適用してみる。企業向けのシステム開発というと、しっかりと計画を立て、要件を定義し、十分なテストをしてリリースすることが当たり前でした。しかし、それでは時間がかかり過ぎるという案件が増えてきています。スピードが重視されるような場合、「完璧を求めずにハードルを下げて、まず実行する」ことは、ますます重要になっていきます。現場やIT部門だけではなく、経営層も含めてそうした考え方を身に付けることが求められるでしょう。

──ローコード開発で効果を発揮した代表的な事例があれば教えてください。

　私が特徴的だなと思ったのは、コロナ禍に伴う給付金申請業務で、さまざまな自治体がローコード開発ツールを活用してスピーディーにユーザーのニーズに応えたことです。具体的には、kintoneで申請処理システムを作って外部にもノウハウを公開した兵庫県加古川市や、「Microsoft PowerApps」や「Microsoft Power BI」で申請状況の確認サービスを開発した兵庫県神戸市などです。スピードが求められる中、各自治体の担当者自らが短期間でサービスを開発できた意義は大きい。やろうと思えばできることを証明した。ローコード開発ツールの普及を象徴するような事例だと思います。

──ローコード開発は今後どう展開していくとお考えですか。

　DXの取り組みの中で新しいサービスや業務プロセスの効率化を素早く作るというニーズが高まっています。また、コロナ禍の影響で、ビジネス環境がより厳しくなっています。コストの最適化を図りながら、新しいサービスや業務プロセスの効率化を実現するアプリケーションを迅速に作るニーズに対して、ローコード開発はうまくフィットします。今後、ローコード開発ツールのニーズが高まっていく可能性は高いと見ています。

制約の中で企業が独自性を出すための有効な選択肢

──ローコード開発によって、SIのコーダーや開発者の役割は変わるのでしょうか。

　ローコード開発が担う領域は広がっていきますが、だからといってコーディングが廃れるわけではありません。むしろ、ローコード開発でできない部分をコーディングすることの重要性が高まるため、コーディングの存在感は増していきます。適材適所でうまく使い分けていくことになります。

　その中でも、ユーザーが必要とされるものを作るという開発者の役割はこれまでと全く変わりません。アプリケーションのアーキテクチャやテクノロジー、アプローチは進化し続けますから、それらを学び、キャッチアップしていくことが求められます。ローコード開発はアジャイル開発と親和性が高いので、アジャイル開発に向けて開発プロセスを変えていくことも求められます。

──ユーザー企業のIT部門の役割はどう変化しますか。

　外注に依存する体制はしばらく続きそうですが、内製化への期待も高まっています。内製化しやすいところにローコード開発ツールが採用されるケースは増えていくでしょう。

　ローコード開発はパッケージと手組み開発の中間に位置するような製品です。SIerからの提案を“うのみ”にするのではなく、自分たちで考えていくことが求められる中、「パッケージがいいのか、手組みがいいのか、それともローコード開発がいいのか」という検討の中での新しい選択肢にもなります。

　SIerやパートナーにローコード開発ツールの利用を訴えていくことで、開発の主導権をユーザーに取り戻す手段の一つにもなるでしょう。ローコード開発は、時間やコストなどの制約が多い中で、ユーザー企業が独自性を出す手段でもあるのです。

特集：“コーディングのプロに嫌われない”ローコード開発

DXトレンドが進展し、ビジネスニーズに応えるスピードが差別化の一大要件となっている。それが社内向け、社外向けであるかを問わず、「ニーズに応えるアプリケーション」開発を、従来のように逐一外部に依頼するスタイルでは、現在のビジネススピードに対応することは難しい。特に、ITがビジネスとほぼ同義になっている今、SoE領域／競争領域のアプリ開発を外部に依頼することは、ビジネスノウハウという無形資産の流出にも等しい。とはいえ、社内に十分な開発リソースを持つ企業は限定的な他、新たに開発人材を雇用することもハードルが高い――こうした中で、今改めて注目を集めているのが「ローコード開発」だ。では具体的に、ローコード開発はDX推進に何をもたらすのか、情シスやIT部門にどのような影響を与えるのか。本特集では“既存の見方”も踏まえつつ、事例も含めて「ローコード開発の今」を徹底解説する。

特集：“コーディングのプロに嫌われない”ローコード開発〜DXに寄与する情シス、頼られる情シスになる方法〜