はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 https://www.medley.jp/jobs/ https://www.medley.jp/team/creator-story.html

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

はじめに こんにちは、コーポレートエンジニアの若林です。 普段はいわゆる社内 SE 的な領域を担当していますが、その名の通り エンジニアの視点も持ったコーポレート機能 という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。 コーポレート IT 担当として会社の成長を支える兼松さんに「聞いてみた」 全社で本気になってリーンに ISMS の仕組みをつくった話 今回もその取り組みの一環で、先日開催された Google Cloud Next ‘19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。 今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。 Google Cloud Next ‘19 in Tokyo について Google Cloud Next は、年一度 Google 主催で催される Google テクノロジーに関するカンファレンスです（今年は、サンフランシスコ、東京、ロンドンの世界 3 会場開催） 日程；7/30(火) - 8/1(木) 会場：東京プリンスホテルおよびザ・プリンス パークタワー東京 イベントサイト： Google Cloud Next ‘19 in Tokyo メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。 なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私が SNS でアナウンスしても既に満席で申し込めないような状態になっておりました・・・ 会場の雰囲気 東京タワーとの一枚 登壇の様子（背景と同色なのは偶然です） セッション内容について Google Apps Script / AppMaker 最新アップデートと活用のヒント 今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。 まず Google の深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。 それを受けて、メドレーでは「Google App Maker 活用事例と開発 Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。 App Maker は GA されてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく（あってもほぼ英語）、現時点において日本で活用できている企業は本当に限られていると思っています。 しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。 ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。 Google App Maker とは 一言で言うと… G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール です！ 主に以下のような特徴があります。 バックエンドのデータストアとして、RDB（Cloud SQL）が利用される 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Script である G Suite のサービス（ユーザーディレクトリ、メール、ドライブ等）と容易に連携が可能である UI のカスタマイズの容易さと高い自由度がある メドレーでの社内活用事例 メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。 今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。（当日はデモも実施しているので、デモの内容を見たい方は セッション動画 をご覧下さい） App Maker を使ったアプリケーション開発の流れと開発 Tips App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tips を紹介させて頂きます。 データモデルの定義 UI 作成 ビジネスロジック記述 1. データモデルの定義 はじめに、GUI ベースで RDB のメタデータを定義していきます。 モデル（テーブル）の主な設定項目 FIELDS：モデルのフィールド情報を定義 DATASOURCES：データベースでいうところのビューに近い概念の設定 RELATIONS：モデル間のリレーションを定義 EVENTS：クライアントのデータベース操作に対するイベントスクリプトを定義 SECURITY：モデルに対する権限を制御 データモデルの定義における開発 Tips EVENTS の挙動 ：MODEL の設定項目なので一見データベーストリガーと思いがちですが、 このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。 （クライアントサイドからの操作限定）サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。 データベースへの更新反映タイミング ：既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。 細かな権限制御 ：GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、 Query Builder や Query Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。 2. UI 作成 次に、ウィジェット（画面を構成する部品）をドラッグ&ドロップで配置して画面を作成していきます。 一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User Picker や Drive Picker 、更には リッチなポップアップ、ダイアログ等 も利用可能です。 スタイルに関しては、 バリアント を利用することで、統一感のあるスタイル適用が容易に可能になっています UI 作成における開発 Tips 組み込みのマテリアルデザインアイコン ：ラベルやボタンの text を特定の文字列にすると、元々組み込まれているマテリアルデザインアイコンを利用することが可能です。（ 文字列とアイコンの対応表 ）一般的に利用されているようなアイコンはほとんど用意されているので、ガンガン活用していきましょう。 3. ビジネスロジック記述 最後に、2 種類のスクリプト（Client Script, Server Script）を利用して、ビジネスロジックを記述していきます。（アイテム生成とか、読み込みとかは基本的に記述不要） Client Script から Server Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。 google . script . run . ServerSideFunction (); ビジネスロジック記述における開発 Tips 外部公開できない ：Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。（トランザクション処理等は複雑化します） ローカルの開発環境と上手く連携できない ：Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。 定期実行トリガーを GUI で設定できない ：Google Apps Script では GUI から設定が可能な、「時間ベース」のトリガーが GUI で簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。 ScriptApp . newTrigger ( "functionName" ). timeBased (). at ( date ); App Maker をこれから始める人向けの情報 なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。 知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。 アプリ作成の一連の流れを掴む How to Build Enterprise Workflows with App Maker (Cloud Next ‘18) Improve Processes by integrating App Maker, Data Studio and GCP (Cloud Next ‘19) 実際に触ってみる チュートリアル テンプレート 情報共有プラットフォームを活用する stack overflow [google-app-maker] タグ Google グループ[App Maker Users] まとめ 今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。 App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。 なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が 0 の状態から 1~2 ヶ月程で Slack との連携も含めて 1 人で実装できました。（RDB や GAS に対する知識は、ある程度習得済みの状態が前提にはなっています） GA 直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。 最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら https://www.medley.jp/team/

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。