GAS 初心者向け よくある間違いやエラー、考え方
ノンプログラマ向けにGAS講座を開催したり、問い合わせを受けたりする中で、割とよくある、多くの人が引っ掛かりやすいポイントがあるようなので、つらつら書いてみる。
エラーにビビらない、エラー文をよく読もう
精神論（長い）
いきなり精神論的ではあるが、プログラミングにおいてはエラーを出してナンボである。エラーを出さずにコードを書き上げることはまず無い。少なくとも私には無理だ。
エラーは失敗ではない。コードを書き上げるための指標だ。
エラーを出すことを、極端に怖がる人、あるいは（無意識的に）忌避したがる傾向のある人も世の中にはいるかもしれない。このあたりは、減点方式による教育の効果というか、弊害というか、そんな影響もあるのかもしれない。
最初は、エラーが出ると、赤い文字だったり、英語で書いてあるし、どう対応して良いか戸惑うかもしれない。その戸惑いは多くの人が経験し、乗り越えてきたものなので安心して欲しい。
エラーが出ても、基本的にパソコンは爆発しないし、核爆発もしない（そのような仕事でコードを書いている人は除く）。エラーはあなたを責めているわけでも、怒っているわけでもない。ただ、そこにエラーがあるだけだ。
エンジニアは、エラーが出ると「怒られた」と良く言うが、これは癖みたいなものなので気にしないでほしい。余談だが、プログラミングにおいて、コードやそれに関係する振る舞いについて「（エラー表示で）怒られた」「（エラーやログを）吐いた」「（APIなどを）叩く」といった言い回しがある。
まずはエラー文を読んでみよう
エラーへの対応として、まずはエラー文をよく読もう。英語が苦手なら、翻訳ツールを活用しよう。ChromeでDeepLの拡張機能を入れておけば、英語文章にマウスカーソルを合わると日本語訳を表示してくれる。エラーの原因や、対応方法がそこには書かれている。
エラー文は端的であるため、よくわからないときもある。エラー文をそのままコピペしてGoogle検索してみると、同様のエラーにつまづいた人、それを解決した人の情報を見つけることもある。最近では、AIに訊くのも手だ。
5〜15分程度、自分で調べても解決しない場合は、人に訊くのがよい。適切に頼るのもスキルのひとつ。
よくあるエラー
大文字と小文字
3行目までは問題なく動いている。
4行目ではエラーとなっている。
エラー文は ReferenceError: X is not defined つまり Xが定義されていない、と言っている。
画像を良く見て欲しい。
2行目では、小文字のxを用いている。
4行目では、大文字のXが赤く色が変わっている。
ファンクション名称の重複
上図では、1行目と6行目でfunction名称が全く同じになっている。
全く同じ名前の関数名が一つのプロジェクト内に存在していると、1行目の関数を呼び出していたつもりが、6行目の関数を呼び出してしまっていた、なんてことになる。
括弧が合ってない
括弧のペアが揃っていなかったり、括弧が必要な場所に無かったりするとエラーとなる。後述するドキュメントフォーマットを用いて、括弧の繋がりがわかりやすくなるようにしたい。
（余談）
中級〜上級になってくると、ガード節を用いてIfのネストを浅くしたりとか、そういった工夫もある。
そのあたりのコードの保守性については「良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方」が良書。
スペルが合っていない（「打たない」を心がける）
打ち間違いは、人間が入力している限り起こり得る。
GASのエディタは気が利いているので、下図のように「fu」ぐらいまで打ってしまえば候補を表示してくれる。自分で全て手打ちするよりも、これらの変換候補を選んだ方が楽だし、打ち間違いも起きにくい。
コードを書く、というと、キーボードをバチバチ叩いているイメージがあるが、それはほんの一側面に過ぎない。変換候補や、スニペットを使うなどして、「打たない」を心がけた方が間違いが少ないので実利的である。コードを書く＝バチバチとキーを打たなければいけない、というわけでもない。
カンマが合っていない
オブジェクトにおいて、プロパティ（キー）と値（バリュー）のセットはカンマ区切りとしていく。このカンマが無いと、エラーとなる。
上図では、4行目の25の後にカンマが無いためにエラーとなっている。
注目は5行目のjobに赤波の下線が引かれていること。この赤波下線が示されている箇所またはその前後が間違っていることが多い。
エラーを減らしていくには
エラー出現時の赤波の下線に注目する
これまで例示したエラー例の画像を再度よく見てみてほしい。
繰り返しになるが、赤波下線が示されている箇所またはその前後が間違っていることが多い。
ドキュメントフォーマットしよう
コードの乱れは心の乱れ。
インデントが揃っていないと、括弧のペアもわかりにくかったりする。
エディタ上で右クリックするか、キーボードショートカットでドキュメントフォーマットを行い、ピシッと見た目を整えよう。
言語によっては、特にPythonなどは、インデント（行頭の空白）が合っていないとエラーになる。
公式ドキュメントを読もう
GASにおける聖典、聖書は下記の2点。
新約聖書と旧約聖書みたいなもん（テキトーに言っている）
Google Apps Script REFERENCE
https://developers.google.com/apps-script/reference?hl=jaJavaScript MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript
咀嚼されたブログ記事も参考になるものは沢山ある。けれども、噛み砕きにくくても、やはり、本家本元のドキュメントを読むことは大事だ。
ドキュメントへの対峙として、よくあるプロセスは次の通り。
公式ドキュメントを読む→
全然わからない。（オフチョベットしたテフをリットしてマブガットする？？）（パルスのファルシのルシがパージでコクーン？？）→
色々なブログ記事などを読みながら、手元でアレコレする→
一定の理解を得る→
公式ドキュメントを再度読んでみると、疑問に思っていたことに対する事柄が書いてある（最初から書いてあったやんけー！となる）
書籍を読もう
書籍としては、やはり通称GAS本とも呼ばれる高橋氏の著作は外せない。
詳解！Google Apps Script完全入門[第3版]
GASとは直接的に関係はないが、ノンプログラマ向けには、以下の書籍もおすすめ。
AIに聞くのも手だよ
繰り返しになるが、BardやChatGPTなどのAIに質問するのもひとつの手段ではある。
ただし、AIの返答には一定の注意も必要である。
質問の仕方が悪ければ、返答の内容もイマイチなものになる。
英語の自動翻訳では、ある程度の英語の知識があると不自然な翻訳、意図しない翻訳に気が付けることがある。自動翻訳に掛ける文章の主語、述語、目的語が不明瞭であったり、修飾がどこに掛かっているのか判りにくかったりすると、翻訳することでそのアラが出ることがある。
質問には一定のコツがある。
プロンプトと呼ばれる、AIへ投げかける文章には、得たい反応を生み出すためのお作法やテクニックがある。
私は面倒くさがりなので、だいたい下記のような雑な文章でAIに質問しつつ、返答を見てまた修正質問したり、コードを直したりしている。
- V8ランタイムに準拠したGASのコードを書いてください。
- ドキュメンテーションコメントを書いてください。
- コードの内容を初心者にもわかるように説明してください。休憩しよう
コーヒーを飲んで一息入れたり。
寝不足の場合は、寝た方がいい。
散歩したり、お風呂に入っていると、アイデアが出てくることがあるのは周知のとおりです。
余談？
GASでどうこう以外に、辞書登録の活用をおすすめしたい。
Windowsユーザなら、クリップボードも有効化してコピペ作業を効率化してほしい。
（ここで、辞書登録？クリップボードの有効化？と思ったら、自分で調べる癖を付けて欲しい）
スプレッドシートの基本的な関数や条件付き書式も使えるようになっていたい。
そして、ぐっちゃぐちゃなデータベースではなく、構造化データとして、綺麗なデータベースになるデータの持ち方、持たせ方を意識していきたい。
こういったことを、そうするのではなく、そうなるように、していきたいですね。
そのへんのデータの話はこちらもどうぞ↓
今日はこんなところで。
思いついたら、また適当に書き加えるかも。
こーゆーのも、学び始めにはよくあるよね、アレも知っておきたかったなどあれば、コメントくださいませ🙏
いただいたサポートで、書籍代や勉強費用にしたり、美味しいもの食べたりします！