ノーコードの自動化フローを全社の武器にする。導入の全体像

業務の自動化は長らく情シスの仕事で、依頼して順番を待って、数か月後にようやく動きます。

この構造だと、小さな不便がそのまま放置されるのは、「依頼するほどのことじゃない」と現場のほうで諦められてしまうからです。
ところがGoogle Workspace Studioのような、ノーコードで組める自動化の仕組みが使えるようになると、この構造そのものが変わります。
現場が自分の手で作れるようになるからです。

今回は、ノーコードの自動化フローを全社に広げていく導入の全体像を書いていきます。
自動化の全体像はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

自動化は情シスの仕事という前提を外す

まず確認しておくと、すべての自動化を現場が作れるわけではありません。
現場が作れるのは単純な処理で、「受信したら記録する」「定時に集計する」「条件に合ったら通知する」といったところです。
情シスや書ける人が必要なのは複雑な処理で、複数の条件による分岐、大量のデータの処理、外部のシステムとの連携になります。

では、単純な処理はどれくらいあるのでしょうか？
「単純な処理が業務の8割を占める」というのが、実務での感覚だと思います。
だから現場が作れるようになると、依頼の総量そのものが大きく減ります。

もちろん、情シスにとっても悪い話ではありません。
「作ってほしい」という依頼が「見てほしい」という相談に変わり、受ける総量が減るからです。

手段そのものの選び方は業務自動化はどのツールで作る？Gem・GAS・Canvasの判断基準で扱っています。

ノーコードの自動化フローで何ができるのか

現場には、3つの起点で説明するのがいちばん分かりやすいと思います。

1つは時刻で動くもので、毎朝7時、毎週金曜17時といった形です。
定例のレポート、リマインド、集計が当てはまります。

もう1つは何かが起きたら動くもので、メールが届いた、フォームが送信された、ファイルが追加された、表の行が更新された、というところです。
これがいちばん強い型で、人が起動しないので担当者が休んでも止まりません。

最後は人が起動するもので、ボタンを押す、指示を出す形です。
ただ、動かすかどうかは人の意識に依存します。

「何かが起きたら動くものを増やすことが目的」だと伝えます。
人の意識に依存しない領域を広げることが、この段階の狙いになるからです。

あわせて、実際にできる例を3つ挙げておきます。
ここは一般論ではなく、自社で実際に動いている実例がいちばん伝わります。
「問い合わせのメールが届いたら台帳に記録して担当に通知する」「毎朝、前日の数字を集計してチャットに流す」「フォームの回答に応じたお礼のメールの下書きを作る」といったところです。

フェーズ1と2：推進チームが作り、部門の作り手を見つける

導入は段階を踏み、最初は推進チームが自分たちで3〜5本作って動かすところから始めます。

選ぶ業務の条件は3つで、時刻で動く単純なもの、失敗しても影響が小さいもの、推進チーム自身が使うものです。
このなかでいちばんの要点は、推進チーム自身が使うものである点です。
自分が使うものを作ると精度の確認ができますし、改善の動機も生まれるからです。

最初に作るものとしては、定例のレポートの集計、AI関連のニュースの収集と配信、稼働している自動化の一覧の更新あたりが向きます。
この段階の目的は、作り方を体得する点と実例を作る点の2つです。

「こういうものが作れます」と見せられる実例が3つあると、次のフェーズが進みます。
この段階にかける期間の目安は、1〜2か月だと思います。

見せられる実例ができたら、次は部門に広げていきます。
やることは、部門ごとに作り手を1人見つけて支援する点です。
選ぶ基準は面白がって触るかどうかで、役職やITスキルより勝手に試している人のほうが伸びるからです。

また、支援の内容は3つあります。
設定でつまずく項目の手順書です。
表と連携するときの設定項目の意味を、具体例つきで説明します。
ここがいちばん詰まる箇所です。

練習用の環境も要り、ダミーのデータで自由に試せる場所にして「壊しても構いません」と明示しておきます。
相談の窓口は、詰まったときに聞ける先を1本に絞ります。

「作る自由と、一覧への登録をセットで渡します」。
つまり、何をする仕組みか、起点、保守担当、最終確認日の4項目を登録してもらう形です。
期間の目安は2〜3か月で、部門ごとに1〜2本作れれば十分です。

設定で詰まる箇所そのものは自動化フローの設定でつまずく3項目。現場が自分で作れる状態にするにまとめてあります。

フェーズ3：作ったフローを共有して棚卸しする

作られたフローの数が増えてきたら、今度は管理の設計に入ります。
やることは5つあります。

1つは一覧を維持することで、何がどこで動いているかを1箇所で把握できるようにします。
この一覧がないと、止まっていても誰も気づけません。
2つ目は四半期に一度の棚卸しで、使われていないものは止め、最終確認日が古いものを確認します。

重複の統合も要り、同じ用途のフローが複数の部門で作られていることがあるので利用回数の多いほうを標準にします。
止まったときに気づける設計も要り、実行の記録を残しておけば記録が途切れたときに止まっていると分かります。

また、良い事例の共有も忘れません。
「〇〇部門でこういうものが動いています」と流すと、他の部門が真似し始めます。

この5つのうち、管理としていちばん重要なのは止まったときに気づける設計だと思います。
動いているかどうかを誰も把握していないフローがいちばん危険で、そういうフローに限って静かに止まるからです。

共有そのものに制約がある場合の扱いは自動化フローが共有できない制約とどう付き合うかで扱っています。

作らせすぎない基準は3つ、配布物はA4で1枚にする

現場が作れるようになると、必要のないものまで作りすぎるという逆の問題が出てきます。

だから作る前の基準を、3つ決めておきます。
1つは頻度で、月1回しか発生しない業務は人がやったほうが安いです。
作る工数と保守の手間が、削減できる時間を上回るからです。

もう1つは例外の割合で、例外処理が3割を超える業務は自動化しても人の確認が毎回入ります。
先に例外のルールを言語化して減らすほうが、順序としては先だと思います。
最後は保守できるかで、「作った本人が異動したら誰が直すのか」に答えられるかどうかで判断します。

「自動化できるか」ではなく「自動化する価値があるか」で判断します。
この言い方を、そのまま配布物に入れておきます。

さらに「作ったものを捨てられる」状態も作っておきます。
3か月使って効果が出なければ止める運用にして、捨てる判断の軽さが健全に回っているサインだと思います。

ここまでの基準は、そのまま1枚の配布物にまとめておきます。
書くのは4つで、作るかどうかの3問、起点の3分類、一覧への登録の4項目、相談の窓口と詰まったときの手順です。

作るかどうかの3問は、頻度は週1回以上か、例外は3割以下か、保守できるかです。
起点の3分類は時刻、イベント、人が起動で、イベント起動を狙うと書いておきます。
必ずA4で1枚に収め、2枚になった時点で参照されなくなるのを避けます。

あわせて「依頼する側の人にも配ってください」とも伝えます。
依頼する側が基準を知っていると、「これは仕組みにする価値がない」という判断が現場でできるようになるので、依頼の総量が減ります。

費用の設計はAI利用の従量課金をコスト設計する。予算とガードレールの決め方にまとめてあります。

メール起点の台帳化はメール情報を台帳化する。転記作業を組織から消すにまとめてあります。

つまずきやすいのは6つです。
すべての自動化を現場に作らせようとする、推進チームが作る段階を飛ばす、練習用の環境を用意しない、一覧への登録を条件にしない、止まったと気づける設計を入れない、「自動化できるか」で判断する。
どれも、単純な処理と複雑な処理で範囲を分けて、実例を3つ作ってから広げて、壊せる環境を渡して、登録とセットにして、実行の記録を残して、「価値があるか」で判断すれば起きません。

初期の型づくりを外部と一緒に進める

ここまで書いてきたとおり導入は3フェーズで進み、そのなかで最も難しいのはフェーズ1です。

難しい理由は2つあります。
1つは、そもそも何を作るかという選定の問題です。

単純で、失敗しても影響が小さく、推進チーム自身が使うという3条件を満たす業務を選ぶには、複数の事例を見た経験が必要になります。
選定を誤ると、最初の実例が「作ったが使われていない」ものになってしまいます。

もう1つは、判断基準そのものを先に作れない問題です。
頻度・例外・保守の基準は、実際に作って運用した経験から出てくるもので、作る前に基準を作ろうとすると、どうしても一般論になります。
フェーズ1が弱いとフェーズ2が進まないのは、見せられる実例がないと部門の作り手が動く動機がないからです。

私たちが提供しているAI導入支援では、この初期の型づくりから、部門への展開と判断基準の整備までを一緒に進めています。
「何から作るかで止まっている」状態なら、進め方の参考になるかもしれません。

単純な処理は現場が作り、複雑な処理は書ける人に任せる

自動化は情シスの仕事という前提は外せますが、すべてを現場が作れるわけではありません。

単純な処理は現場、複雑な処理は書ける人で、単純な処理が業務の8割を占めます。
現場への説明は、「時刻」「何かが起きたら」「人が起動」という3つの起点に分けて行います。
「何かが起きたら」を増やしていくことが目的だと伝えます。

進め方は3フェーズです。
推進チームが3〜5本作り（単純・影響が小さい・自分が使うもの、期間は1〜2か月）、部門の作り手を1人見つけて支援し（手順書・練習用の環境・相談の窓口、期間は2〜3か月）、一覧の維持と棚卸しに進みます。
管理でいちばん重要になるのは止まったと気づける設計のほうで、走った記録を必ず残しておきます。

作らせすぎを防ぐ基準は3つで、頻度（週1回以上）、例外（3割以下）、保守できるかです。
「自動化できるか」ではなく「自動化する価値があるか」で判断します。
判断基準はA4で1枚にまとめておいて依頼する側の人にも配ると、基準が共有されて依頼の総量そのものが減っていきます。

まずは推進チーム自身が使う業務を1つ選び、時刻で動く単純な仕組みをつくってみましょう。