2018-05-30

I/O Extended 2018 Shibuyaに行ってきました

Android

こんにちは

Androidエンジニアの富田です。先日、I/O Extended 2018 ShibuyaにBlog枠として参加させていただきました。I/O Extended 2018 ShibuyaとはMaterial Designに特化したイベントで、IO2018で発表された新しいMaterial Designについてのお話が多く大変興味深かったので内容をレポートしたいと思います。間違いや認識の違いがありましたら、ご指摘いただけますと幸いです。

goodpatch.connpass.com

Material update

Google合同会社鈴木拓生さんによる「リデザインされたMaterial Design」についてです。

そもそもMaterial Designって？

Material DesignとはGoogleが2014年に発表したデザインフレームワーク。元々は社内用のフレームワークだった。なんで社内用にフレームワークを作っていたかというと、サービス間のUIが異なっていて使いにくかったため。GmailとGoogle Calendarでは異なるUIだったので、慣れない人にとっては操作しづらかった。そこでタブレット、モバイル、デスクトップなどに最適化されたフレームワークを過去のデザインシンキング、デザイン資産を使って作り、きちんとOSSとして公開したものがMaterial Design。2014年はGoogle PlayでMaterial Designを利用したアプリが0個だったのに対して、今や150万ものアプリが存在する。一方問題もあり、フレームワークを利用しているためどうしてもアプリの独自のカスタマイズ性が難しい。これを解決するためにできたものがMaterial Theming。

Material Themingって？

E2Eの考え方でブランドに沿った形でデザインをシステマチックに作ることができる機能。ブランドにあったボタン、スライダーなど様々なコンポーネントを利用できる。

Material DesignとMaterial Themingの違いは？

変わっていないところ
- 物質的なものをメタファーとして使っている
- 必要な機能をレイヤーごとにヒエラルキーを作って表現する
- プライマリーカラー、セカンダリーカラー
- フォントをきちんとヒエラルキーを並べて使う
変わったところ
- ボタンの形などの表層的なところはカスタマイズしている
- コンポーネントの組み合わせによってアプリを構築する
- 英文はRobotoフォント、英文じゃないものはNoto Sansフォントを推奨していたが、より多くのフォントをサポートするようになった
- アイコンは1パターンから2パターンになった。自分たちのサービスにあったものを選べる

Material Designを使っているとGoogleアプリっぽくなっちゃう問題

元々Googleの社内向けデザインフレームワークなのでGoogleっぽいデザインになってしまうのは当然。今回はGoogleも一つのMaterial Themingユーザとなり、Material ThemingをカスタマイズしたGoogle Material Themingを開発した。その使用例としてGmail、Google News、Google Pay、Google Homeなどでは、Google Material Themingを使用している。今後、他のGoogleアプリについても同様にGoogle Material Themingに移行していく予定。

Google以外にMaterial Themingを使ったアプリは？

Pocket Casts、Lift、ZapposがすでにMaterial Themingを利用している。

Material Themingをカスタマイズする方法

material.ioのガイドラインを参照するとわかるように今回material.ioが大きくアップデートされ、Material Tools、Material Componentsなどが発表された。Material Designは、デザイナーだけではなく、デベロッパーも使うもので、プラットフォームについてはFlutter、Android、iOS、Webで動く。Material Designはあくまでもデザインフレームワークなのでデザイナーはクリエティブな部分に注力してもらいたい。

マルチプラットフォーム

マルチプラットフォームとしてReact版を開発中。Flutter、Android、iOS、Webと対応されているがAndroid、iOSとは微妙に違いがあり、細かいところでプラットフォームにあった設計をしている。チュートリアルが準備されており、学びたい人は各プラットフォームで触ることができる。デベロッパーの場合は全てOSSで見れるようになっているので、機能拡張やバグなどがあればレポートをお願いします。

Material Themingの使い方

Android
- com.google.android.material:material:バージョンをgradleファイルに追加
- Jetpackの関係でサポートライブラリはandroidxに入りますが、materialのサポートライブラリは別途切り離されて開発され続ける
iOS
- CocoaPodsを使ってインストール
Web
- nodeモジュールとしてnpm installでインストール
Flutter
- 最初から入っているので何もする必要がない

みんなでデザインシステムを構築

みなさんが使っているアプリケーションや導入した過程で使いづらいところに対してフィードバックを送ってほしい。Google Material ThemingのようにGoodpatch Material Themingがあってもよくて、自社で使うときにカスタマイズしたMaterial Themingを使うのもあり。さらにJapan Material Themingといったような、みんなでデザインシステムを作っていくようなやり方を一緒にできると良いです。

UIデザイナーのためのMaterial Designの理解と実践

株式会社グッドパッチ蔡漢翔さんによる「UIデザインーのためのMaterial Desingの理解と実践」についてです。

Material Designのサイト

Material Designサイトには、ガイドライン、デザインツール、コンポーネントがある。Material Designとはデザインシステムで、デザインシステムとはスタイルガイド、コンポーネントライブラリ、デザインから実装までの一つのデカイシステム。サイト上ではデザイン、デベロッパー、ツールのカテゴリ分けされている。

メタファーを使ってわかりやすくMaterial Designについて考える

僕たちが毎日使っているアプリ、Webサイトを料理としてメタファーをつけると、デザイナーとデベロッパーはシェフで料理を作る人。デザインシステムは、料理を作るためのキッチン、調理器具、レシピ、食材などいろんなものを集めるデカイシステム。では、Material Designは料理教室。Foundation、Component、Toolは料理教室の中の料理の基礎知識を教えることで、調理済みの食材や便利なキッチン道具が準備されている。つまり、料理教室は料理の基礎が分かれば誰でも美味しい料理が作れる。Material DesignはUIの基礎が分かれば誰でも美しいアプリを作ることができるデザインシステム。Material Designは、デザインシステムを作るためのデザインシステム。

普段の業務にMaterial Designをどう導入する

Sketch、Material Theming Editorの2つツールを使って次の3つをやってみる。

Color
Typography
Components

Color

Material Designはベースの色システムがある。メインはプライマリー、セカンダリーがあり、その他にバックグラウンド、サーフェース、エラーの色がある。色システムを作るには、自分のデザインスタイルに合わせてプライマリーカラー、セカンダリーカラーを選択すると、マテリアルシステムは2つの色によってカラーパレットを自動生成される。

Typography

文字について大事な内容として、文字を揃えるときはBaselineで揃えること。Line-heightを4の倍数にする。そうすることで全てのテキストオブジェクトを4の倍数に揃えることができる。英語じゃない言語を使うとき注意することがあり、Line-heightを多めに取る必要がある。Titleより小さい文字の時、日本語フォントは英語フォントよりも小さくする必要があるが、プラグインを使うことによって自動的に調整される。

Components

アトミックデザインとは物質を構成する原子、分子、有機体などのメタファーを使ってUIの構成要素を5段階に分解するデザイン方法論。どのオブジェクトを原子、分子に指定することが難しいが、自分の組織が素晴らしいUIシステムを構築するために効果的にコミュニケーションするのに役立つはずです。つまり、アトミックデザインを5段階に分解できなくても、チームが効率的にやりやすい形にする方がいいかもしれない。

Google IO2018からの学び

Google IO2018の会場Wifiパスワードは「Make good things together」でこの中で一番大切なことは「together」。UIデザイナー、デベロッパーなど実際にデザインから実装するまで関わる人間はたくさんいる。みんなのおかげでユーザに優しいプロダクトをリリースすることができる。

Material Theming対応の前に知っておきたい、エンジニア側の対応コスト

株式会社ノハナ瀬戸優之さんによる「Material Theming対応の前に知っておきたい、エンジニア側の対応コスト」についてです。

Material Componentsとは

Material ComponentsとはMaterial Themingを簡単に実装するための専用ライブラリ。エンジニアはこれを使うと実装コストが下がり、Android、iOS、Web、Flutter向けに提供されている。iOSはそれほどコストが高くないが、アップデート回数が多いこととGithubのIssue数が1000ある点に不安がある。AndroidはAndroid Studio 3.2、compileSdkVersion AndroidP対応とコストが高くまだ対応できている会社は少ない印象。Flutterは一行importするだけで導入できるが、導入している会社は少ない。

Material Componentsはどれくらい実用的に使えるか

ボタンの角を完全に丸くしたり、真四角、切り落としなどができる。しかしまだAndroidでは一部Componentsは提供されていない。それらをカスタム実装する方法もあるがコストが高い。ロードマップが公開されているので、Material Componentsがどのように対応して行くのかわかるのでチェックしてみてください。

すぐに使えるComponents

Bottom App Bar、Buttons、Chipsは使える。ただAndroidだけ角を丸くできない。

ちょっと待ちなComponents

Backdropは7月対応予定。Extended FAB、Tooltipsもまだで、Color Themeは一部のコンポーネントが8月対応予定。だいたいのコンポーネントが8月対応であるが、Material Desing Componetnsに対応していなくても実装できる。しかしそれ相応にエンジニアの実装コストがかかるので本当に使いたいかどうかは、会社で色々考えてやりましょう。

gallery.io

galleryとZeplinを比較をすると、galleryには次の利点があります。

無料で使える
Gmailアカウントと連携している
Material Designのコンポーネントのガイドラインがワンクリックで見える
スマートフォンアプリがあるのでデザインの確認がしやすい
Material Theming Editorと親和性が高い

一方ダメなところは、リリースしたばかりなのでまだ機能が整っていない。画像やアイコンのダウンロードが全部の解像度向けにダウンロードできない。ただとにかくフィードバックを送ってほしいと書いてあるので、フィードバックを送っていくことで我々好みのgalleryになっていくかもしれない。

我々の対応

デザイナーの方はエンジニアの方と話し合って、対応できるタイミング、対応すべきタイミングを調べてもらう。Material Designのアップデートに注目して何がどこまでできるのかをエンジニアの方にチェックしてもらって会社のベストのタイミングでガッと対応するとバリューを出せそう。

Material Designの設計思想を探る

株式会社グッドパッチ丸怜里さんによる「Material Designの設計思想を探る」についてです。

新しいMaterial Designについて考察

Material Designガイドラインの序章で語られるPrinciplesの章で新たに二つのデザイン原則が加わった。デザイン原則は大きく以下の5つに分かれている。

メタファー表現
大胆、行き来、意図的
モーションは意味を与える
柔軟な基盤
クロスプラットフォーム

特に下の2つの「柔軟な基盤」、「クロスプラットフォーム」。iOSに提供されているMaterial Design Componentsの実装集が存在するが、これこそクロスプラットフォームを強く意識されているということがわかる。

Material Designのガイドラインで大きくプロジェクトが3つ掲げられている

体験の統一、視覚言語としてのデザイン、ビジュアルの柔軟性という3つが掲げられており、特にビジュアルの柔軟性が新しく追加された要素。今までのMaterial Designは厳格さがあったが、Material Themingでは柔軟性というキーワードが意識されている。Material Themingはコードレベルでデザインが体系化されており、構造やインターフェースを維持したままビジュアル部分のカスタマイズができる。

UXの5階層モデルに当てはめる

UXの5階層モデルには、表層、骨格、構造、要件、戦略がある。構造以下インターフェースとしては不変的であり、より表層に近いものはMaterial Themingを使って挿げ替えることができる。

FABについて

FABの振る舞いはコンテキストでもっとも主要なアクション。行動につながるアクションを提供するボタンであり、もっとも主要なアクションのため複数ではなく、特にモバイルのような画面が小さいではスクリーン内に一つを利用したほうが良い。またFABそのものが別のオブジェクトとして展開できる。

FABをiOSと比較

iOSは右上にその画面の主要なアクションが配置される。これがMaterial DesignのFABに当たるのかもしれない。見栄え的なところでiOSのバーボタンはFABと違って見え辛くその存在に気づきにくい課題がある。ユーザビリティーテスト段階で右上に主要ボタンを配置してもなかなか気づかれなかった。そのため、FABの一目見てわかる存在はiOSよりもMaterial Designの方が優れていると言えるかもしれない。

Bottom App Barについて

Bottom App BarをFABと一緒に使い合わせることによって、今まで上にあったものが下に降りて来て指に届きやすく使いやすくなった。

Elevationについて

Material Designは高さの概念が明確に定義されていて、影によって高さのサーフェースの高さを表現している。これはそもそもデバイスには奥行きがあって、紙のメタファーと言われるサーフェースが重なっている。

Backdropについて

手前にレイヤーがあって、奥にもうひとつレイヤーがある。これを分解してみると、背景レイヤーと前景レイヤーがあり主従関係になっている。主のレイヤーに対してメインコンテンツを配置して、従のレイヤーは前景レイヤーに対するオプションや検索だとフィルター設定などの使い方ができる。Backdropにおけるフォーカスの遷移過程は2ステップあって、前景レイヤーがデフォルトであって、次に背景レイヤーを操作する。これを踏まえてみると、BackdropとiOSのセミモーダルビューに似ているように見えるが、レイヤーを分解してみるとレイヤーの役割が逆転している。

モーションについて

Material Designに限らず、意味のあるモーションは体系化されていて、The 12 Principles of UX in Motionこれがモーション理論がよくまとまっている。モーションの価値は以下の通りで、Material Designもモーションについて体系化されて詳しく説明されているので先ほどの記事と併せて読むと理解が深まる。

非文字言語での対話
動きによって意味を与える
意味のない動きをなくす
時間軸に沿った状態を表現する
未来を示唆する

最後に

貴重なお話を聞くことができて楽しかったですし、特にFlutterはアリババが一番使い倒しているというのは非常に興味深かったです。僕はエンジニアなので、Material Themingを適切に導入できるように日々アップデート情報をキャッチアップしてさらにデザイナーさんに共有していこうと思いました。ありがとうございました！

2018-05-23

Slackの新機能「Actions」で遊んで見る

Slack

こんにちは、凪のお暇を読んで「なんか・・めっちゃMP持ってかれた・・・」という経験をしたのが先月でした。続きが楽しみでありつつ、願わくば元気な時に出てほしい・・・

[まとめ買い] 凪のお暇

作者: コナリミサト
メディア: Kindle版
この商品を含むブログ (1件) を見る

PHPとかやってます金城(@o0h_)です。

さて、昨日は突発サク飲みを経て帰宅後、だらだら〜っとインターネットを見ていたのですが。
Slackから「どやどやどや！」なアップデート情報が飛び込んできまして、今日は早速触ってみたよ！という記事を書きます。

Slack Actionsについて。

2018-05-23

Connehito Marché #2 ~webフロントエンド市~ を開催しました！

f:id:dachi023:20180522145017j:plain

こんにちは。エンジニアの安達(@ry0_adachi)です。先週金曜日(2018.05.18)にコネヒトマルシェの第2回を無事開催することができました 🎉せっかくですのでイベントの様子やLTの内容などを本記事でレポート、ご紹介させていただきたいと思います。

connehito.connpass.com

今回のマルシェのテーマ

今回は「webフロントエンド」がテーマです。

ちなみにコネヒトマルシェでは毎回テーマを変えており、前回はAndroidでした。

発表内容

ママリのweb技術の今と未来

3行まとめ

ママリではいろんな機能でweb技術を活用している
ママリは負債と向き合いながらも前進している
開発効率をあげてユーザーにたくさん還元していきたい

PWA概論

3行まとめ

PWAはネイティブアプリの代替手段ではない
ユーザーに浸透するまではまだかかりそう
PWA対応は機能ごとに1つずつやっていくことが可能

安全にデータを扱うコードの書き方

(資料公開なし)

3行まとめ

ES2015よりも前の時代はなんでもアクセスできちゃってた
constの登場によって取り扱いが容易になった
データはImmutableで扱うことでより安全にデータを扱えるようになる

Don't kill a dragon Rescue the princess (react + golang E2E TDD)

3行まとめ

APIが存在するアプリケーションでTDDを実践したい
細かい改修のたびにモックの修正をしたくないのでユニットテストをやめてE2Eテストだけでやってみた
Client/API/DBなどのレイヤーで分けるのではなく機能ごとに分担して開発していくことでE2Eをやりやすく

30代から始めるwebフロントエンド入門

3行まとめ

数年ぶりにJavaScript触ったら世界が変わってた
初心にかえり、片手間でやらずに覚悟を持って向き合った
何かを始めるのに年齢は関係ない！

懇親会

今回は美味しいサンドイッチとお酒を手に乾杯しました。参加者の方々は登壇者の方に質問や感想を伝えていたり終始楽しそうな雰囲気で幕を閉じました！

次回開催は？

7〜8月頃の開催予定です。お題はまだ決まっていません！諸々決まったらconnpassやTwitterなどで告知します 🙇

2018-04-05

"@connehito/eslint-config" をnpmで公開しました

こんにちは。エンジニアの安達(@ry0_adachi)です。

今回は社内で利用しているESLintの設定ファイルを @connehito/eslint-config という名前でnpmに公開したので、公開しようと思った理由なども含めて書いていきます。

ちなみに、これが初のコネヒトという会社名義でのnpmへの公開となります🎉 www.npmjs.com

公開する前のお話

公開しようと思った理由

npmに上げるまでは各リポジトリに同じような内容の .eslintrc が存在していて、どこかのリポジトリの設定を更新したら「あっちも同じように更新したいな」となり、それをまた別のリポジトリでやって...というような感じでとても面倒でした。そして各リポジトリにあった設定は「同じような内容」であって「全く同じ」わけではなかったのでこれもまた私の作業をより面倒にしていました。

面倒な作業を早く簡単にしたい！設定はどのリポジトリでも一緒でいいのでは！という思いが強くなっていき、それで今回npmに公開して各リポジトリでnpmから落としてくるだけのフローにしました。

公開するまでにやったこと

ESLintの設定を見直す
npmのOrgを作成する
会社名義でpublishするときのルールを決める

あたりが事前にやった作業です。

ESLintの設定を見直す

各リポジトリで微妙に設定が違ったりしていたのもありましたし、その時はPrettierのようにコードフォーマットをお任せできるようなものが入ってるわけではなく、rulesの中には2年前くらいに考えた大量のオレオレルールの記述がされていて、どれがどういうルールなのかを覚えているのも大変でした。

そんな理由から既存のオレオレルールはなくしたかったので、extendsだけでなるべく完結させることにして、あとはGitHubやエディタ上でいい感じの見え方になるような最低限の設定(1行の最大文字数、セミコロンつけるつけない、クォートの種類)だけにしました。

これでどんなルールを設定したか覚える必要もないですし、ESLint本体やpluginをアップデートすればextendsしているrecommendedな設定が更新されていくので最高です。

github.com

npmのOrgを作成する

https://www.npmjs.com/org/create からOrganizationの作成ができるのでぽちぽちやっていきます。実際作った時には間違えて通常アカウントで作ってしまったのですが、有難いことに通常アカウントをOrgに変換する機能がついていたのでなんとかなりました、よかったです。

会社名義でpublishするときのルールを決める

npmに公開したい〜！な人が現れた時のためにアカウント作成やscopeの統一(パッケージ名に@connehitoとか入ってるところ)、publishする時に気をつけることなどを社内ドキュメントにしました。私だけでなくいろんなメンバーに気軽にチャレンジしてもらいたい、という思いを込めて作成しています。

公開した後のお話

公開したあとは各リポジトリに @connehito/eslint-config をインストールして .eslintrc の内容を修正したのちに、各アプリケーションの実装や環境に合わせてenvやglobalsを上書きしました。

---
extends:
  - "@connehito"

公開後の各リポジトリのメンテナンス

@connehito/eslint-config を更新したら各リポジトリで yarn upgrade して eslint --fix するようになりました。設定いじらずにとりあえずコマンド打てば良い状況になったので、あとはCIで定期的に回すなどして自動化できると良いなぁと考えています。

さいごに

npmで公開した経験があまりないので今更ですがkeywordの設定とか依存関係の書き方とかもっとスマートな書き方があるんじゃないかという気がしてきました。気付いた点などあればissueなどでもらえるとものすごく嬉しいです！日本語でももちろんオッケーです！

たくさんの人に見てもらえる場所でたくさんフィードバックをしてもらえる方が作った側としては有難いし嬉しいので、今後も公開できそうな便利なものがあればどんどん公開していこうと思っています。

2018-04-03

データ民主化の実現とRedash

こんにちは。インフラエンジニアの永井(shnagai)です。

今回は、ここ数ヶ月で進めていたコネヒト社でのデータ民主化について書こうと思います。 ※技術的な話はあまりなく、社内向けプレゼンに使った資料をベースにした内容です。

コネヒト社は、ママリというママ向けのアプリとWebを運営しており、もちろん様々なデータを持っているのですが、データ活用に関して下記のような課題を抱えていました。

データに関する課題

1. データが色々なところに存在している

BigQuery,Mixpanel,GA,RDS等様々な場所にデータが点在しているので一望する事が難しく、どこに何があるのかも一部の人しかわからない。 tableau経由で様々なデータソースにアクセス出来る環境はありましたが、その一部のメンバにデータ抽出を依頼する事がコストとなっていました。

2. エンジニアやデータに詳しいディレクターに頼まないとデータが出せない

1と少し近いのですが、データの場所も出し方もわからないのでデータ抽出をしたい時はデータ抽出依頼が必要となっていて、気軽に思いつきのデータを出してもらうのは敷居が高い状況でした。また、データ抽出の得意なディレクタの時間がデータ抽出業務で逼迫されるという状況も起きていました。

3. 抽出データの保存先が多種多様でストックが出来ない

スプレッドシートやそれぞれのデータソースにグラフやデータが点在していました。新しくジョインしたメンバは、中々データの所在が把握出来ない歯がゆい状態でした。

一緒に、データ民主化を進めていたエンジニアと話していたところ社内で下記のような悪循環が起きているのではという仮説立てをしました。

データとか使って検証できたら良し悪しを判断しやすい！
but
データ出せないと「高度に詰めて考えなきゃいけない」
but
「データを出す」には、人に依頼しないといけないから、「依頼コストが高い」という悪循環・・・

理想の姿

データを出すことに対する敷居を下げる↓(データの民主化)
各担当領域でのアイデア出し/提案/改善に定量的な側面をもたせやすくして、みんな仕事がしやすくなるといいな
非エンジニアがSQLをある程度使いこなせている状態にもっていきたい

「もしデータがかんたんに自分で出せる」と
↓
「考えまくる前にデータ出してサクッと確かめてみよ」ができるから
↓
「アタリ」っぽかったら深掘りすればよい！ハズレだったら、すぐ忘れる

=> データの民主化が達成された世界は素敵！！
(&「データで考える」は慣れでしかないので、やっているともっと感じがよくなっていく

Redash

データ民主化の切り札となるBIツールにはRedashを採用しました。 Redashは様々なところで事例も出ていますので詳細は説明しませんが、下記のような利点から導入を決めました。

データ閲覧のインターフェースを出来るだけ、統一することが一番大事だと思っていて、よりよいものが出てきたらRedashから乗り換える可能性は大いにあります。

Redashの良いところ

出したデータをそのままビジュアライズ出来る
SQLの再利用が出来る
URLをそのままシェア出来る
通知やCSVエクスポートも可能
スケジュール機能を使って定期実行も出来る
無料！！

技術的な面

AWSのAMIが提供されている構築コストはほぼゼロ
Google認証のみにすることでセキュリティを担保出来る
Pythonデータソースがあるので、エンジニアのアイデア次第で何でも出来る
開発も活発で便利な新機能が追加されている

TIPS

簡単にデータソース間のjoinが出来る

データ分析をしていると、例えばマスタDBのデータとアクセスログをjoinしたいというようなケースが頻繁に現れます。 Redashでは、Query Resultsという機能を使うことで簡単にデータソース間のjoinが出来ます。

SELECT a.name, b.count 
FROM query_123 a 
JOIN query_456 b ON a.id = b.id

参照: https://redash.io/help/user-guide/querying/query-results-data-source

slack botの活用

Redashは標準で、slackのインテグレーションがあります。 https://redash.io/slack

RedashのクエリURLをslackに貼り付けるとそのままRedashでグラフが表示されます。これのおかげで、一々画像キャプチャを撮ってslackに貼り付けるといった手間が省略出来ます。また、slackのリマインド機能と連携することでslack上で簡単に定点観測が出来たりします。

クエリの再利用

Redashの良いところにクエリのフォーク機能があります。いきなり自分で一からクエリを書くのは敷居が高いですが、他の人のクエリを見て勉強したりコピペから少し変えてみるといった事ができ気軽に始められます。

現在の状況

ちょうど振り返りのような機会があり、社内で下記のようなフィードバックをもらいました。

Redashを導入したことで見れる数字がめちゃ増えてる
本当にデータが民主化され、職種問わずみな興味を持っている
データにアクセスしやすくなったので、視野が広がり実務に役立っている

ちなみに、12月にRedashを導入したのですが、現在600クエリ&80ダッシュボードが運用されています。ひとまずデータを見ることの敷居を下げることはRedashの導入で実現出来たのではないかと思っています。

新しくジョインしたメンバも、Redashにログインすればどのようなデータがあるのかを一望し即座に分析を行うことが出来る状態になりました。

また、社内で有志のSQL勉強会が開かれていて実データを元に日々非エンジニアもSQL力向上を図るという流れも生まれました。

まとめ

今回は、社内でRedashを導入してデータ民主化を実現した話について書きました。私自身、営業やディレクターが作ったクエリを眺めていると、自分にはない発想に出会ったり気づきがありますし面白いです。データが、オープンであることはとても大切だなと実感しています。今後は、ETL周りを整備して、より早くデータを出せるような基盤を作っていこうと思っています。

コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com