短い歴史
長年にわたり、情報を提示するためにデータを表示する方法には、レポート、ビジネス インテリジェンス (BI)、データ視覚化など、さまざまな名前が付けられてきました。2001 年以来、BI プラットフォーム ソフトウェア会社で働き、自動レポート ツールを開発してきた私のこれまでの経験に基づいて、データの表示を XNUMX つのカテゴリに分類しました。
1. 表形式のレポート – 行と列のデータ抽出、 スプレッドシート、または紙や PDF 上のページ区切りデータ。データはデータベースやビューから直接取得されるか、コピー、貼り付け、操作されて出力表示形式になります。
2. ピクセルパーフェクトなレポート – 財務諸表、請求書、領収書、一般情報明細書などのフォーマットされたレポート。表形式のレポート、チャート、グラフの要素を含めることができ、情報を静的かつ構造化された方法で伝えます。
3. ガイド付き分析 – ガイド付き分析は、データ モデルとインタラクティブなユーザー インターフェイスの構築を担当する BI アナリストによって作成された、専用のダッシュボードです。ユーザーは、チャートやグラフ (視覚化と呼ばれる)、表、カスタム レイアウトに適合するその他のオブジェクトを通じてデータを消費します。
4. セルフサービス分析 – セルフサービス分析は、ガイド付き分析開発プロセスをエンドユーザーに民主化します。これらのツールとプラットフォームを使用すると、エンドユーザーは複数のソースからデータを追加してダッシュボードをゼロから作成し、インテリジェントなデータ準備機能と支援付きチャート作成機能を採用したユーザーインターフェイスから視覚化を作成できます。
5. 組み込み分析 – 組み込み分析により、フロントエンド開発者は HTML 5 と JavaScript を使用してコードによる堅牢でインタラクティブな視覚化を生成し、それを Web ページやアプリケーションに直接配置できるようになります。
6.高度な分析 – 分析の未来はかつてないほど明るくなっています。世界中のデータ量が増え続けているため、重要な情報や洞察を得るには、より多くの支援が必要です。人工知能、機械学習、認知分析、ボット、会話型 UI などのテクノロジーにより、誰もがデータの力を活用して生活を向上させることが容易になります。
あらゆるディスプレイ技術に期待すべき最低限のことは、それが害を及ぼさないことである」 – エドワード・タフテ
課題
データの表示 (私はこれを BI と呼んでいます) が進化し、変化し続ける中、問題が残っています。ツールとプラットフォームに対する要求は、それらが提供する機能よりも大きいのです。BI の消費者は、これらのツールに「何が起こったか」や「もしも」の分析以上のものを求めています。彼らが求めているのは、履歴を考慮し、将来に即座に影響を与えることができる、ライフサイクル全体のアプリケーションです。それは、視覚的なものであろうとなかろうと、単一のインターフェイスから洞察を行動に移すという真の約束です。この要件を満たすために、BI 開発者はコーディング方法を学ぶ必要があります。
BI分野で働いていた経験から、私は多くのアナリストと話をし、 の BI プラットフォームの API をテストしましたが、意味がありませんでした。
BI 固有の API を学習するのは難しい課題です。
これに一般的なコーディングを学ばなければならないことを組み合わせると、結局、投資と労力は返ってくる価値に見合わないものになります。それが ローコード BI 開発者にとって、BI や視覚化を超えた機能を備えた完全なアプリを提供するには、これがより優れた方法です。BI API を使用してコーディングしたり、BI ツールが実行しない操作 (BI データセットへの書き戻しなど) を実行するために必要なツールを統合したりするよりも、簡単で強力です。皮肉なことに、アプリケーション開発者は逆の方向で同じことを行おうとしています。
入社以来 Mendix、私は顧客と週に何度も会話を交わし、ローコードを使用してレポート作成や BI のようなアプリケーションを開発し、エンドユーザーが上記のカテゴリで利用可能な機能のいくつかを実行できるようにしてきました。開発の目標は BI 開発者と同じです。情報を意味のある形で伝える力を持つ完全なアプリを構築し、データの更新や変更をサポートしながらそれを使って何かを行い、エンドユーザーに分析の柔軟性を提供します。
ローコードアプリケーションでネイティブチャートを使用する際の考慮事項
レポート、BI、分析などに関して、アプリケーション開発者にとっての基本的な前提は、車輪の再発明をしないことです。基本に忠実に従い、エンド ユーザーが次のステップに進むのに役立つデータを表示します。チャート作成機能とレポート機能 (リスト ビューとデータ グリッド経由) は、ユーザーがアプリケーションで達成したいタスクに関連する意味のあるデータを表示するのに適しています。ユーザーがやりたいことを何でもできるように、実行時にすべてのデータを利用できるようにすることは適切ではありません。何をすべきかを決めるときは、次の 3 つの最初の質問をすることを検討してください。
1. ユーザーのために解決しようとしている問題は何ですか?
ユースケースと、情報をユーザーに伝える方法について考えてみましょう。顧客がアプリのホームページやユーザーエクスペリエンスのどこかに主要業績評価指標（KPI）を表示したい場合、次のようなプラットフォームに含まれるチャートやグラフを使用します。 Mendix 美しく便利なビジュアルをすばやく簡単に作成できるため、理にかなっています。顧客がアプリケーション実行中にあらゆる種類のセルフサービス機能を求めている場合は、要件を満たす統合プラットフォームを検討する時期です。
2. アプリケーションにはどのくらいのデータがありますか?
アプリケーションには 100 行のデータがありますか、それとも 100 億行のデータがありますか。後者の場合、すべてのデータを詳細に表示しても、アプリケーションでレンダリングするのにかかる時間に比べて価値が大幅に低くなります。大量のデータを含むダッシュボードやグラフを含むアプリを設計する場合は、フィルターと条件付きロジックを使用して、KPI、グラフ、リスト ビューの集計を規定的かつ制限的にします。表示される内容の価値を高めながら、洞察を得るまでの時間を短縮できることに、ユーザーは感謝するでしょう。
3. どの程度のレベルのインタラクティブ分析が必要ですか?
ガイド付きおよびセルフサービス分析のインタラクティブな性質により、エンドユーザーはチャートやグラフをクリックして、そのアクションによってデータセットにフィルターを適用することに慣れています。ただし、これらのツールの操作方法は変化しており、多くの場合、クリックまたは操作に対する望ましい応答はアクションの実行です。これらのアクションには、ドリルダウン (データの 1 つのレイヤーから別のレイヤーに移動)、詳細を表示したり入力を求めたりするためにアプリケーションで新しい画面を開く、通知やアラートをトリガーするワークフローまたはユーザーに特定のレコードを割り当てることが含まれます。これらすべてのアクティビティでは、次のステップに進むためにビジュアルと組み合わせたロジックが必要であり、ローコード プラットフォームはこれらのアクションの構成を容易にする直感的な方法を提供します。
逆に、ローコード開発者は、チャートに表示されたデータを接続する必要があるかもしれませんが、これは分析プラットフォームで簡単に行うことができます。チャートのグループを接続して、インタラクションに一斉に応答することは可能ですが、 Mendix、労力とソリューションの望ましいメリット、メンテナンス、規模を比較検討することが重要です。多くの場合、このレベルの複雑さを処理するために特別に構築されたプラットフォームを統合する方が理にかなっています。
ローコード アプリケーションに埋め込まれた BI プラットフォームの使用に関する考慮事項
レポートおよび BI プラットフォームをローコード アプリケーションに統合する理由はたくさんあります。まず、組織は BI にかなりの投資を行っており、それを活用する必要があります。アプリケーション内のトランザクション ベースのシステムは、BI プラットフォームが独自のデータ エンジンを使用して対処する分析要件を処理するようには設計されていないため、ユーザーがデータを細かく分析する必要がある場合、BI には明確な利点があります。さらに、BI プラットフォームとローコード アプリケーション プラットフォームの両方で、それぞれのスタックのさまざまなレイヤーでの通信を容易にする API が公開されています。これにより、BI 側でフックを作成しやすくなり、ローコード側で再利用可能なコンポーネントを作成して、両方のテクノロジのパワーを組み合わせることが容易になります。ビジネス インテリジェンスと分析をアプリケーションに組み込む際に考慮すべきいくつかの質問を以下に示します。
1. データは複数のソースから取得されていますか?
ローコード プラットフォームと BI プラットフォームはどちらも、強力な ETL、データ処理、変換機能を備えています。考慮すべき点は次のとおりです。
- 1 つのプラットフォームがデータ ブレンディングを実行し、他のプラットフォームに必要なものを供給できる場合、他のシステムでそれを再作成する労力はそれほど価値がない可能性があります。
- データ ブレンディングに使用するプラットフォームを決定する必要がある場合は、データを最もよく理解している人がツールも最もよく理解できるプラットフォームを選択してください。最近のすばらしい点は、ローコード プラットフォームと BI プラットフォームの両方に相互通信するための API があることです。
- ユースケースをサポートするために両方のプラットフォームでデータを処理することは避けてください。そうすると、データ品質のリスクが生じ、計算における潜在的なエラーを追跡したり、データ系統をエンドツーエンドで追跡したりすることが難しくなります。
2. エンド ユーザーは、グリッドや出力で表示するデータのフィールドを選択したり、実行時に基礎データを使用して視覚化を作成したりするためのセルフサービス機能を必要としますか。
これまでの説明が十分明確でなかったら、 しない 次なる優れたツールを構築することが目標でない限り、任意のアプリケーション開発プラットフォームを使用してセルフサービス レポートおよび分析ツールを構築することはできません。 市場には、私が説明したカテゴリの 1 つ以上を満たすオプションが多数あり、その多くはソリューションをホワイト ラベル化して顧客に独自のものであると思わせるオプションを備えています。 時間とコストを節約し、開発者の疲労を防止します。
3. BI プラットフォームで導出されたメトリックは、イベントをトリガーし、アプリケーション ロジックを呼び出し、基礎となるデータ ソースに書き込み、BI 視覚化を更新する必要がありますか?
今日の BI の世界では、同じプラットフォーム内で分析からアクションに移るためには、解決策をコーディングする必要があります。これは、経験豊富なソフトウェア開発者にとっては時間のかかる作業であり、問題の解決に取り組んでいる BI アナリストにとっては、まったくの無謀な作業です。ローコード アプリケーション開発プラットフォームを使用すると、ビジュアル ロジック (Visio を想像してください。ただし、フローがアクションとして解釈されます) を使用して、ユーザー インターフェイスのインタラクションを駆動し、バックエンド アクティビティを処理する堅牢なアプリケーションを誰でも簡単に作成できます。ローコードと、BI プラットフォームに結び付けられた組み込み分析を組み合わせると、両方の長所を活かすことができます。分析プラットフォームが提供する接続性と対話性を活用し、ローコード プラットフォームを使用して、アプリケーション ライフサイクルのデータ処理と操作ロジックを処理できます。
これら 2 つのテクノロジーの融合については疑いの余地はありません。アプリケーションの需要が高まるにつれて、アプリケーションが生成するデータを解釈して提示する需要はさらに急速に高まります。ローコード プラットフォームは、多数のレポート作成およびチャート作成のユースケースを処理する能力を備えています。洞察からアクション、レビュー、そして再び実行までの所要時間がますます短くなるにつれて、両方の長所を最大限に活かすために、分析とローコードを活用したより洗練されたソリューションを検討する必要があります。