仕組みの基礎のあとは
仕組みの基礎の意図、仕組みの基礎のあとのビジョンが明確でない場合、以下の課題が徐々に浮き彫りになるのではないかと。
さらに、実装したアプリケーションは、いわゆる「野良アプリケーション
」と呼ばれてしまいます。
とりあえず動作するアプリケーションができる
デスクトップ/WEB、実装者のスキルで実装される
操作マニュアルはあるが、目的や意図がわからない
実装者以外がメンテナンスできない
とりあえずExcelマクロで実装する
とりあえずAccessマクロで実装する
野良アプリケーションの定義
左:今までの定義
右:現在の定義
今までは実装範囲が広く、他人が何もできない属人化が問題であった。
現在はノーコード開発を利用する為、実装範囲が狭くなり、属人化問題ではなく、連携不可が問題となる。
仕組みの基礎にある「AirTable」「Kintone」は連携が可能です。
アプリケーションから呼び出せない
とりあえずSaaSを利用する
とりあえずサービスを利用する
仕組みの基礎のあとに考えるビジョン
小さなアプリケーションを実装した後、次は連携したいという話に進みます。
アプリケーション間を直接連携すると、連携数の増加と共にメンテナンスが厳しいという話が発生します。
今までの問題の解決策、つまりゴールはハブの位置に連携の仕組み、ツールを導入することです。しかし、ハブの位置に該当する連携の仕組みにも変化が発生しており、それはアプリケーションのタイプが今までとは変わっているためです。
アプリケーションのタイプ
アプリケーションは以下の2種類、SoRまたはSoEに、さらに前者は基幹系システム、後者は情報系システムと分類されます。
各アプリケーションの特徴は以下の記述になり、上段がSoE、下段がSoRになります。SoEは利便性やスピードを重視するために「攻めのIT 」、SoRはコスト削減を重視するために「守りのIT」と呼ばれております。
連携の仕組みを考えるときは、SoE、SoR、ハイブリッド(SoEとSoR共に)を考えた上で、さらにSoE、SoR、どちらにシフトを置くかを考慮した上で最も適した連携の仕組みが求められています。仕組みの基礎はSoE がベースです。
タイプ
・外部サービスを利用
・企業内のみで利用する
レスポンス
・リアルタイムあり ※1件データ処理
・リアルタイムなし ※大量データ処理
呼出方法
・APIエコノミー
・データベース・ファイル・企業内API
データタイプ
・定型化データマッピング
・カスタムデータマッピング
連携の仕組みの種類
連携の仕組みを整理した場合、以下の図のとおりになります。
「クラウド・オンプレミス」、「処理するデータ量(レスポンス)」、「リアルタイム」という3つの軸があります。
レシピ型とは定型処理をイベントドリブンで処理を行う事で、エンドユーザーが処理を設定することができることです。
例:Gmailメール本文→Google SpreadSheetに保存する
例:Gmail添付あり→Google Driveに保存する
連携の仕組みのツール
レシピ型 Zapier
レシピ型 Workato
レシピ型 Power Automate
EAI Node-Red
EAI Apache NiFi
ESB MuleSoft
ETL Asteria
ETL DataSpider
iPaaSについて
SaaSサービスが増えており、サービスを連携する場合、ETL等を利用する以外の選択肢がありませんでしたが、Integration Platform as a service (iPaaS)の登場により、SaaS間の連携がスムーズにできるようになります。
iPaaSの普及により、アプリケーションと同様に連携の仕組みにおいてもエンドユーザー自らが対応できるようになり、「レシピ型」という新しいカテゴリーが登場しています。
エンドユーザーができること
ブロックプログラミンの概念で連携の仕組みが考えられるため、システムの専門家がいらない
様々な端末から最新の状態にアクセスできること
クラウド上であれば端末に制限はなく、最新の状態へのアップデートもサービス提供者自身が実施する
多くのサービスを利用していること
自分で検索して利用できる有名なサービスを既に利用しているので、抵抗感がほとんどない
コストが安いこと
Howではなく、Whatが対象であるため、必要最低限の機能があれば実現できる
今求められるつなぐ仕組みとは
SaaS利用が前提の今の時代において、当社では以下の基準に基づいて、つなぐ仕組みを提案しております。
パターン1:SaaSサービスのみを考えたつなぐ仕組み レシピ型
パターン2:SaaSサービスと社内システムを考えたつなぐ仕組み EAI (Node-Red)
パターン2を実現する際、高価なツールを1つ購入して対応せず、カテゴリー毎にEAIツールを用意し、EAIツール間を連携する分散型のつなぐ仕組みを構築することにより、拡張性が高く仕組みができると考えております。また、Node-Redは
OSS(無料)です。
パターン1を実現する際、日本企業のSaaSサービスは非常に少ないため、レシピ型では対応していない事が想定され、レシピ型でのサポートが増加する事により、パターン1での実現性は徐々に高くなると考えております。
変化点
ETLを導入すれば、課題は解決する
プラグイン追加コスト等、クラウド対応では金食い虫になる
変化点
バッチ処理でも時間的な余裕がある
リアルタイムで結果を確認する業務が多い
変化点
専門的な連携パターンに対応することができる
容易な連携パターンに対応することができる
変化点
機能とツールのコストがマッチしている
必要な機能のみに対してコストが発生する
Node-Red
Node-Redの特徴は以下の通りで、オープンソースではありますが、IBMが当初は開発しており、ビジュアルプログラミングですので、短期間にて技術を習得することができます。
オープンソース
IBMが開発し、JS Foundationに寄贈して、現在はオープンソース
フローベース
フローで処理の流れを作成するビジュアルプログラミング方式
ブラウザーベース
ブラウザー上でフローを作成することができる
多種多様な連携
デバイス、SaaSサービス等、様々なアプリケーション/サービスと連携
コネクター
標準コネクター以外に様々なコネクターをダウンロードできる
IoT対応
IoTで不可欠な技術、MQTT、WebSocket、RestAPIに対応済