gas 開発 外注｜見積の内訳と、社内に残す範囲の線引き

「毎月の集計を自動化したいんですが、これって外注するといくらくらいなんでしょう」

スプレッドシートの運用を一緒に見ているとき、よく出てくる質問です。社内にGoogle Apps Script（GAS）を書ける人がいないので外に頼みたい、あるいはすでに見積をもらったけれど妥当なのか判断できない。どちらの相談も、聞きたいことは同じ形をしています—この作業は、いくらが普通なのか。

先にお伝えしておくと、この記事に金額の相場は載せません。GASの開発は、対象の業務がどこまで決まっているかで工数が何倍も変わるので、相場の数字を出すと自社の見積を読む役に立たないからです。代わりに、見積を何の積み上げとして読むかを分解します。

実際に起きているのは、こういうことです。「毎月の集計を自動化したい」という一文だけで見積を頼むと、受ける側は例外がどれだけあるかを読めません。読めないので、リスクを見て多めに積むか、安く受けて着手後に膨らませるかのどちらかになります。前者は高すぎる見積として見送られ、後者は「追加でこれもかかります」という会話に化けます。どちらも、依頼文が薄いことから始まっています。

そこでこの記事では、二つのことを扱います。ひとつは見積を読み解くための内訳の分解。もうひとつは外に出す範囲と、社内に残しておくべき範囲の線引きです。外注そのものをするべきかどうかの判断は外注か内製かの判断基準で扱っているので、ここでは「外に出すと決めたあと」に絞ります。

同じ「シートを自動化してほしい」で、見積が何倍も変わる理由

GASの開発は、書く作業の量そのものが読みにくい仕事です。理由は、スプレッドシートが人の運用と一体になっているからです。プログラムを書く相手が向き合うのは、きれいに整ったデータではなく、現場が数年かけて育ててきたシートです。列が増築され、備考欄に大事な情報が入り、特定の取引先だけ別のルールで書かれている。この「育ち方」は外から見えません。

だから、同じ依頼文でも、渡す情報の量で見積が変わります。シートの実物と例外の一覧が添えられている依頼と、やりたいことを一文だけ書いた依頼では、受ける側が想定しなければならない幅がまったく違います。見積の幅は、業務の複雑さではなく、業務の不明さで決まるという言い方のほうが実態に近いと思います。

この構造を踏まえると、依頼側がやるべきことは「安いところを探す」ではなく「見積を読める状態を作る」になります。次の節から、その読み方を分解していきます。

見積を読むための5つの内訳

GASの開発を発注するとき、見積の総額を一つの塊として見ると比較できません。次の5つの内訳に分けて、それぞれが入っているかを見ます。金額の妥当性ではなく、抜けている内訳がないかを見るための表です。

経験上、安い見積は、たいてい1番目と4番目と5番目が入っていません。整える作業は依頼側の宿題として置かれ、引き継ぎ資料は「必要なら別途」になり、保守は書かれていない。書く作業と動作確認だけを比べれば、当然その見積がいちばん安く見えます。

ここで大事なのは、抜けている内訳が悪いということではありません。抜けている内訳は消えるのではなく、自社側に移っているという点です。整える作業を自社でやると決めたなら、その見積は妥当です。決めていないなら、その作業は着手後に誰かが困る形で現れます。見積を並べるときは、金額の隣に「この内訳を自社で持つのか」という列を足して見てください。

工数を膨らませているのは、たいてい例外の数

では、何が作業量を読めなくしているのか。処理の難しさが原因になることは、実はあまりありません。集計して転記して通知する、という骨組みそのものは素直です。読めなくなるのは、ほぼ業務側の事情です。

• 列の意味が揃っていない：同じ列に違う種類の値が入っている。単位が混ざっている。日付なのか文字なのかが行によって違う
• 例外が業務側で把握されていない：「この取引先だけ締め日が違う」「この案件だけ二重に計上する」が、着手後に会話の中から出てくる
• 「1件」の定義が決まっていない：1行を1件と数えるのか、同じ番号の行をまとめて1件と数えるのか。数え方が決まっていないと、集計結果が正しいかどうかを誰も判定できない
• 人がシートを並べ替えたり行を挿入したりする運用がある：位置を前提に組むと、翌月に人が並べ替えた瞬間に結果が変わる

この四つは、外注先には解けません。業務を回している人しか答えを持っていないからです。だから、依頼する前に社内でやっておくと見積が読めるようになります。やることは三つで足ります。ひとつ、対象のシートの列を1行ずつ「この列に何が入るか」を書く。ふたつ、例外を列挙する。みっつ、「こうなったら成功」を1文で書く。

二つめの例外の列挙で、いくつも出てくる場合は少し立ち止まってください。例外がいくつも並ぶなら、自動化の前に例外そのものを減らす検討をしたほうが早いことがあります。例外を残したまま自動化すると、例外の数だけ分岐が増え、そのぶん止まる箇所と直す箇所が増えます。整える作業そのものの進め方は業務棚卸しのやり方で整理しています。

三つめの「こうなったら成功」は、短くて構いません。「月初の朝に、前月分の集計が1枚のシートにできていて、担当者が手で触らずに見られる状態」くらいの粒度で十分です。これを書いておくと、見積を受け取ったときに「その金額でこの状態になるのか」を一つの基準で確かめられます。

アカウントと権限をどう渡すか

ここがGAS固有の、いちばん見落とされる論点です。GASはGoogleアカウントの権限で動きます。つまり「誰のアカウントで動いているか」が、そのまま運用のリスクになります。汎用の外注の話には出てこない論点なので、契約の前に決めておくものを並べます。

• 誰のアカウントで動くか：作った人のアカウントで動く形にすると、その人が抜けたときに止まります。外注先の担当者のアカウントで動いていれば、契約終了と同時に動かなくなることもあります。業務で使うなら、会社のアカウントで動く形にしておきます
• スクリプトの所有者：ファイルの所有者が外注先のアカウントのままだと、契約が終わったあとに中身を見ることも直すこともできません。納品時に会社側の所有へ移すことを、条件として書いておきます
• 渡す範囲：作業に必要なシートとフォルダに限ります。会社全体が見えるアカウントを渡さない。人事や取引の情報が入った領域まで含まれていないかを、渡す前に確かめます
• 本番と練習を分ける：実データのコピーで作り、本番へ移すときに接続先を切り替えます。作りながら本番のシートを触る形にすると、試した操作がそのまま業務の記録を壊します

そのうえで、ひとつだけ強くお伝えしておきたいことがあります。ログイン用のパスワードや二段階認証のコードを外注先に渡す形にしないでください。共有はファイル単位・フォルダ単位の共有設定で行います。そして、個人情報や取引情報が入っているシートは、渡す前に対象の範囲を絞るか、値を置き換えたコピーを渡します。名前や連絡先を別の文字列に置き換えたコピーでも、処理を組むことはできます。

なお、共有設定で実際にどこまで見えるかは、組織の管理者の設定や利用しているプランによって変わります。ここでは断定せず、自社の管理者と一緒に、渡す前に実際の見え方を確認することをおすすめします。「共有したつもりの範囲」と「相手に見えている範囲」がずれていた、というのは十分に起こりうることです。

引き継げる形で受け取る条件

動くものを受け取っただけでは、運用は始まりません。契約前に、納品物として次のものを書いておきます。あとから「これも欲しい」と言うと追加の作業になりますが、最初から範囲に入っていれば見積の一部として組まれます。

• どのシートのどの列を読み、どこに書くかを言葉で書いたもの（コードのコメントではなく、業務の人が読める文章で）
• 動かす条件：何時に動くのか、誰が押すと動くのか、どのシートの更新をきっかけに動くのか
• 止まったときに最初に見る場所：どこを開けば、動いたのか動いていないのかが分かるのか
• 変更したい典型パターンと、その変更をどこで直すか：通知の宛先、判定の閾値、対象の期間といった、運用しながら必ず変わる項目
• 引き渡し後に、社内の誰か一人が実際に一度動かして、上の典型パターンを自分の手で直してみる場

最後の項目が、いちばん抜けます。そして抜けると、書類だけあって誰も触れない状態になります。資料は納品されているので、契約上は何も欠けていません。ただ、社内の誰も一度も触っていないので、実際に変更が必要になった日に開いて読み解くところから始まります。読み解けないので外に頼み、頼めない時期だと止まったままになります。

この形は、外注に限った話ではありません。社内の一人が作った仕組みでも同じことが起きます。構造としては同じなので、作った人しか直せないツールのリスクと属人化を解消する3ステップで整理した考え方がそのまま使えます。受け取り方を設計しておくことは、属人化の予防そのものだと考えています。

外に出す範囲と、社内に残す範囲の線引き

ここがもう一つの核です。全部を外に出すと、止まった日に何もできません。逆に全部を社内でやろうとすると、そもそも始まりません。その両方を避ける線を、範囲ごとに引いておきます。

並べてみると、線は技術の難易度では引かれていません。判断が入るものは社内、手順が決まっているものは外という形になります。何を異常とみなすか、どの列に何を入れるかは、業務の意思決定です。これを外注先に決めてもらうと、決めた根拠が社外にしか残りません。あとで基準を変えたいときに、なぜその基準にしたのかを誰も説明できなくなります。

一次確認を社内に残す、というのも実務的な理由です。「動いていません」だけを伝えても、相手は何から調べればいいか分かりません。実行の記録がどこに出るか、いつまでは動いていたか、この二つを社内の誰かが見られるだけで、直すまでの時間はかなり短くなります。ここは技術の話ではなく、連絡できる状態を持っているかどうかの話です。

そもそもGASで作るべきか（依頼する前の1問）

最後に、見積を取る前に一度だけ確かめてほしいことがあります。その業務は、手順が決まっていて、入力の形が揃っていて、判断が要らない状態になっているか。この三つが揃っていないと、GASを外注しても止まります。書き手の腕とは関係なく、業務側の前提が動いているものは、動くものとして固定できないからです。

揃っていない場合は、順番を入れ替えます。先に業務側を整え、そのうえで自動化する範囲を切り出す。遠回りに見えますが、整えないまま発注すると、整える作業が見積のいちばん読めない部分として金額に乗るか、着手後の追加として現れます。どちらにしても、結局は整える作業をやることになります。任せられる範囲の見立てはGASでできることで、業務そのものを仕組みに載せる判断はExcel業務のシステム化の判断で整理しています。

もうひとつ、逆方向の選択肢もあります。扱う量や求める要件が、そもそもスプレッドシートの想定を超えている場合です。行が積み上がり続ける、同時に何人も書き込む、履歴を厳密に残す必要がある—こうした条件が並ぶなら、GASを外注して支えるより、その要件だけを別の道具に出すほうが素直なことがあります。道具の選び方はSaaSとスプレッドシート＋自動化の選び方にまとめました。全部を移す必要はなく、超えている要件だけを切り出す形で構いません。

まとめ

GAS開発の見積は、総額ではなく5つの内訳で読みます。整える、作る、確かめる、引き継ぐ、止まったとき。安い見積で抜けているのは、たいてい整える・引き継ぐ・止まったときの三つで、その作業は消えたのではなく自社側に移っています。移すと決めているなら妥当な見積、決めていないなら着手後に現れる作業です。

作業量を膨らませているのは、処理の難しさより業務側の例外の数です。だから依頼の前に、列の意味を1行ずつ書き、例外を列挙し、「こうなったら成功」を1文で書く。この三点があるだけで、受け取った見積を自社の条件と照らして読めるようになります。

アカウントは会社のもので動かし、スクリプトの所有は納品時に会社側へ移す。ログイン用のパスワードや二段階認証のコードは渡さず、共有設定で必要な範囲だけを見せる。個人情報や取引情報が入るシートは、範囲を絞るか値を置き換えたコピーを渡します。

そして線引きです。何を異常とみなすか、列の意味をどう決めるかという判断は社内に残し、書く・確かめるは外に出す。止まったときに最初に見る場所だけは、社内に一つ持っておく。私たちが道具の導入より前に業務プロセスの構造化に時間をかけるのは、判断を外に預けたまま仕組みを乗せると、止まった日に誰も動けない構造ができてしまうからです。まずは、自社のシートの列を1行ずつ書き出してみるところからで十分だと思います。