「2022年版ガートナー® マジック・クアドラント™： 製造実行システム（MES）」における当社の「チャレンジャー」としての位置づけに関する本ブログシリーズでは、これまでに「コンポーザビリティ」という概念の詳細や、それが さまざまな業界でどのように 活用されているかについて、数多く取り上げてきました。
さて、ここで、Tulipフロントライン運用プラットフォームがMESクアドラントにおいて「チャレンジャー」に選出された理由、そしてそれが従来のMESについて何を示唆しているのかについて考えてみましょう。
PaaS（Platform as a Service）と従来のMESとの主な違いは、前者のアーキテクチャがモジュール式のソリューションを実現できる点にある。
コンポーザブル・アーキテクチャとはどのようなものか？
コンポーザブル・アーキテクチャには4つの柱があります。
敏捷性
アジリティとは、プロセスを「やるべきこと」に合わせて調整できることを意味し、その逆ではありません。この柱の特徴は、迅速な実装、更新、反復、そして柔軟でアクセスしやすいデータ構造にあります。
拡張性
コンポーザブル・アーキテクチャは、他のソリューションと連携できるモジュール性を備えており、あらかじめ構築されたコネクタを備えたオープンAPIを提供します。また、ノーコードによるエッジ接続機能やローコード機能も備えている必要があります。
アクセシビリティと拡張性
構成可能なアーキテクチャであれば、類似したサイトや状況に対してソリューションを複製できるようになるはずです。また、信頼性が高く、規模が拡大しても安定したパフォーマンスを発揮する必要があります。さらに、必要なデータは、特定のステーションやサイトだけでなく、どこからでも、ユーザーが求めるデータ構造でアクセスできる必要があります。
人間中心
コンポーザビリティの本質は、人間中心にある。コンポーザブルなアーキテクチャには、直感的なインターフェースと、作業用デバイスからのデータを取り込んだ効率的なワークフローが不可欠である。こうした要件は、現代の製造現場の労働者が抱く要望や期待を反映したものである。人々は、自身の経験を尊重する革新的な企業で働きたいと願っている。
過去のモデルはどのようなものでしたか？
従来のMESでは、プラットフォームのようにコンポーザビリティに対応することはできません。
ある拠点に従来のMESを導入するとします。要件定義や業務フロー図の作成を経て、ベンダーを選定します。その後、ベンダーによるMESの導入が開始されます。
ほとんどの場合、お客様側でのカスタマイズが必要となります。統合やプロセスのために、システムの要件に合わせて調整していただく必要があります。
理想的な状況では、要件のすべてが正確であり、MESを選定した時点から本格導入するまでの間に何の変化も生じないということです。
さて、今度は別の場所に導入しようとしています。そこでは状況が異なります。追加の対応が必要になります。（例えば、最初の導入ではマシンが中心だったのに対し、その場所にはマシンが1台もないといった場合などです。）その後、さらに別の場所にこれを追加したいと考えます。同じMESを導入する際、コアコードベースに対して行う変更やカスタマイズは、導入先ごとに少しずつ異なってきます。
さて、2つ目のサイトから、3つ目のサイトに直接適用できるベストプラクティスを見つけたいとしましょう。そこで問題が発生します。モノリシックなコードベースという概念そのものが、サイトごとの実装に合わせてカスタマイズを行うことを必然的に求めているからです。
マイクロサービスのアプローチではそうではありません。
では、クラウドへの移行に対する懸念が概ね解消された今、なぜ誰もがこのアプローチへの切り替えをためらっているのでしょうか？
レガシー。メーカー各社は、すべてのソフトウェアがオンプレミス利用向けに構築されていた時代に下されたアーキテクチャ上の決定がもたらした影響に、今なお対処せざるを得ない。単にそのコードベースをクラウドに移行しただけで、問題なく動作するとは期待できない。
最初からクラウドネイティブ環境で開発を始めていなければ、クラウドネイティブアーキテクチャならではの構築方法を再現するのは難しい。
つまり、行き詰まっているわけですね。最初からクラウドネイティブで構築していなければ、ベストプラクティスを適用して次のサイトへ移行するのは非常に困難です。MES 1.0からMES 2.0、あるいは2.1や2.2へのアップグレードは、さらに難しいかもしれません。それは苦痛を伴い、時間もかかります。
それはあなたの視点からの話ですね。でも、従来のMESベンダーにとってはどうなのか、想像してみてください。彼らにとってどのような影響があるのでしょうか？
もし12社の顧客を管理しており、各社が12の拠点を持っている場合、144種類の異なるコードベースを維持管理する必要があります。中核となるサービスに何らかの変更を加える際には、そのコードの144種類の異なるフォークすべてに対して下位互換性を確保しなければなりません。そのため、このソリューションは複雑で困難なものとなります。
そして、これがMESにおけるイノベーションの進展が遅い理由を説明しています。初期段階でのアーキテクチャの決定が、すべてを左右するからです。
まとめると、従来のMESモデルは以下の通りです：
人間ではなく、システムに焦点を当てている
アップグレードが難しい
更新に時間がかかり、コストもかかる
複雑で、部門間の連携が不十分
Tulip 従来のMESにどのようなTulip 突きつけているのか？
先ほど説明した従来のアーキテクチャ（これもまたオンプレミスで生まれたものですが）と比較すると、クラウドネイティブアーキテクチャの方が作業が簡単かつ迅速になります。
Tulip 単一のコードベースを採用しており、アプリはカスタマイズをコードで記述するのではなく、設定によって構成されます。コンポーザブルアーキテクチャの柱を振り返れば、俊敏性と拡張性という観点から、これは必然的なアプローチと言えます。
単一のコードベースを採用することで、そのコードベース全体にわたって定期的かつ迅速な更新が可能となり、サイト全体での大規模な改修やカスタマイズを行うのではなく、2週間ごとや四半期ごとのプラットフォームアップグレードを実現できます。これにより、新しい機能をいち早く利用できるようになります。
つまり、アプリを通じて、各サイトでベストプラクティスを簡単に展開することも可能です。
Stanley アンドStanley （Stanley で、現場のオペレーター向けにソリューションを構築したソフィアを覚えていますか？もし、そのアプリケーションを、導入の恩恵を受けられるさらに10の拠点に展開する機会があれば、彼女はそれを簡単に実現できるでしょう。しかし、もしSB&Dが以前のアーキテクチャと従来のMESを使ってアプリケーション開発の取り組みを始めていたとしたら、それは事実上不可能だったはずです。
まとめると、クラウドネイティブ・プラットフォームとコンポーザブル・モデルの利点は以下の通りです：
すべてのサイトで同じコードベースが使用されています
アプリの共有に関するベストプラクティス
業務全体を見渡す
2週間ごとの自動アップデート
イノベーションへの早期アクセス
ノーコードアプリは柔軟性を実現します
『2022年版 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES)』では、市場の変化がもたらす影響について、多くの洞察に富んだ考察が述べられています。また、本レポートでは「MESアーキテクチャ・イノベーション」という新たな評価基準が導入されており、これはベンダーが、今日の成功する製造企業に不可欠とされるアジリティと開発スピードを支えるマイクロサービス・アーキテクチャを提供していることを前提としています。
従来のMESではそれができません。だからこそ、Tulip 既存の枠組みに挑む存在Tulip 。
とはいえ、従来のMESからコンポーザビリティへの移行は、Tulipではないという点に留意しておく必要があります。
これはもっと根本的な問題です。ソフトウェア開発をどう捉えるか、そして開発がどこで行われるべきか、またどこで行えるかという点が問われているのです。従来のソリューションはオンプレミス型のアーキテクチャに基づいて構築されていましたが、コンポーザビリティを実現するにはクラウドネイティブなアーキテクチャが必要です。私たちは、製造プロセスを次の段階へと進化させる準備ができています。
Tulipでデータ収集を自動化し、生産性を向上させましょう
当社の担当者にぜひご相談ください。アプリを活用したシステムが、貴社の業務全体にわたる従業員、機械、機器をどのように連携させることができるかをご説明いたします。