どうも。つじけ（tsujikenzo）です。今日は「Google Workspace ソリューションデベロッパーになる」というお話について書き留めたいと思います。
きっかけ
2021年の年明けから「GASの勉強は沢山してるけど、社内の業務効率化に貢献してる？」という各方面からの疑問を一蹴すべく、「そう言えばあれ作りたかったなぁ」というツールをGASで色々書いていました。
- スプレッドシートの2次元配列を連想配列化した後に2次元配列に戻すツール
- 2つのデータの差分を取るツール
- ドキュメントで業務マニュアルを作る際のサポートツール
- セルの書式設定を自動でやるツール
- など
当然ブログも同時に書いていまので、気付いたら1週間で約40,000字近い原稿を書いていたようです。ちょうど、基本的な文法や段落の設定などを学べる「ノンプロ研ライティング講座」の開催も重なり「ブログを書くぞ！」というスイッチが入ったようです。
コードをシェアするとは
プログラミングを学び始めて間もないときは「動けばいいや」「月をまたいだらコードを修正すればいいや」という感じでしたが、学習を進めていくうちに「これ後で使いまわししそうだな」「日付の定義をしっかりして変更に耐えられるようにしておこう」というコードを意識して書くようになりました。
その意識が強くなると、コードを利用する対象者も「個人（自分自身）」→「社内」→「世界中のユーザー」のように範囲が広くなっていきます。
GASには自分が書いたコードをシェアする方法がいくつか用意されています。
- ウェブアプリケーション
- 実行可能API
- アドオン
- ライブラリ
主に4つの方法を挙げましたが、根底にある技術にはさほど変わりがありません。「そのコードを使うユーザーにとって、操作しやすいシェア方法はどれか」というぐらいです。
OSなどのプラットフォームを問わず動かしたい場合は「ウェブアプリケーション」としてコードをシェアする方がいいですし、ユーザーもプログラマの場合は「ライブラリ」としてシェアする方が双方にとって楽です。
また「コードを実行するのは誰なのか？」によっても選ぶべき方法が変わってきます。（厳密に言うとGCPの紐づけの違いみたいな話になりますが、私も勉強中です💦）
私が公開したライブラリ
完全な状態ではありませんが、少しずつ自作ライブラリも公開していますので覗いてみてください。ご質問などあればSNSで回答させていただきます。
・スプレッドシートをキーバリュー形式の2次元配列に変換する「SpreadsheetDateConverterToObject ver1.1」
・2つのテーブルの差分（対象差）を返す「SymDiffChecker Ver.1.0」
Google Workspace アドオン
一方でGoogle Workspaceの各サービス（スプレッドシートやドキュメントなど）専用に使えるコードでしたら「アドオン」としてシェアする方がいいです。2021年の動きとして、Googleさんはアドオンを押している傾向にあるようです。
Google Workspaceの情報発信について信頼できる「隣IT」さんも言及してますし、その流れは間違いないと思います。
主役はAppSheetなどのノーコード、GASなどのローコードという位置付けに、スプレッドシートやドキュメント、Gmailに追加できるアドオンが補佐役となって、私たちの働く環境をサポートしていくのだと思います。
アドオンを使う瞬間
とはいえ「便利なのはなんとなく分かるけどアドオンってどんな時に使うの？」という声も聞こえてきます。私自信がアドオンを作り始めたきっかけは「コンテナバインドスクリプトを他のスプレッドシートにも移植したい」と思ったからです。「便利」というより「必要に迫られて」という感覚です💦
そして私と全く同じように「Google スライドのコンテバインドスクリプトで便利なコードを書いていたが、新規作成する度にコピペしていた」という方がいるので、そちらの記事もご紹介させていただきます。
「Apps Script のプロジェクトを G Suite アドオンとして供給した方がよい理由」
プログラミング学習とアウトプット
プログラミング学習をされている方で、もう一歩成長したいなと思っている方は「書いたコードをパーツ化」することをまずは意識してみてください。繰り返し冗長になっているコードはメソッド一つで簡素化できることがありますし、後で使いまわしができるように繰り返されているコードのパーツ化（Functionに分けるなど）をやってみましょう。
パーツ化ができるようになったら、ライブラリの公開は比較的簡単です。数クリックで世界中にシェアすることができます。（誰でも使えるような汎用性のあるコードにするための要件定義は大変ですが💦）
ライブラリが作れるようになったら「ウェブアプリケーション（実行可能APIも含む）」や「アドオン」にチャレンジしてみましょう。プログラミング学習と同時にアウトプットを意識することは非常に有効です。
まとめ
皆さんもご経験があると思いますが、「繰り返し登場するコードのパーツ化」や「便利なfunctionの外部からの呼び出し」というスキル獲得はプログラミング学習を進めるうえで必ずぶち当たる壁です。
しかし、皆さんにとってプログラミング学習の目的は「もう一つ体が欲しい」「繰り返しの単純作業に耐えられない」といった課題を解決する為だったはずです。ツールを一つでも作って動かしている方は、既に課題の解決方法（ソリューション）を提供する側（デベロッパー）に立っているのです。
なので「いやいやまだまだ勉強中だから」と思わずに、コードをシェアしたり、または他人がシェアしているコードを見てみたり、世の中の課題に向き合う「ソリューションデベロッパー」を目指しましょう。プログラミング学習を頑張っていたら、社会にも貢献できていたってとても素敵ですね。私も頑張ります！
