「Functions」が一般提供開始となりました：ロジックを一度記述するだけで、あらゆる場所で管理できます

業務はそれぞれ異なり、そのどれもが常に変化し続けています。業務を最もよく理解しているアプリ開発者やプロセスエンジニアは、その変化に追いつくために最も大きなプレッシャーにさらされています。彼らは、1つの詳細が変更されただけで、十数ものアプリで同じ検証ルールを更新したり、作業指示フローのすべてのコピーを洗い出したり、あるいはチームがすでに実施方法を把握していることをIT部門が標準化するのを待ったりしなければなりません。

本日、Tulip の再利用可能なトリガーロジック機能である「Functions」が、早期アクセス段階を終了し、r380の一環として、すべてのウィークリープランのお客様を対象に、すべてのワークスペースでデフォルトで有効化されます。

関数を使用することで、アプリ開発者は、オートメーションですでに使い慣れているのと同じビジュアルエディタ、ネイティブなループ機能、複雑な条件分岐を用いて、トリガーロジックの一部を一度だけ定義し、その操作に必要な数の「Apps 」やトリガーから呼び出すことができます。関数を更新すると、それを参照しているすべてのアプリが、次回の公開時にその変更を反映します。同じロジックのコピーを何十個も探し回って手動で同期させる必要はもうありません。

これこそが、本来あるべき開発のあり方です。プロセスに最も近い立場にある方々、品質責任者、プロセスエンジニア、センター・オブ・エクセレンスが、ベンダーや中央の開発チームが変更を必要な場所すべてに波及させるのを待つことなく、ガバナンスの行き届いた再利用可能なソリューションを直接構築するのです。

再利用可能なロジックは、信頼できる場合にのみ役立ちます。そのため、Functionsは導入当初からガバナンスが適用されるよう設計されています。アプリを公開すると、そのアプリが使用するすべてのFunctionsのバージョンが固定されます。そのため、後でそのFunctionsのロジックが変更されても、本番環境で実行中のApps は、これまでとまったく同じように動作し続けます。Functionsを編集する前に、「使用箇所」で、現在そのFunctionsに基づいてビルドされているApps を確認できます。これにより、変更後に影響が判明するのではなく、変更を行う前にその影響を把握することができます。

また、センター・オブ・エクセレンス（COE）にとっては、その信頼性が真の強みとなります。App Builder の各担当者が手作業で同じ繊細なロジックを再現するのではなく、COEが一度「Function」を構築・レビュー・承認しておけば、チームの他のメンバーはそれを基盤として、安心して開発を進めることができるのです。

これは、プラットフォームとしての「Tulip 」全体に貫かれている原則と同じです。つまり、スピードを追求するために、操作性を犠牲にする必要はないということです。

「Functions」は、ここ数ヶ月間、アーリーアダプターの方々に利用されてきました。本日より、すべてのワークスペースでデフォルトで有効化されるほか、アーリーアダプターの方々から要望のあったいくつかの機能も追加されました：

• インポート／エクスポート機能により、関数はApps とともにインスタンスやワークスペース間を移動し、その際、マシンおよびユーザーへの参照が相手側で再マッピングされるため、意図せず誤った場所を指してしまうようなことはありません。
• 「関数」一覧ページから直接、関数の名前変更、複製、アーカイブを行うことができます。

これらは決して理論上の話ではありません。Tulip の中でも特に処理負荷の高い顧客のいくつかは、早期アクセス段階からFunctionsを活用してきており、彼らが確立した活用パターンは、いかなる機能一覧よりも、Functionsの真の用途を如実に物語っています。

あるモバイルオートメーションメーカーでは、最も頻繁に使用される2つの関数を、ユニットの作成（進行中の作業指示書を取得するか、ERP から次に処理可能な作業指示書を取得する）と、作業指示書の完了処理を中心に構築しており、これらはいずれも約300のアプリケーションで毎日頻繁に実行されています。 同社のプロセスエンジニアにとって、その価値は単に重複するトリガーが減ったことだけではありません。読みやすさにもあります。if/thenロジックが延々と続く「壁」を見る代わりに、「ユニットの作成」というステップを見るだけで、その背後にある仕組みを確認することなく、何が起きているのかを正確に理解できるのです。

別のロボットメーカーでは、Functionsが「ハブ・アンド・スポーク」型のアプリアーキテクチャへの移行を支える中核となっています。中央で管理される少数のFunctionsが標準的な処理を担当し、市民開発者がその周囲で特定のアプリを構築しています。特にテーブルへの書き込みは、設計上、Functionsのみで処理されるようになっています：

「テーブルレコードを作成したり、大幅に変更を加えたりする場合は、毎回関数を通じて処理するようにしています。そうすることで、市民開発者に対して明確な指針を示すことができます。誰かがユニットを作成する際には、まったく同じ情報を、まったく同じ方法で提供してくれると分かっています。誤った使い方をされて、私が後で原因を特定しなければならないような不具合が発生することはありません。」
— ソリューションエンジニア、チームの関数活用について

昆虫由来のタンパク質を生産するために高度に自動化されたプロセスを運用しているInnovafeed社は、Functionsを活用して、同一アプリの異なるバージョン間でロジックの一貫性を保っています。現在、コンテナの割り当てや出荷書類の作成に関するロジックは、1つのFunctionで定義されており、プランナーが使用するフル機能のデスクトップアプリと、現場のオペレーターが携帯する軽量なモバイル版の両方から、同じ名前で呼び出されています。このFunctionは、以前は異なるボタンに分散していた同一ロジックの3つの別々の実装に取って代わるものです。 また、チームはFunctionsを活用して、メンテナンスが煩雑になっていたループ処理による回避策を置き換え、繰り返されるロジックを単一の再利用可能なコンポーネントに統合しました。これらの変更により、実行速度が向上し、信頼性が高まり、メンテナンスもはるかに容易になりました。

まずは、すでに持っているパターンから着手するのが最善です。チームがこれまでに何度もコピー＆ペーストしてきたロジックを探してみてください。たとえば、すべてのスキャンステップで繰り返される検証ルール、アプリごとに再構築されている作業指示書の更新シーケンス、すべてのコネクタ呼び出しに毎回適用されている同じエラー処理などです。こうした繰り返しは、通常、Functionを導入することで即座に効果が得られる箇所を最も明確に示す兆候です。それは、今日の時間短縮という面でも、次回そのロジックを変更する必要が生じた際のリスク低減という面でも、大きなメリットをもたらします。