迷走ITProですわな~

ITPro駆け出しによるブログ。ゆるくいきます

Google Cloud Next '19 in Tokyo にて、App Maker 活用事例を紹介

はじめに

またまたご無沙汰になってしまいました。
現在は、引き続き事業会社でコーポレートエンジニアをやってます。
最近は全社システムのグランドデザインや、セキュリティ方針策定をやっていて、中々ハードな日々を過ごしてますねぇ。

そんな中、先日7/30(水) - 8/1(木)に東京プリンスホテルおよびザ・プリンス パークタワー東京で開催された Google Cloud Next '19 in Tokyo に、カスタマースピーカーという形で登壇させて頂きましたので、その内容をこちらにも残しておこうと思い、久しぶりに記事をかかせて頂いた次第です。 セッション情報へのリンクはこちら

cloud.withgoogle.com

会場の雰囲気

東京タワーとの一枚

f:id:michaelowen628:20190806210419j:plain

登壇(背景と同色なのは偶然です)

f:id:michaelowen628:20190806210509j:plain

Google App Maker とは

一言で言うと...

G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール

f:id:michaelowen628:20190806210538p:plain

特徴

  • バックエンドのデータストアとして、RDB(Cloud SQL)が利用される
  • 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script
  • G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能
  • UIのカスタマイズの容易さと高い自由度

App Maker を使ったアプリケーション開発の流れ

1. データモデルの定義

GUIベースで、RDBメタデータを定義していきます。

モデル(テーブル)の主な設定項目

  • FIELDS:モデルのフィールド情報を定義
  • DATASOURCES:データベースでいうところのビューに近い概念の設定
  • RELATIONS:モデル間のリレーションを定義
  • EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義
  • SECURITY:モデルに対する権限を制御 f:id:michaelowen628:20190806210553p:plain

利用にあたってのPOINT

2. UI作成

ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。

利用にあたってのPOINT

3. ビジネスロジック記述

2種類のスクリプト(Client Script, Server Scriot)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要) * Client Script から、サーバーでスクリプトを実行したい場合 Javascript google.script.run f:id:michaelowen628:20190806210635p:plain

利用にあたってのPOINT

  • 外部公開できない
    • Google Apps Script で言うところの、doGet/doPost 関数のような Web APIは、App Maker のスクリプト内に作ることができないようになっています
    • 外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります(トランザクション処理等は複雑化します)
  • ローカルの開発環境と上手く連携できない
    • Google Apps Script で利用可能な clasp も、現時点で App Maker には対応していません
    • バージョン管理、デプロイ管理機能は開発コンソールに実装されています
  • 定期実行トリガーをGUIで設定できない
    • Google Apps Script Javascript ScriptApp.newTrigger('functionName').timeBased().at(date);

App Maker をこれから始める人向けの情報

まとめ

今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。

App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。

GA直後ということもあり、ユーザーコミュニティもまだまだこれからという感じなので、一緒に人柱になりながら App Maker 触っていこうという方、是非情報交換しましょう!

環境の変化

久しぶりの投稿

言い訳させてください(コラ)

  • 2回目の転職
  • 結婚
  • ・・・もうねーわ

はい、あんま大したことなかったですね、すいません。まぁ、ようは2回目の転職しました。

今の仕事

ざっくり転職の理由を言うと、もう何もかも自分でやりたくなったからですね。
受託のSIしかり、ITコンサルしかり、結局色んなシステム化ニーズがある会社の社内ITの方が圧倒的に色々できるだろうと。

ということで、急成長している(仕組み化が間に合っていない)医療×ITを中心にサービスを提供しているベンチャー企業のコーポレートITという立場で働かせて頂いています。
入社して半年経過しましたが、今までやったことをざっくりリストアップすると

  • エンタープライズWikiシステム(Confluence)をIaaS(AWS)を使って社内展開(インフラレイヤ、アプリケーションレイヤ共設計・構築)
  • オフィス移転に伴い、最大500人規模の社内LAN設計・構築(床下配線からRouter Config, 無線AP設定まで)
  • G Suite のメールフロー整備(社内利用ポリシー策定・現行運用からの移行)
  • コーポレート機能周辺の業務プロセス改善提案・実行(Slack、GAS, AWS周りで)
  • PCキッティングの自動化(Powershell)
  • その他、通常の問い合わせ対応とか、トラブル対応とか

てな感じで、SIerやらコンサルやらやってた時に社外から一杯感じてたモヤモヤを完全に忘れさせてくれるぐらいやりたい事・やれる事まみれです。
上記の内容も出せる限りはここにガンガン出していきたいと思います。(実行する方向に注力しすぎて書けてませんでしたが)

今後やりたいこと

JDLAのG検定取ってから、しばらくAI, ML周りのネタから離れていましたが、「AIの民主化」の波もありハードルも下がってますし、色々使えそうなところが社内にもあるので何か一つは取り組みたいと思っています。

SharePoint REST サービスによる Microsoft Flow の拡張と SPD 連携

SharePoint Online(SPO)にて、ちょっと複雑なワークフローを作る際に色々得るものがあったので備忘録を兼ねて。

SharePoint クライアントサイドAPIについて

SharePoint のクライアントサイドAPIの使い分けについては、この辺りを読めば良い感じですね。

んで、今回利用する REST API はこれ。

SharePoint におけるワークフローについて

SharePoint は長らく SharePoint Designer(SPD) でワークフローを作成するというのが主流でしたが、SPD の開発停止発表、Microsoft Flow の機能強化、さらには Microsoft 内外とのサービス連携が活性化してきた昨今、SPD でのワークフロー作成もそろそろ不要になる流れです。
まだ Microsoft Flow 側のアクションが心もとない感じではありますが、下記の記事にもあるように SharePoint REST サービス呼び出しで機能補間が可能です。

ということで、「もう SPD いらねーな」と思っていた矢先・・・( ^ω^)

※処理対象のリストに参照列が13個以上含まれていると、REST APIがこけて詰みます。

ということでメインテーマ

SPD - Microsoft Flow 連携による Lookup 閾値の回避(イベント編)

結論から言うと、SPDでイベントハンドルして必要な情報だけ Microsoft Flow 側に Http Callで渡すことで回避できました。
※今回はイベント時のエラーでしたが、Flowによる操作対象がLookup閾値を超えている場合、別の工夫が必要かと思われます。
詳しい方法は、以下が参考になるかと。

Microsoft Flow での実装のほうが、デバッグやエラーハンドリングも捗るので、できるだけ Flow に寄せていきたいですね。

  • SPD 側の実装イメージ

f:id:michaelowen628:20180424173755p:plain

MS系 Chatbot 触ってみた

久しぶりに

世間のAI(というか機械学習)ブームに乗っかって、統計学やらの基礎理論から復習してると中々ここに書くネタもなくおろそかになってしまいました。
Azure MLやらAzure ML Workbenchやらも触ったんですが、やっぱり競馬とか株とかに繋げないと遊んでても面白くないですね。
その辺はまた今度競馬で遊ぼうかと思いますが、今回はChatbotネタを。

Botって

広義には、以下のような意味ですね。(Wikipedia抜粋)

Bot(ボット)は、robot(ロボット)の短縮形・略称。転じて、コンピュータやインターネットの分野においては、作業を自動化するプログラムの総称。

最近、「Bot」と使うと自動的に「Chatbot」に変換されて、さらにいうとなんかAIと紐づいてどんな質問しても色々返してくれるみたいなことを想像される人が多いですが、AI使わないBotも普通にあります。
というか、AIの定義も非常に曖昧なので、何をしたらAIなのかも微妙なところですね。
という前置きはこの辺にして本題になりますが、Microsoftから現在提供されている Chatbot 関連のサービスを以下の資料にまとめてみました。

※最近、ブログにまとめるというよりスライドにまとめて話すことが多く・・・あんまり見るだけだと分かんないです(;'∀')

私個人としては、Chatbotをスマート化しまくってカスタマイズを進めると、普通のWeb Applicationでいいじゃんってなる気がしていて、 この資料の中にあるQnA Maker + Azure Bot Serviceぐらいの感覚がChatbotを実装する上で一番バランスいいかなって思ってます。

Chatbotが実際に活用されている有名な例もはっつけておきます。(NTT Docomoが提供しているRepl-AIがベースになっているようですが)

横浜市のゴミ分別

まぁ、とりあえずはFAQ Chatbotが無難なところですかね。

JICS 2017 振り返り

予め記載させて頂くと、この記事はあまり技術的な話ではないです。

これですね。参加してきました。
※仕事の都合でAM中のセッションは聞けず

nosurrender.jp

AD FSを入り口として「Digital Identity」領域にハマって1年半ぐらい経ちますがこの領域の動向は非常に興味深いです。 改めての部分もありますが、面白かった内容を掻いつまんで記載していきたいと思います。

1. SNS IDを活用したB2C向けのID基盤

元々エンタープライズ領域ではMicrosoftのADが非常に高いシェアを誇っていましたが、クラウド・モバイル活用により社員のIDの在り方を改めて考え直す必要が出てきています。 また大学などの教育機関でも多くの場合、所属する学生に対してなんらかのIDを払い出してサービスを提供している形態になってきています。
しかし、普段の生活においてエンドユーザーはそれらのIDを必要としません。FacebookやLINE、インターネットショッピングに組織から払い出されたIDは使えません
利便性だけを考えるとFacebookやLINEに登録しているID(個人ID)と組織のIDを完全に同一のものにするのが理想的ですが、現在の状況を考えるとまだまだ難しいです。(プライバシー面(個人側)や、セキュリティ面(組織側)で)
そこで、一歩引いて組織から払い出されるIDと個人が利用しているIDを紐づけることで利便性を向上させる動きが出てきています。(Azure AD B2C + LINE ID等)
組織間コラボレーションを目的としたAzure AD B2Bというサービスもあるように、IDはもはや一つの組織の中で閉じるものでは無くなってきています。
将来的には個人IDで、自分に必要なすべてのサービスを利用できる日が来るかもしれませんね。

2. トラストフレームワークの基本と今後の適用分野

この業界でトラストフレームワークと聞くと真っ先に思いつくのがPKIでしょうか。これも基本的には考え方が同じです。
IdPとRP/SPが乱立する中、それぞれのID Federation確立時にIdPやSP/RPをセキュリティ面等でアセスメントするのは非常に非効率です。
そこでそれらのIdPやSP/RPが信頼に足るかを第3者機関によるトラストを付与しようという働きかけですね。
既に欧米では始まっている動き(TFPAP等)ですが、日本ではまだ大学のネットワークで発足しているGakuNinぐらいようです。
学術認証フェデレーション 学認 GakuNin
政府としてもトラストリポジトリの重要性を認知させるため、試作段階ものがあるようです。(XMLベースで作成されており、システムからの読み取りも容易な形式)
https://trustlist.openlabs.go.jp/
これらの目的はあくまでも組織間ID Federationの活性化なので、これ自体が営利目的に運営されるのは避けてもらいたいですが、仕組みとしては経済の活性化に繋がる取り組みかと思います。

3. 基礎から OAuth と OpenID Connect

OAuthとOIDCのプロトコルの詳細セッションなので内容は下記参照。
デジタルID最新動向(1):「OAuth 2.0」の基本動作を知る (1/4) - @IT

以前から広く言われていることですが、OAuthは認可のプロトコルであり、認証に使うのはセキュリティ上危険であることを改めて強調されていました。

4. Achieve Balance between Security, Usability and Privacy with Invisible Identity

企業側はセキュリティを中心にID基盤を構想しますが、過度なセキュリティのために利便性を欠いた環境になっているとエンドユーザーはそれを回避したがります。
例えば・・・

  • 多数のID・パスワードの設定 → 全て同一にする(個人で利用するサービスと同一Passを利用)
  • パスワードの定期的な変更の強制 → 覚えられないからメモに書いておく

など、これらは企業が過度なセキュリティを押し付けた結果、セキュリティホールが生まれていることになります。
結果として、セキュリティは強まるどころか弱まっている(目的と真逆の結果になっている)ことを認識すべきだと思います。
ユーザーエクスペリエンスの向上に関しても、ディズニーで利用されているバンドを例に挙げて解説されていました。
もしTDRに導入されたら “開園ダッシュ” がなくなる!?「ディズニー・ワールド」MyMagic+ 完全ガイド(1/5) - ディズニー特集 -ウレぴあ総研

5. Be Self Sovereign! Block Chain+Identityが目指す姿

Identityを自分で管理できない世界は非常に危険なのではないか。(Yourdentity
近年ID Federationの普及により、個人IDの世界でも利便性は向上しきていますが結局のところIdPに自分のIdentityを握られているのが現状です。(FacebookGoogle等)
仮にFacebookGoogleアカウントが停止してその復旧が困難な場合、SAML、OAuthやOIDCで繋いでいる全てのIdP、SP/RPも利用ができなくなります。(組織IDの場合、望ましい状態かと思いますが)
個人IDの最終コントロール権は手元に残さないと、IdPの一存で個人のIDが停止されてしまうことを認識しましょう。
そして、それを解決する光となるのがBlock Chainによる分散台帳技術かもしれません。(Mydentity

今後のDigital Identity領域が楽しみです。

SharePoint Onlineにおける通知機能の補完方法

SharePointの通知にはリボンメニューから設定できる「個人用通知」と、SharePoint Designerで設定する「ワークフローのメール送信」がありますが、いずれも実際に使ってみると少し機能が足りないと感じることが多いです。
※個人用通知では、全く足りないですが・・・

私が過去に不足感を感じた用途は以下になります。

  • ワークフローを起動するタイミングが「アイテムが作成されたとき」or「アイテムが変更されたとき」しか設定できない f:id:michaelowen628:20170816205008p:plain
  • 匿名ユーザーの投稿や編集では、ワークフローの起動に失敗する

この問題に対応するために別途タスクスケジューラに対して条件に合うアイテムを「更新」するスクリプトを登録することで、SharePoint Designerで設定したワークフローを起動するようにして実現していることも多いかと思います。

オンプレミスのSharePoint Serverであればそれでいいのですが、上記の方法ではSharePoint Onlineに対応することができないです。
そこでSharePoint Onlineにおいて、上記問題を解決する方法を2点ご紹介させて頂きます。

  1. Office 365 サイト用の Azure Web ジョブ ("タイマー ジョブ") の使用の開始 | MSDN f:id:michaelowen628:20170816212652p:plain

  2. オンデマンド Flow による新しい SharePoint 通知 – MS Japan Office 365 Tech Blog f:id:michaelowen628:20170816212948p:plain

それぞれのソリューションを簡単に比較すると以下のようになります。

【価格】

  • Azure Webジョブ + SharePoint Designer
    Azure WebジョブはAzure App Serviceのコストがかかってきます。 ただ、他で利用しているAzure Web Appにのせることも可能です。

  • Microsoft Flow
    制限はありますが、多くのOffice 365ライセンスにプランが含まれています。
    プラン | Microsoft Flow

【機能】

  • Azure Webジョブ + SharePoint Designer
    SharePoint Online内で完結するのであれば、基本的にやりたいことはできます。
    Exchangeや、Skype、Dynamics等他のMicrosoft アプリと連携すると不利。
    ※Azure Webジョブ側にアップロードするスクリプトにコードを記載すれば多くのことを実現できるが、基本的にはSPDのトリガー補助を想定

  • Microsoft Flow
    SharePoint Online内で完結する場合、SPDのワークフローと比較して複雑なフローになりがちですが、機能面ではSPDにほとんど追いついていると考えられます。
    他のOffice 365アプリ等と連携する場合、とても強力です。

【運用】

  • Azure Webジョブ + SharePoint Designer
    SharePointリストと連携する等、実装を工夫することで、事前に想定される運用作業は軽減可能です。
    しかし根本的な実装面で改修が必要な場合、SPDスクリプトの理解及びその環境が必要になります。
    Powershell+CSOM等のスクリプトをオンプレミスで利用している場合、参照するDLLと合わせてアップロードすることでSharePoint Onlineでも同じスクリプトを利用可能です。

  • Microsoft Flow
    フローが複雑になりがちですが、ブラウザのみで比較的容易に編集可能です。   Json,zip形式でインポート/エクスポート可能ですが、当然ながらオンプレと異なる実装となります。

将来的にMicrosoftは、SharePoint DesignerとInfopathの開発を打ち切るとアナウンスしていることからも、Microsoft Flowの利用にも慣れておきたいところですね。

なお、今回はよく直面する問題として通知機能を中心に記載していますが、このソリューションはSharePoint Onlineに対してあらゆるスケジューリングタスクを実現してくれますので、応用範囲は多岐に渡ります。
是非色々試してみてください。

Azure上でNested Virtualizationが利用可能に

最近色々ゴタゴタしていたので久しぶりの投稿になります。

タイトルの通り、Azure上のVMNested Virtualizationが利用可能になったようですね。
(※一部のサイズに限定されているようですが)

azure.microsoft.com

オンプレでは、Windows Server 2016から既にこのNested Virtualization機能は利用できるようになっているので、Azureの仮想化基盤が追いついてきた形になります。
ちなみにオンプレの場合は、Hyper-Vホスト側で以下のコマンド実行が必要だったのですが、Azureではどうなるのでしょうか・・・

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

まぁ何はともあれ、これでAzure上でHyper-V周りの検証も実施できるようになりました。Docker for Windowsも内部的にはHyper-Vの機能を利用することになるので、今まではAzure上のVMで利用することができなかった仮想化周りの検証が捗りますね。

docs.docker.com