質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.04%

業務アプリで GAS (Google Apps Script) を使い続けていて大丈夫なのでしょうか

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 9
  • VIEW 4,291

unau

score 2410

私、自営業ですが、業務に Gmail や Googleスプレッドシート、Google カレンダーなどを定常的に利用しています。Google Apps Script (以降、GAS) もゴリゴリ書いて、それらのツールの連携を図ったり、機能拡張したりしています。GAS がないと業務がただちに滞るレベルです。

Googleスプレッドシート (など) は、オフラインでできることが増えてきていて、ますます使いやすくなってきました。
しかし、スクリプトをライブラリとして使うことが非推奨となったり (プロジェクトキーのサポートが終了というのはそういうことかな、と)、レビューを受けていないアプリだと一部のスコープの承認を得られなかったり、その制限を無視して (unsafe であることを許容して) 特定のスコープの承認を得るためには言語を一旦英語に切り替える必要があったり、と、お気軽に使いずらくなってきた印象があります。

Google が、特に無料のサービスを突然やめちゃう、というのは珍しくないので、GAS をこのまま使い続けていいものか、不安を覚えています。
G Suite に移行すれば問題なし、という話なら、それはそれで構わないと思っています。それだけの価値のあるサービスだと思いますので。

このまま業務アプリを GAS に頼っていて大丈夫なのか、この先の見通しはどうなのか、諸兄の見解を賜りたく、質問した次第です。
多数有用なご回答をいただいたとしても、teratail の仕組上、ベストアンサーは一つしか付けられないと思いますが、その点はご容赦ください。


追記 : 2017-08-25 15:08
ちなみに、GAS で業務アプリを組んで、常用し続けて 4 年半になります。

あと、「プログラミングに関係がない質問」との指摘をしていただいたようです。
業務アプリの作成、特にメールの自動処理やスプレッドシーの拡張などについては、GAS は手軽かつ強力なツールかと思います。これからも採用を検討される人もあろうかと思います。
そのような人が他のサービスとの比較検討するうえでも、この質問についた回答が役に立つのではなかろうか、と思い、質問した次第です。
プログラミングそのものではなく、その環境・サービスとして適切な利用シーンはなんなのか、という観点での質問ですので、「プログラミングに関係がない質問」と言われたら、定義次第ではそのとおりかと思います。が、私自身はプログラミングに関係のない質問とは考えておりません。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

+6

この問題は、Googleに限らず、他のクラウド型のサービス全般に言えることだと思います。
当然、ご指摘なような、突然ルールが変わったり廃止になったりするリスクは想定しておく必要があると思います。

プログラム上で何らかの問題に対処するための設計手法としては、
こういった外部のプログラムやAPIを、業務アプリ上で直接呼び出さないようにするとよいと思います。
すべて、自作のライブラリを通してコールするように設計します。
こうすれば、もし何か問題があっても、プログラムの修正範囲はそのラッパーに使っているライブラリだけになるので、修正作業やテストが最小限に抑えられるかと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/08/25 16:46

    ご回答、ありがとうございます。
    そうですね、ラッパーをかませることが可能な箇所についてはそのような設計が望ましいですね。
    現在使っている出荷計画表やら会計帳簿などは、Google スプレッドシートにゴリゴリ機能を拡張する形になっており、頭を悩ますところです。

    キャンセル

checkベストアンサー

+5

他の方の回答も気になりますが、ひとまず私の意見を書いてみたいと思います。

GoogleAppsScript は利便性の面で素晴らしい言語だと思います。
自分でサーバーを用意しなくともWebアプリを公開したり、プログラムを定期実行できるのは大きなメリットだと思います。

しかしその反面、(クラウドサービス全般に言えることですが)サービス起因のトラブルが起きた場合、解決するために出来ることと言えば Issue を投げることぐらいで、基本的に「解決されるのを待つ」ことしか出来ないのは不安材料ではあります。

具体例を挙げれば、(unauさんも記載されてますが)「スコープの承認を得るためには英語に切り替えなければならない」という現象が起きました。

GAS で「一部のスコープへのアクセス権限がありません」と怒られたときの対処法

いまでは日本語のままでも承認できるようになりましたが、そうなるまでに一か月ほどかかっていると思います。
上記 Qiita 記事で回避方法を共有してもらえなければ、新規プログラムをずっと実行できないままだったかもしれません。

また、いま現在でも DriveApp の openFileById() などの一部メソッドがタイムアウトする現象が起こっています。
(既存のプログラムは問題ない)

Method call of DriveApp happend timeout.

このような状況を踏まえると、
クリティカルな業務アプリをGASで構築するのは避けた方がいいのではないかと感じます。
(上記トラブルは既存システムに影響を与えてないため、絶対にダメ、とも言い切れませんが)

まとめますと
GASはあくまで業務の補助として使用し、 クリティカルな部分は別途システム構築したほうが安心
というのが私の意見です。

私は使用していないので要領を得ませんが、
AWSなどのクラウドサービスを業務で利用している方の意見も伺ってみたいですね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/08/25 15:03

    DriveApp のタイムアウト現象は解決したようです。

    キャンセル

  • 2017/08/25 15:25

    ご回答いただき、ありがとうございます。
    「GASはあくまで業務の補助として使用し、 クリティカルな部分は別途システム構築したほうが安心」なのは確かですね。4 年半、GAS で基幹業務のツールを使ってきましたが、そろそろべったり依存するのは見直したいと思います。

    キャンセル

+5

参考にはならないかもしれませんが、GASを使っていてこわいと思ったのはonEditが反応しない、定期実行が失敗する、タイムラグの3つです。

onEditはユーザーの入力が早いとonEditがついていけずにスルーされてしまうリスクがあるので使いどころには注意しています。たとえばIDを入力すると対応する品名が出て来るみたいな流れ(セルに関数式を仕込みたくないのでonEditを使いたくなるとき)で素早くIDを連続して入力されるとonEditがついていけなくてスルーされることです。

定期実行が失敗するリスクですが、失敗に備えて再実行するコードを組むなどしています。ただそれでも定期実行には成功したがとえばスクレイピングなどで100件とってくるべきところ、1件しか取れないということも稀にあります。

タイムラグ、というのはたとえばユーザーが何らかのデータ入力→他のシートにあるテーブル更新→集計ボタン(図形でもいいし、メニューに追加してもいいですが)押す→集計結果が表示されるといった流れのなかで、データがQUERY関数などでちまちま処理が行われている最中に集計ボタンを押されて最新の状態を反映していない結果が表示されちゃうリスクなどです。JavaScriptで擬似的にSQLっぽいこともできなくはないですが規模がある程度いくとシート上でQUERY関数で処理させてその結果を取得してという流れのほうが早い、けどタイムラグが・・という感じです。

このように「(書き方のせいもあるかもしれないが)コードは正しいのに主として実行速度の問題などでいつも自分の意図したとおりに動作してくれるとは限らない」というもどかしさが最大の不満、不安です。

99回は正常に動作するが1回は動作しない、動作するが動作中に新しい処理を注文されるリスク(これはsetFormulaを使って動的にシート上に関数による処理を入れてその処理結果をさらにGASで受け取って処理を連続的に行う場合など)、と言ったらいいんでしょうか。

従っていかにこの予期しない結果や動作に備えるかですが、プログラミングだけでカバーするのは限界があるような気がします。最後は直接目で見て何かしらの事後的な確認作業が必要なところも出てくるのかなと思っています。

たとえば上記のスクレイピングの例で言えば取得結果件数をメールさせるようにしていて1件だけしか取得できていない場合は手動で実行し直すといった具合です。

そういった人的作業、手動対応も含めた業務フロー全体を考える必要はあると思います。

GASのいいところはその圧倒的なコストパフォーマンス、習得のしやすさ以外にも、他のシステムとの親和性が優れているところで、Slackとの相性もいいし、基幹システムが吐き出すデータをGASで受け取ってゴリゴリ自動的に加工集計して基幹システムにはない見栄えの結果を定期的かつ自動的に担当者にメールするといった拡張的なこともできるので、使わなくなることはないと思っています。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/08/26 18:52

    ご回答、ありがとうございます。
    onEdit やトリガーの「空振り」、ありますね。タイミングがシビアなものは作らない、実行しないようにしているので、「タイムラグ」の件は経験したことありませんが、「なるほど、いかにもありそう」という感じがします。
    true さんがおっしゃるような、手動対応も含めた業務フロー設計は自然とやっていましたが、新たに導入を考えている方は、その点、要注意ですね。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.04%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる