Google Apps Script が突然動かなくなったときにすべきこと
今回も、Google Apps Script（GAS) の話題です。GASは手軽なのに、かなり高機能なシステムを組むことができるプログラミング環境です。もし、職場でG Suiteを使っているのであれば、あなたや同僚の仕事を効率化することができるかもしれません。例えば 、Google Calendar の予定を自動手的に登録したり、定例レポートをスプレッドシートに吐き出してチームに自動的に共有するようなタスクが簡単に作成できます。
ただし、重要な業務を担うシステムを組む場合は注意が必要です。テストでバグをすべて解消したとしても、システムが突然動かなくなるリスクが、GCPやオンプレミスで組んだシステムに比べると高いことを知っておく必要があります。
私もこの5年で様々な困った状況にぶち当たりました。そこで、どのように対応をしてきたのか、システム開発を請け負うベンダーとしての立場で、まとめてみます。
GAS はサポート対象外であることを知っておく
まず知っておくべきことは、GAS はサポートを受けられないことです。これは、有償の G Suite 契約者でも受けられません。私も何度か困ったときにGoogleに問い合わせているのですが、答えは「UI から再現できないことはサポート外です」です。以前、CalendarのAPI（CalndarApp）で特定のシチュエーションで通知メールが飛ばない挙動があったのですが、UI から再現できず、サポートを受けることはできませんでした。基本的にGASのAPIでできることはUIでもできる（一部UIでのみ可能なことはある）のですが、サポートを受けられるかどうかは無関係です。
これに関しては、Googleに文句を言ってもどうしようもありません。それに納得してGASを利用する必要がありますし、お客様に対しても、それを納得してご利用いただく必要があります（私たちは、請負開発の契約書で明記しています）。
情報収集（＆提供）は Google の IssueTracker で
Google 側のバグかな？と思ったときの情報ソースとしては、Google Issue Tracker が一番です。GAS に限らず様々なバグ報告や要望が集まっているので、似たようなケースが見つけられることが多いです。
私が体験した中で一番大きかったのは、GAS のJDBCのバグで、「コネクションタイムアウトが常に0になってしまうことで、ほとんどのSQLがエラーになってしまう」問題です。
これも、今だから上記が原因だとわかるわけですが、ユーザーに表示されるエラーメッセージは直感的でなく、まったく見当が付きません。私のところにも複数のお客様から問い合わせがあったのですが、ワークアラウンドすら見つからず、とても苦労した記憶があります。
上記のような派手な問題は、世界中のユーザーからの報告や問い合わせ、改修要望が相次ぐため、比較的見つけやすいです。類似のIssueを見つけたら、手持ちの情報を補足するか、「同じ現象が起きてる！ASAPで対応して！」などのコメントを送りましょう。
お客様へは事実ベースでこまめに報告を
GAS内部で発生した問題は「放っておけばいつか修正される」「こちらでできることが少ない」とはいえ、お客様に対しては事実をこまめに報告すべきです。上記JDBCの問題は解決するのにほぼ1日必要でしたが、その間にお客様には複数回の状況報告を行いました。報告内容も、Issue Tracker から引用します。
- 問題が発生したと思われる日時（報告が上がり始めた日時）
- Google からそれを認識した日時（Google のエンジニアがIssue Tracker 状で問題を認めた日時）
- 問題解決に向けてステータスが更新された日時と内容
ちなみに、以下が実際の報告内容の一部です。
事実ベースであることが肝要です。こちらで対応できることが少ない分、正確な情報を出しつつ、その間に運用回避策を検討します。
βサービスは極力本番では使わない
ここまでは、ある意味Google内部で発生したバグが原因の突発的な事象です。一方、サービス終了に伴う、「予期できるシステム停止」もあります。Google のサービスやAPIは割とスパっと終了します。もちろん猶予期間はありますが、システムで利用していた場合は、それに合わせた改修が必要となります。
例えば、FusionTables 。これは結局βのまま終了が決定し、もうすぐ利用できなくなります。 Realtime API は正式リリースされましたが終了しました。大きなところではGoogle+も終了しますね。
もちろん、サービスの終了は予想できるものではないのですが、せめてβサービスの本番利用は避けるなどの手堅さは持ちましょう。以下、G Suite の最新状況ヘルプページが役に立つことも多いので、こまめにチェックします。
まとめ
当たり前のことなのですが、情報をこまめに収集し、無理な使い方はしない、ということですね。あと、Google Issue Tracker の使い方に慣れておくと良いでしょう（Google へのログインが必要です）。
いろいろ怖そうなこと書きましたが、基本的なサービスのAPIは安定していますし、大きなインパクトのあるサービス終了も1年程度前から予告が入ります。お客様ともGASのメリット・デメリットを共有し、賢く便利に利用していきましょう。
GoogleAppsScript でのシステム構築 ～ 事例とハマりどころ
この5年、一番たくさん書いたのはGoogle Apps Script（GAS)です。一人で使う小さな仕組みから何千人が利用する本格的なシステムまで、たくさん開発しました。Access や ColdFusion からの移行とか、とんでもなく大きなサイズのExcelからスプレッドシートへの移行とか。
GASはネットで手に入る情報も比較的多く、個人でプログラミングをする分には困りません。ただ、本格的なシステムを組もうとすると、ハマりどころも多く、苦戦している人も多いかと思います。
2017年の G Suite ユーザー会で発表した時の資料なのですが、一部見直してアップしました。事例をもとに、典型的なアーキテクチャというかシステムの型を紹介しつつ、それぞれのメリットとデメリット（ハマりどころや限界）をまとめています。
何かお役に立てれば幸いです。GAS （G Suite）関連のご相談も、今はAgile Studio Fukui で受け付けておりますのでどうぞ。
受託開発ビジネスをスクラムで回す
スクラムは要は改善フレームワークであり適用範囲が広く、それを学びプロジェクトで実践するうちに、ソフトウェアの開発だけでなく、部署や会社などの組織的活動にも適用したくなるかと思います。
もちろん、私もその一人で、今日は自分の取り組んでいる活動をご紹介させてします。
活動をサービスとして考える
私は、アジャイルスタジオ福井（ASF）のディレクターという肩書ですが、やっていることはプロダクトオーナー（PO）だと自覚しています。スタジオを立ち上げるまでには、次のようなことをやってきました。
- 名前を決めた（構想段階では「福井アジャイル開発センター」と呼ばれていました）
- 部屋のコンセプトを決めた（「和洋折衷」をコンセプトとした部屋）
- サービスのビジョンやコアバリューを決めた
- 顧客（ターゲット）を想定し、サービスの具体内容（リモートでのアジャイル・クラウド開発）を決めた
- 「ディレクター」という呼び名を決めた（「スタジオ」だから「ディレクター」だよね、という安直さなんですけども）
要は「アジャイルスタジオでの開発サービス」のPOとして、「なぜと何」に注力しているわけです。逆に、働きやすさに直結する机やいすやモニターなどを選ぶことはメンバーの仕事ですし、ビジョンやサービス内容をまとめたパンフレットやランディングページの実装も、それが得意なメンバーや外部の業者さんに任せます。
会社と事業部をステークホルダーとして考える
実は、アジャイルスタジオ福井は組織ではなく、そこに「配属される」ものではありません。シンプルに、「リモートアジャイル開発の作業場所がASFである」にすぎず、私にメンバーを選ぶ権限はありません。メンバーはほぼ全員がITサービス事業部に所属していて、それゆえ、ASFでのビジネスの売り上げも経費もITサービス事業部※につきます。
※ちなみに、私もITサービス事業部の一員であり、ASF立ち上げのタイミングでエンジニア職にシフトしています。それまでは部長という肩書の管理職でした。ASFのPOという役割がこなせているのは、諸々の管理業務が減ったことも大きいです。
このように、ASFは「ITサービス事業部の事業」という位置づけなのですが、根本には、「ビジネスを加速するソフトウェアづくりを、お客様と一緒にアジャイルチームを作ってやりたい。福井でやりたい。」という全社（社長）ミッションがあります。
さらには、「福井でのリモートアジャイル開発」というモデルを浸透させることによって、当社で働きたいというエンジニアを増やすという狙いもあるので、POとしては「働きやすさの実現とアピール」も優先度の高いバックログアイテムになっているのです※。
※ すでに満杯になっているのですが、2月24日に
をASFで開催します。
活動はスプリントで改善
「アジャイルスタジオ福井という部屋」のキャパは16名で、ありがたいことに現時点ではすべて埋まっている状況です。ただし、アジャイル開発に対応できるチームはASF以外にももちろんあり、「リモートアジャイル開発サービスとしてのASF」をもっと広めるためにマーケティング活動をスクラムチームで継続中で、これが今一番力を入れている活動ですね。
このチームのメンバーは、私とマーケティング・営業担当と社長で、私はPOとして重要なステークホルダーである社長の思いをくみ取りつつ、スプリントゴールや優先度を決めています。
スプリントは1週間で、デジタルなカンバンツールを利用しながら、イベントやプロモーションといったタスクにサインアップし、集まって成果をレビューし改善し、というスクラムチームの動きです。
あと、チームの営業担当に、私から直接指示も評価もできないのがミソでだと思っています。彼も私と同じITサービス事業部なのですが、私はあくまでPOでありエンジニアであり、彼の上司ではないのです。彼の個人ミッションや目標は上司である事業部長から与えられていて、それをどう実現するかは彼のマターであり、私は優先度を与えたりアドバイスすることはあれ、直接的に指示することはありません。
いろんな仕事を組み合わせて相乗効果を出す
他にも、見学への対応や外部発信、採用への協力や事業部所属のエンジニアとしての役割などASFのPO役以外の仕事もありますが、今のところ良い相乗効果が出ていると考えています。これらについても紹介したいところなのですが、、長くなってきたのでまたの機会に。
『管理ゼロで成果はあがる』に刺激を受けて4年ぶりにブログを書く
先日福井で、『管理ゼロで成果はあがる』を出版されたばかりの倉貫さんと久しぶりにお会いすることができました。
「働く時間も場所もしばりなし」「休暇は取り放題」「経費は承認なく使える」「上司なし・決裁なし」「売上目標・ノルマなし」など、刺激的なワードが飛び交う本なのですが、これらを実現するためのノウハウ集として読んでも効果はないでしょう。
本書は「生産的に働く」「自律的に働く」「独創的に働く」の3部構成になっていて、これらは、武道やアジャイル開発の文脈でいうところの「守・破・離」にそれぞれ相当してます。
なので、まずは生産的に働くことができるチームとそれを支える仕組み作りのために、第1部に書かれている内容が自分の職場に比べてどうか、自分事として考えるところからスタートです。
おそらく、アジャイル開発に正しく取り組めている職場であれば、納得感をもってうなずける考えや仕組みが多いかと思いますが、「本当に生産的に働くためにあらゆることを自分事で取り組めているか？」と自問自答すれば、まだまだ「非効率だと分かっているけど面倒なので放っておいてること」があることが気が付きます。
私も、自分の仕事とか人に任せる作業を、「置きに行く」ことがあるんですよね。成果にフォーカスしきれない時や改善ループ回せない時、いまだにあります…。
ちなみに、前回のブログは、2014年に倉貫さんが最初に書かれた本の書評でした。4年以上も情報発信していなかったわけです。
当時私は、納品のない受託開発も参考にしながら、新しい受託開発ビジネスを立ち上げようとしていて、その後、G Suiteをベースとした改善型開発サービスであるKAIZENクラウド や、Excel や Access を G Suite に引っ越しするサービスである、HIKKOSHIクラウド を立ち上げました。かれこれ4年になりますが、トータルでリピート含め約70件のお仕事をさせていただいております。
今は、これら G Suite ベースの開発も包含したリモートアジャイル開発サービスを、アジャイルスタジオ福井という場所で展開しております（あと、 Scrumのトレーナー としても活動中）。
本書によると、倉貫さんは2009年から300本以上もブログで情報発信を続けているとのことで、大いに刺激を受けました。私も今後、この4年間で得た学びや、自分の思いを発信していきますので、あらためて、よろしくお願いします。
書評。『「納品」をなくせばうまくいく』を読んで身を引き締める
「自分たちの持つ技術で、お客様に価値を提供し続ける」
このお題目を達成するのは様々な理由で実に難しく、それはSEになって20年の私も大いに実感するところです。それを「納品のない受託開発」という形で成し遂げようとしているソニックガーデンの倉貫さんが、ご自身のビジョン・戦略・ビジネスモデル・事例・現在のIT業界の課題までひっくるめ、読みやすくまとめてくれた本が、『「納品」をなくせばうまくいく』です。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
私はここ一年新しい受託開発モデルの構築をミッションとしており、その過程で「納品のない受託開発」も研究させていただいております（おかげで社内の誰よりも「納品のない受託開発」について語ることができます）。
研究の結果たどり着いた結論は、「納品のない受託開発」というビジネスは、形だけ、一部分だけ真似ることはできないということ。恐らく「納品のない受託開発」の劣化コピーは、誰にとってもハッピーでないビジネスになります。
倉貫さんたちがすごいのは、大手と競合しないマーケットとビジネスモデル、質の高いエンジニアを集め育てることができるカルチャー、会社を小さく保ったままミームを拡散できるギルドというシステム、これらが精巧に組み合わさった合理的かつ、パッションにあふれるシステムを作り上げたことです。
劣化コピー禁止とはいえ、もちろん、参考になる考え方は盛りだくさんです。
まず、第5章2節の「納品のない受託開発を支える技術戦略」は、受託開発をはじめ開発能力をビジネスの源泉にする組織のマネージャに読んでいただきたいです。低コスト・短納期化する案件をこなすには、ここに書かれているような戦略的思考が必要です。
次に、第6章の「これまでの受託開発は別の業種」という一節は、受託開発ビジネスの経営者の方に響くと思います。戦略は、どうしても、お客様や事業ユニットとの関係、会社の中での位置づけ、全社経費ベースのコスト試算など、既存の何かの「積み上げ」を考慮せざるを得ないものですが、倉貫さんたちは、「アジャイル開発をビジネスに」というシンプルな理念を実現するために会社を作ってしまったようなものなのです。
それに至るまでの経緯詳細は、ぜひ本書を読んでいただきたいのですが、理念を持ち、それを実現するためには、何かを壊したり闘って勝ち取る必要があることを思い知らされます。
開発者の方は「エンジニアにとっての幸福な働き方は」の一節に共感を覚えるのではないでしょうか。「顧客とそのビジネスに寄り添う」ことに嬉しさを感じる方なら、このような職場で働きたいと考えるでしょう。
でも、本書にも書かれているのですが、そこは楽しくて充実はしてるけど、決して楽なわけではありません。常に最新の技術を追い求め、自律的でモラルを持った働き方と人生観が必要です。本物のエンジニアじゃないとついていけない世界かもしれない・・・。
おっと、私にもすっかり「納品のない受託開発」のミームが浸透しているようです。本書から学んだことをしっかりと自分の中で咀嚼し、劣化コピーではなく、「自分たちの強みを生かした受託開発」を作り上げていきます。
テンプレートに従うばっかじゃ面白くないよ
息子の通う中学校に提出する「新中学3年生に向けた保護者からのメッセージ」アンケート回答です。クラス全員の「啓発録」を読んだ感想なんですが、「なんかみんな行儀良すぎるなぁ」と思ったので正直に書きました。いつか息子が見つけることを期待してWebに放ちます。
それぞれに自分の良い点・足りない点を見つめなおし、目標としてはっきりと宣言することができたのは素晴らしいですね。「目標を持つ」「努力する」「自分の考えを持つ」、どれも大切なことであり、これから君たちが大人になっていく中で意識する必要があることです。
ただ、1点だけ、少しだけ残念に思ったのは、みなさんの個性の発揮をもう少し見たかった。
「目標を3つ挙げる」などという型（テンプレートといいます）に従うのはうまく生きていくためには重要です。
でも、みなさんはまだ若く、個性はテンプレートから大いにあふれ出すくらいでちょうど良いのです。
みなさんの「本当にやりたいこと」もテンプレートからは見つかりません。自分の頭で考え・行動し・間違っていたら直す。そして友達とたくさん語り合うことで成長し、自分の夢を見つけたり育てられるようになってくださいね。私たち親は、時にはテンプレートを与え道を作ることもしますが、子供が自ら選んだ道を見れるのが本当は一番うれしいのです。
といいつつ、この文章自体がある意味テンプレートにはまってるよなぁ。
私のガラパゴス体験
今をさかのぼること十数年前。私は主に金融機関のお客様の仕事を行う部署におり、当時黎明期であったJavaやWebについて大いに関心を持ち始めていたころのことであります。
当時の標準的なブラウザといえばNetscape Communicator4.01とInternet Explorer3.02。いずれもJava VMを搭載し、誰しもAppletで画像やボタンをブラウザに張り付けて遊んでおりました。
あのころは「イントラネット」ビジネスが盛んで、それまでのVBによるクライアント・サーバーアプリを、Webアプリに置き換える案件が数多くあり、私もそのような案件に従事することになります。
今でこそHTML（と、CSSとJavaScript）で、おおよそどのようなUI、UXも実現できますが、当時はJavaScriptなど画面にデコレーションを加えたり、サーバーにPostすることなく電卓を実現するくらいのものでした。
そのような状況で、当社はJava Applet活用した業務アプリ開発環境（「E-INTRA」といいました）を独自に開発することになります。売り文句は「通常のHTMLでは実現ができ ないリッチな業務画面が実現できますよ」です。AppletからFrameを起こし、そこにButtonをAddしたりして、VBっぽい画面遷移を実現するのであります。
とはいえ、このような売り文句は実は後からついてきたものであり、開発側としてはAppletで何かしてみたい！というモチベーションが強かったこ とは否定できません。一般向けに販売するものではありませんでしが、受託開発案件における生産性向上ツールとして、某メガバンク（当時はメガバンクという言葉はなかった気がしますが）における、「初の全47都道府県の支社に展開するイントラネットアプリ」を開発する機会にも恵まれ、エンジニアとしては燃える日々でした。
このE-INTRAについてもう少しだけ書かせてもらいますと、、
「開発者はJava言語を書かずにApplet＋Frameによるアプリを開発可能。DBとも連携できるよ」というコンセプトであり、当初はユー ザー操作Eventの発火をビジュアルに接続するシンプルなものでした。ただ、時を得て実際の開発に投入されると「IfやWhileが欲しい」という要望 が出てくるにいたり、結局は「E言語」という言語が生まれ、しまいには「Java VM上で動作するインタープリタ言語」というごっついものになりました。
私はこのE言語の世界で一番の使い手であり、一番のユーザーとしてE-INTRAのプロダクトオーナー的な役割を担うことになりました。E- INTRAの開発チームに対し改善要求を投げ議論し、それをテストし実戦投入することを繰り返していたわけです。機能は洗練されつつどんどんふくらみ、しまいには「E言語からJavaのメソッドが呼べる」というよくわからないことに。
でも、当時はいいものを作った気分で高揚してたし、お客さんも喜んでくれました。（でも、今思えば、これってE-INTRAやAppletという技術に対してじゃなくて、私たちの実現したシステム全体のサービスレベルに対する評価なんですよね）
いまにして思えば、なんというガラパゴスです。イントラネットという比較的閉じたビジネス・技術領域で最適化を繰り返したため、特定のお客様の特定の環境（ブラウザやVM）にマッチする機能が生まれては消えました。当然ながら、E言語という完全に標準でないプログラミング言語に習熟した開発者を育ててもまったくつぶしは効きません。
と、冷静にふりかえればビジネスや技術の戦略的にはまったくの失敗でしょう。今は標準の技術に習熟した開発者を目指すべきだし、そのような開発者を育てて、彼らの力でビジネスし、逆に技術に恩返しできる組織でないとダメだと思う。
でもね、私は当時のことを今でもよい経験として思い出せるし、超ガラパゴスな言語や開発環境だったけど後悔はしてません。プロダクトオーナー的立場といいながら、技術的には開発環境や言語をどうやって作るか、というアーキテクチャ的な勉強にもなったし、実際のお客様の環境に適用するにあたっては、いろんなトラブルに出会うことで経験値詰めましたし。
そして何より、楽しかったなぁ。。
今回なんでこんなオチのない昔話をしたかといえば、長年弊社で一線のアークテクト・技術者として働き、私たち開発者から慕われたTさん（もちろん、 E-INTRAの生みの親）が先日定年退職されたからなのです。Tさん、お疲れ様でした。そして、育ててくださり、ありがとうございます。
