おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

おはこんばんちは、開発本部エンジニアの大岡です。 先日、TechLunch という社内勉強会で「フロントエンジニアが UI 設計〜実装で考えていること」という内容で発表しました。UI 設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。 UI 設計 UI 設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独で UI 設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。 とその前に、他人と UI について話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。 自分が他の人に UI デザインの説明をするとき、あまり使わないようにしている言葉がいくつかあるので、それらについて描きました。 私の中では、これ系の言葉は、 初心者：使いがち 中級者：ほぼ使わない 上級者：たまに使ってる みたいな印象があります。 pic.twitter.com/O2URgRCVHe — シンギュラリティ (@singularity8888) December 2, 2018 普通はそうする 直感的にわかる 使いやすい わかりやすい これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。 今回何ヶ所か使っていますが実際 UI について話すときは使わないように心がけています 。 デザイナーから画面仕様をもらう場合 デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。 なぜこの課題がうまれたのか 解決したい課題の本質はなんなのか 他の解決策はないのか この機能を追加してしまうことにより他に影響がでてしまわないか 追加ではなく他の機能を落とすことにより解決できないのか そもそも必要なのか など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。 似たようなコンポーネントがあったら統一できないか より使いやすくできないのか 操作感が他と明らかに違わないか 操作に対して予想した動きになっているか 表示されている情報に意味があるのか など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。 手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめる ように努力してます。 自分で UI 設計をする場合 「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。 それらを踏まえ、 すでに実装済みの UI で似たようなものがあれば似たように作ります 。理由としては既にユーザが学習済みの UI のため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。 似たような UI がなく新たに作らなければならないときは以下を意識しています。 表示する情報の精査 表示する情報はリストなのか詳細表示なのか 表示する情報に対しての操作はどんなものがあるのか 操作に対してのレスポンス・納得感はどうすれば得られるのか エラー表示をどうするのか 表示する情報が多すぎて収まり切らない場合どうするのか 表示する情報がない場合どうするのか 画面サイズ毎に適切に表示できるか 状態（クリックやホバーなど）を表現できてるか リストの場合デフォルトの順番は適切なのか などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑 実装 細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。 何も考えずにコピペしない 修正が大変になるので一箇所になるべくまとめる 用途にあったコンポーネントを使う 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも コンポーネント間の関係が疎になるようにする 密接な関係だと気を使い合わなくてはならず修正が大変 コンポーネントを作成する際に無理に汎用性をもたせない 修正が困難になり逆に汎用性がなくなる場合が多い Redux に管理させるステートの粒度は適切か なんでもかんでも Redux に状態を管理させてしまっていないか 無駄な再レンダリングをしていないか 無駄な通信をしていないか 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか 関数や変数は適切な命名で適切な場所に書かれているか マジックナンバーを使ってしまっていないか 使ってると修正大変 なるべく簡単に書けないか エラー・例外時の動きは適切か など細かいことを言い出したらキリがないですが、こんなこと意識してます。 よりよいものを届けるために いろいろと書きましたが UI 設計から実装完了まではなるべく早く終わらせようと意識しています。１サイクルを UI 設計 実装 触る フィードバック とした場合に、 このサイクルをリリースまでに多く回すことによってより多くの気づきが得られる からです。基本的には一回作ってうまくいくことは希かと思っているからです。 ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。 フロントエンドの UI やパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。 初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し 一人でも多くの人に触ってもらい気付ける回数を増やすことは大事 なことだと思っています。 さいごに あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。 ▼ メドレーで働くクリエイターたちのストーリーはこちら www.medley.jp

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQuery の Partitioned table について発表しましたので、その話について書きたいと思います。 なぜ今 Partitioned table? ある案件でユーザーの操作ログを扱う必要があり、データ保管先に BigQuery を利用しようと考えていました。その際に、「以前は β 版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。 なぜ分割テーブルを使おうと思ったのか ユーザーの行動/操作ログの確認については API サーバーのアクセスログで、ある程度その目的を果たすことができていました。 しかし、API のアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ（通知の取得ログなどをはじめとする各種データ参照など）を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。 ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しく Partitioned table に保存することにしました。 また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。 分割テーブルの各種方法について まずひとくちに「分割テーブル（Partitioned table）」と言っても、BigQuery ではいくつかの実現方法があります。 「取り込み時間で分割」されたテーブル 「特定のカラムに基づいて分割」されたテーブル 「時間ベースの命名方法を使用して分割」したテーブル 前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列として DATE 型または TIMESTAMP 型を指定することで利用することができます。 こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス（スキャン対象データ量の限定、高速化）が可能になります。 注意点として 公式ドキュメント にもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシー SQL を利用することができないため、標準 SQL を利用する必要があります。 クエリキャッシュ 分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。 そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約（例外）があります。 今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ（パーティション）がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。 そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。（ストリーミングバッファが付いているかどうかは、WebUI のテーブル情報の詳細タブから確認できます） データ移行 前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。 「access_yyyymm」的なテーブルから、移行用のデータを取得 必要なデータを付与 移行先のテーブルにデータを insert とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。 やってみた まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ… 「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」 と、怒られてしまいました。 分割テーブルの制限としてストリーミングインサートは、過去７日までしか書き込むことができないようでした。・・・と！発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて 公式ドキュメント（パーティショニング オプションの比較） 見てみると、過去１年まで扱えるようになっている！？ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。 最終的に 前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCS にインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。 作業当初はデータ移行を行う手段として Embulk を利用することも検討していました。 Embulk はさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。 あとから気になったので、Embulk のプラグインである embulk-output-bigquery を調べてみると、やはりストリーミングインサートは実装しておらず、また GCS 経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも…という気持ちで今はいっぱいです ( ꒪⌓꒪) まとめ 今更ながら BigQuery の Partitioned table 周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面で BigQuery を利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。 今回のデータ移行を行った後あたりに Clustered Table(beta) のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。 また、TechLunch での発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは？と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDB はより適した用途のように思いますので、こちらも今後検証していきたいと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。開発本部エンジニアの平木です。 去る 2019/02/23(土)に開催された JAWS-UG（AWS User Group – Japan）主催の全国規模での交流イベントである JAWS DAYS 2019 にメドレーが ‌ ランチサポーター として協賛させていただきましたので、当日の様子などをお伝えしていきます。 会場の様子 自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場の TOC 五反田メッセ はイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国から AWS ユーザが集まるイベントの規模の大きさが伺えました。 公式発表 で 1,900 人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。 セッションもバラエティに富んだ ラインナップ で見たいものが若干カブってしまっていた位で、大変有意義なものでした。 またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、 JAWS-UG 公式 Twitter に負けず劣らず、 アマゾンウェブサービス公式 Twitter でイベントの様子を Tweet していたのは、さすがだなと思わされました。 メドレーのスポンサー活動 さて、そんな活気に包まれていた JAWS DAYS 2019 での弊社のスポンサーとしての取り組みについてですが、今回は ‌ ランチサポーター として 協賛させていただきました 。 企業サポーターブース まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。 パンフレットを置かせていただいていたのは、会場内で 2 番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。 ランチセッション そして、ランチサポーターとしてランチセッションで弊社の田中が AWS マネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウ と題したセッションでお話させていただきました。 メドレーで運営しているサービスである CLINICS カルテを AWS を使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWS の各サービスをどのように使っているか?というお話をさせていただきました。 詳細としては 医療情報システムを構成する際に準拠しなければならない 3 省 3 ガイドラインの抜粋 CLINICS カルテでガイドラインがシステム構成に影響を与えた部分 日本国内法の適用が及ぶ場所へのシステムの設置 ユーザである医療機関の使用するアプリ側で TLS クライアント認証を実施 ユーザアカウント毎の権限管理と各種操作ログの管理 AWS 東京リージョンへの移行や、システム構成を AWS の各サービス( ECS や fargate 、 NLB など)を使いながら TLS クライアントに対応していった話 セキュリティを強固にするために AWS サービス群をどのように使用しているかの話 AWS CloudTrail Flow logs Amazon GuardDuty AWS Config Session Manager といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。 セッションが終わって一安心した田中 最後に イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました! メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽に お問い合わせ いただければと思います。

こんにちは。昨年末に クリエイターズストーリー が公開され顔面が白日のもとにさらされ『イケメンじゃなくね？イケメンつーか犯罪者顔じゃん！』と影口たたかれてないか不安な日々をおくる開発本部のガラスのハートことイケメン担当デザイナーの小山です。 さて今回は先月末におこなった社内の勉強会の内容をご紹介させていただきます。 デザインのプロセスは、時代とともに明らかになりつつあり、個人主導より参加型のデザインワークが主流になりつつあります。例えばサービスデザインはステークホルダーと課題を協議しながら解決策を見出していきます。視点は異なりますが、デザインスプリントも各参加者の視点や思考を総動員して短期でプロダクト（解決策）を作り出す手法です。 関係者が参加したデザインプロセスにより出来たデザインを製品レベルへ品質を高めるため、デザイナーの手によってブラッシュアップされていきます。この段階から本格的にデザイナーの感覚由来の思考が組み込まれ、プロダクトが洗練されていきます。 ですが、思考が組み込まれると、周囲とは別世界の領域として扱われている感覚になることがあります。どういう思考プロセスを経て、デザインされたのか周囲は触れることができません。それゆえに、周囲はデザインにおいての思考プロセスはデザイナー頼みになりやすく、作業依頼の最後の決まり文句として『いい感じに！』という言葉を掛けがちです。 こうした周囲が踏み込みづらい距離感が生まれてしまうのは仕方のないことだと思っています。 原因は、デザイナーの感覚由来の思考プロセスが共有されない状態＝ブラックボックス化にあります。またデザイナーが自発的にブラックボックスをオープンにして、周囲の目に留まる環境を用意できていない点も原因としてあります。 目に留まる環境ではないため、周囲はアウトプットだけしか注目できず『いい感じに！』以外の言葉を掛けようがありません。 デザイナーは、色や形を論理的な思考と感情的な思考の掛け合わせでアウトプットします。目では見えにくいプロセスに突入するので、周囲からは抽象的で曖昧な領域と思われがちです。 今回は、これまでの経験の中で最もその『曖昧な領域と思われがち』だと感じている 余白 について、デザイナーの視点でご紹介*し、ブラックボックスの中身を少しお見せしたいと思います。 *個人的見解なので世のデザイナー全員に当てはまる訳ではないことをご理解いただければ幸いです。 余白について みなさん、余白の言葉の意味はご存知ですか？　辞書では  “文字などに書いた紙面の何も記されないままで残っている部分”と記されています。字面としては言い得ているのですが、デザイナー視点ではこれが全てではありません。 もちろん”何も記されていない”が余白の前提なのですが、なぜそれが必要か？が重要です。 まずは余白の機能から説明します。余白には最も伝えたいメッセージを視覚的に浮き彫らせ、理解を促す効果があります。多種多様で氾濫した情報から希望したものを抜き出すプロセスを、見ている人に強いるのではなく、デザインが肩代わりします。 昨今の日本のデザインは、見ている人の情報に対しての許容量が増え、膨大な量を詰め込んでも理解してもらえる場面が多々あります。 ただスタミナが必要です。スポーツをするのと同じように情報に触れるだけで人はスタミナを消費します。そして、人間であればスタミナには限りがあります。 デザインは、その限りあるスタミナを情報の探索に使うのではなく、本来の目的に沿った行動に運用できるような仕組みに整備します。その手段の１つとして余白があります。   photo by  Guillermo Pérez 余白は目的ではなく情報を届けるための１つ手段です。 届けたい情報がどういう文脈であるべきなのか、そことセットで考えなくては余白や目的が破綻します。このプロセスが抜けおちた状態でプロジェクトが成功してしまうとブラックボックス化が進みます。 そうすると周囲の参加が難しい状況になり、『なんだかわからないけど良いだろう…』という状況に陥ります。いつまで経ってもデザインの思考プロセスは理解されないままの状態が続くでしょう。そのために余白を意味あるものとして文脈が必要となります。 Apple Store 表参道店 店内　 Photo by wongwt ヨドバシカメラの店内   Photo by chesterbr 文脈は明快であるべきです。その例として AppleStore とヨドバシカメラがあります。AppleStore は電化製品を扱う店舗の部類としては、延べ床面積に対しての商品数が極端に少ないお店。電化製品としてではなく、利用者の人生に大きな影響を与える重要なプロダクトになり得るものを提供しているプライドが伺えます。高級ブランドに近い売りかたですね。 ヨドバシカメラは様々なメーカーの商品を一度に、そして大量に伝達するために、より多くの商品を陳列します。世の中には商品が多くあり、その全てをありのままに伝達しスタッフのアドバイスを受けながら最適解を導き出す戦略です。 この２つの店舗の場合、それぞれ余白はどうあるべきなのかその機能や意味が見出せます。 AppleStore は通路を広くとり、商品を最も強調させるために机以外のノイズを限りなく削ぎ落とし、空間デザインにおいても余白を有効活用しています。物理的な余白を意図的に作ることで、商品に人の視線や意識が集まりやすくなり、より魅力が伝わる設計がなされています。 一方、ヨドバシカメラは様々なメーカーの商品を多く陳列することで横断して比較でき、自分にあった商品を見つけられる購入体験を実現します。そのために狭いスペースの中に如何に商品を詰め込められるかを念頭に設計しているように見えます。そこに余白はどこにもなく、情報の洪水が押し寄せているように感じられます。 ですが、余白はしっかりあります。それは人の頭の中です。 ヨドバシカメラは種別ごとに商品をしっかりまとめ、近しい情報であれば同じ見栄えのポップで整理し、遠くからでもどこにあるか商品がわかりやすいように陳列の技術を駆使し、来店する人のスタミナの消費量を軽減しています。 情報の整理をすることで、探す労力を利用者に強いることなく、無意識のうちに理解できるスイッチが入るように設計しています。ヨドバシカメラの場合は物理的な余白をとるのではなく、意識下に余白を作り出している高度な設計をしています。 文脈を設計し伝えるべき情報を効率良く届けるために、余白は様々な手段があります。２つの事例をあげましたが、ここには物理的な余白、そして意識的な余白があります。 主に UI デザインする個人的な意見ですが、余白の真の意味は、利用する側の頭の中の情報を整理し、スタミナ消費を軽減し意思決定のアクションを促せる『余地』を作ることにあると思っています。 と、自分なりの余白の考えをお話しました。普段の業務の中でデザイナーの立場として、こうした話をする機会はなかなかありません。しかし考え話すことでデザインに周囲が参加できる素地を作らなければ、いつまで経っても、「いい感じにつくって」の状態から逃れられません。 デザイナーの役目として作ることは大前提。しかし、単に手を動かして作るだけでは意図を理解されにくいため、対話を通して思考プロセスを共有しないとその後の改善はその場限りになります。これはデザインに限りません。 事業編成による人事異動や事業規模の拡大など大きな変化のなかでも作り続けれるようにするために、余すところなく言語化し共有することが大事だと思います。 メドレーには凡事徹底９箇条という仕事の質を高める指標があり、全社員がそれを意識しています。その指標の１つに『ドキュメントドリブン』というものがあります。全てを記録し共有できる状態にし無駄な取り組みをしないというものです。またドキュメントドリブンやドキュメントそのものの意味は、次の人にバトンを渡すことでもあると思っています。 言語化されたデザインの思考プロセスは、デザイナー以外にバトンとして次に繋ぐことで、本当にプロダクトが良いものになるのか、検証と改善を継続できるようにする道しるべにもなります。 幸運にもブラックボックスを開けて周囲を巻き込む術はたくさんあります。冒頭の手法以外にもライブデザイニングという手法があります。これはデザイナーのデザイン業務や思考プロセスを公開しながら進めていくものです。詳しくは こちら 。 弊社のデザイナーはプロダクト毎に、一人専任でデザインを任されています。それだけに重要な仕事を任される面白さはあるものの、デザイナーの感覚由来の思考プロセスで解決策が生まれやすい状況とも言えます。 デザインはデザイナーだけのものではないので、チームならチームに組織なら組織に思考のプロセスを明らかにすることで、新しい発見や解決策が生み出せるかもしれません。その機会をデザイナーから作り出し、より良い事業推進に貢献できたらと思います。 最後まで読んでいただきありがとうございます。 お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp

こんにちは。昨年末に クリエイターズストーリー が公開され顔面が白日のもとにさらされ『イケメンじゃなくね？イケメンつーか犯罪者顔じゃん！』と影口たたかれてないか不安な日々をおくる開発本部のガラスのハートことイケメン担当デザイナーの小山です。 さて今回は先月末におこなった社内の勉強会の内容をご紹介させていただきます。 デザインのプロセスは、時代とともに明らかになりつつあり、個人主導より参加型のデザインワークが主流になりつつあります。例えばサービスデザインはステークホルダーと課題を協議しながら解決策を見出していきます。視点は異なりますが、デザインスプリントも各参加者の視点や思考を総動員して短期でプロダクト（解決策）を作り出す手法です。 関係者が参加したデザインプロセスにより出来たデザインを製品レベルへ品質を高めるため、デザイナーの手によってブラッシュアップされていきます。この段階から本格的にデザイナーの感覚由来の思考が組み込まれ、プロダクトが洗練されていきます。 ですが、思考が組み込まれると、周囲とは別世界の領域として扱われている感覚になることがあります。どういう思考プロセスを経て、デザインされたのか周囲は触れることができません。それゆえに、周囲はデザインにおいての思考プロセスはデザイナー頼みになりやすく、作業依頼の最後の決まり文句として『いい感じに！』という言葉を掛けがちです。 こうした周囲が踏み込みづらい距離感が生まれてしまうのは仕方のないことだと思っています。 原因は、デザイナーの感覚由来の思考プロセスが共有されない状態＝ブラックボックス化にあります。またデザイナーが自発的にブラックボックスをオープンにして、周囲の目に留まる環境を用意できていない点も原因としてあります。 目に留まる環境ではないため、周囲はアウトプットだけしか注目できず『いい感じに！』以外の言葉を掛けようがありません。 デザイナーは、色や形を論理的な思考と感情的な思考の掛け合わせでアウトプットします。目では見えにくいプロセスに突入するので、周囲からは抽象的で曖昧な領域と思われがちです。 今回は、これまでの経験の中で最もその『曖昧な領域と思われがち』だと感じている 余白 について、デザイナーの視点でご紹介*し、ブラックボックスの中身を少しお見せしたいと思います。 *個人的見解なので世のデザイナー全員に当てはまる訳ではないことをご理解いただければ幸いです。 余白について みなさん、余白の言葉の意味はご存知ですか？　辞書では  “文字などに書いた紙面の何も記されないままで残っている部分”と記されています。字面としては言い得ているのですが、デザイナー視点ではこれが全てではありません。 もちろん”何も記されていない”が余白の前提なのですが、なぜそれが必要か？が重要です。 まずは余白の機能から説明します。余白には最も伝えたいメッセージを視覚的に浮き彫らせ、理解を促す効果があります。多種多様で氾濫した情報から希望したものを抜き出すプロセスを、見ている人に強いるのではなく、デザインが肩代わりします。 昨今の日本のデザインは、見ている人の情報に対しての許容量が増え、膨大な量を詰め込んでも理解してもらえる場面が多々あります。 ただスタミナが必要です。スポーツをするのと同じように情報に触れるだけで人はスタミナを消費します。そして、人間であればスタミナには限りがあります。 デザインは、その限りあるスタミナを情報の探索に使うのではなく、本来の目的に沿った行動に運用できるような仕組みに整備します。その手段の１つとして余白があります。   photo by  Guillermo Pérez 余白は目的ではなく情報を届けるための１つ手段です。 届けたい情報がどういう文脈であるべきなのか、そことセットで考えなくては余白や目的が破綻します。このプロセスが抜けおちた状態でプロジェクトが成功してしまうとブラックボックス化が進みます。 そうすると周囲の参加が難しい状況になり、『なんだかわからないけど良いだろう…』という状況に陥ります。いつまで経ってもデザインの思考プロセスは理解されないままの状態が続くでしょう。そのために余白を意味あるものとして文脈が必要となります。 Apple Store 表参道店 店内　 Photo by wongwt ヨドバシカメラの店内   Photo by chesterbr 文脈は明快であるべきです。その例として AppleStore とヨドバシカメラがあります。AppleStore は電化製品を扱う店舗の部類としては、延べ床面積に対しての商品数が極端に少ないお店。電化製品としてではなく、利用者の人生に大きな影響を与える重要なプロダクトになり得るものを提供しているプライドが伺えます。高級ブランドに近い売りかたですね。 ヨドバシカメラは様々なメーカーの商品を一度に、そして大量に伝達するために、より多くの商品を陳列します。世の中には商品が多くあり、その全てをありのままに伝達しスタッフのアドバイスを受けながら最適解を導き出す戦略です。 この２つの店舗の場合、それぞれ余白はどうあるべきなのかその機能や意味が見出せます。 AppleStore は通路を広くとり、商品を最も強調させるために机以外のノイズを限りなく削ぎ落とし、空間デザインにおいても余白を有効活用しています。物理的な余白を意図的に作ることで、商品に人の視線や意識が集まりやすくなり、より魅力が伝わる設計がなされています。 一方、ヨドバシカメラは様々なメーカーの商品を多く陳列することで横断して比較でき、自分にあった商品を見つけられる購入体験を実現します。そのために狭いスペースの中に如何に商品を詰め込められるかを念頭に設計しているように見えます。そこに余白はどこにもなく、情報の洪水が押し寄せているように感じられます。 ですが、余白はしっかりあります。それは人の頭の中です。 ヨドバシカメラは種別ごとに商品をしっかりまとめ、近しい情報であれば同じ見栄えのポップで整理し、遠くからでもどこにあるか商品がわかりやすいように陳列の技術を駆使し、来店する人のスタミナの消費量を軽減しています。 情報の整理をすることで、探す労力を利用者に強いることなく、無意識のうちに理解できるスイッチが入るように設計しています。ヨドバシカメラの場合は物理的な余白をとるのではなく、意識下に余白を作り出している高度な設計をしています。 文脈を設計し伝えるべき情報を効率良く届けるために、余白は様々な手段があります。２つの事例をあげましたが、ここには物理的な余白、そして意識的な余白があります。 主に UI デザインする個人的な意見ですが、余白の真の意味は、利用する側の頭の中の情報を整理し、スタミナ消費を軽減し意思決定のアクションを促せる『余地』を作ることにあると思っています。 と、自分なりの余白の考えをお話しました。普段の業務の中でデザイナーの立場として、こうした話をする機会はなかなかありません。しかし考え話すことでデザインに周囲が参加できる素地を作らなければ、いつまで経っても、「いい感じにつくって」の状態から逃れられません。 デザイナーの役目として作ることは大前提。しかし、単に手を動かして作るだけでは意図を理解されにくいため、対話を通して思考プロセスを共有しないとその後の改善はその場限りになります。これはデザインに限りません。 事業編成による人事異動や事業規模の拡大など大きな変化のなかでも作り続けれるようにするために、余すところなく言語化し共有することが大事だと思います。 メドレーには凡事徹底９箇条という仕事の質を高める指標があり、全社員がそれを意識しています。その指標の１つに『ドキュメントドリブン』というものがあります。全てを記録し共有できる状態にし無駄な取り組みをしないというものです。またドキュメントドリブンやドキュメントそのものの意味は、次の人にバトンを渡すことでもあると思っています。 言語化されたデザインの思考プロセスは、デザイナー以外にバトンとして次に繋ぐことで、本当にプロダクトが良いものになるのか、検証と改善を継続できるようにする道しるべにもなります。 幸運にもブラックボックスを開けて周囲を巻き込む術はたくさんあります。冒頭の手法以外にもライブデザイニングという手法があります。これはデザイナーのデザイン業務や思考プロセスを公開しながら進めていくものです。詳しくは こちら 。 弊社のデザイナーはプロダクト毎に、一人専任でデザインを任されています。それだけに重要な仕事を任される面白さはあるものの、デザイナーの感覚由来の思考プロセスで解決策が生まれやすい状況とも言えます。 デザインはデザイナーだけのものではないので、チームならチームに組織なら組織に思考のプロセスを明らかにすることで、新しい発見や解決策が生み出せるかもしれません。その機会をデザイナーから作り出し、より良い事業推進に貢献できたらと思います。 最後まで読んでいただきありがとうございます。 お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 www.medley.jp www.medley.jp