多くのアナリストの定期業務は、基本的に同じ流れをたどります。データをソースから取得し、クレンジングし、他のデータと結合し、ビジネスロジックを適用し、成果物を出力する流れです。出力先はレポートかもしれませんし、Snowflakeのテーブルやメールかもしれません。そして翌週の月曜日に、同じ処理が再び実行されます。あるいは、実行されないこともあります。そのワークフローを作成した担当者が不在の場合です。
多くの組織では、このような業務を自動化するにはPythonやSQLが必要であり、エンジニアリングの課題であるという前提があります。しかし、必ずしもそうとは限りません。本当の問題は、表計算ソフトの中や、それを作成したアナリストの頭の中にあるロジックが、これまで恒久的に保存される場所を持っていなかったことです。この記事では、コードを書くことなく、そのロジックを再利用可能な形で定着させる方法を解説します。
もしあなたのチームに、毎週同じ手順で実行しているレポート（同じデータソース、同じロジック、同じ出力）があるなら、そのワークフローを思い浮かべながら読み進めてください。
なぜ手動のデータワークフローは繰り返し破綻するのか — そして、なぜツールを増やしても解決しないのか
問題を考える前に、ひとつ重要な区別をしておく必要があります。ビジネスロジックは、さまざまな場所に存在しています。ERPの設定ルール、CRMのワークフロートリガー、BIツールの計算フィールドなどです。組織はシステムの中に膨大なロジックを組み込んでいます。しかし多くの場合、記録されていない層が存在します。それは、特定のレポートや意思決定においてデータを実際に活用可能な状態にする、アナリスト独自の解釈です。
その層には、次のようなものが含まれます。例えば、特定の地域の勘定科目を除き、差異が3％以内であれば許容するとする照合ルール、システム間でIDの形式が異なる顧客の例外リスト、四半期の最終週に取引が成立した場合にどの収益認識方法を適用するかという判断などです。これはシステム設定としてのビジネスロジックではありません。つまり、生データだけでは読み取れない情報を理解できるアナリストたちが、数か月あるいは数年にわたって積み重ねてきた判断の蓄積です。
その知識は、表計算ソフトの数式やルックアップテーブル、そして業務を構築した担当者の頭の中に存在しています。そして、その多くは体系的に文書化されていません。文書化されていない以上、体系的に保守されることもありません。Salesforceのフィールド名変更、新しいコストセンターの追加、営業テリトリーの再編など、上流システムに変更が生じるたびに、そのロジックが手作業で適用されている箇所をすべて特定して修正する必要があります。
最もよく発生する3つの問題
知識継承の問題：重要なワークフローを担当していたアナリストが退職や異動をすると、そのプロセスは停止するか、一から作り直されることになります。再構築には通常数週間を要します。そして、再構築されたプロセスには、誰も気付かない小さな誤りが入り込みます。その誤りが発覚するのは、多くの場合、取締役会や経営会議で数値が提示された後です。これは人的な問題ではありません。組織の知見が一人の記憶の中にしか存在していないことが原因です。
気付かれないまま壊れる問題：上流システムで列の追加、フィールド名の変更、ID形式の変更などが行われます。すると、VLOOKUP関数が誤った列を参照するようになります。しかし、出力結果は一見正常に見えます。誰も2回のレポートサイクルにわたって気付きません。問題が発覚した時には、すでに2か月分のデータが影響を受けています。しかも原因を突き止めるためには、文書化されていないプロセスを遡って調査しなければなりません。脆弱性は上流システムの変更によって生まれたのではありません。もともと存在していたのです。
拡張性の限界：現在のデータ量やレポート数では問題なく動作しているかもしれません。しかし、事業が成長し、新しい製品ラインの追加や企業買収が行われると状況は変わります。手作業のワークフローはスケールしません。担当者ごとに少しずつ異なるバージョンが作成されます。その結果、微妙に異なる数値が生成されます。そして、その違いは最も発見されたくないタイミングで明らかになります。
BIツールはクリーンで構造化されたデータを入力として必要とします。しかし、そのデータを作り出すわけではありません。ETLパイプラインはスキーマレベルで処理を行う仕組みであり、前述のような判断を伴うビジネスロジックを実装するためのものではありません。Pythonやdbtは、エンジニアリングチームにとってはこの課題を解決できます。しかしその場合、ロジックの所有権は、そのロジックを理解しているアナリストから、スクリプトを保守するエンジニアへ移ります。欠けているのは、ビジネス固有のロジックを一度だけ定義し、そのロジックを理解している担当者自身が管理し、人手を介さずに継続的かつ確実に実行できるレイヤーです。それこそが、データワークフロー自動化が実現しようとしているものです。
Python、Power Automate、それともノーコード自動化か： 現実的な比較
適切なツールは、誰がロジックを管理する必要があるのか、そしてそのロジックがどの程度の頻度で変更されるのかによって決まります。
Python + dbtは、変換ロジックが複雑で、バージョン管理を前提とした開発が必要な場合に適しています。また、その仕組みを維持・運用するためのリソースがチーム内にあることが前提です。
Power Automateは、Microsoftエコシステム内でのアプリケーション連携には優れています。しかし、スキーマが異なる複数システム間で多段階の分析データ準備を行うために設計されたものではありません。
エンジニアが管理するパイプラインは、処理量が非常に多く、スキーマが安定しており、ビジネスルールの変更がほとんど発生しない場合に適しています。
ノーコードのワークフロー自動化は、ロジックの所有者がアナリストであり、そのワークフローをビジネスを理解している担当者自身が理解・修正する必要があり、変更への迅速な対応が求められる場合に適しています。
率直な診断方法として、「業務ルールが変更されたとき、誰がその場にいる必要があるか」を考えてみてください。その答えがアナリストであるなら、そのワークフローはアナリスト自身が保守できるツール上に存在するべきです。
コードを書かずにデータワークフローを自動化する方法：ステップバイステップガイド
以下の手順は、どのノーコードワークフロー自動化プラットフォームにも共通して適用できます。対象読者は、データとビジネス課題を理解しており、エンジニアリングチームに依頼することなく最初の自動化ワークフローを構築したいシニアアナリストです。
ステップ1：最初に自動化するワークフローを選ぶ
すべてのワークフローが、最初の自動化対象として適しているわけではありません。最初に取り組む対象として最適なのは、次の3つの特徴を備えた業務です。固定のスケジュールまたは定期的なトリガーで実行されること、毎回同じ種類の成果物を生成すること、そしてその業務を担当している人がその業務に必要なビジネスロジックも理解していることです。
簡単な見つけ方があります。過去3か月分のカレンダーを開いてみてください。「レポートを更新」「数値を取得」「週次レポートを実行」といった名前が付いた作業を探してみてください。「これとまったく同じ作業をもう何十回もやっている」と思うものがあれば、それが最初の自動化候補です。
最初から最も複雑なワークフローを選ぶ必要はありません。まずは、予測可能なプロセスから始めましょう。最初の自動化の目的は、最も難しい課題を解決することではありません。エンドツーエンドで理解できる実用的なテンプレートを構築し、自動化の基盤を整えることです。
ステップ2：ツールに触れる前に、すべての手順を書き出す
これは多くのアナリストが省略しがちなステップですが、最初の自動化プロジェクトが途中で頓挫する最大の原因でもあります。どのツールやプラットフォームを開く前にも、最初のデータソースから最終成果物までのプロセスを詳細に書き出してください。大まかな流れではなく、実際に行っているすべての作業を対象にします。
おすすめの形式は「データソース」、「処理内容」、「出力結果」です。各ステップについて、データの取得元となるシステムやファイル、そのデータに対して行う処理（フィルタリング、結合、計算、クレンジング、形式変換など）、そしてその結果として得られる成果物を記載してください。2つのテーブルを結合する場合は、結合キーと既知の不一致パターンも記録してください。数式を適用している場合は、その数式をそのまま書き出してください。例外処理がある場合は、それらも明確に記録してください。例えば、通常とは異なる扱いをする勘定科目、異なるロジックを適用する日付範囲、ルックアップテーブルで管理している設定などが該当します。
多くのアナリストは、この作業に45〜90分ほどかかり、想像以上に長い文書になることに気付きます。しかし、文書化に90分かかり、毎週の実行に2時間かかるようなプロセスは自動化の有力候補です。「ケースバイケースだから説明できない」という理由で文書化できないプロセスは、ロジック自体がまだ十分に整理されていないことを示しています。
ステップ3：ルールベースのロジックと判断を要するロジックを区別する
この区別によって、自動化できる部分と人間の判断が必要な部分が明確になります。
ルールベースのロジックとは、状況にかかわらず常に同じ結果が得られる処理のことです。例えば、このキーで結合する、差異が5％を超える行にフラグを付ける、ステータスが「受注済み」のデータに絞り込む、指定された為替レートを適用するといった処理が該当します。これらはすべて、ワークフローのステップとしてそのまま実装できます。
一方、判断を要するロジックとは、答えが明文化された条件ではなく、担当者の知識や経験の中に存在しているものです。よくある例として、「この3つの勘定科目はIDの対応付けがうまくいかないから毎回手動で確認する」、「この売上項目は第4四半期だけ意味が異なる」、「通常は5％だがエンタープライズ顧客については8％を閾値とする」といったケースがあります。ステップ2で作成したプロセス文書を見ると、こうした処理はたいてい「手動確認」、「状況による」と書かれている箇所として現れます。
目的は判断を排除することではありません。判断基準を明文化することです。判断が必要な各ステップについて「自分は実際にはどのルールに基づいて判断しているのか？」と自問してみてください。多くの場合、そのルールは言語化できます。一度明文化すれば、それは毎回人が判断する事項ではなく、ワークフローが参照する設定可能なパラメーターやルックアップテーブルとして管理できるようになります。例えば、表計算ソフトのAC列に保存している例外アカウント一覧は、ワークフローが参照できる独立した参照ファイルとして管理できます。また、これまで頭の中だけに存在していた閾値は、ワークフローの先頭に配置された名前付きパラメーターとして管理できます。
ステップ4：データ接続と現在の取得方法を整理する
プラットフォームを選ぶ前に、ワークフローで利用しているすべてのシステムを書き出してください。そして特に重要なのは、現在どのようにデータを取得しているかを明確にすることです。各データソースを、次の3つのカテゴリのいずれかに分類してください。システム内でレポートを実行してファイルをダウンロードするもの、他の担当者からメールでエクスポートデータを受け取るもの、またはSQLやAPIを介してシステムに直接クエリを実行するもの、です。
この分類が重要なのは、プラットフォームのコネクタが実際に何を置き換える必要があるのかが明確になるからです。カテゴリ1とカテゴリ2は、現在も手動でのデータ取得が発生していることを意味します。「Salesforce連携」を謳っていても、依然としてSalesforceレポートのスケジュール設定やファイルの取得が必要なプラットフォームでは、その手順がなくなったわけではなく、単に別の場所へ移っただけです。これらのデータソースには、中間的なエクスポートを行わずに、実行のたびに最新のデータを取得できるライブ接続が必要です。ワークフロー構築を始める前に、この点を必ず確認してください。
この段階では、データアクセスに関する課題 — 認証情報、アクセス権限、ファイアウォールのルールなど — も明らかになります。これらは、開発を開始した後よりも、開始前に解決しておく方がはるかに容易です。
ステップ5：最初のバージョンは段階的に構築する
ドキュメントが完成し、ロジックの分類と接続の整理が終わったら、いよいよ構築を開始します。重要な原則は、各段階で正しい結果が得られることを確認してから次に進むことです。
ステージ1は、最初のデータソースと最初のフィルター、またはクレンジング処理だけを実装します。データソースに接続し、手作業で最初に行っている処理だけを適用します。そして結果をプレビューするか、フラットファイルとして出力します。同期間の手動処理の出力結果と比較し、行数とレコードのサンプルが一致していることを確認してください。一致しているはずです。一致しない場合は、接続設定またはフィルター条件に問題があります。その問題を解決してから次のステップへ進みます。
その後、次の処理を追加します。結合処理の場合は、この段階で最も多くの時間を要します。一致率（マッチ率）を必ず確認してください。手動プロセスで94%の一致率が得られているのであれば、自動化後のプロセスでも同じ94%の一致率になるはずです。そうならない場合は、結合ロジックがまだ手動プロセスと同等になっていないことを意味します。先頭のゼロが欠落したID、日付形式の不一致、大文字・小文字の表記ゆれが、最も一般的な原因です。まずはIDを正規化し、一致率を確認してから下流の処理を構築してください。
各ステップを順に進めていきます。この方法は、ワークフロー全体を一度に構築するよりも時間がかかるように見えますが、デバッグは大幅に容易になります。出力結果に差異が生じた場合、どのステップで問題が発生したのかを正確に特定できるためです。
ステップ6：スケジュール化する前に3回手動で実行する
ワークフローをスケジュール実行へ移行する前に、3種類のデータセットを使って手動実行してください。先週のデータ、2か月前のある週のデータ、そして四半期末、営業テリトリーの変更、買収完了などの通常とは異なる出来事があった週のデータです。それぞれについて、自動化ワークフローの出力と手動プロセスの出力を比較します。
この作業により、頭の中では正しく理解していたにもかかわらず、ワークフローへの実装時に誤っていた前提条件を発見できます。最も一般的なのは、当週では正しく機能するものの月替わりで動作しなくなる日付フィルター、大半のレコードは正しく処理できるものの特定の例外カテゴリでは誤った処理を行う結合ロジック、そしてNULL値や想定外のフィールド長によって出力形式が崩れるケースです。
3回のテスト実行すべてで手動プロセスと同じ結果が得られたら、ロジックの検証は完了です。その時点でスケジュールを設定してください。これで最初の自動化は完成です。そして、それまでの手作業プロセスもその役目を終えます。
評価すべきプラットフォームを見極める3つの基準
ノーコードおよびローコードのデータツール市場は大きく成長し、多くの製品がデモでは似たように見えるようになっています。しかし、実際に使い始めると次の基準が本当の違いを明らかにします。
データ接続はライブ接続か、それともエクスポート依存か
初めて自動化に取り組む際によくある不満の原因は、プラットフォームの「Salesforceコネクタ」が実際にはSalesforceレポートのエクスポートをスケジュール実行し、その出力ファイルを取り込む必要があることに後から気づくことです。つまり、自動化できているのはデータ処理だけであり、データ取得はまだ自動化されていないということです。多くの場合、最も時間のかかる作業がそのまま残ってしまいます。
具体的に確認してください。そのプラットフォームは、ソースシステムに直接接続し、ワークフローを実行するたびに最新のデータを取得しますか？SnowflakeやDatabricksのようなクラウドデータウェアハウスに対して、データを事前にプラットフォームへ移動することなく、インデータベース処理でクエリを実行できますか？これらの答えによって、エクスポート作業を本当に排除できるのか、それとも単に場所を変えただけなのかが分かります。
ロジックを作成者以外も確認できるか
手動ワークフローの大きな問題のひとつは、ロジックが作成者本人の頭の中にしか存在しないことです。表計算ソフトを同じように中身が見えにくいワークフローを持つプラットフォームへ置き換えただけでは、問題は解決されません。問題を別の場所へ移しただけです。
理想的なのは、すべての変換ステップが可視化され、ラベル付けされ、アクセス権を持つ誰もが内容を理解できるワークフローです。何が、いつ、どの入力を使って実行されたのかを記録する監査ログも必要です。さらに、実行ごとの変更内容を確認できるバージョン履歴も重要です。これらは単なる「あれば便利な機能」ではありません。組織が所有するワークフローと、一人のアナリストだけが所有するワークフローを分ける要素です。
ビジネスが変化したとき、誰がロジックを更新できるか
これは、多くのプラットフォームが大規模運用の段階で満たせなくなる基準です。パラメーターを更新するだけでもエンジニアリングチケットが必要なツールで構築されたワークフローは、アナリストが保守できるものではありません。それは依存関係をなくしたのではなく、依存関係を自動化したに過ぎません。
テストとして、自分の業務で定期的に変更されるビジネスルールを1つ選んでください。たとえば、閾値、テリトリーマッピング、例外アカウントの一覧などです。そのプラットフォームで、ワークフロー構築から6か月後にそのルールを更新する場合を想定してください。しかも、最初に構築した担当者がすでにチームを離れているとします。その内容を確認するためにコードファイルを開いたり、チケットを起票したりする必要があるのであれば、そのガバナンスモデルはアナリストが管理するロジックには適していません。
収益照合の自動化：6つのステップを適用した例
以下の収益照合は Alteryx One で構築されていますが、前のセクションで挙げた3つの基準を満たすプラットフォームであれば、同様の流れで実行できます。
手動プロセスの流れ
毎週月曜日、収益オペレーション担当のアナリストは、前週に成約した商談データをSalesforceからCSV形式でエクスポートします。また、財務チームからOracle ERPの請求書データ抽出ファイルをメールで受け取ります。両方のファイルは、2年間にわたり3人のアナリストが引き継いで運用してきたマスター照合用の表計算ファイルに取り込まれます。現在のバージョンは、当初の構成に加え、その都度、必要に応じて担当者が追加した2回分の修正が積み重なった、いわばハイブリッドな状態になっています。
VLOOKUP関数で、商談IDを基にレコードを照合します。調子の良い週でも一致率は約94％です。残りの6％は手動レビューの列に回されます。主な理由は、Salesforceでは商談IDの先頭にゼロが付いているのに対し、Oracleではエクスポート時にそのゼロが削除されるためです。アナリストは既知の不一致をマッピングするルックアップテーブルをAC列で管理しており、新しい不一致が見つかるたびに追加しています。
不一致を検出するための5％の差異閾値は、元のバージョンを作成したアナリストが設定したものです。現在のアナリストはその数値を知っていますが、その根拠までは把握していません。その情報はどこにも文書化されていません。
問題なく進む週でも、合計所要時間は2時間半から3時間です。エクスポートが失敗した場合や、Salesforceレポートに新しい列が追加された場合は、デバッグにさらに1時間かかります。
問題が発生する箇所
年半ばの組織再編により、40件のアカウントが別の営業テリトリーへ移されます。Salesforceのテリトリーフィールドの値が、Oracleの対応するGLセグメントコードと一致しなくなります。VLOOKUP関数自体は実行されます。ただし、その40件のアカウントについては誤った基準で照合されます。出力は一見正しく見えます。その結果、FP&A担当者が地域別の数値の不整合に気付くまで、対象アカウントの収益が誤ったセグメントに配分された状態が2回のレポートサイクルにわたって続きます。
調査が始まると、レポート担当のアナリストは、問題の内容を説明するためにロジックを口頭で再構成しなければなりません。問題は彼女がミスをしたことではありません。問題は、照合ロジックが「テリトリーとセグメントの対応関係は固定である」という構造的な前提の上に構築されていたにもかかわらず、その前提がルールとして明文化されていなかったことです。そもそも、それを書き残す場所がありませんでした。
自動化後の同じワークフロー
ステップ1では、この業務が最初の自動化候補として適していると判断されました。理由は、毎週決まったサイクルで実行されること、出力形式が一貫していること、そして業務担当者がビジネスロジックも管理していることです。ステップ2では、IDの不一致の問題や例外対応用の参照テーブルを含むプロセスのドキュメントを作成しました。ステップ3では、差異の閾値と営業テリトリーからセグメントへのマッピングを、明示的に定義する必要がある判断依存のロジックとして分類しました。その結果、どちらも名前付きパラメーターとして管理されるようになりました。ステップ4では、Alteryx DesignerがSalesforceとOracleの両方にライブ接続できるコネクタを備えており、エクスポートファイルを介さずに最新のデータを取得できることを確認しました。
構築されたワークフローは、ネイティブコネクタを利用してSalesforceとOracleに直接接続します。IDの正規化ステップでは、先頭ゼロの不一致を設定済みの変換ルールとして処理します。テリトリーとセグメントの対応関係は、ワークフロー内のルックアップテーブルで管理されます。このルックアップテーブルは、変更されるたびにバージョン管理されます。また、5％の差異閾値はワークフローの先頭に配置された名前付きパラメーターとして定義されています。そのパラメーターには設定理由を説明するメモが付いており、アクセス権を持つアナリストであれば誰でも更新できます。出力結果はSnowflakeに送信され、その後配布リストへのメール送信が行われます。実行スケジュールは毎週月曜日の午前7時です。
組織再編が発生した場合は、アナリストがテリトリーとセグメントの対応表を更新します。所要時間は15分程度です。その後の月曜日には、ワークフローは正しい内容で実行されます。FP&Aチームから「なぜセグメント別の配分が変わったのですか？」と質問された場合も、回答は口頭での説明ではありません。ワークフロー内に記録されたタイムスタンプ付きの変更履歴を確認すれば済みます。
ステップ6（スケジュール設定前の3回のテスト実行）では、1つの問題が見つかりました。日付フィルターに「過去7日間」のロジックを使用していたため、日曜夜に成立した商談に付与されるSalesforceのエクスポートタイムスタンプの扱いにより、月曜日と火曜日で結果が異なっていたのです。この問題は、本番環境で発生する前にテスト段階で修正されました。
上記のワークフローは、実際の現場で最初に構築される自動化の典型例です。ご自身の業務プロセスでも同じアプローチを試してみたい場合は、 Alteryx Oneの無料トライアルを利用できます。 IT部門による環境構築を待つ必要はなく、すぐに開始できます。
まず着手すべきなのは、すでに問題だと分かっているワークフロー
前述の6つのステップは、すでに「どこか問題がある」と感じているプロセスに適用したときに最も効果を発揮します。チームの中で最も複雑な業務ではありません。最も手間がかかり、繰り返し発生する業務です。たとえば、「もし2週間休んだらどうなる？」という質問に対して、「誰かが一から作り直すことになるが、おそらく少し異なる結果になる」と答えるようなワークフローです。
最初の自動化対象を見つけるための3つの質問：上流システムに変更があったとき、再構築に最も時間がかかるプロセスはどれですか？その仕組みを理解している特定の担当者の記憶に最も依存しているプロセスはどれですか？誤った数値が出力されたにもかかわらず、修正が難しくなるまで誰も気付かなかったプロセスはどれですか？この3つすべてで最も問題が大きいワークフローこそ、最初に自動化すべき対象です。
ツールを開く前に、まず文書化のステップを実施してください。その一手間 — 最初のデータソースから最終的な出力に至るまでのすべての処理を書き出すこと — だけで、そのプロセスが予想以上に簡単に自動化できること、あるいは誰もが思っていた以上に脆弱であることが明らかになる場合が少なくありません。いずれの気付きにも価値があります。
Alteryx Oneが自社の業務に適したプラットフォームかどうかを評価したい場合は、自社のデータと業務プロセスで実際に試せる無料トライアルが、最も直接的な方法です。トライアルを開始するために、IT部門の関与は必要ありません。また、ステップ2で作成したワークフローのドキュメントは、最初に構築するワークフローの仕様書としてそのまま活用できます。
現時点で無料トライアルを試すことよりも社内での合意形成を優先したい場合は、AlteryxのAnalytics Maturity Assessment（分析成熟度評価）を利用すると、同業他社との比較に基づいたスコア付きレポートを取得できます。このレポートは、自動化への投資がどの領域で最も測定可能な成果を生み出す可能性が高いかを検討する際の、ビジネスケース作成に役立つ参考資料となります。