2020年をふりかえる

この記事はあじゃてくアドベントカレンダーの15日目です。

早いもので今年も終わりに差し掛かっています。思えば去年の今頃はRSGT2020の登壇前でひぃひぃ言ってました。それぐらい考えて準備したし、実際に参加してみて、本当に得るものが大きく、2020年はいいスタート切れた!ぐらいに思ってました。

 

happyman.hatenablog.jp

 その後コロナ禍に突入してから、色々なことが変わりました。在宅勤務が日常になるという仕事・生活環境面もそうですし、様々なイベントがオンライン化することによって、むしろ参加する機会が増えたことで、様々なコミュニティや会社の方との繋がりが増えたり、強まったり。

 

happyman.hatenablog.jp

久しぶりに市谷さんと話ができて楽しかった。すごくたくさんの方に参加いただきオンラインイベントの可能性にびっくり。

 
content.members.co.jp

多分初めてZoomウェビナーで話す機会をいただいたメンバーズさんのウェビナー。おかげさまでオンラインで話すコツが掴めた気がします。

 

happyman.hatenablog.jp

もはや伝説となりつつあるイベント。同僚とプロポーザル書いて通って話したのはもちろんですが、オブラブのメンバーであることを久々に名乗れたのが嬉しかった。

 

www.agile-studio.jp

パネルもとても知的で刺激を受けました。このように今まであまり接点のないコミュニティでお話できたのもオンラインならではかも。

 

その中でも特に、あじゃてく(ひらがな表記が正しいのだろうか・・)コミュニティとの関わりは印象的です。最初のイベント(Episode0)ではゴールドスポンサーを担わせていただき、来年1月に開催されるイベント(Episode1)でも、引き続きご協力させていただくことになりました(オーガナイザーの皆さんには色々とご縁をいただき感謝です。引き続きよろしくお願いします)。

オンラインイベントでのスポンサーとしてのふるまいの難しさ(直接の声掛けできないので集客すごく工夫しないとダメ)を実感したりと、このあたりはもうしばらくノウハウが必要かな、と思っていて、来年の継続課題になりそうです。

※ 12月17日に開催される、「Agile Tech EXPO mini #2」ではノーコードとアジャイルについてゆるーくお話させていただくので、よろしければご参加ください!

agiletechexpo.connpass.com

 

そして忘れちゃいけない Agile Japan 。こちらはお客様とAgile Studioメンバーが一緒に登壇し、共創スタイルのリモートアジャイルの話をしてくれました。とてもたくさんの方に視聴いただき、自分のことのように嬉しかった!

www.agile-studio.jp

 

そうそう、日本中の「アジャイル基地」の方々とオンラインで集まり、アジャイル基地をつくるパタン言語をつくったことも良い思い出です。初めてライターズワークショップに参加してワクワクしてました。

anagileway.com

 

 他にも、Agile Studio Fukui が Agile Studio になって毎月のイベントを完全にオンライン化したり、メンバーのリモートアジャイルのノウハウを編集して配布したり(たくさんの方に読んでいただきました)、動画編集して YouTubeで配信したりと、このような状況でなかったらやってないだろうってことにも果敢にチャレンジできたかな、と思ってます(動画編集楽しいけどすごく大変ってこと身をもって知ることができた)。

www.agile-studio.jp

あー、こうやって1年をふりかえるのは良いですね。大変なこともありましたが、どれも楽しく、自分の身になっていることを実感します。そして何より、ほとんどの出来事が、人とのご縁から生まれているんだなぁ、ってこと。巻き込んでくれたり紹介してくれたり誘ってくれたりなどそんなことが大半です。ありがたいことです。

来年がどんな年になるかはわかりませんが、気持ちは若く保ち、めげずに色々トライし、さらにはいろんな方を巻き込んでいきたいと思いますので、今後ともよろしくお願いいたします。

 

60分でAppSheetを理解する

AppSheetの基本を理解できる資料を作りました。結構大きくなってしまったので、ダウンロードしてもらったほうが良いかもしれません。

www.slideshare.net

Google Cloud への仲間入りが発表されてからあまり大きな動きがなかったノーコードツールの AppSheet ですが、この夏以降、デザインが Google 風になったり、Google Workspace (旧 G Suite)への統合が実際に進んだりと、少しずつ面白くなってきたかな、という雰囲気です。

ただ、Twitter の #AppSheet の流れもそれほどでもなく、日本ではまだ模様眺めなのかしら?という感覚もあります。

で、もっと盛り上がるといいな、そのためには、企業内の AppSheet に関心はあるけどまだ試してない人や、ちょっと触ったけど実利用にはいたってない人に向けて、 AppSheeの基本モデルや、実際に組織で使うにあたっての注意点を手短に理解してもらえる読み物があると良いとのではと考えました。網羅的ではありませんが、現時点での最新情報に基づいてます。「これさえ読んどけば、AppSheetのことはだいたい上司や同僚に説明できる」ぐらいにはなってるかと。

やはりどちらかといえば、ソフトウェア開発の経験者寄りの視点になっています。ステップバイステップの丁寧な説明は、高橋さんの連載が素晴らしいので、こちらと合わせて読んでもらえるのも良いかと思います。

長らく Google Apps Script で業務効率化のためのシステムを開発してきた経験者からしても、AppSheet の効率性はものすごく魅力的です。バーコードやOCRの扱いもノーコードなので、お客さんの困りごとがすぐに解決できます。DXやアジャイル開発に絡めると、PoCやユーザーと対話しながらのプロトタイピングにはもってこいだと思いますし、いろんな活用法を探っていけたらと。

追記:2021年8月30日

Automation に対応したアップデート版を作りました。今後はこちらをどうぞ。

  

happyman.hatenablog.jp

 

 

Spreadsheet#getUrl の戻り値の仕様がここ最近変わったらしい件

スプレッドシートのURLを取得したいケースはそれなりにあって、PDFを出力するために、スプレッドシートのURLに export?format=pdf を追加してURLFetch することをよくやっていました。例えば次のような感じです。

https://docs.google.com/spreadsheets/d/XXXXXXXX/export?format=pdf

スプレッドシートのURLは自分で組み立てても良いのですが、せっかく専用のメソッドがあるのでそれを使いたく、Spreadsheet#getUrl を利用しました。ただドキュメントには「URLを返す」としかないので、具体的にどのようなURLを返すのか試したところ、次のように末尾に edit をつけて返ってくることがわかりました。

https://docs.google.com/spreadsheets/d/XXXXXXXX/edit

そのため、かれこれ5年くらい、末尾のeditを取り除く作り(/edit$/をreplace)になっていたのですが、どうも、ここ数日でgetUrlの仕様が変更されてるようです(※)。
getUrlの戻りを見てみると、次のように、ouid と urlBuilderDomain というパラメータが付与されてます。パラメータをキーワードに検索してみたのですがまったく情報はなく、正直よくわかりません。

https://docs.google.com/spreadsheets/d/XXXXXXXX/edit?ouid=999999999999&urlBuilderDomain=esm.co.jp

(注:ouidの値は置き換えています)

この変更が恒久的なものか一時的なものかはわかりませんが、ともかく、この変更に合わせた修正を余儀なくされました。仕様に明記されてない戻り値に依存するのではなく、自前でURLを組み立てるほうが良かったですね。

※ 現時点で私の管理する3つのドメインでの報告がありましたが、すべての環境でこの変更が発生しているとは限りませんし、元に戻る可能性もあります。ちなみに、G Suite でなく個人(Gmail)環境だと、このようなパラメータは付与されていないようです。

※ 追記:2020年8月20日 Google Form でも同様の現象が発生している模様。
google apps script - Issue with formResponse.getEditResponseUrl() not returning a working url - Stack Overflow


 

Scrum Fest Osaka 2020 で何度も「うっ」となっていた話

つい先ごろまで、新型コロナの影響でオンライン開催となった Scrum Fest Osaka に参加していました。500名以上の参加者がDiscordとZoomで繋がった、おそらく史上類に見ない形のオンラインカンファレンスです。

登壇者として軽く「うっ」

私はもともと、同僚と一緒に登壇する予定でした。ここ1年で技術転換しアジャイルマインドを身に着けた彼にとって、自分の体験をコミュニティの場で話すことは初めてであり、とても楽しみにしていました。

それゆえ、オンラインへの切り替えに際しては、軽く「うっ」と思ったことを白状しておきます。やはり、リアルに登壇して、あの緊張感を伴う高揚感を味わって欲しかったし、(当時は)オンラインのノリもよくわからなかったし。

※(初日から参加された方にはすぐに伝わるかと思いますが)「うっ」は、初日の基調講演で永瀬さんが送り出したキーワードです。「うっ」と思ったことに取り組むことで成長を促す。コンフォートゾーンを抜け出すことが大事。内容といい、パッションといい、Zoomの背景で語るプレゼンスタイルといい、本当に素晴らしい講演でした。

トラックオーナーとして少し「うっ」

実はもう一つ「うっ」と思ったことがあります。例年通りの開催であれば、当日私と同僚で大阪に行って時間になったら登壇して話をすればよいのですが、今回は全く違いました。

Scrum Fest Osaka 2020は最初から始まっていて、登壇者は、ずっと関わり続けることができました。逆に言えば、自分たちの話す場所を自分たちで選んだり作っていく必要があるということ。これは面白いけど、結構な「うっ」ポイントです。

私も最初は別の縁があるコミュニティのトラックで登壇させてもらおうと相談したのですが、すでに埋まっているとのこと。どうしたもんかなぁ、と思っていたら、「福井トラックが生まれますね、きっと」との川口さんの一言が。

なるほど、ここはそういう世界なのね、と理解した瞬間でした。

f:id:HappymanOkajima:20200627194047p:plain

どうしたもんかと少し悩んだのですが、結局は福井ではなく「オブラブ」トラックを作ることを選びました。

古豪オブラブとして「うっ?」

オブラブオブジェクト倶楽部。今は正式名称がオブラブ)は、老舗の技術コミュニティで、オブジェクト指向アジャイルなどを中心テーマに、十数年以上活動しています。とはいえ、最後に大きなイベントが行われたのは2011年の7月で、表現が適切かどうかはわかりませんが、私は「古豪」という冠を付けたくなります。長く業界にいらっしゃる方は、オブラブと聞くと懐かしさが先に立ってしまうのではないでしょうか?

そんなオブラブに、少しだけ刺激を与えてみたくもあり、木下さんや天野さん、もちろん平鍋さんに持ち掛けて、今回オブラブトラックとして参戦することになったのです。みんな楽しんで乗ってくれましたが、もしかすると「うっ?」と思っていたのかしれません。

私たちの以外で3つあったセッションは、それぞれの持ち味が出て、私も素で楽しんでました(内容詳細はきっと本人達がブログに書いてくれるはず)。特に平鍋さんの話はオブラブやアジャイルの歴史も踏まえつつ、最近のリモートワークの状況まで盛り込まれており、一言一言に、チャットがとても活発に反応していたのが印象的です。

初参加スタッフの初めての「うっ」

もう一人、多分一番「うっ」とした人がいると考えています。二日目の最後、各トラックから3分で内容を振り返るコーナーがあったのですが、そこを任せた彼です。

オブラブトラックとして参加することを決めた後、社内からスタッフを募りました。そこで唯一手を挙げたのが彼で、オンラインイベントの運営について興味があるとのこと、多分今回は想像と違うぞー、と思いつつ、「やる気があるのはいいね!」とのことで、巻き込みました。

コミュニティイベントにはあまり参加したことがないとのことで、あのノリの中で、数百人とつながったZoomで、3分間とはいえ話をするのは、結構「うっ」だったんじゃないかな?(ありがとう、良いまとめでした)。

さらなる未知の「うっ」を求めて

 素晴らしい経験をもたらしてくれた運営スタッフの皆さん、オブラブトラックに来てくださった皆さん、他コミュニティの皆さん、ありがとうございました。今回はトラックオーナーかつ登壇者だったこともあり、ずっとオブラブから離れなかったのですが、これから他のトラックでの録画を見ることで、新しい刺激を受けたいと思います。

 オブラブスタッフの皆さんも、急な提案に乗ってくれてありがとうございます。次回もオンラインでの開催とのことです。さらなる「うっ」を求めて、再度参戦にチャレンジすることを宣言しておきます(笑)。

最後になりますが、私と同僚による発表スライドです。何度もの「うっ!」という思いを乗り越えて、アジャイルマインドが「降ってきた」エンジニアのストーリーです。発表の後も、彼にDiscordで質問してくださる方もいらっしゃいました。やっぱフィードバックもらえるの嬉しいですよね。

 そしてもう一つ嬉しいことが。彼が大きく成長するきっかけとなったお仕事で共創したお客様が、今回(お金を払って)参加してくださいました。これって本当に素晴らしいとです。聞くところによると、(移動を伴わない)オンラインだから参加できたとのことで、こんなところでもオンラインイベントのメリットが実感できました。 

www.slideshare.net

 

 

コロナとリモートアジャイルとDXと摩擦

昨晩、Zoom使ったオンラインのDevLOVEイベントで、久々に市谷さんと木下さんと語りました。テーマ(キーワード)は「アフターコロナ・リモートアジャイル・DX」で、今最もホットな話題かもしれません。そのせいもあって、たくさんの方に参加いただきました。ありがとうございます。

対談なので結論を出すようなものではなかったのですが、市谷さんのまとめは、私も木下さんもその場で膝を打ちました。「分断」に注目するのが市谷さんらしい。

note.com

 さて、このエントリは私が昨日自己紹介で話をした内容を補足を交えて記録しておこうという思いから書いています。

自己紹介は、3人が共通の質問に答える形でのポジショントークでした。

f:id:HappymanOkajima:20200526135845p:plain

リモートアジャイルどうやってますか?

まずは「リモートアジャイルをどうやってやってますか?」

緊急事態宣言を機に、私の勤務先でもほぼ全てのアジャイルプロジェクトがリモートに切り替わりました。基本的にはうまく切り替えできていて、壁(ホワイトボード)をmiroに、コミュニケーション(雑談専用)は、Discord に、など各チームのメンバーがそれぞれ色々試しながら、現場にフィットさせています。(このあたりはYouTubeチャンネルにまとめてあります(余談ですが、自分で動画編集してYouTubeデビューなんてこともコロナの影響ですね)。

f:id:HappymanOkajima:20200526135932p:plain

ノウハウ伝えるだけでは足りない

ノウハウはそれなりに蓄積され、今でも小さな改善を繰り返し、それを皆様に共有できるようにしているのですが、やはり、これだけで全てを語りつくせないという思いはあります。

今回、真ん中にWhy(ASFを作りたい!というビジョンの根本である平鍋さん)を置くゴールデンサークルを描いたのは、現在リモートアジャイルでも成果を出せているのは、ビジョンに基づいて日々活動する現場のメンバーのHow(ノウハウ・知恵)があり、それを「リモートアジャイルサービス」というWhatにして表現できているからなんだろう、という思いからです。

それぞれ大事なんですが、やっぱ、Whyって必要だよなぁ、と。そのWhyを形にしたAgile Studio Fukui では今は誰も働けてないのですが、そこに込められた思いや、その現場でのふるまいの記憶が、リモートに切り替わっても理想形として影響を与えている(まるでプラトンイデアのように)。

 

f:id:HappymanOkajima:20200526140026p:plain

アフターコロナでどこが変わりそうですか?

次に「アフターコロナでどこが変わりそうですか?」という問いです。

これも多様な回答が生まれる問いかけになっているのですが、自身の経験と役割から、組織論的な回答にしています。私自身コロナモードに入ってから、社外の人達(コミュニティ)との会話や共同作業が増えました。もちろん、たまかまかもしれないし、全ての人がそうであるとは言いませんが、オフィスという定期的な集合場所がなくなると、個人はそれぞれで繋がっていく機会というか欲求が増えるのでは?という感覚はあります。

組織内でもそれは発生すると考えると、実際に組織階層が解体されることはなくても、社内コミュニティのようなソフトな人的ネットワークが強まり、そのような仕事スタイルが是認されうるかと。

 

f:id:HappymanOkajima:20200526140102p:plain

DXはコロナの影響を受けてますか?

最後の質問は「DXはコロナの影響を受けていますか?」

いち受託ベンダーとして大局観で語ることはできないテーマなのですが、「DX推進担当」の視点から、中長期的に見たポジティブ要素について。

実際に事業会社さんの本気度が上がっているケースを見ていますし、ウェビナー等の機会に、参加される人も増えている実感があります。

今まで誰も経験したことのない状況に、世界中の人や企業が対応を迫られているわけですから、当然カオスだとは思います。ただ、各社各人それぞれ生き残りに向けた戦略が必要になり、それに本気を出さざるを得ない、という意味では動きが「読みやすい」のかな、という思いがありました。

DX、つまりデジタルによる抜本的な革新や業務の効率化の達成が、大半の組織や活動にとって、できたらいいな、ではなく、やらないと生き残れない、という目標に格上げされるイメージです。

ここで「摩擦」という言葉を選んだのは、「今はこのような状況だから○○を進めるべし」的な大義名分が作りやすく社内の抵抗が減る、というのがストレートな例えなのですが、それだけでなくて、対外的な状況も非常に広範囲で固定化されうる、つまり読みやすくなる、ところまであるのかな、という思いです。

これは、机上の戦争と実際の戦闘とを区別する概念であるクラウゼビッツの「摩擦」から借りてきています。

これ以上書くとぼろが出そうなのでここまでにしておきますが、それぞれの戦場=現場で、それぞれの指揮官が、DXというゴール(だけでなくて、状況をより良くするための改善や改革提案)実現に向けて、アクションしていきましょう、という思いです。

f:id:HappymanOkajima:20200526140202p:plain

「摩擦」は減っているかもよ

 最後に、このような機会をくれた市谷さんと木下さんに感謝です!対談はなかなか難しいですが、また、語りましょう。

 

App Makerで開発したアプリをAppSheetに移行する

AppSheetのガチ目検証第2弾は、Google App Maker(+Google Cloud SQL)で開発したアプリの移行です。今後あちこちでありそうなシナリオ「データベース(Cloud SQL)はそのまま使い続ける」+「アプリはAppSheetで完全に作りなす」を実際にやってみました。

今回作り直したアプリの仕様は次の通りで、前回と違って実際にスマートフォンでテストしています。

スマートフォンのカメラでバーコードを読み取り、データベースとマッチング。対象があれば、その商品の詳細を表示する。商品や商品分類などのデータは、別途専用の画面でメンテナンスできる(ただし、管理者のみデータの登録・変更・削除が可能)。

結論から言えば、半日程度の作業でアプリはかなりいい感じに生まれ変わり、Cloud SQLの利用もスムーズでした。

バーコードの読み取りはiPhoneで試したのですが、精度や速度が素晴らしいです。ついでにOCRやチャットへの投稿、手書き署名の入力なども試しています。もちろん、これらはCloud SQLがなくても手軽に試せるので、AppSheetでの開発に関心のある方はスライドを読んでみてください。 

www.slideshare.net

 今回の内容は前回の記事を前提知識にしているので、AppSheetの基本的な使い方や用語の説明などは割愛しています。基本的なところを知りたい方は、前回の記事にあるスライドを参考にしてください。

happyman.hatenablog.jp

AppSheetはサンプルだけでなく公式のドキュメントも充実しており、今回の検証もほとんどハマるところなく進められて良かったです。APIの呼び出しや逆にAppSheetをAPIとして呼び出すこともできるようで、もう少し深堀してみようかな、という気分です。 

AppSheetを使い倒してみた ~ GASで1週間かかったアプリはどの程度で開発できるのか

一部の人には衝撃的なニュースであった「Google App Maker の2021年1月終了」ですが、私もその一人です。実際にお客さま先で動いているし…。 

www.publickey1.jp

Google は移行先として先だって買収と Google Cloud への統合を発表した AppSheet を挙げていますが、実際のところ、どの程度使えるものなのでしょうか?

実はそれまで、私は AppSheet 完全ノーマークだったのですが、お客様のためにも自分のためにも、あるいは単についカッとなって、AppSheet をガチ目に検証してみました。

www.slideshare.net

方法は、「私が過去に開発したアプリ(GAS+スプレッドシートによるタブレット向けWebアプリ)を、AppSheet ならどの程度の期間、機能、使い勝手で実現できるのか、実際に作ってみる」です。

結論から言えば、GAS( Google Apps Script )版で1週間程度かかったものを、(習得期間含めて)2~3日程度で実現できました。ノーコードツールであり、もちろん、エンジニア向けとしては物足りなくありますが、アイディアとガッツがあるユーザーによる内製のためのツールとしてみれば良いものだと実感しています(少なくとも 同様の触れ込みであった App Maker よりは断然簡単に習得できます。正直 App Maker で作りこむとGASの塊になってしまいがちでした)。

ブログで書くと相当長文になってしまうので、スライドにまとめました。AppSheetが気になる方は、是非スライドを読んでみてください。

ちなみに私個人は、AppSheet のように「できることが限られてる開発環境」は嫌いじゃないです。むしろ創造性が高まる感じがして。きっと内製化したいと考えるエンドユーザーの方も、同じ気持ちなんじゃないかな、と想像できます。まさに「自由は不自由。不自由は自由」ですね。エンジニアと実際のユーザーでは、アプリ・システムを作るという行為についての、メンタルモデルが違うことを理解しないと、ですね。

追記(2020/10/27):

一から理解するためのエントリを書きました。GASのことを知らない方でも読みやすくなっています。  

happyman.hatenablog.jp

追記(2021/2/18):

Apigeeを経由したREST APIとの連携について、具体的な設定手順をまとめました。企業内で本格的にAppSheetを検討されている方の参考になれば。  

happyman.hatenablog.jp

 

追記(2021/3/8):

Google Apps Scriptの関数をApigeeを経由してAppSheetから利用する方法はこちらにあります。 

happyman.hatenablog.jp