- #セキュリティ対策
- #セキュリティガバナンス
- #情報セキュリティ
- #DX
- #EMOROCO CRM Lite
- #Creative CRM
- #アーカス・ジャパン
- #CRM4.0
- #法人心理学
- #企業心理学
- #CRMドクター
- #CRM・xRM
- #EMOROCO
- #人工知能･機械学習(AI･ML)
- #顧客・販売戦略(SFA)
- #カスタマーサービス･コールセンター(CS)
- #マーケティング・オートメーション(MA)
- #カスタマーエクスペリエンス(顧客体験)
- #AI
- #フィールドサービス(FS)
- #CRM
「メタデータ駆動型CRM」とは何か — なぜEMOROCO CRM Liteはプログラムなしで業務変更に追いつけるのか
こんにちは、CRMエバンジェリストの松原です。
「業務が変わるたびにシステムに追加費用がかかる」
「フィールドを一つ追加するだけでベンダーに連絡して数週間待つ」
「現場から『この項目を追加してほしい』と言われても、すぐに対応できない」
これらの問題の根本原因は、多くの業務システムが「コードベース」で作られているからです。フィールドを追加するためにはデータベースの設計を変え・プログラムを修正し・画面を再構築し・テストをしなければならない。
EMOROCO CRM Lite ver2.0が採用する「メタデータ駆動型設計」は、この問題を根本から解決します。
この記事では「メタデータ駆動型CRM」の仕組みを、技術的な背景から実務的な効果まで、わかりやすく解説します。
「メタデータ」とは何か——まず言葉の定義から
「メタデータ（Metadata）」という言葉を分解します。
【メタデータの定義】
meta（メタ）：「〜について」「〜を超えた」という意味の接頭辞
data（データ）：情報・データ
→ メタデータ = 「データについてのデータ」
「データを説明するデータ」
具体例で理解する：
普通のデータ：
「田中工業株式会社」（取引先名）
「東京都渋谷区△△町1-2-3」（住所）
「ホット」（感情温度）
メタデータ：
「取引先名」というフィールドは
・テキスト型である
・最大100文字まで入力できる
・必須項目である
・一覧表示の1列目に表示される
「感情温度」というフィールドは
・選択式（ドロップダウン）である
・選択肢は「ホット・ウォーム・クール・コールド」
・フォームの上部に大きく表示される
・このフィールドが変化したときワークフローを発火する
→ メタデータとは「このシステムに何がどう存在するか」という
構造の定義情報のこと
meta（メタ）：「〜について」「〜を超えた」という意味の接頭辞
data（データ）：情報・データ
→ メタデータ = 「データについてのデータ」
「データを説明するデータ」
具体例で理解する：
普通のデータ：
「田中工業株式会社」（取引先名）
「東京都渋谷区△△町1-2-3」（住所）
「ホット」（感情温度）
メタデータ：
「取引先名」というフィールドは
・テキスト型である
・最大100文字まで入力できる
・必須項目である
・一覧表示の1列目に表示される
「感情温度」というフィールドは
・選択式（ドロップダウン）である
・選択肢は「ホット・ウォーム・クール・コールド」
・フォームの上部に大きく表示される
・このフィールドが変化したときワークフローを発火する
→ メタデータとは「このシステムに何がどう存在するか」という
構造の定義情報のこと
通常のシステムとメタデータ駆動型の決定的な違い
製品資料（ver2.0・スライド12）に明示されているように、EMOROCO CRM Liteは一般的な業務システムとは根本的に異なる設計思想を採用しています。
【通常のシステム（コードベース）の設計】
「取引先名」フィールドを追加する場合：
①データベース設計の変更
DBテーブルに新しい列を追加するSQL文を書く
②バックエンド（サーバーサイド）の修正
この列をAPIで読み書きするロジックを実装する
③フロントエンド（画面）の修正
入力フォームに新しいフィールドを追加する
一覧画面に列を追加する
④テスト
追加したフィールドが正しく動くかテストする
既存の機能が壊れていないか確認する
⑤リリース
変更をサーバーに反映する
所要時間：数日〜数週間
費用：ベンダーへの開発依頼費用（数万円〜数十万円）
リスク：テスト不足による既存機能への影響
「取引先名」フィールドを追加する場合：
①データベース設計の変更
DBテーブルに新しい列を追加するSQL文を書く
②バックエンド（サーバーサイド）の修正
この列をAPIで読み書きするロジックを実装する
③フロントエンド（画面）の修正
入力フォームに新しいフィールドを追加する
一覧画面に列を追加する
④テスト
追加したフィールドが正しく動くかテストする
既存の機能が壊れていないか確認する
⑤リリース
変更をサーバーに反映する
所要時間：数日〜数週間
費用：ベンダーへの開発依頼費用（数万円〜数十万円）
リスク：テスト不足による既存機能への影響
【EMOROCO CRM Lite（メタデータ駆動型）の設計】
「取引先名」フィールドを追加する場合：
①管理画面を開く
「エンティティ管理」→「フィールド追加」をクリック
②フィールドの定義を入力する
フィールド名：取引先名
型：テキスト
最大文字数：100
必須：はい
③保存する
④即座にフォームと一覧に反映される
所要時間：3〜5分
費用：追加費用ゼロ（月額1,500円/ユーザーに含まれる）
リスク：なし（データベースの構造は変わらない）
「取引先名」フィールドを追加する場合：
①管理画面を開く
「エンティティ管理」→「フィールド追加」をクリック
②フィールドの定義を入力する
フィールド名：取引先名
型：テキスト
最大文字数：100
必須：はい
③保存する
④即座にフォームと一覧に反映される
所要時間：3〜5分
費用：追加費用ゼロ（月額1,500円/ユーザーに含まれる）
リスク：なし（データベースの構造は変わらない）
この差がどこから来るのかを理解するために、メタデータ駆動型の内部の仕組みを見ていきます。
メタデータ駆動型の仕組み——「定義が画面を生成する」
メタデータ駆動型システムの核心は「定義情報（メタデータ）から、画面を自動生成する」という設計です。
【メタデータ駆動型の動作原理】
通常のシステム：
フィールド定義 → 開発者がコードを書く → 画面が作られる
（画面はコードそのもの）
メタデータ駆動型：
フィールド定義 → メタデータとして保存される
↓
画面表示のリクエストが来たとき：
「このフォームにはどのフィールドが・どの順番で・
どんな型で表示されるか」のメタデータを読み込む
↓
その定義情報から画面を動的に生成する
（画面はコードではなく、定義情報の結果として存在する）
→ フィールドを追加するとは「メタデータを変更すること」
メタデータを変更すれば、画面は次のアクセスから自動的に変わる
コードの変更は不要
通常のシステム：
フィールド定義 → 開発者がコードを書く → 画面が作られる
（画面はコードそのもの）
メタデータ駆動型：
フィールド定義 → メタデータとして保存される
↓
画面表示のリクエストが来たとき：
「このフォームにはどのフィールドが・どの順番で・
どんな型で表示されるか」のメタデータを読み込む
↓
その定義情報から画面を動的に生成する
（画面はコードではなく、定義情報の結果として存在する）
→ フィールドを追加するとは「メタデータを変更すること」
メタデータを変更すれば、画面は次のアクセスから自動的に変わる
コードの変更は不要
これは、Power Appsの「モデル駆動型アプリ」が採用してきた設計思想と同じ原理です。EMOROCO CRM Lite ver2.0は、Microsoft Azureプラットフォーム上でこの設計思想を実現しています。
【EMOROCOのメタデータが管理するもの】
エンティティ（Entity）のメタデータ：
「取引先」「案件」「活動」「問い合わせ」など、
管理する対象のオブジェクト（テーブル）の定義。
「どんな種類の情報を管理するか」の最上位の定義。
フィールド（Field）のメタデータ：
各エンティティが持つ属性の定義。
名前・型（テキスト/数値/日付/選択式/ユーザー型など）・
必須/任意・最大文字数・選択肢の値・ルックアップ先など。
フォーム（Form）のメタデータ：
「どのフィールドを・どの順番で・どのセクションに配置するか」
という入力・編集画面のレイアウト定義。
ロールごとに異なるフォームを持つことができる。
ビュー（View）のメタデータ：
一覧画面に「どの列を・どの順番で・どんな条件で」
表示するかの定義。
「今週のアクションリスト」「感情温度クール以下」など
複数のビューを定義できる。
グラフ（Graph）のメタデータ：
ダッシュボードに表示するグラフの種類・軸・
集計条件などの定義。
ワークフロー（Workflow）のメタデータ：
「どのフィールドが・どの値に変化したとき・
どのアクションを実行するか」のルール定義。
→ これらすべてのメタデータが「管理画面で設定でき」
「設定した瞬間から画面に反映される」のが
EMOROCO CRM Liteのメタデータ駆動型設計
エンティティ（Entity）のメタデータ：
「取引先」「案件」「活動」「問い合わせ」など、
管理する対象のオブジェクト（テーブル）の定義。
「どんな種類の情報を管理するか」の最上位の定義。
フィールド（Field）のメタデータ：
各エンティティが持つ属性の定義。
名前・型（テキスト/数値/日付/選択式/ユーザー型など）・
必須/任意・最大文字数・選択肢の値・ルックアップ先など。
フォーム（Form）のメタデータ：
「どのフィールドを・どの順番で・どのセクションに配置するか」
という入力・編集画面のレイアウト定義。
ロールごとに異なるフォームを持つことができる。
ビュー（View）のメタデータ：
一覧画面に「どの列を・どの順番で・どんな条件で」
表示するかの定義。
「今週のアクションリスト」「感情温度クール以下」など
複数のビューを定義できる。
グラフ（Graph）のメタデータ：
ダッシュボードに表示するグラフの種類・軸・
集計条件などの定義。
ワークフロー（Workflow）のメタデータ：
「どのフィールドが・どの値に変化したとき・
どのアクションを実行するか」のルール定義。
→ これらすべてのメタデータが「管理画面で設定でき」
「設定した瞬間から画面に反映される」のが
EMOROCO CRM Liteのメタデータ駆動型設計
「育てるCRM」という価値——メタデータ駆動型が実現するもの
メタデータ駆動型設計の最大の価値は「CRMを自分たちで育てられること」です。
【コードベースCRM vs メタデータ駆動型CRMの「育てやすさ」比較】
業務変化のシナリオ：「感情温度フィールドを追加したい」
コードベースCRM（例：一般的な受託開発システム）：
1. ベンダーに連絡する
2. 要件定義のMTGを設定する
3. 見積もりが来る（数万円〜）
4. 開発・テスト期間を待つ（1〜4週間）
5. リリース後に動作確認する
→ 結果：「やっぱりやめよう」という判断が増える
「あのフィールド、まだ追加されていないの？」という不満が続く
CRMの改善が止まる
EMOROCO CRM Lite（メタデータ駆動型）：
1. 管理画面を開く
2. 「感情温度」フィールドを選択式で定義する
選択肢：ホット・ウォーム・クール・コールド
3. フォームに追加してレイアウトを設定する
4. 保存する
→ 結果：その日から全担当者が感情温度を入力できる
「あ、新しいフィールドが出た。使ってみよう」という体験
CRMが業務の変化に追いついてくれる
業務変化のシナリオ：「感情温度フィールドを追加したい」
コードベースCRM（例：一般的な受託開発システム）：
1. ベンダーに連絡する
2. 要件定義のMTGを設定する
3. 見積もりが来る（数万円〜）
4. 開発・テスト期間を待つ（1〜4週間）
5. リリース後に動作確認する
→ 結果：「やっぱりやめよう」という判断が増える
「あのフィールド、まだ追加されていないの？」という不満が続く
CRMの改善が止まる
EMOROCO CRM Lite（メタデータ駆動型）：
1. 管理画面を開く
2. 「感情温度」フィールドを選択式で定義する
選択肢：ホット・ウォーム・クール・コールド
3. フォームに追加してレイアウトを設定する
4. 保存する
→ 結果：その日から全担当者が感情温度を入力できる
「あ、新しいフィールドが出た。使ってみよう」という体験
CRMが業務の変化に追いついてくれる
【「育てるCRM」のサイクル】
現場の声：「このフィールドが欲しい」
「この一覧に○○の列を追加してほしい」
「このワークフロー、条件を変えたい」
↓（通常のシステムなら数週間かかる）
↓（EMOROCOなら当日中に対応できる）
管理画面での設定変更（5〜30分）
↓
即座に全員の画面に反映される
↓
現場担当者が「すぐ対応してもらえた」という体験
↓
CRMへの信頼と利用率が上がる
↓
さらに「こうしてほしい」という要望が出る
↓（このサイクルが「育てるCRM」）
→ コードベースのシステムでは「要望→開発→リリース」の
時間的・費用的コストが高いため、このサイクルが回らない。
「現場の要望を無視するか・費用をかけて追加するか」の
二択になってしまい、CRMが形骸化していく。
現場の声：「このフィールドが欲しい」
「この一覧に○○の列を追加してほしい」
「このワークフロー、条件を変えたい」
↓（通常のシステムなら数週間かかる）
↓（EMOROCOなら当日中に対応できる）
管理画面での設定変更（5〜30分）
↓
即座に全員の画面に反映される
↓
現場担当者が「すぐ対応してもらえた」という体験
↓
CRMへの信頼と利用率が上がる
↓
さらに「こうしてほしい」という要望が出る
↓（このサイクルが「育てるCRM」）
→ コードベースのシステムでは「要望→開発→リリース」の
時間的・費用的コストが高いため、このサイクルが回らない。
「現場の要望を無視するか・費用をかけて追加するか」の
二択になってしまい、CRMが形骸化していく。
技術的な深掘り——なぜメタデータ駆動型は「安全」に変更できるか
技術に詳しい読者のために、なぜメタデータ駆動型設計が安全に変更できるのかを説明します。
【メタデータ駆動型が「安全な変更」を実現できる理由】
通常のシステムでフィールドを追加するリスク：
コードを変更するたびに「既存のコードとの整合性」を
確認する必要がある。
「このメソッドを変えたら、別の画面が壊れた」という
サイドエフェクト（副作用）が起きやすい。
テストが不十分だと、リリース後に問題が発覚する。
メタデータ駆動型でフィールドを追加するリスク：
フィールドの追加は「定義情報の追加」であり、
既存のコードには触らない。
「新しい定義が加わった」だけなので、
既存の機能に影響を与えるサイドエフェクトが起きない。
変更できること・変更できないこと：
✅ フィールドの追加・削除・名前変更（いつでも可能）
✅ フォームのレイアウト変更（いつでも可能）
✅ ビューの追加・変更（いつでも可能）
✅ ワークフローの追加・変更（いつでも可能）
⚠️ フィールドの型の変更（データが存在する場合は要注意）
⚠️ エンティティ（テーブル）の削除（データが失われる可能性）
基本的な運用の変更（フィールド追加・フォーム変更・ビュー追加）は
既存データへの影響なく・コードへの影響なく・即座に実施できる。
データベースの設計と画面の分離：
EMOROCOのデータベース（実際のデータが入る層）と
メタデータ（定義情報の層）と
画面（メタデータを読んで動的に生成される層）が
明確に分離されている。
画面の変更はメタデータ層の変更で完結し、
データベース層には原則として影響しない。
→ これが「安全に・何度でも・即座に変更できる」理由。
通常のシステムでフィールドを追加するリスク：
コードを変更するたびに「既存のコードとの整合性」を
確認する必要がある。
「このメソッドを変えたら、別の画面が壊れた」という
サイドエフェクト（副作用）が起きやすい。
テストが不十分だと、リリース後に問題が発覚する。
メタデータ駆動型でフィールドを追加するリスク：
フィールドの追加は「定義情報の追加」であり、
既存のコードには触らない。
「新しい定義が加わった」だけなので、
既存の機能に影響を与えるサイドエフェクトが起きない。
変更できること・変更できないこと：
✅ フィールドの追加・削除・名前変更（いつでも可能）
✅ フォームのレイアウト変更（いつでも可能）
✅ ビューの追加・変更（いつでも可能）
✅ ワークフローの追加・変更（いつでも可能）
⚠️ フィールドの型の変更（データが存在する場合は要注意）
⚠️ エンティティ（テーブル）の削除（データが失われる可能性）
基本的な運用の変更（フィールド追加・フォーム変更・ビュー追加）は
既存データへの影響なく・コードへの影響なく・即座に実施できる。
データベースの設計と画面の分離：
EMOROCOのデータベース（実際のデータが入る層）と
メタデータ（定義情報の層）と
画面（メタデータを読んで動的に生成される層）が
明確に分離されている。
画面の変更はメタデータ層の変更で完結し、
データベース層には原則として影響しない。
→ これが「安全に・何度でも・即座に変更できる」理由。
Power Appsのモデル駆動型との比較——設計思想の共通点と差異
EMOROCO CRM Lite ver2.0は「Power Appsのモデル駆動型アプリのような設計思想を取り入れた」と製品資料に明示されています。この設計思想の共通点と差異を整理します。
【Power Appsモデル駆動型とEMOROCOの比較】
共通する設計思想：
・エンティティ・フィールド・フォーム・ビューという
メタデータの階層構造で画面を定義する
・メタデータを変更することで画面が動的に変わる
・コードを書かずに業務アプリを構築できる
差異と各ツールの特性：
Power Apps（モデル駆動型）：
基盤：Microsoft Dataverse（Dynamics 365の基盤）
強み：Microsoft 365との高い統合性・エンタープライズ向けの拡張性
対象：大企業〜中堅企業のIT担当者・開発者
コスト：中〜高（Microsoft 365のライセンスが前提）
CRM標準機能：自分で設計が必要（CRM標準は別途Dynamics 365）
EMOROCO CRM Lite：
基盤：Microsoft Azure上の独自実装
強み：CRM標準機能があらかじめ組み込まれている・
中小企業向けのシンプルさ・低コスト
対象：中小企業の経営者・現場担当者（IT専門知識不要）
コスト：月1,500円/ユーザー〜
CRM標準機能：取引先・活動・案件・感情温度・ナラティブが標準搭載
→ 「Power Appsの設計思想の良さ（メタデータ駆動型の柔軟性）を、
CRM標準機能と組み合わせて、中小企業向けに提供する」
というのがEMOROCO CRM Lite ver2.0の独自のポジション。
共通する設計思想：
・エンティティ・フィールド・フォーム・ビューという
メタデータの階層構造で画面を定義する
・メタデータを変更することで画面が動的に変わる
・コードを書かずに業務アプリを構築できる
差異と各ツールの特性：
Power Apps（モデル駆動型）：
基盤：Microsoft Dataverse（Dynamics 365の基盤）
強み：Microsoft 365との高い統合性・エンタープライズ向けの拡張性
対象：大企業〜中堅企業のIT担当者・開発者
コスト：中〜高（Microsoft 365のライセンスが前提）
CRM標準機能：自分で設計が必要（CRM標準は別途Dynamics 365）
EMOROCO CRM Lite：
基盤：Microsoft Azure上の独自実装
強み：CRM標準機能があらかじめ組み込まれている・
中小企業向けのシンプルさ・低コスト
対象：中小企業の経営者・現場担当者（IT専門知識不要）
コスト：月1,500円/ユーザー〜
CRM標準機能：取引先・活動・案件・感情温度・ナラティブが標準搭載
→ 「Power Appsの設計思想の良さ（メタデータ駆動型の柔軟性）を、
CRM標準機能と組み合わせて、中小企業向けに提供する」
というのがEMOROCO CRM Lite ver2.0の独自のポジション。
「メタデータ駆動型」の実際の活用シーン——どんな変更を現場でできるか
抽象的な説明から、実際に「何ができるか」という具体的な活用シーンに落とし込みます。
【現場でよく起きる「業務変更」とEMOROCOでの対応時間】
シーン①「新しい商材が増えた→案件レコードに商材カテゴリを追加したい」
通常のシステム：ベンダーへの依頼→2〜4週間・数万円
EMOROCO：管理画面でフィールド追加→15分・追加費用ゼロ
シーン②「担当者が増えた→役割別に異なる画面を見せたい」
通常のシステム：権限設計の再開発→2〜8週間・数十万円
EMOROCO：セキュリティロール×フォーム設定→30〜60分・追加費用ゼロ
シーン③「法改正で顧客情報に新しい項目が必要になった」
通常のシステム：要件定義→開発→テスト→4〜8週間
EMOROCO：フィールド追加→フォーム更新→当日対応可能
シーン④「今月から営業フェーズの管理方法を変えたい」
通常のシステム：変更に2〜4週間。今月は旧方式のまま運用
EMOROCO：BPFの定義変更→翌日から全員が新しいフェーズで管理できる
シーン⑤「新しいダッシュボードを経営者向けに作りたい」
通常のシステム：開発費用・2〜4週間
EMOROCO：ビュー・グラフの新規作成→1〜2時間で完成
シーン⑥「代理店向けに別のフォームを作りたい」
通常のシステム：別画面の開発→数週間〜数ヶ月
EMOROCO：代理店用フォームの新規作成→2〜4時間で完成
シーン①「新しい商材が増えた→案件レコードに商材カテゴリを追加したい」
通常のシステム：ベンダーへの依頼→2〜4週間・数万円
EMOROCO：管理画面でフィールド追加→15分・追加費用ゼロ
シーン②「担当者が増えた→役割別に異なる画面を見せたい」
通常のシステム：権限設計の再開発→2〜8週間・数十万円
EMOROCO：セキュリティロール×フォーム設定→30〜60分・追加費用ゼロ
シーン③「法改正で顧客情報に新しい項目が必要になった」
通常のシステム：要件定義→開発→テスト→4〜8週間
EMOROCO：フィールド追加→フォーム更新→当日対応可能
シーン④「今月から営業フェーズの管理方法を変えたい」
通常のシステム：変更に2〜4週間。今月は旧方式のまま運用
EMOROCO：BPFの定義変更→翌日から全員が新しいフェーズで管理できる
シーン⑤「新しいダッシュボードを経営者向けに作りたい」
通常のシステム：開発費用・2〜4週間
EMOROCO：ビュー・グラフの新規作成→1〜2時間で完成
シーン⑥「代理店向けに別のフォームを作りたい」
通常のシステム：別画面の開発→数週間〜数ヶ月
EMOROCO：代理店用フォームの新規作成→2〜4時間で完成
「メタデータ駆動型」の限界——正直に伝えること
メタデータ駆動型設計にも限界があります。正直に示します。
【メタデータ駆動型で「できないこと」「難しいこと」】
できないこと：
❌ プログラムによる高度なビジネスロジックの実装
（例：複雑な計算式・機械学習モデルの組み込み）
❌ 外部システムとのリアルタイムな双方向APIの複雑な実装
（外部コネクタで対応できる範囲はあるが、
複雑なカスタムAPIはコードが必要）
❌ 既存フィールドのデータ型の変更（データが失われるリスク）
メタデータ駆動型が「苦手」なこと：
⚠️ 業種固有の非常に複雑な業務フロー
（kintoneのJavaScript拡張やPower Automateの複雑なフローが
必要なレベルのカスタマイズは範囲外）
⚠️ 既存システムとの深い統合
（外部コネクタで対応できる範囲を超えるケース）
→ EMOROCOが最も価値を発揮するのは：
「CRM標準の業務（顧客管理・案件管理・活動記録）を
自社の業務に合わせて柔軟にカスタマイズしたい
中小企業・中堅企業」
「一般的なCRMの業務をやりたいのにコードベースのシステムで
硬直化してしまっている」という問題を解消することに強い。
できないこと：
❌ プログラムによる高度なビジネスロジックの実装
（例：複雑な計算式・機械学習モデルの組み込み）
❌ 外部システムとのリアルタイムな双方向APIの複雑な実装
（外部コネクタで対応できる範囲はあるが、
複雑なカスタムAPIはコードが必要）
❌ 既存フィールドのデータ型の変更（データが失われるリスク）
メタデータ駆動型が「苦手」なこと：
⚠️ 業種固有の非常に複雑な業務フロー
（kintoneのJavaScript拡張やPower Automateの複雑なフローが
必要なレベルのカスタマイズは範囲外）
⚠️ 既存システムとの深い統合
（外部コネクタで対応できる範囲を超えるケース）
→ EMOROCOが最も価値を発揮するのは：
「CRM標準の業務（顧客管理・案件管理・活動記録）を
自社の業務に合わせて柔軟にカスタマイズしたい
中小企業・中堅企業」
「一般的なCRMの業務をやりたいのにコードベースのシステムで
硬直化してしまっている」という問題を解消することに強い。
まとめ——「メタデータ駆動型CRM」をひとことで
【「メタデータ駆動型CRM」の本質を3行で】
①定義情報（メタデータ）を変えることで画面が変わる
→ コードを変えなくていい
②管理画面から設定できるため、プログラマーがいなくても変更できる
→ 現場の担当者・CRMドクターが自分で育てられる
③変更が即座に反映され・追加費用がかからない
→ CRMが業務の変化に追いついてくれる
①定義情報（メタデータ）を変えることで画面が変わる
→ コードを変えなくていい
②管理画面から設定できるため、プログラマーがいなくても変更できる
→ 現場の担当者・CRMドクターが自分で育てられる
③変更が即座に反映され・追加費用がかからない
→ CRMが業務の変化に追いついてくれる
「業務が変わるたびにシステムへの費用が発生する」という問題の解決策は、「変更がメタデータの更新で完結するシステム」を選ぶことです。
EMOROCO CRM Lite ver2.0のメタデータ駆動型設計は、Power Appsのモデル駆動型アプリが大企業向けに実現してきた「変更の柔軟性」を、中小企業が月1,500円/ユーザーから利用できる形で提供します。
「CRMを育てることを諦めた」すべての企業に、このアーキテクチャの話を届けたいと思っています。
EMOROCO CRM Lite 製品ページ
関連記事：[【連載：EMOROCO CRM Lite ver2.0 第1回】「使うCRM」から「育てるCRM」へ。機能強化の全体像と設計思想の深化]
関連記事：[kintoneとEMOROCO CRM Liteのノーコードツール比較——「作り込むか・最初からCRMか」の判断基準]
関連記事：[EMOROCO CRM Liteのセキュリティロールとフォーム権限管理で営業担当・管理者・代理店の役割別画面を設計する方法]
関連記事や関連ページのご紹介
この記事を書いた人
