GAS + Google Sheets で見積書や請求書を発行するシステムを制作します。

Written by .digital 日付: 1月 14, 2022 , Posted in Tips.

読者のみなさん，請求書は紙面で送付・受け取りしていますか ? 面倒ですよね！請求書の様式も事業者や金融機関ごとに異なっています．データで貰いたいですよね !

さて標題の通り，この記事では見積書や請求書を発行するシステムを Google Apps Script と Google Sheet で表現してみます．そもそも，見積書や請求書はどのような為にあるでしょう．現状のデジタルトランスフォーメーションの取り組みは，人の手がいっぱい介在することでようやっと成立する（賢い人間による）システムをそのままコンピュータにさせようとすることが多いように見受けます．これをすると，新たなデジタルシステムが完成しても属人的な業務を排除することができず，正確性や（嫌な）業務の圧縮につながっていないのです．

どのように DX の取り組みをすればいいかは，巷の WEB メディアで識者が注意喚起している方法を参照することも良いですが，更に気になる方は .digital なりの考えや仮説検証をお伝えしますので RFP フォームに具体的な問題点を添えて記入してください．この作業は無償ですし，読者の手間も煩わせないのでおすすめします．

本編は 1 回モノです．大変長くなりますので，読者はこれを再現しようと思うのであれば予め 1 週間の仮説検証（自身や自社がこのシステムで課題を解消できるか） 1 週間のプログラミング作業の期間を見込んでください．

• Spreadsheet ( Google Sheets ) だけで個人事業主の確定申告を完結しよう !
• Spreadsheet ( Google Sheets ) のデータ上限と回避する運用

多くの読者にどうやって制作プロセスが進むのかという質問を受けるので本編は制作実務に則した手順にして書きます．

目次

1. ヒアリング（実務のドキュメント化と予算の検証）
1. いきさつ
2. 実務 A（受注まで / 営業部）
3. 実務 B（施工債務 / 技術部）
4. 実務 C（施工後債権回収まで / 管理部）
2. アプリケーション開発の準委任契約（又は社内予算の確保）
3. 理想像を描いて，周辺環境や契約金額を顧み，実現可能なレベルまで落とす作業
4. 開発
1. 環境の整備
2. 見積データを型作り
1. 準備
2. データ項目の抜粋
3. データに名前をつける
4. データベースをつくってプロパティを固定する
3. 見積のプログラミング
1. 見積業務フローを論理的にスクリプトへ
2. startQuote() を検討
3. 
   

ヒアリング（実務のドキュメント化と予算の検証）

いきさつ

そもそも，本稿を書くに至ったきっかけは東海の設備工事事業者，いわゆるサブコンのクライアントから .digital が直接次のような依頼を受けたことです．

依頼

1. 施工取引プロセス全体の人為的なエラーを減らしたり，情報共有をするシステムを設計して，デジタル化してほしい．特にコンピュータを使ってする業務のクオリティが低い問題を解決してほしい．
2. 顧客からまともな事業者に見えるように通信分野の問題を指摘し，改善してほしい．

建設業はすべての業界の中で最もテレワークが上手な業種です ! 顧客を特定し得る情報や接触の経緯を明かすことはできませんが，概ね資本が 500 万円，法人 7 期目で初年度から営業損益はいつも僅かに黒，スタッフの拡充に取り組み続け，現状 15 人，年商 6 億円，年商の増加は前年比 +1.2 ~ + 1.5 くらいで，前年度より個人経営のコンサルタント（兼 .digital の代理店）が入り，成長計画を立てていく中で次のような事業環境を，そのコンサルタントは危険と指摘しました．

関係図

*緑色の部分は本件が関係しようとする取引過程

危険性を孕む問題点

1. サブコン A 社の顧客（施工先ではなく取引先）は取引高 20% が商業施設や運輸機材を扱う大企業数社で，80% 程は設備保守管理を請負う専門企業 B（これも大きいか大きい企業の子会社）からの下請．B を仲介させる顧客のメリットは，同時進行する複数の現場の設備保守や店舗設備開発の管理や入出金の管理を委託できること．所謂顧客の非専門（メインオペレーション以外の）業務を別会社が行うことで顧客は本業に集中して商取引の危険を回避する利点があること．しかし仲介 B が介在することで顧客に対して不必要に高い金額で施工見積が渡ることがあって，失注することがある．
2. A と顧客の間の取引プロセスは次の通り．これに 1. を解決したとすると B を仲介させるメリットは無い．（本来 B が行うべき業務を A が無償でしている．）
1. A が顧客の各店舗や施設の主任者レベルから各種設備の修繕工事の依頼を受けて見積に向かう．
2. 概算見積を（ B が A の見積に更に盛る金額を想定して）その場で顧客の主任者に伝達し，顧客は施設別の予算等から実施，不実施を検討して後日 A へ電話．
3. 実施のときは，A は顧客本社の担当部署に B へ実施の旨を伝達するように依頼して，その後 A は B に対して，概算見積からちょっと値引した見積を紙面送付して，PDF をメール．（値引は B の取り分，顧客は B の見積書しか見ない．）
4. 顧客が見積を是認したら B から手配連絡，A 自身で作業員や下請を手配し，顧客と B へ施工日時を電話で連絡．
5. A は施工を完了したら顧客に対する施工終了の報告書を顧客へ郵送し，B に対して顧客主任者のサインが入った終了通知をスキャンして PDF にしてメール．
6. A は（複数の）B に対して，毎月締日直後に 120 件弱程の工事ごとの請求書を作成する．複数の B に対して，それぞれの B 事業者ごとに請求書を 1 部複数ページの請求書（多いところで大体 60p ）PDF にまとめ上げ，各 B に対してメールと郵送をして債権を回収する．
3. B は各社 IT 導入を（悪い意味で）推進しようとしている．一方 A は IT にとても弱い．どれくらい弱いかというと，Microsoft Excel 2013 の PDF エクスポート機能が使えず，当然全社で使うメールも整備されていないので，eo 光の @hogehoge.eonet.ne.jp メールや，スタッフ個人の Gmail を混在して利用して顧客や B をたまに困らせることもある（もとより shadow IT と化している）．尚コンピュータは会社に 1 台，主に社長が見積書を作ったり，請求書を作ったり，施工報告書を作るために使う． B が推進しようとする IT 導入の内容は未だ詳しく分からないが，従来 FAX や電話で通報していた施工依頼や見積依頼を Excel フォーマットを各者に提供してメールしてもらう程度だと予測．B に A が IT に特段弱いのはバレているので，せめて切られないように，あわよくば B の面倒なシステムを導入されることで A の無駄な生産性の無い業務を増やしたくない．（ B の機能を A が請け負うことで，顧客と直接取引をする部分を増やし，B との取引を減らしたい．）

ここまでの情報をうけて，.digital とその経営コンサルタントと A 社はどのように業務を進めていくべきか，最も理想的な事業環境（外部）と内部組織（内部）を仮定してオペレーション設計を進めていくことになりました．

ここから，A 社の取引プロセスや組織の機能で分類しながら，オペレーションのドキュメントを作成していきます．（現実のドキュメントは， A 社の取引先や公開会社の一般が知り得ない情報を含んでいる為，ここからは .digital が締結した NDA に抵触しない程度にぼかしたり内容を変えたりしています．）

実務 A（受注まで / 営業部）

A 社では，施工の受注は営業部の仕事です．主に工事の現場経験者が壮年になって営業部に配属したり，若い初任者でも数年現場経験を積めば希望によって配属しています．

いきさつ に記したように，工事は平均 3 日がかりくらいのものが大小，120 件 / 月ほどありますが，それを 3 人のスタッフが顧客別に走り回っているのです．（ 大変だ ! ）

営業スタッフは顧客（施工先施設）の主任者とはそこそこ仲が良く，いつでも電話連絡できてコミュニケーションは抜群です．工事の経験もあることから，施設主任者から連絡が来た時は，到着から 1 時間程度で概算見積をして，本社技術部に調達する部材や工員の手配，価格の本見積をするように LINE の個別チャットで依頼しています．ここまでの流れを理想化すると，次の Google Docs の A の部分になりました．

https://docs.google.com/document/d/1iq85J8Cg_ODIPRAg5oueq4SOG0sBuredJGax2t7Embc/edit?usp=sharing

主要の考え方は，

• 誰でもできることは相手にやらせる．
• 知る必要があるなら自発的にアクセスして調べる．報告しない．
• 優先順位をよく見えるようにして，他人へのおせっかい（お手伝い）をできるようにする．

実務 B（施工債務 / 技術部）

A 社では，施工に関するほとんど全てを技術部が掌理し，複数の複雑な案件・数十社の下請けをまとめあげ，強いリーダーシップを発揮する集団です．主に高校卒業後や中途で紹介で入社し，青年スタッフが多い印象でした．

営業部と受注情報を電話や事務所，LINE などでやりとりし，必要な部材や工員，下請企業への発注，営業部へ施工日時と行程の連絡，必要に応じて施工計画書や図面を引いたりもします．

技術部は設備技術や土木技術の学習の向上心が強く，スタッフの皆さんは忙しい合間を縫って勉強したり，塗装素材や鋼材工場に見学に行ったりもしているそうです．（ 自費で ! ）彼らのフラストレーションは，そういった取り組みが企業のためになると社長に度々訴えかけていますが，届かないことだそうです．あとは現場の地理的範囲の広さに対して車両が足りない ! と仰っています．

私は A 社社長とお会いして，「会社の資本は人だ ! 」という純粋な方でしたがスタッフや下請の待遇は平均水準より良い分，設備投資に非常に消極的な（ よくわからないんだなぁ〜 的 ）印象でしたのでそのとおりの原状と見ました．

また現実的には部材の納入期日や調達，人員の手配など様々な「時間」の調整に苦慮されている印象です．調整前，後の情報共有の方法として，Google Calendar や TimeTree,  Trello, Notion 等が存在するという情報を仕入れて，試してみたらしい（素晴らしい ! ）のですが共有しきれていないとか，手段が目的化しているという感覚を得たらしく，断念したそうです．（正しい !! 正直ここまでセンスが良い企業はあまり見ないですね ! 駄目だと思ったらやらない方がいいですよ ! ）

理想の業務 （ Google Docs の B ）

実務 C（施工後債権回収まで / 管理部）

従来の管理部の業務には，

• 請求書やその他の一般事務書類の作成
• メールチェック
• 入金の照合，出金の審査
• 税理士と協調した経理業務
• 弁護士と協調した契約法務

があって人員 2 名に対して相当忙殺されている印象でしたが，新しいプロセスでは 請求書の作成 （ *債権の登録と認識 ）までは営業部の仕事として，もっと会社の財務部分にフォーカスした業務に移行していけることを理想しました．なぜなら，例えば A 社は 2 年前なら過去最高益を叩き出したのに対して，正直不要なまでの余剰金を発生する見込みがあったにも拘らず設備投資や余剰金の再分配について税理士との連携がうまくいかず，次年のパンデミックによる影響で減益したことにより所得税や消費税の負担が重くなることがあったそうです．

またせっかく僅かであっても長年にわたって黒字を維持し，複数の取引先と良好な取引基盤が構築できているにも関わらず，これまで一度も資金調達をしたことがないのだそうで，コンサルタント曰く特に設備資金の調達に関しては様々優遇措置もあるそうなのでそういった経営企画や専務部分の取り組みをすすめていけるようにしようという趣旨で理想のプロセスを描いています．

もう一点重要なのは，A 社では誰もが疎いコンピュータまわりの業務を専任するスタッフを雇用できるように機関化をすすめておくことです．コンピュータやモバイル端末を使いこなせない人は，どれだけトレーニングしても無駄ですし，IT ヘルプデスク化するのが最近の私達 .digital の主流です．

理想の業務 （ Google Docs の C ）

さて，ここまでヒアリングをすすめ，具体的に A 社がどうすればいいのか指針ができましたので，契約の提案をしていくことになります．非 IT 領域の企業読者にとってデジタルトランスフォーメーション全体の取引プロセスがどう進むか非常に気になると思いますので次の章から詳記していきます．おわかりの通り，IT にかかわる業務は，コンピュータと向き合ってプログラムを検討して書いてという業務と同等以上に相手に関して理解して，世の中の産業・業務がどう進んでいるのか掌理することに時間をかけているのです．本当はこの検討プロセスにもっと時間をかけて最適化していきたいのですが，コンサルティング企業でも無い限り無償でやることも多く，良いクオリティに到達できない場合もあります．

参考 : 話が来てからヒアリングの終了まで 0 円 / 40 人・時間

アプリケーション開発の準委任契約（又は社内予算の確保）

国税庁 No.5461 ソフトウエアの取得価額と耐用年数 に記載されていることがすべてではありますが，IT は安いものでは無く，一つ建物を建てるのと同じですので減価償却，何年使うか，それに見合っているか検討するところからスタートするし，それがすべてです．

2020 代の潮流の少しずつでも DX ! なんていうのは，複数の SaaS に縛り付けられて事業生命の根幹を握られてヤメられない泥沼に自ら落ちていくようなもので，shadow IT リスクも増えるし，やらないほうがマシだというのが何度も言うように .digital の根本的な考え方です．

さて，A 社と .digital が締結した契約書そのままになりますが，下記の通りの準委任契約を結びました．

準委任契約書 テンプレート 05:2021-06

.digital では恐らく同様の事例であれば，他のクライアントにもこのテンプレートを一旦ご提示する形になると思います．これ以外には，法人向け既存ソフトウェアの 01 - 売買契約書 02 - 使用許諾契約書，個人向け 03 - 使用許諾契約書，ビスポークのうち仕様が定まっている場合 04 - 請負契約書，05 - 準委任契約書，ビスポークで要件が定まっていないときに助言から入る（若干コンサルティング的業務）06 - 準委任契約書 とかがあります．

契約書のテンプレを作るのに相当弁護士費用とかが掛かっていたので，Web で公開こそしませんが，問い合わせを受ければいつでも開示しますので RFP フォームからお問い合わせください．

ここで，テンプレートの提示後今回は A 社から全く異論・提案はありませんでしたが、私達や .digital の法務部が敢えて異議を唱えるならどういう点かということを述べておきます。

理想像を描いて，周辺環境や契約金額を顧み，実現可能なレベルまで落とす作業

開発

環境の整備

まずコンピュータとインターネットの接続環境が必要です．なるべく多くの利益を残す為に必要最低限の機能を揃えたものにします．まず Chromebook を購入．開発もこれでやります．

ASUS Chromebook CX1 (CX1100CNA-GJ0040) : JPY 19,800 × 3 = 59,400（残り予算 4,740,600 ）

インターネット環境は実際に利用する事業所の特徴に合わせて揃えるのが良いでしょう．この事例では現場で閲覧することを想定するので，au でスマートフォンをいくつか契約してそれをテザリングすることにします．

スマートフォン (5G) おすすめ料金プラン 使い放題 MAX 5G で，代表者，お金管理担当者，現場担当者の 3 名分の端末と回線を契約します（ 2 年契約 × 3 ）．

au 回線 : JPY 1,302,840 / 60 月
ASUS Zenfone 8（ZS590KS-SL128S8）: JPY 79,800 × 3 = 239,400（残り予算 3,198,360 ）

これでハードウェアは揃ったようなものです．次は Google アカウントを作成します．

個人事業者なら ビジネス向け個人アカウント ，法人事業者なら Google Workspace を契約します．Google Domains でドメインの取得も忘れずに．

ドメイン料金（高く見積もって）: JPY 66,000 / 5 年
Google Workspace（の場合）: JPY 40,800 / 60 月（残り予算 3,091,560 ）

あらら，結構予算を使ってしまいました ! .digital の tips では何度も指摘しているように，なるべく速く完成してしまうことが費用削減のポイントです．きちんとした開発事案では要求を契約に落とし込み，要件を合意して，仕様を策定してドキュメントにし，作業をはじめるべきですが，今回はある意味アジャイル的にすすめることで開発しながら仕様のドキュメント化をしていくことにしましょう．

ドキュメント化だけは絶対にしないといけません．引き継ぎできませんので !!

見積データを型作り

準備

ビジネスプロセスに沿って，見積書にどのような内容を記載すべきかを考えます．見積書のお手本をいくつか検証してみましょう．

大は正義なので，国交省の指針を参照します．標準化のために，海外の事例も検索しましょう．電子データのお手本として，Stripe も参照します．

検索してみると，国交省の

公共建築工事見積標準書式（設備工事編）（令和 3 年改定）

という pdf が見当たったのでこれをひとつめの採用とします．どうやら海外の官公庁でも同じような書式は提供していそうですね．設備工事技術の先進国はどこなのでしょう．土木建築分野なら北欧と聞いたことがありますが，このあたりはわからないので，勝手に選んでみます．

中国建設行程（CSCEC）や中国中鉄（China Railway）が有名な中国は良いお手本になるでしょう．関西国際空港の VINCI（バンシとよむ）も良いですね．

では，急ぎますので中国とフランスの指針があれば十分ということにしましょう．

Deepl で "中華人民共和国の工事見積もりの標準書式" と入力すると，"中华人民共和国工程概算的标准格式" と出力したので Google 検索でこれを調べてみましょう．すると，

广播电视工程建设项目概（预）算编制标准

という pdf に行き当たりました．これは良さそうです．フランスも同様にやってみますと，私は一番最初に

Cadre de classement des collections du département des Estampes et de la photographie

に行き当たりましたが，タイトルを訳してみると "版画・写真部門のコレクション分類の枠組み"，これは違いそうですね．再度 "Formulaire standard du gouvernement français pour les devis de construction" で検索してみます．service-public.fr に行き当たったので，このサイトの中を探索してみましたが，主に生活ユーザや商業ユーザへの公共サービスのガイダンスの内容で，難儀しそうで諦めました．（フランス文に明るい方は挑戦してみてください．）

今回は英文で理解できるものと，オリエントの文献を軸にデータを作っていきます．

データ項目の抜粋

データを次の規則に基づいて作っていくことにしましょう．

1. グローバルなもの（どの業界 / 世界でも共通であると考えられるもの）と業界特有のもので分別する．
2. 後々オブジェクトにする為に，包括関係や上下関係などの構造を明らかに説明する．

抜粋の作業は面倒でしょうから，私達がやっておきます．以下の Google Sheets にまとめましたのでサブコン業界の方はそのまま転記して利用できます ! (Lucky!)

抜粋したデータ項目は下記の Google Sheets に掲載しています．

https://docs.google.com/spreadsheets/d/1YkWC_P41q7gNIeZfudD71TQZjfgUbans8izUDcLLbSM/edit?usp=sharing

データに名前をつける

ddigi_common_person_name

のように命名しましょう．本編で用いるデータにつけた名前は，前述の Google Sheets に同じように記載しています．

データを大きくして参照を少なく作るか，データは ID やパスで連携して小さく / 参照を多くするか問題については，Sheets の 1 cell あたりの文字数上限が 50,000 に対して，GAS の処理は time-out まで 6 分という制約があり，そのどちらが嫌かと言われると後者なので，なるべくデータは大きくして，無駄に参照をさせないような設計にしました．

ここまでどのようなデータを扱うか決める作業をしてきましたが，すべてを網羅するのは難しく，必要最低限を揃えてあとから拡張できるかどうか気になるところです．読者の皆さんで特に現業の方は，ある "モノ" をオブジェクトしてみて，自社の SE さんに聞いてみてください．

データベースをつくってプロパティを固定する

マスタといわれたりしますが，例えば person のデータひとつとっても，どの person を呼び出すのかとか，保存するか，といった "情報の根源" なる部品を設計します．Google Sheets のスプレッドシートを DB として利用してみましょう．

カラのスプレッドシートを新規でいくつか立ち上げます．

// Common

1. 見積のデータを扱うデータベース
2. 自然人のデータを扱うデータベース
   Google Contact で代用できます．もし，　B to C *一般の消費者向け事業 をされているのであれば上限セル数や Google Sheets が Drive のストレージ容量に算入されていることを顧みると Contact で代用すべきです．今回は簡単のために Google Sheets でサンプルを作ってあります． // インフラがしっかりしているかどうかが問題なのです．
3. 商人格（取引先）のデータベース
4. 製品と価格表のデータベース
5. 役務と価格表のデータベース
6. 契約のデータベース（これはあとに控える請求書を発行するシステムに必要です．）
7. 請求のデータベース

// Constr

1. 工事のデータを扱うデータベース

あわせて 8 つ，多いですね ! Apps Scipt から新しいプロジェクトを立ち上げます．（有識者はここで，「えっ ! スプシのコンテナにバインドしなくていいの ?! 」と思うかもしれませんが，あまりメリットを感じなかったので stand-alone でやってみようと思います．

8 つのシートを作って，それぞれ spreadsheet ID を取得し，その ID を名前をつけてプロパティストアに格納する作業をします．

function setUpDatabases() {
  const spreadsheetsCreateFromNowArr = [
    "common_quotation",
    "common_contact",
    "common_account",
    "common_product",
    "common_sercice",
    "common_contract",
    "common_invoice",
    "constr_work"
  ];
  let spreadsheetObj = {};
  for (let i = 0; i < spreadsheetsCreateFromNowArr.length; i++) {
    let id = SpreadsheetApp.create(spreadsheetsCreateFromNowArr[i]).getId()
    spreadsheetObj[spreadsheetsCreateFromNowArr[i]] = id;
    PropertiesService.getScriptProperties().setProperty(spreadsheetsCreateFromNowArr[i], id);
  }
  Logger.log(spreadsheetObj);
}

このスクリプトを上のメニューの実行ボタンから実行します．認証画面でアカウントへのアクセスを許可し，終了すると次の画像のような状態になります．

次に setUpDatabases()は全部コメントアウトか消すかしてしまいましょう．消しても，例えば

function check() {
  Logger.log(ScriptProperties.getProperty("common_quotation"))
}

とすればきちんとプロパティに格納されたことがわかります．Google Drive や Spreadsheet アプリから名称変更したり，場所を移動しても問題ありません !

見積のプログラミング

見積業務フローを論理的にスクリプトへ

今から一気にだいたいのフローを書き切ります．

1. ユーザは見積フォームにアクセスする．
   startQuote()
2. ユーザはどの見積依頼に応答するか選択する．
   answerRfq(ddigi_constr_rfq)
1. 見積依頼が未収受の場合は，自分で作成する．
   createNewWork(ddigi_constr_customer, ddigi_constr_orderer)
1. 依頼人の商人格データを作成する．
   createNewAccount()
2. 担当者のデータを作成する．
   createNewContact()
2. 見積依頼がある場合は，その依頼のデータを取り込む．
   getRfq(ddigi_constr_rfq)
1. 見積依頼人が商人格データに登録されていなければ，登録する．
   createNewAccount(ddigi_constr_rfq)
2. 担当者のデータが登録されていなければ，登録する．
   createNewContact(ddigi_constr_rfq)
3. ユーザは工事の情報が不足していたら追加する．
   setWorkInfo(ddigi_constr_rfq)
4. ユーザは見積データを作成する．
   createQuotation(ddigi_constr_rfq)
1. 製品や役務をピックアップしながら明細を入力する．
   setLineItems()
2. 製品や役務が登録されていなければ，登録する．
   createNewProduct()
createNewService()
5. ユーザは見積データを保存する．
   finishQuote()
1. ユーザは見積データを下書きの状態にしたまま保存する．
   draftQuote()
2. ユーザは見積データを依頼人に公開する．
   openQuote()
3. 公開する場合，メールで担当者に送る．
   emailToOpenQuote()
6. ユーザは閲覧や追加をするために見積データを呼び出す．
   getQuotation(ddigi_id)
1. データが Draft 状態であれば，そのまま編集を継続する．
   editQuote()
2. データが Open 状態であれば編集できないようにする．
   quotationIsOpening()
7. 依頼人はメールを見て，この見積もりを是認するか，拒否するか選ぶ．
   acceptQuote()
cancelQuote()
1. 是認した場合は見積データを Accepted 状態にする．
   quotationIsAccepted()
2. 拒否した場合は見積データを Canceled 状態にする．
   quotationIsCanceled()
8. 依頼人から再見積や一度 Open にした見積を編集するときは Canceled の見積を複製して再編集できるようにする．
   duplicateQuote(ddigi_id)

一旦ここまで ! 実務はもっとハードで複雑ですが，一旦簡単にしておきましょう．請求に関するプログラムはまたあとから．

startQuote() を検討

この関数は見積書の作成を開始するところを制御するものです．GAS で getUi() が利用できるのは FormApp, DocumentApp, SpreadsheetApp, SlideApp の 4 種類です．もし DriveApp が使えたら Google Drive に "見積書作成" なりのメニューを作って簡単にファイルを作成できるのですが，これは不可能なので起動用のシート兼見積書テンプレートファイルを 1 つ用意する必要がありそうです．

更に，Google Sheets （に限らず様々な Google Docs の機能）のなにが良いところかを考慮すると，共同編集の良さを消しては勿体ないのです．

この事例では，複数の編集者が別々の見積書を同時に作成する可能性があることを顧みて，1 つのフォームを同時に編集するのでは作成する目標が異なるため不適切です．

ですので，まずランチャーを起動したら編集用のファイルを個別に作成していくことが大事そうです．

カラのスプレッドシートを 1 つ "見積フォーム" などと名前をつけて作成し，あとでバインドしたスクリプトを作成します．必要に応じて何枚かシートを作り，次のように id を抜き出しておきます．（図中では既にテンプレートの作成をしていますが，この時点では必要ありません．）

（後記 Properties で固定することも考えましたがあとからテンプレートを改修したときなどにすぐ変更できてコードに見えてあるほうがよいかと思い，こうしました．）さて，既に少しスクリプトを書き始めていますが，下記の通りに考えました．

function setUpDatabases() {
  const spreadsheetsCreateFromNowArr = [
    "common_quotation",
    "common_contact",
    "common_account",
    "common_product",
    "common_sercice",
    "common_contract",
    "common_invoice",
    "constr_work"
  ];
  let spreadsheetObj = {};
  for (let i = 0; i < spreadsheetsCreateFromNowArr.length; i++) {
    let id = SpreadsheetApp.create(spreadsheetsCreateFromNowArr[i]).getId()
    spreadsheetObj[spreadsheetsCreateFromNowArr[i]] = id;
    PropertiesService.getScriptProperties().setProperty(spreadsheetsCreateFromNowArr[i], id);
  }
  Logger.log(spreadsheetObj);
}