どうも。ケニー（tsujikenzo）です。このシリーズでは「[Asana API]スプレッドシート連携でタスク登録をしよう」をお届けしています。
今日は7回目です。
前回のおさらい
前回は、「スプレッドシートとAsana準備編」をお届けしました。
ガッツリ、アプリの要件定義をしましたね。
本来であればこの後に、「処理のフローチャートはどうなるのか」や「スプレッドシートの列にはどんなデータ型があるのか」などの、設計について開発する人使う人などの議論が交わされます。
しかし、ノンプログラマーは開発者＝使用者でもあることが多く、設計図を書かずに、いきなりプログラミングをし始めることが多いです。
それでいいと思います。不便だなと思い始めたら、設計図を書きましょう。
「書いたらすぐGWSのサービスを動かせるスクリプト」は、Google Apps Scriptの強みです。
今回は、「スプレッドシート設計とGASの下準備」です。
今日のアジェンダ
- スプレッドシート設計
- ダミーデータを入力して実行する（架空）
- GASを書き始める前の下準備
スプレッドシート設計
まず、2種類のシートを準備します。
- data・・・全データを置く構造化データベース
- post・・・タスク登録に特化したシート
dataシートのヘッダーは、各GIDを入力します。増えたり減ったり、順番が入れ替わったりすると思いますが、問題ありません。（画像ではworkspaceというフィールドを用意していますが、1ワークスペースに1スプレッドシートという運用をしますので、不要です。） 
postシートのヘッダーは、数式になっており、dataシートを参照しています。 
流れとしては、まず、dataシートにタスク行を追加し、履歴も残していきます。
Asanaにタスク登録するときや、タスク更新をするときは、postシートに転記する（作業がおわるとpostシートはクリアされる）という感じです。
実際のフローを、イメージしてみましょう。
ダミーデータを入力して実行する（架空）
まず、dataシートに、マイタスク用のタスクを入力します。
A列のstarは、処理済みかどうかの判定用です。 
それでは、このタスクをAsanaに登録する流れのイメージです。まだ実装していない工程は（架空）と表記しています。手動で作業します。
- 必要なタスク（1行以上、MAX50行ぐらいかな）のA列にstarが入っていないことを確認します。
- （架空）「カスタムメニュー」をクリックして、「postシートへ転記」をクリックします。
- postシートに転記されました（いまは手動でコピペしてください）。 転記処理が完了した、という意味で、dataシートのA列のstarに★が付与されます。
- （架空）dataシートのタスクには★が付いています（いまは手動で付与してください）。
- （架空）「カスタムメニュー」をクリックして、「Asanaへタスク登録」をクリックします。
- （架空）Asanaにタスクが登録されました。
- （架空）postシートはクリアされています。（今は手動で削除してください）
という、流れになります。
【注意】フロー順にアプリを作り始めない
このように、手作業でフローを確認することで、「アプリの本質的にやりたいことはなにか」を考えることが非常に重要です。
転記や処理済み★の付与などは、手作業で構わないので、まず、Asanaへの登録機能を作って、アプリとしてお披露目するということが大事です。（MVPという考え方です。）
GASを書き始める前の下準備
フロー（図）を確認したら、GASを書き始めてもいいのですが、今回は、わたしなりの環境をご紹介します。
ご自身なりの環境がある方は、読み飛ばしても構いません。（むしろ参考にならないと思います）
ユースケース図
ここまでのユースケース図は、こんな感じです。
本来は、スプレッドシートやGASを作るまえに、全体像を書くべきですが（要件定義）。 
機能を追加したいときや、LINE連携などをするときは、ユースケース図に書き加えていきたいと思います。
GitHub
GASを書くときは、必ずGitHubのリポジトリを用意しています。
理由は、チーム開発でもバージョン管理でもなく、「コードの再利用」です。
以前書いたGASを再利用したい、ということがあると思いますが、大量のクラスをコピペするのは大変です。
常に最新の書き方に変わりますし、適材適所でナイスな書き方も違います。なのでテンプレート化もムダな苦労になります。
いちばんいいのは、「この間書いたコードいい感じだったな」を、まるまる複製して使い回しすることです。
それには、コードだけをアップロード、ダウンロードできる、GitHubがよろしいかと。
タイミングがあれば、このシリーズでさらっと触れます。
VSCode
わたしは、コードを書くエディタはVSCodeです。もちろん、実行時には、GASのスクリプトエディタを使います。
VSCodeを使う理由は、GitHub連携がラクということです。最近だと、Copilotによるプログラミングも時間短縮につながりました。
ちなみに、このブログもVSCodeで書いてます。
Googleドライブ
基本的にあまり用途はないのですが、やはり、プロジェクト専用のGoogleドライブのフォルダが、ローカルに1つあるとプロジェクトを整理しやすいです。
最終的に、コードを管理しているのはGitHubですが、VSCodeのファイルはローカルなので。
Googleドライブには、プロジェクトで使うフォームや、スプレッドシートなどを格納します。 
GASを書き始める手順
それでは、実際に書き始めるまでの手順です。
- Googleドライブに、専用のフォルダ（プロジェクトフォルダと呼びます）を作成する。（さきほど作成したので割愛します。）
- VSCodeで、プロジェクトフォルダを開きます。
- ワークスペースとして保存するをクリックします。
- 【GitHubワークスペース】という名前を付けて、保存します。
この作業を行うことで、開発作業を始めたいときに、1クリックで開発環境を呼び出せます。
- 下準備で作成したGitHubリポジトリを、クローンします。ターミナルにbashを使っています。
- GitHubに置いてある、過去に書いた、いい感じのリポジトリをクローンします。今回は、去年作った、スプレッドシートを操作する系のプロジェクトをクローンします。LINE連携がよくできていたプロジェクトもクローンしておきます。
- 過去に書いたクラスや、global.gsやonOpen.gsなどを、今回のプロジェクトにドラッグアンドドロップしていきます。
- ステージングしてコミットしてGitHubにPushします。
- GitHubにアップロードされました。
- スプレッドシートのコンテナバインドスクリプトを開いて、リポジトリをPullします。
- スクリプトエディタにコードがダウンロードできました。
コードは、基本的にVSCodeで書きます。スクリプトエディタでは編集せずにダウンロードだけにします。
これは、「常に一方通行」というルールで、コンフリクトがおきず、安心してコーディングができます。
まとめ
以上で、「スプレッドシート設計とGASの下準備」をお送りしました。
わたしの開発環境を紹介してみたので、長くなってしまいました。参考になれば幸いです。
それでは、実際に、コーディングを始めましょう。
次回は、「スプレッドシートクラス」をお届けします。お楽しみに。
