GASとは何かを推進担当が説明できるようにする。非エンジニアへの伝え方

自動化の提案をすると、「それはGASで作るんですか」と聞かれます。

技術的には正しく説明できても現場に伝わる言葉になっていないので、GASとは何かを聞かれた推進担当のほうが説明に詰まります。
「よく分からないもの」として扱われた時点で、その後の提案は通りにくくなります。
推進担当が説明できる価値は、自分が作れることとは別にあります。

今回は、この伝え方を整理します。
自動化の全体像はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

自動化の話は、技術用語で止まる

なぜ自動化の話は止まるのでしょうか？
理由は3つあります。
「スクリプト」「実行環境」「トリガー」といった専門用語が並ぶと、聞いた人は自分が判断する話ではないと解釈します。
何ができて何ができないかが伝わらないと、自分の業務に当てはめようがありません。

「情シスに頼むのか、自分でできるのか」が不明なままだと、要望を出す先そのものが分からなくなります。
この3番目が、いちばん要望を止めます。
「これもできますか」という声が、そもそも出てこなくなるからです。

一言でいうと、技術用語で話すほど要望は遠のきます。
用語を現場の言葉に置き換える話はRAG・エージェント・ワークフローを現場の言葉に翻訳するにまとめてあります。

GASは、この2文で説明がつく

長い説明は要らないので、まず一言の説明を決めて、推進担当が同じ説明を繰り返し使えるようにします。
「Googleのサービスを操作する、簡単なプログラムを書ける仕組みです」。
この一言に、すぐ具体例を添えます。
「例えば、毎朝スプレッドシートのデータを集計してメールで送る、フォームの回答を別の表に転記する、といったことができます」。

これ以上詳しく話しても覚えてもらえないので、この2文で十分です。
また、費用の心配が最初に来る場面が多いので、「無料で使える」を先に付け足しておきます。

逆に良くないのは、「JavaScriptベースのサーバーレス実行環境」といった説明です。
技術的には正確でも、この言い方をした瞬間に、現場は判断する立場から降りてしまいます。

できることとできないことは、先に線を引く

そもそも、GASはどこまでが得意なのでしょうか？
範囲を明示するのが、いちばん効きます。

使える場面は5つあります。
表計算のデータを処理する用途がいちばん多く、集計や転記、突合、形式の変換までを含みます。
定時に何かを実行する用途で、毎朝や毎週、毎月の処理がここに入ります。

メールやカレンダーを操作する用途で、送信や取得、登録までをまとめて扱えます。
ファイルを操作する用途で、コピーや移動、一覧の作成までをこなせます。
外部のサービスと連携する用途で、他のツールから情報を取ったり通知を送ったりできます。

使えない場面は3つです。
実行時間に上限があるので、大量のデータを高速には処理できません。
数万行を一度に処理する用途では詰まります。

とはいえ簡単なものは作れるので、画面のあるアプリを本格的な業務システムとして作るのは向きません。
数秒ごとに動く用途には使えないので、リアルタイムの処理にも向きません。
「書ける人が限られる」という制約も、必ず併せて伝えます。

技術的な制約より、この人の制約のほうが実務では大きく効きます。
手段そのものの選び方は業務自動化はどのツールで作る？Gem・GAS・Canvasの判断基準で扱っています。

誰が作るかを名前で示すと、要望は止まらなくなる

誰に聞けばいいのかが曖昧なままだと、要望はそもそも出てきません。
伝えるのは3つです。
名前を出して「〇〇さんに相談してください」と言い切ります。
「情シスに」では、誰も相談しません。

「やりたいことを1〜2行で書いて、この窓口に投げてください」という形にして、技術的な要件は不要だと明示します。
「3営業日以内に、できるかどうかを返します」と、返す期限も決めておきます。

「これはできますか」という質問は歓迎すると伝えます。
もちろん判断するのは受ける側の仕事で、聞く側が背負う必要はありません。

現場向けの勉強会も、この線で設計します。
目的は「作れる姿」ではなく「要望を出せる姿」です。

最初の5分は、一言の説明と具体例です。
上の2文に、自社の実例を3つ添えます。

次の10分は、使える場面と使えない場面です。
「これができる」より「これはできない」を丁寧に伝えると、期待外れを防げます。
自社で既に動いている自動化を1つ見せるほうが、説明を重ねるより理解が速いので、次の10分は実際に動いているものを見せる時間にします。

最後の5分は相談の経路です。
誰に、どんな形で、どのくらいで返ってくるかを伝えます。
そのうえで、「自分の業務で自動化できそうなこと」をその場で1つ書いてもらいます。
この5分で出てきたものが、そのまま次の施策の候補になります。

要望を出し続けてもらうには、共有がいちばん効く

勉強会のあと、要望はどうすれば途切れないのでしょうか？
対処は4つです。
複数の窓口があると迷って結局出さなくなるので、相談の窓口はチャットのチャンネル1本にまとめます。
「実行時間の上限があるので、この処理は別の手段が必要です」というように、できなかった場合も理由を返します。

理由が返ると、次の要望の精度が上がります。
「〇〇部門の依頼で、こういうものを作りました」と流すと、他の部門が「それ欲しい」と言い出します。
対処4つのうち、この共有がいちばん効きます。

「メールを転記するだけ」のような小さい要望も断りません。
小さい成功が、要望の数を増やしていきます。

線引きも明示しておきます。
全社員がGASを書けるようになる必要はありませんし、目指すべきでもありません。
目指すのは2つです。

何ができるかを知っていて相談の経路を知っている状態が、全社員に必要な要望を出せる姿です。
もうひとつが、部門に1人書ける人がいる状態です。
その1人が周りの要望を聞いて作れば、10人に厚く伝えるほうが100人に薄く教えるより速く回ります。

書ける人を選ぶ基準は、面白がって触るかどうかです。
役職やITスキルより、勝手に試している人のほうが伸びます。
推進担当自身も、書けなくても推進はできますが、書ける人と会話できる水準は必要です。

必要な水準は3つです。
何ができて何ができないかを判断できる、実現の難易度をおおよそ見積もれる、保守の負荷を判断できる、の3つです。
この水準は、実際に簡単なものを1つ作ってみれば身につきます。
数時間あれば足ります。

「書ける」より「判断できる」ほうが重要です。
書ける人は社内にいるか外部に頼めますが、判断できる人がいないと手段の選択そのものを誤ります。

内製化の全体像は社内AIツールの内製化。現場が自分で作れる組織にするまで、ツール連携の考え方はAPIを「窓口」として理解する。ツール連携の判断ができる組織になるにまとめてあります。

失敗になりやすいのは6つです。
技術用語で説明する、できる面だけを伝える、相談先を「情シスに」と言う、技術的な要件を書かせる、小さい要望を断る、全社員に書けるようになってもらおうとする、の6つです。
2文の説明に切り替え、できない面も丁寧に伝え、名前を出し、やりたいことを1〜2行で受け、小さい要望から受け、部門に1人で足りると割り切れば、どれも避けられます。

教科書は、手段の全体像を地図として示す

ここまで書いてきたのは、現場に伝えるための最小限です。
推進を担当する立場では、どこまで体系的に押さえておけばいいのでしょうか？
組織の体制、保守できる人がいるか、費用の構造、業務の重要度まで含めた判断の枠組みが必要なので、手段の判断は技術の知識だけでは決まりません。

弊社代表が書いた『組織で成果を出す「AI推進」の教科書』では、手段の整理から推進体制の作り方、現場への浸透の順序までを一冊にまとめています。
断片的な情報を集めている段階なら、地図として使いやすいかもしれません。

部門で作ったGASのWebアプリは、私たちの組織のAIポータル「AI Portalize」に登録すると全社に公開され、使われた回数が作った人に返ってきます。

GASは、伝え方ひとつで要望の量が変わる

自動化の話が止まる原因は、専門用語で説明される、できる範囲が伝わらない、誰が作るのかが分からないの3つです。
3つのうち、誰が作るのかが分からない状態が、いちばん要望を止めます。
一言の説明は「Googleのサービスを操作する、簡単なプログラムを書ける仕組み」に、具体例を2つと「無料で使える」を添えた形で、2文で足ります。

使える場面と使えない場面は明示します。
「書ける人が限られる」という制約が、実務ではいちばん大きく効きます。

誰が作るのかは、名前を出す、やりたいことを1〜2行で受ける、3営業日以内に返すの3点で伝えます。
「情シスに」では、相談されません。
勉強会は30分で、目的は「作れる姿」ではなく「要望を出せる姿」です。

動いているものを見せて、最後に自分の業務から1つ挙げてもらいます。
窓口を1本にし、できなかった理由を返し、作ったものを共有し、小さい要望を断らなければ、要望が出続ける状態は作れます。
もっとも効くのは、作ったものを共有する点です。

全社員が書けるようになる必要はありません。
目指すのは、要望を出せる状態と、部門に1人書ける人がいる状態です。
自社で動いている自動化を1つ選び、それを2文で説明できれば、伝え方の土台はできています。