ローコード能力モデル

前置き

low-code の大旗の下、様々なローコードプラットフォームがひしめき合っています：

• 応用シーン：PC 中后台、モバイル H5、ミニプログラム、React Native などのクロスエンドもあり

• コア機能：UI 編成、（ロジック）フロー編成、さらにはサービス編成まで

• インタラクション方式：フォーム設定、ドラッグアンドドロップ、さらにはリッチテキスト拡張まで

いくつかの疑問が浮かびます：

• それらと比較して、私が現在行っている（または行おうとしている）ローコードプラットフォームにはどのような特殊性があるのか？自分で解決しなければならない重要な問題とは何か？

• 手元のプラットフォームは現在どの段階にあるのか？次の段階はどこか？どのようにして次の段階へ進むのか？

これらの疑問を解くために、能力モデルを構築し、ローコードプラットフォームの変化に跡可循るように尝试します

一.ビジネスシーン

能力モデルの第一次元はビジネスシーンで、カバーするビジネスシーンが多いほど、ローコード能力は強くなります

異なる角度からビジネスシーンを異なる划分可以进行，例えば：

• 製品：2C、中后台

• ビジネス：マーケティング活動、フィードバックフォーム、常规図文展示、複雑なリッチインタラクション

• エンド：モバイルエンド、PC Web、ミニプログラム

このような大分類はすべてのビジネスに適しているとは限りません。ビジネスの重要性（核心、重要、边缘）、差異程度（使用する技術体系、面向するユーザー群体）などに基づいて具体的に划分できます。必要であれば、さらに各サブ次元に細分化することもできます。目的は既存のローコード能力が目標ビジネスシーンに対する支持程度を定量的に記述し清楚にすることで、プラットフォームはすでにどの数種類のビジネスシーンを満たすことができ、未来にはさらに哪些を満たすことができるのか？

垂直シーンの划分的基础上，さらにクロスビジネスライン投放、クロスエンド搭投、一搭多投などの混合の探索方向を派生させることができます

二.ユーザー群体

第二次元はローコードプラットフォームが面向するユーザー群で、ユーザー群体が大きいほど、ローコード能力は強くなります

一般にユーザーの専門程度に基づいて分類します：

• 特定の技術人員：フロントエンド、バックエンド、DBA などの専門人員

• 一般技術人員：ある程度のロジックコーディング能力を持つ開発人員で、式、イベントなどの概念を素早く理解して運用できる

• 非技術人員：開発経験のない製品、運営、商務、行政人員

もしプラットフォームの最終目標が非技術人員に面向するものであれば、機能に対して高度な抽象化を行い、下層の技術詳細を屏蔽して、使用の敷居を下げ、より広範なユーザーを取り込む必要があります。另一方面、ユーザーの数量もローコード能力を衡量する重要な指標で、カバーするユーザー量が大きいほど、異なる属性（チーム、部門、第三者）のユーザーが多いほど、ローコードプラットフォームの成熟度を体现できます

三.能力完全性

第三次元は能力完全性（つまり技術表現力の完備程度）で、完全性が高いほど、ローコード能力は強くなります

目標ビジネスシーンにおいて、能力完備のローコード開発プラットフォームはソースコード開発と同等の技術表現力を持ちます。つまり、人工でコードを書いて実現できるものは、必ずローコード開発プラットフォームを通じて完成できます

Web App を例にすると、能力完全性はローコードプラットフォームが UI（インタラクション効果を含む）、フロントエンドビジネスロジック、インターフェース呼び出し、さらにはバックエンドビジネスロジック、データモデルなどを表現できることを要求します。ソースコード開発を代替でき、目標ユーザーはプラットフォームを通じて目標ニーズのすべての開発作業を完成できるのであって、プラットフォーム能力に制限され、ある一部分の作業しか完成できないのではありません

四.原料包容性

第四次元は原料包容性で、つまりローコードプラットフォームが異なる入力に対する接受能力です。例えば：

• 既存のビジネスコンポーネント、モジュールの录入をサポートするか？

• 任意の第三者モジュールの引用をサポートするか？

• 非標準モジュールの導入をサポートするか？

ソースコード開発の一大優勢は現有コードを最大限度地に再利用できることで、公共コンポーネント/ビジネスコンポーネント、第三者モジュール、さらには非標準モジュールでも、いつでもカプセル化を通じて導入でき、さらにはソースコードコピーの方式で再利用できます。しかしローコードプラットフォームは異なり、コンポーネント、モジュールに対して明確な准入規則があり、標準に符合する「原料」だけがプール中に入り、プラットフォームユーザーに再利用されます

一つの簡単な做法はコンポーネントの通用程度に基づいて公共コンポーネントとビジネスコンポーネントに分類します（モジュールの処理はコンポーネントと類似しており、本節では厳格に区別しません）。プラットフォームは通用の公共コンポーネントのみを収録し、コンポーネントバージョン管理を大幅に簡素化しますが、このような划分は長期にわたって継続的にイテレーションするビジネスには適用されません。現有コードを再利用できないため、ローコードモードでの開発効率は高度に再利用されるソースコード開発よりもはるかに低いです

したがって、より良い做法は標準程度に基づいてコンポーネントを標準コンポーネントとカスタムコンポーネントに分類することです：

• 標準コンポーネント：プラットフォームが事前設定したコンポーネント

• カスタムコンポーネント：プラットフォームユーザーがいつでも導入できる其它コンポーネント

ユーザーがカスタムコンポーネントを录入できることを許可して初めて、そのコード再利用ニーズを満たし、開発効率を再び同一レベルに戻すことができます。長期イテレーションするビジネスにとって、日常使用が最も頻繁なのは必ずビジネスコンポーネントであり、通用の公共コンポーネントではありません。このような情况下、どのようにカスタムコンポーネントを录入するか、どのようにカスタムコンポーネントと標準コンポーネントの混用をサポートするかは深入りして探索する価値のある方向です

五.産物豊富度

第五次元は産物豊富度で、プラットフォームが出力する産物形態が豊富であるほど、ローコード能力は強くなります

出力産物は 3 種類に分類できます：

• 最終産物：機能モジュール、ページ、アプリケーション

• 中間産物：ビジネスコンポーネント、ブロック、テンプレート

• 初級産物：UI コンポーネント

最終産物の完成度は最も高いですが、再利用程度は最も低く、初級産物はこれと反対です。多種形態の出力産物は強力な再利用性と柔軟な統合方式を意味します。例えば：

• ローコード開発とソースコード開発の混合使用、平滑な移行を許可

• ローコードプラットフォームが産出する半成品に基づいた二次開発、一部分の作業量を軽減

つまり、能力完全性は目標応用シーンを決定し、産物の豊富度はローコードプラットフォームの実際応用シーンを決定します

六.リンクカバレッジ

第六次元はリンクカバレッジで、完全な生産リンクに対するカバー程度を表し、カバレッジが高いほど、ローコード能力は強くなります

完全な生産リンクは一般にニーズ - 設計 - 開発 - テスト - 公開 - 運用保守を含み、ローコードプラットフォームが生産リンクに対するカバーが完全であるほど、協業フローは円滑になり、効率向上もより明確になります。異なるビジネス環境において、具体的な生産リンクは異なる可能性がありますが、ローコードプラットフォームのリンクカバー範囲を明確にし、カバー範囲内の環節を不断に最適化すると同時に、範囲外の各環節との協業コストを可能な限り低くする必要があります

具体的に、リンクカバレッジを向上させるには 2 種類の方式があります：

• 併入：範囲外の環節も取り入れる。例えば開発をサポートする基础上で、テスト、公開フロー管理、および相应のワンキーデプロイ能力を提供し、必要フローに対して可能な限り完善なサポートを提供し、ローコードプラットフォームと生産リンクの上下流の継ぎ目をユーザーに暴露するのを避け、人工で埋める

• 连通：範囲外の環節と接続する。例えば、表現力が非常に限られたローコードプラットフォームはソースコード開発モードと配合して使用する必要がある場合、この時ソースコード開発中のコードリポジトリと連動することを考慮し、産物をワンキーでコードライブラリにアップロードするか、または逆にローコード能力を IDE に埋め込み、ソースコード開発を補助する

生産全リンクをカバーするには必ずしもすべての環節をローコード開発プラットフォームに納入する必要はなく、データリンクを打通し、現有ツール、プラットフォームと連動させるだけでよいです。例えば：

          原料協議
物料資産 ----------> ローコードプラットフォーム
           産物協議
ローコードプラットフォーム ----------> 公開プラットフォーム/コードリポジトリ
             中間産物協議
UED 設計ツール --------------> ローコードプラットフォーム
            インターフェース記述協議
API 管理プラットフォーム ------------> ローコードプラットフォーム
           データ記述協議
ローコードプラットフォーム -------------> データ Mock プラットフォーム

七.協業効率

第七次元は協業効率で、異なる役割がローコードモード下での協同作業効率を指し、協業効率が高いほど、ローコード能力は強くなります

ソースコード開発と異なり、ローコード開発は一種の新しい研發モードとして、協業効率方面で大きな想像空間があります。例えば：

• 製品マネージャー：ローコードプラットフォームを通じて高忠実度プロトタイプを産出でき、研發人員に引き渡してさらに開発し、さらには自行で素早く文案、画像素材などを調整可能

• UED：設計ツールがローコードプラットフォームと对接し、人工注釈、効果チェック不要

Design2Code（設計稿転コード）は UED と研發人員の協業効率問題を解決するもう一つの思路で、それと比較して、ローコードプラットフォームの核心優勢は専門性要求を下げ、製品マネージャー、UED などの非技術人員も自主調整する能力を持ち、さらには部分的なニーズを独立完成できることです

八.智能程度

第八次元は智能程度で、越智能、ローコード能力は強くなります

まず、どのように智能を定義するか？

簡単に人工の意思決定を幫助または代替する能力と定義します。つまり、プログラムが自動的に（私も正しいと認める）決定を下せる場合、それは智能的です。例えば現代の IDE は海量コードライブラリの単語頻度特徴、現在の入力コンテキスト、ユーザーのコーディング習慣などの情報を総合的に計算して最も可能性のある数個の候補を選択して補完ヒントとして提供し、大概率は私が入力したい内容なので、智能ヒントと呼びます

配置化（データ化）のローコード開発は智能化開発に向かう必经の道です。智能の基礎はデータであり、ビッグデータセット分析に基づいて得出された規律はプログラム意思決定の重要な根拠です。ソースコード開発はその柔軟性により、細やかな有効入力を提供できず、ローコードプラットフォームは人工コーディングの柔軟性を制限し、一種の配置化的プログラム表現方式を提供し、産生する配置データは推薦アルゴリズムの入力として使用でき、さらに人工意思決定を幫助します：

• 自動推薦/選択内容、例えばレイアウトテンプレート、コンポーネントスタイル（フォントサイズ、色）、画像素材など

• 自動推薦/選択文案、例えばキーワード、句式、スタイルなど

• さらに大量の UI 組合せを自動産生し、均等に投放して効果を検証し、効果フィードバックに基づいて自動で最佳を選択

部分的な生産環節を人工意思決定から自動化へのデータ駆動意思決定に移行させ、ローコードプラットフォームはこのような智能化プロセスにおいて代替不可能な役割を果たします

至此、8 次元ローコード能力モデルはすでに構築されました。下図の通り：

[caption id="attachment_2311" align="alignnone" width="500"] low code model[/caption]