【今こそ、ローコードを考える】第2回 ローコードの要素

LANSAは30年余りにわたり、一貫してAdvance Software made simpleを掲げてIBM i やWindows環境の開発の一翼を担い、ローコード開発環境を提供してきました。

そして、いろいろな意味で大きく環境が変わる昨今、開発環境についてローコード(Low-Code)への期待が日本でも高まっています。

今回のシリーズでは、ローコードのテーマを中心にLANSAを紹介させていただきます。

• 第1回　ローコードの背景
• 第2回　ローコードの要素
• 第3回　ローコードの理想と現実
• 第4回　LANSA V15のハイライト
• 第5回　LANSAのPWA(プログレッシブWebアプリケーション)

第2回は、もとめられる「ローコードの要素」を解説させていただきます。

ローコードの要素

適切なローコードソフトウェア開発プラットフォームは、ソフトウェア開発ライフサイクル全体のコストを大幅に削減します。また、さまざまなデバイス、インターフェース、プラットフォームにプロジェクトがどのように展開するかを心配する必要がなくなり、ビジネスアプリの迅速な提供に集中できるようになります。

以下は、ローコードプラットフォームを評価する際に考慮すべき主要な要素のリストです。これらのすべての領域に対応する適切なソリューションを見つけることで、アプリ開発を単純化し、更新の周期を短縮し、長期的に変化する基盤テクノロジーから開発者を保護するのに役立ちます。

ローコードプラットフォームに求められる重要な要素：

1. 幅広いアプリ作成機能
2. 新規と既存のシステムとの簡単な連携
3. 開発環境の適用範囲
4. ビジネスルールによるアプリ保守の大幅な軽減
5. 幅広いクロスプラットフォームのサポートと導入オプション

1. 幅広いアプリ作成機能

最も効果的なローコード開発プラットフォームは、企業向けのWebやモバイルアプリを作成するラピッド プロトタイピング、設計、展開の段階で役立ちます。基盤となるプログラミングコードからビジネスロジックを分離することで、保守し易いアプリの構築に役立ちます。

• リアルタイム プロトタイピング

  ビジネスアナリストやエンドユーザーと協力して、アイデアを具体化し、プロセスを最適化できるように、直ちにプロトタイプを用意する必要があります。リアルタイム プロトタイピングを使用してユーザーのフィードバックを早い段階で収集すると、開発フェーズの後工程で時間を節約でき、ユーザーの好感を大幅に向上させることが確認されています。

  いくつかのローコード開発プラットフォームは、プロトタイプのパーツを実際のビジネスロジックを反映した実際のプログラムに置き換えることで、最終的なアプリに置き換えることができます。これが可能であると、プロトタイピングの労力が無駄にならず、完成したアプリを以前よりも迅速に提供できます。

• 柔軟な展開オプション

  通常、ローコードプラットフォームは携帯電話、タブレット、デスクトップ、Webブラウザーまでさまざまな種類のデバイスに展開するニーズに対応します。したがって、レスポンシブデザインが採用できることが必須です。 多くのローコードソリューションは、モバイルファーストのアプローチを採用しているために、デスクトップバージョンの提供には追加の開発の必要があることが注意点です。

  最高のローコードプラットフォームは、一つのコードベースからモバイルとデスクトップの異なるバージョンを提供します。 モバイルバージョンは小さな画面向けに最適化され、デスクトップバージョンは大きな画面向けに最適化されて、エンドユーザーの生産性を可能な限り高めるWindowsのようなユーザーエクスペリエンスを提供します。

• 開発者の生産性

  ローコード開発プラットフォームは、基礎となる技術の詳細レベルの記述を不要にして、高い効率と短い学習曲線を実現する直感的な開発環境を提供し、開発者の生産性を高めるように設計されています。

2. 新規および既存のシステムとの簡単な連携

多くのアプリは、特定のタスクをサポートする単一の機能と見なすことができます。実際にアプリの背後には一連の複数の連携ポイントがあり、データベース、内部および外部API、接続されたデバイスなどのさまざまなコンポーネントと通信します。したがって、この複数のコンポーネントとの連携は、ローコードプラットフォームにおいて重要な強みとなります。

多くのローコードプラットフォームは、RESTful APIを使用して「すべて」と連携すると説明しています。RESTful APIには重要な役割があることは間違いありませんが、一方で常に利用できるとは限りません。連携を行うために開発環境外でラッパー等を別途開発する必要がある場合があります。ローコードソリューション外の環境での開発を削減するように設計されていますが、どのような場合に外部環境の開発が必要かは注意が必要な点です。

したがって、より幅広い連携ポイントと連携する機能がある方が外部環境で開発を実質的に削減することができます。ほとんどのシステムには、ビジネスを実行するコードを含むEXE、DLL、NETコンポーネントを備えたレガシーアプリがあります。RESTful APIとしてラッピングの作業を別途行わずにこれらを連携できることが重要です。

強力なローコードプラットフォームは、次のようなさまざまな連携ポイントをサポートする必要があります。：

3. 開発環境の適用範囲

アプリのあらゆる場面にすばやく取り組むことができるフルスタックの開発者(複数の技術分野についての知識や技能に精通した技術者)を採用することは非常に困難で費用がかかるため、企業がローコードソリューションに興味を持つことが一般的であることは既に述べた通りです。ローコード開発プラットフォームは、開発者を煩雑さから解放し、開発者に代わってすべてのソースコードを自動生成することにより、アプリ開発を加速します。

開発者は、生成されたコードを確認する必要はありません。しかし、一部のプラットフォームでは、ローコードソリューションのサポート範囲を超えた機能を保守または拡張する場合に、生成されたコードをローコード以外の環境に持ち出し保守する必要がある場合があります。一度Visual StudioやEclipseに持ち出し、従来のアプリ開発環境に戻すと、ローコードの利点と期待を裏切る結果となります。さらに、ローコード環境から一度外に出てしまうと、完全に統合されたDevOpsプロセスが中断することは言うまでもありません。

アプリを構築、維持、拡張する場合、最適なローコードプラットフォームでは、開発者がローコード環境を離れる必要はありません。

開発者がローコードの環境外での作業を余儀なくされることが多いほど、開発者が従来のアプリ開発環境に戻らなければならないため、これらのプラットフォームの「ローコード」の適用範囲が小さくなります。これにより、ローコード環境の内部と外部の両方で保守を行う必要があるために、保守の労力に大きな影響を及ぼします。

機能が十分でないローコードプラットフォームでは、上記の状況が次の場合にしばしば起こります。：

• 画面の再設計-アプリのデバッグ
• 外部環境でのコードの変更-アプリの展開

開発環境内でこれらのタスクを実行できる場合は、開発と継続的な保守の両方が断片化することはありません。 また、最初の開発者がプロジェクトから離れた場合でも、新しい開発者を組み入れることもはるかに簡単です。

4. ビジネスルールによるアプリ保守の大幅な軽減

データの処理方法の詳細を記述するビジネスルールは、アプリにとって非常に重要です。アプリの記述では、次のもの記述されます。；

• データ定義
• テーブル定義
• 接続
• 関係
• ビジネスロジック

ルールの保守は、システムのライフサイクルにわたる継続的な課題です。多くの場合、複数のアプリが同じルールを参照して使用する必要があります。すべてのプログラムでそれらを一つ一つハードコーディングすると、保守の負担が増加し、ルールが複数の場所に存在することによって潜在的な不整合が生じます。

すべての定義、接続、ルールを、アプリの外部にある一元化されたビジネスルールエンジンに格納することで、アーキテクチャ上の大きな利点を得ることができます。これを実現すると、ルールが変更に対してそれを使用するすべてのアプリが自動的に変更を継承することができるようになります。すべてのアプリでルールの実行を保証することができるようになります。

ハイエンドのローコードプラットフォームは、アプリ本体からビジネスルールエンジンを以下のように分離します。：

• 単一リポジトリでの定義の作成、保管、保守

  ルールエンジンの基本原則は、データ定義を、動作するアプリやデータベースから分離することです。すべての開発者は、リポジトリの定義を簡単にアクセスできるようになります。これにより、アプリのレイヤーとデータ定義を分離できるため、たとえば、他のアプリに影響を与えることなく、あるデータベースから別のデータベースに置き換えることができます。

• 独立したデータサービスレイヤーでの定義の保存

  データベースレベルでルールを展開することの欠点は、すべてのデータベース製品がトリガーとストアドプロシージャを独自の方法で実装する方法を持っていることです。これにより、一度作成されたアプリはデータベースを置き換えると特定のデータベース機能を使用できなくなります。ルールエンジンとしてアプリ層でルールを挿入することにより、データベースへのロックインを回避できます。ただしこの場合は、すべてのプログラムはソースコードを複製する必要があり、コードの管理に矛盾や困難が生じる可能性があります。

  理想は、ルールエンジンをデータベースとアプリとも分離して、独立したデータサービスレイヤーを提供されるモデルです。 このアーキテクチャの利点は、アプリの変更や再コンパイルなしに、ルールエンジン内で行われた変更を、自動的に適用することです。

• 既存のデータスキーマのインポート

  多くのプロジェクトでは、既存のデータベースを使ってアプリを拡張する場面があります。開発者が既存のデータ、スキーマ、ストアドプロシージャ定義をローコードプラットフォーム外のソースからインポートして、ルールエンジン内で使用できるかは考慮が必要な点です。

• ローコードプラットフォーム外のプログラムからのビジネスルールのアクセス

  使用されている開発環境(ローコード、RPG、COBOL、Java、C＃、PHP、VB、JavaScriptなど)に関係なく、ルールエンジンを任意のアプリから利用できる場合は、アプリは、その開発時期や技術に関係なく恩恵を受けます。ビジネスルールの共通セットですべてのアプリのデータベースI/Oを管理し、データの整合性を大幅に向上させることができます。

  ローコードプラットフォーム以外でビジネスルールを使用できない場合は、それらを複製する必要があります。ルール定義の重複、保守の重複を意味し、ビジネスルールの不整合につながる可能性があります。

  ルールエンジンは、ルールが全てに適用されることを理解した非開発者(ユーザー)の保守も可能になります。

  このアプローチにより、次のことが簡単になります。：

  • 変更リクエストの実装
  • 新しいアプリ機能の追加労力の軽減
  • 保守を担当する新しい開発者の受け入れ
  まとめると、これらのことにより、アプリの保守の負荷が大幅に軽減され、その結果コストが大幅に削減されます。
  

  5. 幅広いクロスプラットフォームのサポートと展開オプション

  ローコードソリューションの利点の1つは、基盤となるテクノロジーから開発者を保護し、あるテクノロジーから別のテクノロジーへの移行を容易にすることです。展開オプションについても同様です。多くの導入オプションを備えたローコード開発プラットフォームは、将来の移行パスを柔軟にして、必要に応じてアプリを別のテクノロジースタックに簡単に移植するのに役立ちます。

  ローコードプラットフォームは、次のような幅広い導入オプションと機能をサポートすることが重要です。：

  Webアプリ:	電話、タブレット、デスクトップブラウザでの表示を最適化するレスポンシブデザイン。
  モバイルアプリ:	すべてのデバイス用のWebブラウザー。あらゆる画面サイズのiOS、Android 、Windows Mobileデバイスのハイブリッドやネイティブ環境。
  データベース:	Microsoft SQL Server、Oracle、IBM DB2、Sybase SQL Anywhere、MySQL、 MongoDB、他のすべての一般的なリレーショナルおよび非リレーショナル（NoSQL）DBMS。
  サーバープラットフォーム:	特定のニーズと要件に応じて他のプラットフォームの利用可能性があるWindowsおよびLinux。
  場所:	クラウド、オンプレミスまたはハイブリッド。

  移植性は、上記の展開オプションと同様に重要です。高品質のローコード開発プラットフォームは、アプリの変更を、ほとんど、あるいは行わずにサーバープラットフォームやデータベースの移植を容易にします。クラウドとの間の移行も、ハイブリッド環境をサポートするだけでなく、単純なプロセスでなければなりません。

  モバイルやWebアプリに加えて、ラップトップおよびワークステーション用のスタンドアロンまたはクライアントサーバーのWindowsデスクトップアプリ、ジョブスケジューラから開始されるWindow サーバープログラムは、多くのシステムで重要です。Windowsがインフラストラクチャの重要な部分である場合、ローコードソリューションはネイティブWindowsアプリの構築もサポートする必要があります。

  テクノロジーの向こうに

  適切なローコード開発プラットフォームは、TCOを大幅に削減することができます。これには、初期の設計と開発だけでなく、進行中のアプリの保守、拡張、最新技術の適用も含まれます。したがって、アプリの初期生成のみならず、簡単に保守拡張できる機能は、ローコードのプラットフォームを選択するときに重要な考慮事項でなければなりません。ローコード開発プラットフォームの技術的な考慮事項に加えて、パートナーとなる適切なベンダーを選択することも非常に重要です。ローコードソリューションの場合、以下の要因を考慮する必要があります。：

  ベンダーが開発の取り組みを継続的にサポートできるようにすることが重要です。

  • プロジェクトの数とタイプを含む、アプリ開発で顧客をサポートした実績
  • 新しいテクノロジーを最新に保つ実績
  • POCプロジェクトをサポートする能力
  • 提供されるサポート、研修、指導/助言オプション
  • プロフェッショナルサービスの提供
  • カスタマーレビューとリファレンス

  デジタルトランスフォーメーションプロジェクトは多くの場合に数年かかることがあり、ローコードアプローチは提供にかかる時間を短縮しますが、ベンダーとそのプラットフォームが長期にわたって存在することも重要です。

  第1回と第2回のまとめ

  市場は急速に進化しており、将来的に成功するビジネスは、テクノロジーを利用して競争を激化させ、得られるチャンスを最大限に活用することになります。これは新しいシステムとアプリを作成するか、既存のものを刷新して最新化していく必要があることを意味します。

  従来のアプリ開発は不十分であり、ビジネスのイノベーションで求められる厳しいスケジュールでの対応は困難です。

  ローコード開発プラットフォームは、簡単な導入と保守機能を備え、ビジネスニーズを満たすための高品質のアプリを提供するための、より新しくより優れた方法を提供し時代の要請に応えます。

  ローコードは、大小さまざまな組織にとってこれまでになく利用しやすく、新しいアプリがビジネスに革命的価値を提供する最大の機会を提供します。

  今回は、新しいアプリを構築する際の課題と、ローコードでそれらの課題にどのように対処できるかを紹介し、さらに、ローコードのプラットフォームの選択にあたり考慮すべき項目をまとめました。

  LANSAは、業界をリードするローコードプラットフォームVisual LANSAで、信頼できるパートナーになる準備ができており、サービス、サポート、専門知識とともに、より良いアプリ開発を通じてビジネスを革新、改善、変革するためのお手伝いをさせていただきます。

  第3回は、「ローコードの理想と現実」を解説させていただきます。