Q&A
ご回答、ありがとうございます。
onEdit やトリガーの「空振り」、ありますね。タイミングがシビアなものは作らない、実行しないようにしているので、「タイムラグ」の件は経験したことありませんが、「なるほど、いかにもありそう」という感じがします。
true さんがおっしゃるような、手動対応も含めた業務フロー設計は自然とやっていましたが、新たに導入を考えている方は、その点、要注意ですね。
私、自営業ですが、業務に Gmail や Googleスプレッドシート、Google カレンダーなどを定常的に利用しています。Google Apps Script (以降、GAS) もゴリゴリ書いて、それらのツールの連携を図ったり、機能拡張したりしています。GAS がないと業務がただちに滞るレベルです。
Googleスプレッドシート (など) は、オフラインでできることが増えてきていて、ますます使いやすくなってきました。
しかし、スクリプトをライブラリとして使うことが非推奨となったり (プロジェクトキーのサポートが終了というのはそういうことかな、と)、レビューを受けていないアプリだと一部のスコープの承認を得られなかったり、その制限を無視して (unsafe であることを許容して) 特定のスコープの承認を得るためには言語を一旦英語に切り替える必要があったり、と、お気軽に使いずらくなってきた印象があります。
Google が、特に無料のサービスを突然やめちゃう、というのは珍しくないので、GAS をこのまま使い続けていいものか、不安を覚えています。
G Suite に移行すれば問題なし、という話なら、それはそれで構わないと思っています。それだけの価値のあるサービスだと思いますので。
このまま業務アプリを GAS に頼っていて大丈夫なのか、この先の見通しはどうなのか、諸兄の見解を賜りたく、質問した次第です。
多数有用なご回答をいただいたとしても、teratail の仕組上、ベストアンサーは一つしか付けられないと思いますが、その点はご容赦ください。
追記 : 2017-08-25 15:08
ちなみに、GAS で業務アプリを組んで、常用し続けて 4 年半になります。
あと、「プログラミングに関係がない質問」との指摘をしていただいたようです。
業務アプリの作成、特にメールの自動処理やスプレッドシーの拡張などについては、GAS は手軽かつ強力なツールかと思います。これからも採用を検討される人もあろうかと思います。
そのような人が他のサービスとの比較検討するうえでも、この質問についた回答が役に立つのではなかろうか、と思い、質問した次第です。
プログラミングそのものではなく、その環境・サービスとして適切な利用シーンはなんなのか、という観点での質問ですので、「プログラミングに関係がない質問」と言われたら、定義次第ではそのとおりかと思います。が、私自身はプログラミングに関係のない質問とは考えておりません。
回答3件
0
この問題は、Googleに限らず、他のクラウド型のサービス全般に言えることだと思います。
当然、ご指摘なような、突然ルールが変わったり廃止になったりするリスクは想定しておく必要があると思います。
プログラム上で何らかの問題に対処するための設計手法としては、
こういった外部のプログラムやAPIを、業務アプリ上で直接呼び出さないようにするとよいと思います。
すべて、自作のライブラリを通してコールするように設計します。
こうすれば、もし何か問題があっても、プログラムの修正範囲はそのラッパーに使っているライブラリだけになるので、修正作業やテストが最小限に抑えられるかと思います。
投稿2017/08/25 07:06
総合スコア1939
0
参考にはならないかもしれませんが、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 07:13
総合スコア440
0
ベストアンサー
他の方の回答も気になりますが、ひとまず私の意見を書いてみたいと思います。
GoogleAppsScript は利便性の面で素晴らしい言語だと思います。
自分でサーバーを用意しなくともWebアプリを公開したり、プログラムを定期実行できるのは大きなメリットだと思います。
しかしその反面、（クラウドサービス全般に言えることですが）サービス起因のトラブルが起きた場合、解決するために出来ることと言えば Issue を投げることぐらいで、基本的に「解決されるのを待つ」ことしか出来ないのは不安材料ではあります。
具体例を挙げれば、（unauさんも記載されてますが）「スコープの承認を得るためには英語に切り替えなければならない」という現象が起きました。
GAS で「一部のスコープへのアクセス権限がありません」と怒られたときの対処法
いまでは日本語のままでも承認できるようになりましたが、そうなるまでに一か月ほどかかっていると思います。
上記 Qiita 記事で回避方法を共有してもらえなければ、新規プログラムをずっと実行できないままだったかもしれません。
また、いま現在でも DriveApp の openFileById() などの一部メソッドがタイムアウトする現象が起こっています。
（既存のプログラムは問題ない）
Method call of DriveApp happend timeout.
このような状況を踏まえると、
クリティカルな業務アプリをGASで構築するのは避けた方がいいのではないかと感じます。
（上記トラブルは既存システムに影響を与えてないため、絶対にダメ、とも言い切れませんが）
まとめますと
GASはあくまで業務の補助として使用し、
クリティカルな部分は別途システム構築したほうが安心
というのが私の意見です。
私は使用していないので要領を得ませんが、
AWSなどのクラウドサービスを業務で利用している方の意見も伺ってみたいですね。
投稿2017/08/25 05:28
総合スコア174
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/08/25 07:46