自動化フローが共有できない制約とどう付き合うか

Workspace Studioのような自動化のフローを作り始めると、しばらくして「作ったフローを他の人に渡せない」という共有まわりの制約に当たります。

作った本人のアカウントに紐づいた状態で動いているので、他の人が使うには同じものを作り直す必要があります。
共有できても、参照している資料や表の権限が絡んで、そのままでは動かない場合もあります。
これは仕様の問題なので、こちらで解決できるものではなく、制約を前提に展開を設計するしかありません。

今回はこの付き合い方について整理していきます。
何で作るかの判断基準そのものは業務自動化はどのツールで作る？Gem・GAS・Canvasの判断基準にまとめてあります。

個人で作ったフローは、全社の仕組みにならない

まず何が問題になるのか、起きていることから整理していきます。

いちばん分かりやすいのが、担当が異動すると止まる問題で、個人のアカウントに紐づいていると停止された時点で動かなくなります。
厄介なのは、止まったことに周りがなかなか気づかない点です。

同じものを複数人が作ってしまう問題もあり、渡せないので必要な人がそれぞれ作ることになって、「同じ通知の仕組みが部門に3つ並ぶ」といった状態になっていきます。
修正が本人しかできない問題もあって、中身を見られないので他の人が直せません。
動いているかどうかを推進チームが把握できないのも問題で、個人が作ったものは管理の外にあるからです。
このなかで危険なのは、異動で止まる問題と把握できない問題が組み合わさる場合です。

誰も把握していないフローが担当の異動で静かに止まり、数週間後に「あの通知が来ていない」と気づく展開になりがちです。
引き継ぎの様式は担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計で扱っています。

制約の性質を見分けると、回避の選択肢が決まる

制約にはいくつか種類があるので、まず区別しておくと対処のほうも決まります。

ひとつが、共有そのものができない場合で、フローを他の人に渡す機能がない、または限定されている状態のため、作り直すか別の手段を使うしかありません。
次が、共有できても参照先の権限で動かない場合で、フロー自体は渡せても表や資料の権限が受け取った人になければ動きません。
これは権限を整えれば解決します。

さらに、共有できても実行が本人の権限で行われる場合もあり、フローを渡した相手が実行するとその人の権限で動くので、同じフローが人によって違う結果を出すことがあります。
参照先の権限は解決できるので、まずここを確認するのが順序になります。
「共有できないと思っていたものが、実は権限の問題だった」というケースもあります。

そのうえで、制約を回避する手が4つあります。
ひとつが共有アカウントで作る手で、部門用のアカウントを1つ用意してそこでフローを作れば、個人の異動に影響されません。
全社または部門で使うフローなら、これが最も確実です。
ただし、アカウントの管理は別に要ります。

次が別の手段で作り直す手で、スクリプトで書けば共有と権限の設計が自由になるので、重要な業務で書ける人がいる場合に選びます。
3つ目が設定手順を文書化して各自が作る形で、フローは共有せず作り方のほうを配ります。
個人の業務で、それぞれが少し違う形で使う場合に向きます。
設定でつまずく箇所は自動化フローの設定でつまずく3項目。現場が自分で作れる状態にするにまとめてあります。

最後が諦めて手動で回す選択で、頻度が低く月1回程度で自動化の効果が小さいものなら、これも正しい判断です。
このなかで最も汎用的な解は、共有アカウントだと思っています。
部門用のアカウントを1つ用意する運用を先に決めておくと、後から作り直す手間がなくなります。

共有アカウントは、管理をセットで設計する

共有アカウントを選ぶ場合は、決めておくことがいくつかあります。
まず誰がアクセスできるかで、そのアカウントに入れる人は限定しておかないと、誤って設定を変える事故が起きます。

次にパスワードと認証をどう管理するかで、個人が知っている状態だと退職時に変更が必要になるので、情シスの管理下に置くのが基本です。
また、何を作るか何を作らないかも決めておき、部門共通で使うものだけを置いて、個人の業務のフローは混ぜません。
数が増えると、管理そのものができなくなるからです。
最後に一覧を作り、何をする仕組みか・起点・保守担当・最終確認日の4項目を並べます。

アカウントを1つ用意するだけでは足りません。
管理の設計をセットでやらないと、そのアカウントを知っている人だけが分かる、別の属人化が生まれます。

制約への対処と並行して、いま個人が作っているフローの把握も要ります。
やることは1つで、「自動化のフローを作っている人は、一覧に登録してください」と依頼するだけです。
登録する項目は4つで、何をする仕組みか・自分のアカウントで動いているか・止まったら業務に影響があるか・作り方を文書に残しているかです。

このなかで重要なのは業務への影響で、止まったら影響があるものは共有アカウントに移す優先度が高くなります。
影響がないものは、そのままで構いません。

あわせて、「作ったのを咎めない」と明言しておきます。
「勝手に作った」という扱いにすると登録されないので、「便利なので把握しておきたい」という伝え方にします。

展開は、制約を前提に線を引いておく

制約があることを前提に、展開のほうも設計しておきます。
まず個人の業務は個人が作る前提にし、共有できない制約がある以上、そもそも共有は目指しません。
作り方の手順書を配って、各自が作れる状態にするほうが現実的です。

部門・全社で使うものは最初から共有アカウントで作り、後から移すのは手間なため、着手の時点で判断しておきます。
判断の線も明示しておき、「2人以上が使うものは共有アカウントで作ってください」という1行を配布物に入れておきます。

重要な業務は共有できる手段で作り、止まったら業務に影響があるものは、スクリプトなど共有と権限の設計が自由な手段を選びます。
手段の判断基準に、「共有できるか」を1項目足しておく形です。

共有できるかという観点を、業務の洗い出しや優先順位付けのどの段階で持ち込むかは、業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順と照らし合わせると決めやすくなります。

制約は変わるものと考え、単純な構成で作っておく

最後に、この領域の特徴をもう1つ押さえておきます。
仕様そのものが変わるという特徴です。

もちろん、今できないことが半年後にできるようになる場合もあるので、制約に合わせて大きく作り込まないほうがいいと思います。
やっておくべきことは2つあり、ひとつが一覧を維持することで、何がどの手段で動いているかが分かっていれば、仕様が変わったときに移す判断ができます。
もうひとつが作り方を文書に残すことで、別の手段に移すときも何をする仕組みかが分かっていれば作り直せます。

逆にやらないほうがいいのが、制約を回避する複雑な構成を組むことです。
複数のアカウントを連携させたり中継の仕組みを作ったりすると、仕様が変わったときに作り直しになりますし、誰も理解できない仕組みが残ります。
つまり、単純な構成で作って制約は運用で吸収する、という判断がこの領域では合っていると思います。

つまずきやすいのは5つです。
共有できないことを確認せずに作り込む、権限の問題を共有の制約だと判断する、共有アカウントを用意するだけで管理を設計しない、属人フローの登録を「勝手に作った」扱いにする、制約を回避する複雑な構成を組む、です。
どれも、着手前に共有の可否を確認して権限をまず見て、一覧と管理をセットにして咎めない伝え方にし、単純な構成で作れば避けられます。

自動化フローの一覧づくりや作り方の記録は、私たちが提供しているAI伴走支援でも、AIワークフローの実装とあわせて現場の担当者と一緒に進めています。

共有アカウントと一覧化が、属人化を防ぐ本丸になる

自動化のフローが共有できない制約は仕様の問題なので、こちらでは解決できません。
制約を前提に展開を設計するしかないので、まず制約の種類を区別します。
共有そのものができないのか、参照先の権限で動かないのか、実行が本人の権限で行われるのか。
参照先の権限は整えれば解決するので、ここを先に確認します。

回避の選択肢は4つあり、共有アカウントで作る・別の手段で作り直す・設定手順を配って各自が作る・手動で回すという並びです。
全社・部門で使うなら、共有アカウントが最も確実です。

共有アカウントを選ぶ場合は、アクセスできる人・認証の管理・何を作るかを決めて一覧を作ります。
アカウントを用意するだけでは、別の属人化が生まれます。
展開の線は「2人以上が使うものは共有アカウントで作る」で、重要な業務は手段の判断基準に「共有できるか」を1項目足しておきます。

制約のほうは変わるので、大きく作り込まないでおきます。
一覧を維持して作り方を文書に残しておけば、仕様が変わったときに移せます。
自部門の個人フローを一覧にして、止まったときに影響が出るものから手を打ってください。