電子商取引のサプライチェーンシステム構築は一般的にデータ管理に重点が置かれていますが、このタイプのシステム構築における大きな問題は、フロントエンド開発とバックエンド開発間の通信コスト（研究開発費と比較して）の高さです。特に、フィールドの追加や削除といった単純なリクエストの通信コストは、50%以上に達することもあります。この通信コストをいかに削減し、高品質な配信を確保するかが、喫緊の課題となっています。

要件とシステム ページを分析した結果、次のデータが得られました。

• サプライチェーンプロジェクトでは、必要な工数が総作業時間の約50%を占めます。2週間のイテレーションサイクルでは、フロントエンド開発者は10件以上のリクエストを受け取ることがあり、結果として深刻な時間的断片化が生じます。これらのリクエストは非常に単純で、基本的にはフィールドの追加や削除、単一選択から複数選択への変更、インポート/エクスポートの追加などです。

• サプライチェーンのページの70%は、CQUDとも呼ばれる標準リスト型です。これらのページは、シンプルなインタラクションと標準的な機能を備えています。一般的な機能には、クエリ、作成、編集、バッチ処理、オンライン/オフライン/削除、インポート/エクスポート、操作ログの表示、詳細の表示などがあります。

• これは、いわゆる契約精神の問題、つまりインターフェース記述はいつ配信されるべきか、そしてどのように明確に記述できるかという問題に関係しています。現実には、これを実現するのは非常に困難です。サーバーがインターフェース記述をアップロードできるタイミングは不確実であり、たとえアップロードできたとしても、様々な要因によって期待に応えられない可能性があります。これは、多くの場合、サーバーがインターフェースとその属性について明確に評価していても、それが必ずしもユーザーに理解できるとは限らないためです。これが情報ギャップです。しかし、ユーザーがそれを真に理解できるようにするには、必然的にサーバー側の負担が大きくなり、それを不必要だと考える人もいるかもしれません。
• サーバーは、入力および出力パラメータの形式を通信せずに変更することがありますが、これは統合またはテスト段階まで検出されない可能性があり、これはかなり遅い段階であり、繰り返し発生する問題です。

ソースコードとローコードの学習コストの傾向チャート

ローコードと複数のクロスドメインツールの学習コストの比較

• Alibaba Low-Code Engine: https://lowcode-engine.cn/index は、視覚的な構成生成ページに重点を置いています。
• Baidu Amis: https://aisuda.bce.baidu.com/amis/zh-CN/docs/index では、ページを生成するための JSON 構成に重点が置かれています。

• Amisは、より強力なJSON設定機能を提供します。やや複雑なシナリオに対応するために多くのスクリプトを記述する必要があるLowcode Engineと比較して、JSON設定は学習曲線が緩やかで、サーバーサイド開発者がすぐに使い始めるのに適しています。
• Amisのドキュメント機能はより強力になり、JSONを直接編集し、変更後の結果を表示できるようになりました。これにより、APIの開発と学習が大幅に容易になります。

1. ターゲットオーディエンスの理解不足： B2Bローコード製品のユーザーの大多数はフロントエンド開発者です。専門家はローコードに対して多少の抵抗感を持つ傾向があるため、他者に使用させる前に慎重に検討する必要があります。なぜ彼らはローコードを使用するのでしょうか？あるいは、何が彼らにローコードを使用する動機を与えるのでしょうか？個人的には、B2Bシステムのフロントエンド開発者にローコードツールを提供しても、効果は期待できないと考えています。多少の効率向上は見られるかもしれませんが、専門家レベルのダウングレードや開発プロセスの煩雑さに比べれば、その効果は微々たるものでしょう。
2. 柔軟性の不足：特定のロジックに遭遇すると、使いにくくなったり、実装が不可能になったりすることがあります。「たった1行のコードで英雄も困惑する」という諺があるように、ゼロから開発するしかないため、コードを繰り返し修正する必要があり、ユーザーエクスペリエンスが大幅に低下する可能性があります。これは通常、コンポーネントやローコードエンジンによるサポートが不足していることが原因です。
3. 機能が不完全：優れたページを作成するには、統合テスト、ページ管理、公開/ロールバック、メニュー、権限など、多くの側面を考慮する必要があります。これらすべてが考慮されていますか？断片的なエクスペリエンスと、複数のプラットフォームに分散したプロセスは、間違いなく批判されるでしょう。
4. 設計哲学の欠如:たとえば、共通コンポーネント構成に複数のプロパティ命名規則がある場合があり、関数の実装が共通の理解に準拠していないと、API の理解と学習に多大なコストがかかります。
5. 高い認知コスト：例えば、現在のフルスタックのサーバーサイドシナリオでは、コンポーネントの概念やいわゆるデータドリブンアプローチさえ知らない可能性があります。受け取るPRDには、ページの説明文が長々と記載されているだけで、きちんとしたワイヤーフレームさえ含まれていない場合もあります。初心者にとって、同じ標準的なインタラクションでページを再現することは大きな課題です。これらはすべて、私たちが検討し、解決しなければならない細かい点です。

名前の表示、名前の表示を選択します。パスワードの無効化、名前の非表示、パスワードの無効化を選択します。

 import React, { useState } from 'react' ; import { Radio, Form, Input } from 'antd' ;
 type FieldType = {  username?: string ;  password?: string ;  type?: number; };
 const App: React.FC = () => { const [form] = Form.useForm(); const [hiddenName, setHiddenName] = useState( false ); const [diablePassword, setDiablePassword] = useState( false );
 const onValuesChangeHandler = (values: FieldType) => {    setHiddenName(values.type !== 1 );    setDiablePassword(values.type === 2 );  };
 return (    <Form      form={form}      name= "basic"      labelCol={{ span: 8 }}      wrapperCol={{ span: 16 }}      style={{ maxWidth: 600 }}      onValuesChange={onValuesChangeHandler}      autoComplete= "off"    >      <Form.Item<FieldType> name= "type" wrapperCol={{ offset: 8 , span: 16 }}>        <Radio.Group>          <Radio value ={ 1 }>显示姓名</Radio>          <Radio value ={ 2 }>禁用密码</Radio>        </Radio.Group>      </Form.Item>      {!hiddenName && (        <Form.Item<FieldType> label= "姓名" name= "username" >          <Input />        </Form.Item>      )}
      <Form.Item<FieldType> label= "密码" name= "password" >        <Input.Password disabled={diablePassword} />      </Form.Item>    </Form>  ); };
 export default App;

 { "type": "form", "body": [ { "type": "radio", "name": "type", "label": "type", "options": [ { "label": "表示名", "value": 1 }, { "label": "パスワードを無効にする", "value": 2 } ] }, { "type": "text", "name": "ユーザー名", "label": "名前", "visibleOn": "${type == 1}" }, { "type": "password", "name": "password", "label": "パスワード", "disabledOn": "${type == 2}" } ] }

• コンポーネントの使用方法や概念をすぐに理解します。
• 複雑な形式のリンク関係。
• 要件に応じてページ構造を生成または変更します。
• これはページの構成を理解するのに役立ちます。

• コンポーネントの例、コンポーネント API の説明、概念の説明、例、ドキュメントに保存されている QA の質問に基づいて、シードの質問をすばやく生成します。
• Proto とインテリジェントな質問回答からの肯定的フィードバックと否定的フィードバックの両方が、シード質問のトレーニング データとして使用されます。
• シード質問の数は限られており（1000件未満）、手動で検証が行われます。例えば、SearchPageコンポーネントに関連する質問と回答の精度が低いと感じた場合は、シード質問を検索して修正することができます。以下に、シード質問の簡単なキャリブレーションツールを示します。

全体的なプロセスは上記に要約されています。

機能アーキテクチャ図