ローコードワークフロー自動化プラットフォーム：本当に重要なこと

ローコードのワークフロー自動化を提案する際、決まって最初に強調されるのが「スピード」です。より速い構築、より速いデプロイ、あらゆる作業の高速化。

確かにスピードは役立ちますが、ワークフローが最初の1年を乗り越えられるかどうかを決める要素ではありません。重要なのはオーナーシップです。具体的には、ワークフロー内のロジックを誰が管理し、その担当者がチームを離れたり、昇進したり、あるいは2週間の休暇で不在になったりした場合にどうなるかということです。現在は高速に実行できても、その仕組みが特定の1人の頭の中にしかないワークフローは、自動化されているとは言言えません。単に速いだけで、長期的に維持できないことが問題です。

スピードと持続性の間にあるこのギャップが製品デモで取り上げられることはほとんどありません。当然ながら、どのツールにとってもセールスポイントになる内容ではないからです。実際、この問題が表面化するのは8か月ほど経ってからです。ワークフローを構築した担当者が不在になったり、別の職務に移ったりしても、そのワークフローから作成されるレポートの締め切りは月曜の朝にやってきます。そうなれば、当初どれほど速く構築できたかを喜ぶ人はいません。

この記事では、スピードと持続性に差が生じる5つのポイントを、まずスピードそのものに関する議論から順に解説します。

ローコードが重要なのはスピードだけではありません

スピードがローコードの大きなメリットであることは確かですが、それ自体を目標にしてしまうと、得られるのは単に高速化されたスプレッドシートであり、長期的に利用できるワークフロー自動化にはなりません。

多くの組織がスピードを重視しており、市場の数字もその傾向を裏付けています。Gartnerは、エージェント型AIと市民開発が導入をさらに後押しすることで、ローコード開発テクノロジー市場は年率14.1%で成長し、2029年までに582億ドルに達すると予測しています。しかし、その数字だけでは、構築したものが長期的に機能し続けるかどうかはわかりません。

そして、ここで「導入」と「持続性」の違いが本当に重要になります。構築が速く、引き継ぎも容易なワークフローは、作成者以外の担当者でも引き継いで改善を続けられるため、月を追うごとに価値が高まります。一方、単に構築が速いだけのワークフローは、作成者以外に内部の仕組みを十分に理解している人がいないため、月を追うごとにリスクが高まります。この2つを混同していることが、多くのローコードマーケティングの問題点です。

例えば、あるアナリストが午後の数時間でワークフローを作り上げたとします。問題なく機能し、いつの間にか業務に欠かせない存在になります。しかし6か月後には、他の誰も安心して手を加えられなくなっています。これはどの分析チームでもよく見られるパターンで、おそらく実際に目にしたことがあるでしょう。

これはローコード特有の問題ではありませんが、ローコードは構築が速い分、手作業でコーディングするプロセスよりも途中で十分に精査されないまま、こうした状態に早く陥りやすくなります。

同じ週に、同じ問題を解決する2つのワークフローを構築したとします。1つ目は短期間で構築され、リリース当初と変わらない速さで動作しますが、ドキュメントはなく、作成者以外に明確な担当者もいません。いわば、誰も開けたがらない、何の表示もないドアのようなワークフローです。2つ目は、文書化された構造と明確な引き継ぎ方法を備えて構築されているため、完成までに少し時間がかかります。

1年後、1つ目のワークフローは、更新するのが危険だと感じられるため、手つかずのままになっています。2つ目のワークフローは、安心して更新できるため、別の担当者によって4～5回改善されています。

2つのワークフローの構築速度はほぼ同じでも、12か月間でもたらした価値には大きな差が生まれます。

コードフリーかコードフレンドリーかは、一度決めたら変えられない選択ではありません

手作業による処理が、スクリプト化されたステップに変わります。スクリプト化されたステップは、他のワークフローからも呼び出せる、共有可能で再利用可能な要素へと発展します。多くのベンダーコンテンツでは、コードフリーかコードフレンドリーかを導入時に一度だけ決める選択肢として扱っていますが、実際にはこうした発展こそがワークフローの本来のライフサイクルです。

購入者がローコードを選ぶ理由の一つは、構築方法を一つに固定されないためですが、調達時点でどちらか一方に決めつけてしまうと、どちらの場合も問題が生じる可能性があります。コードフリーに偏りすぎると、インターフェースでは対応できない例外ケースが初めて発生した時点で、プラットフォーム外に場当たり的な回避策を追加することになります。コードファーストに偏りすぎると、ガバナンスの効いたキャンバスなら標準機能で対応できるものを構築するために数か月を費やし、さらに本来ローコードによって軽減できるはずだった保守作業まで抱えることになります。

より重要なのは、次の点です。要件が変わるたびに作り直すことなく、1つのワークフロー内でドラッグアンドドロップのステップとSQLやPythonのコードを組み合わせられるでしょうか？ワークフローに求められるものは長期間同じままであることがほとんどないため、「コードフリー」か「コードフレンドリー」かというラベルよりも、こうした柔軟性の方が重要です。導入時には問題なく機能していたドラッグアンドドロップによる結合も、ソースシステムから送られるフィールドの形式が以前と変われば、6か月後にはカスタムの正規表現を使ったステップが必要になるかもしれません。

プラットフォームがドラッグアンドドロップにしか対応していなければ、その正規表現の処理は別の場所に作られ、作成者だけが把握しているスクリプトとして管理されることになります。ワークフロー自体は引き続き「動作」しますが、本当に重要なロジックは、いつの間にか本来それをガバナンスするはずのシステムの外に移ってしまいます。

チーム内に、こうした二者択一を早い段階で決めてしまい、それ以来見直していないことが原因で、今まさに行き詰まっているワークフローはありませんか？

市民開発を厳しく制限すると、かえってシャドーITが増加します

状況をコントロールするために市民開発を厳しく制限すると、多くの場合、シャドーITは減るどころか、かえって増えてしまいます。このようなパラドックスが生じるのは、アクセスを制限しても自動化への需要がなくなるわけではなく、許可を得ずに簡単に使える別のツールへと移るだけだからです。そして、そのツールは、本来なら意図的に選ばれるようなものではないことがほとんどです。

市民開発に関するForresterの調査によると、少なくとも3分の2の組織が、すでに正式な市民開発戦略を策定しているか、今後12か月以内に策定する予定です。Forresterは、市民開発を責任を持って拡大するための3つの方法を示しています。

• Privateer：1つの事業部門内に設置された、小規模で自律的なチーム
• Democracy：誰でも利用できる広く開かれたモデルで、構築できる範囲には一定のガードレールが設けられています
• Federation（連携型）：中央で定めた標準と分散型の構築を組み合わせたハイブリッドモデル

市民開発を適切に管理するには、需要がガバナンス体制を上回ってから慌てて対応するのではなく、あらかじめガバナンスの仕組みを整えておくことが重要です。

ただし、その仕組みを構築する前に、実際に誰が何を構築するのかについて共通認識を持つ必要があります。市民開発に関するMITの研究では、3つの異なるロールに分類しています。

• シチズンデベロッパーは、アプリケーションを構築します。
• シチズンオートメーターは、標準では連携できないシステム間の自動化を設定します。
• シチズンデータサイエンティストは、モデルやダッシュボードを構築します。

これらのロールにはそれぞれ異なる種類の監督が必要であり、すべてを「市民開発」とひとまとめにしてしまうと、その違いが見えなくなります。

目標は、ワークフローを構築する人を減らすことではありません。重要なのは、作業内容を可視化し、監査可能な状態に保てるシステム内で構築してもらうことです。セルフサービス分析は、この考え方が実際に機能している好例です。IT部門がそれを脅威と見なすのではなく、使いやすさを考慮して設計すべきものとして捉えるようになると、導入が一気に進みました。

「アナリストが自分の業務を自動化してもよいのか」という問いへの答えは、誰かが午後の作業時間を短縮するために初めてマクロを書いた時点で、すでに出ています。したがって、もはやIT部門が議論すべきなのは、その問いではありません。

本当に議論すべきなのは、どこにガードレールを設けるかです。財務数値に影響する前に、明確な担当者とレビュー手順が必要なワークフローはどれか。一方で、チケットの処理を待たずにシチズンオートメーターがそのままリリースできるほど低リスクなワークフローはどれかを見極める必要があります。この議論を避けても、市民開発そのものが減るわけではありません。同じだけの市民開発が続き、単にその実態が見えなくなるだけです。

ローコードベンダーとの検討で確認すべきチェックリスト

以下の4つの質問は、どのプラットフォームを評価する場合でも、ベンダーとの検討に役立ちます。

1. ワークフローを再構築することなく、そのロジックをコードフリーからコードフレンドリーまで柔軟に移行できますか？
2. プラットフォーム内の市民開発にはガバナンスが効いており、可視化されていますか？それとも、単に許可されているだけで、監視されていませんか？
3. ワークフローは再利用可能で文書化されたコンポーネントとして構築されていますか？それとも、他の人が安心して開くことのできない一度きりのスクリプトになっていますか？
4. このプラットフォームは、要件の変化に応じた継続的な改善に対応していますか？それとも、初回の導入だけをサポートしていますか？

何も再利用されなければ、ローコードは行き詰まります

ローコード導入の拡大を左右するのは、ほぼ常に再利用性です。そのワークフローは、後から再び活用できるように構築されていますか？それとも、一度動作したらそのまま忘れられるような作りになっていますか？

例として、調達チームが発注書の例外とベンダーの請求書を照合するケースにおいて、この再利用に関する問題が通常どのように生じるかを見てみましょう。通常、チームの誰かが金額の不一致を検出する個人用のExcelマクロを作成し、それが十分に機能するため、何年もの間、誰も疑問を持たなくなります。オフィスのマクロの世界では、何年という期間はほぼ永遠に等しいものです。

このようなマクロは、たとえば9種類中7種類といった大半の例外を問題なく検出できますが、ERPシステムと請求書PDFでPO番号の形式が異なるケースなど、誰も想定していなかったエッジケースを見逃すことがあります。これは、特定のベンダー固有の書類のフォーマット方法に起因するものです。まさにこのようなギャップが、SOX監査での指摘につながります。

他の人が作成した表計算ファイルを引き継いだことがある方なら、このような状況に心当たりがあるでしょう。普段その表計算ファイルを管理しているアナリストが不在になると、チームの他のメンバーはそのマクロの存在すら知らず、ましてや開き方もわからないため、誰にも気づかれないまま数週間にわたって例外処理のバックログが蓄積していきます。

こうした問題がきっかけとなり、最終的にチームは、元のマクロが見落としていたエッジケースも含め、独自のスケジュールとトリガーを備えた、ドキュメント化された再利用可能なワークフローコンポーネントとして、照合ロジックを適切に再構築することになります。

これは、構築を高速化するためだけの話ではありません。重要なのは、その存在を特定の担当者が覚えていることに依存しない仕組みを構築することです。これはチームにとってだけでなく、財務や監査のステークホルダーにとっても同じように重要です。

以下は、Alteryxで構築された再利用可能なコンポーネント（この場合はマクロ）の例です。

これが自社のチームにも当てはまるようであれば、ベンダーを選定する前に、現在のワークフローの状態を厳しく検証してみる価値があります。「ワークシートからワークフローへの移行」では、特定の担当者が管理する表計算ファイルから、再利用可能でドキュメント化されたワークフローへの移行が、実際にどのようなものかをご紹介します。

自動化は導入して終わりではありません

一度自動化しただけで、その後見直されることのないワークフローは、メンテナンスされていない表計算ファイルと同じように劣化します。ただし、その劣化はより見えにくいものです。その問題は後になって、監査での指摘や、いつの間にか実態と一致しなくなった数値という形で表面化することがよくあります。

調達の例で紹介した再利用可能なコンポーネントという考え方は、ここでも効果を発揮します。ベンダーの変更や閾値の変更などがあった場合でも、共有の照合コンポーネントを一度更新するだけで、それを基に構築されたすべてのワークフローが自動的に更新されます。そもそもコピーが1つしかないため、複数のコピーを探し出して一つひとつ修正する必要はありません。

自然言語AIアシスタントもここで活用され始めていますが、実際に何ができるのかを明確に理解しておくことが重要です。Ask Alteryxがその好例です。チームは平易な言葉を使って、既存のガバナンスの効いたワークフローに対してクエリを実行したり、更新したりできますが、それが基盤となるガバナンス構造に取って代わるわけではありません。設計者ではなく、アシスタントと考えてください。この2つは異なる役割であり、ツールを評価する際には明確に区別しておくことが重要です。

Alteryx Oneで検証したチェックリスト

先ほどご紹介したベンダー評価の基準に照らして、Alteryxがどのように評価されるかを見てみましょう。

ローコードのワークフロー自動化を始めましょう

さらに詳しく検討したい場合は、定期的なアナリストワークフローの自動化と正式な評価フレームワークで、この記事だけではカバーしきれないポイントを解説しています。

ただし、始める前にそのすべてを読んだり、プラットフォーム全体を導入したりする必要はありません。誰かの個人用の表計算ファイルに残っているような、定期レポートや手作業による照合プロセスを1つ選び、その部分だけをガバナンスの効いた再利用可能なコンポーネントとして再構築してみてください。残りの部分を移行する価値があるかどうかを判断する前に、まずはその効果を確かめてみてください。

重要なのは、ローコードのワークフロー自動化が真価を発揮するのは、最初の構築スピードだけでなく、誰が管理できるのか、そして長期的に運用できるかという点にあることです。Alteryx Oneはまさにその点を念頭に置いて構築されており、無料トライアルを利用すれば、自社のワークフローでも期待どおりに機能するかをすぐに確認できます。