毎回手作業でやっているチェックを自動化する

pipelineビルダーを開き、自分が手作業で行っているチェックに一番近い既製のグラフを選ぶ。単価ゼロの項目にフラグを立てる、最も高額な項目を一覧にする、予算上限を守る、検証を通るまでエクスポートをブロックする、といったものだ。それはキャンバス上にすでに配線済みで、すぐ実行できる状態で置かれる。

理由: 何も置かれていないキャンバスは、たいていの自動化のアイデアが立ち消えになる場所である。最初の1時間はどのポートがどこにつながるかを解明することに費やされてしまうからだ。最初のクリックで動くグラフから始めれば、動かないロジックを推測するのではなく、機能しているロジックを読んで手を入れることから始められる。

テンプレートのデータソースを自分の内訳書、単価台帳、または検証結果に差し替え、このプロジェクトで意味を持つ数値を設定する。予算ガードが作動する上限や、閾値ゲートが比較対象とする数字などである。形が完全には合わない箇所には計算列、グループ集計、リネーム、あるいは分岐を追加し、データソースが空のときは実行を止める空チェックを付け加える。

理由: テンプレートが運ぶのはロジックであり、あなたのプロジェクトの数字ではない。上限がデモ用の数値のまま残っていると、投入したものすべてを通してしまう。これはガードが全くない状態より悪い。実行結果が緑になり、誰もがチェックが行われたと思い込んでしまうからだ。

実行ボタンを押す前に問題件数を確認する。必須入力に配線されていないステップや、キャンバス上に配線が一本もなく孤立したノードがあれば、そこにフラグが立つ。それを解消してからpipelineを実行し、最終合計だけでなく各ステップが実際に何をしたかを確認する。

理由: どこにも繋がっていないステップはエラーにはならない。単に一度も実行されないだけであり、pipelineはキャンバスの見た目より少ないことしかしていないのに成功と報告してしまう。これこそ探す価値のある失敗である。実行結果が緑になること自体が、誰も二度と見返さなくなる原因になるからだ。

検出結果を検証プロセスに引き継ぎ、指摘された項目を修正し、来月はピッカーに出てくるようにワークフローを保存する。記憶を頼りに一から作り直す必要はなくなる。

理由: 自動化が元を取るのは2回目の実行からである。一人の頭の中にしかないチェックは、その人が休暇に入った週に飛ばされ、長いプロジェクトではまさにその週が高額な問題を見つけられたはずの週になる。