デザイン制作が捗るSketchプラグインについて

はじめまして。デザイナーの藤井（理）です。
現在、ジモティーでは様々なページやUIの改修・制作などを同時に取り組んでおり、デザイン制作をする中でクオリティはもちろんのことやはり、スピード感も重視されます。

そんな中、私がデザイン制作をクオリティを意識しつつ・効率よく素早く完了させるために日々、よく使用しているデザインツールがSketchになります。
Sketch · Design, collaborate, prototype and handoff

Sketch自体はUIもシンプルで使い方もで簡単に利用できるため、デザイナー以外にも利用されている人は多いと思います。 そんなSketchでデザイン制作が捗るプラグイン３つご紹介させて頂きたいと思います。

Sketchプラグイン３つご紹介

数多くのプラグインが用意されている中でより、制作が捗ると感じたプラグインご紹介させて頂きます。

１.｢Sketch Guides｣

手作業でガイド引くを手間を省けるプラグイン https://celynxie.com/sources/sketchguides.html

オブジェクトに対して上下左右の中央を自動で簡単にガイドを引くことができます。 デザインをする中で必ずと言って良いほど行う作業の一つでもあるため少しでも負担を軽減できるのはいいですね。

２. ｢Craft｣

プロトタイプで有名InVisionから出ている多機能プラグイン
※Craftの機能の中の「Duplicate」を使用

https://www.invisionapp.com/craft

いくつかの機能を持ち合わせている中の一つ「Duplicate」はデザイン要素を複製でき、要素を垂直・水平にピクセル単位で正確に複製することができて繰り返しの作業がとても楽に出来ます。リストの制作の際などで時間短縮も出来、とても便利です。 その他にもCraftにはダミーテキストや写真を入れられる便利なプラグインなどがいくつか用意されてますので色々な場面でとても便利です。

３. ｢Sketch Measure｣

実装に必要な情報を自動で書き込んでくれるプラグイン https://github.com/utom/sketch-measure

オブジェクトのサイズ・余白・距離・スタイルなど実装に必要になる情報を生成してくれるプラグイン。アートボードをエクスポートすることでワンクリックでHTMLページを自動的に生成しオフラインでCSSスタイルなどの実装に必要なデザイン詳細を見ることができます。エンジニアとの様々なやりとりの効率化出来るので、デザイナーとエンジニア間のやりとりでのプロセスの改善に期待大です。

まとめ

日々の業務の中で小さなことではありますが、何気なくやっていることや完了後に振り返ってみると地味に時間がかかってしまっているような作業（オブジェクト複製作業だったりetc..）を効率化することで当初、予定していた工数見積もりよりも早く終わらせることも出来たりもした案件もありました。

今回は３つのみの紹介ですが、他にも様々な高品質なプラグインがあるので用途などに応じて、今後もプラグインを追加してみてより効率よくデザイン制作を進め、より良いプロダクトを世に出していきたいと思います。

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

ジモティーでのタスク管理について

こんにちは ジモティーでiOSエンジニアをしている小林です

今回ジモティーで利用しているタスク管理ツール「JIRA」の活用及び利用促進活動をメインで担当する機会があったので、JIRAについて書いてみようと思います！

日頃、誰がどんなタスクをどのくらい抱えていて、進捗はそれぞれどうなっているのか。プロジェクトの管理者やマネジメント者はその辺りを把握するためにタスク管理ソリューションを何かしら使っていると思います。

ジモティーでなぜJIRAが採用されたのか、使ってみてどうだったのかをご紹介していこうと思います！

背景

弊社ではもともとRedmineを利用して課題の管理をしていました。 なぜJIRAにしたかというと、非エンジニアとのタスクについてのコミュニケーションに課題を感じていたからです。

実はチーム単位ではTrelloなど導入していて個々に最適化はしていたものの、全社導入するにあたっての諸要件をクリアできなかったので数あるサービスから消去法でJIRAが候補として残った経緯があったりします。

JIRAとは

JIRA Softwareは、Atlassian(アトラシアン)社が開発した課題管理ツール(プロジェクト管理ツール)です。その高度なカスタマイズ性により、バグ管理ツールの枠を超えて、タスク管理、工数管理、進捗管理、スケジュール管理などプロジェクト全般を広く管理します。複数プロジェクトの進捗やタスクを一元管理します。

JIRA Softwareは、チーム内でのタスクの見える化を簡単に実現します。

スクラム、カンバンに対応しています。 参照：ricksoft

アジャイル開発で課題となるタスク管理、工数管理、進捗管理、スケジュール管理、振り返りが１パッケージで可能で、しかもある程度の見易さ・使いやすさが売りという感じです！

JIRAの良さ

ジモティーではアジャイル開発を行っているためスクラムモードで運用しています。 スプリント毎にタスク・アサインの管理ができるのが選択のポイントでした。

1. 誰が何をしてるのか分かる！ 進行中のスプリントが表示されている画面で、進行中のタスクはそれぞれ誰が担当しているのか一目瞭然！

2. 誰がどれだけ作業しているのか分かる！ 進行中のスプリントでメンバーがどのようなアサイン状況か一覧できるのでスプリントにどれだけタスクを入れられるか判断しやすくなりました

3. 非エンジニアからも進捗が把握し易い！ これだけビジュアライズされているので、Redmineに煩雑さを感じていた方も直感的にみやすくなったのではないでしょうか！

4. 作業依頼がしやすくなる！ スプリント毎にどの程度タスクが埋まっているのか把握できるので、Aさんの工数余裕ありそうだから、〇〇の修正やってもらえるかな？など見込んでから依頼ができるのでスムーズなコミュニケーションができるようになりました

5. 振り返りが明快になる！ JIRAにはスプリント毎のレポート機能があり、バーンダウンチャートや完了タスク・繰越タスクを確認しながら振り返りを実施できます。 ジモティーでは要振り返りタスクにラベルを設定して振り返るべきタスクを明確にしリリース結果の数値を見ながら円滑に振り返り会議を進めています 次回スプリントへのフィードバックもタスクのコメントにメッセージを残すことで振り返り会議に参加していないエンジニアへの情報共有も漏れがなくなりました！

6. 適切なワークフローを意識して手戻りが減る！ JIRAの使い始めは特にフローを意識せず作業前-作業中-完了でやっていたのですが、ヒアリングを行い現状で最善なワークフローとなるよう整理してJIRAヘ反映させました。 タスク毎にどのような観点が必要かアサイン者が理解しやすくなる、或いはレビュー者のレビュー観点漏れ抑止にも繋がり手戻りが減り気持ちよく作業ができる環境へ近づいたのではないでしょうか。

運用のコツ

２ヶ月程ですが運用した気づきを書いていこうと思います

ワークフロー

ワークフローの整理は導入初期にするべきです。自分たちのタスク遂行がどのようなフローで行われていて、どこでスタックしているのかを整理することで最善なフローへ導くことができると思います。そのフローをJIRAへ反映させ、タスクを遂行する上での留意点を意識しやすくすることで考慮漏れや共有漏れが減るのではないでしょうか。

工数見積もりの見える化

最初の設定が煩雑な気もしましたが、徐々に使い慣れていき「JIRAの良さ」で説明した通り、工数の把握がしやすい形にしていきました。

JIRAコメントでの進捗共有

レビューや重要なチェック要素についてはコメントにログを残すようにしています。例えば予想見積もりを超える工数を要したタスクの振り返り時にログを見返すことで適切なフィードバックを得られるようになります。

エピックの活用

エピックは通常長期に渡る案件を管理する箱のようなものですが、ジモティーではタスクの振り分け用に使用しています 各エピックへ関連づけられたタスクを、エピック毎に把握しやすくなり手薄になっている観点や今後の施策立案の適正さの維持に役立っています

振り返り

タスク毎に振り返り記載用のフィールドを用意して、数値的振り返りが必要なタスクについて担当者が記載するようにしています。 振り返りが必要なタスクへのラベル付けと合わせて、円滑に振り返りミーティングを進められるようになり、適切なフィードバックが行えるようになりました。

まとめ

今回、エンジニアメンバーへのJIRA利用促進と合わせて、マネジメントサイドへのJIRAを用いた状況確認の方法の共有をさせてもらいました。 そこでの気づきは、作業フローの属人化やスタックしやすいフローを継続しているシーンなど散見されることを認識出来たのが改善に直結したと感じました。 把握できた課題をJIRAを通して改善へ導くことも非力ながら貢献できたのかなと思います。

JIRAは機能が豊富だし、拡張性も非常に高いので各組織での最適な利用方法は千差万別だと思います。しかし、できることをしっかり理解して組織に根付くことを最優先に運用することで作業する側もマネジメントする側も気持ちよく働けるようになると実感しました。

このエントリーが参考になれば幸いですが、JIRAに限らず色々な管理手法を試していこうと思うので何か発見があったときに、またここでご紹介できればと思います！

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

Kotlin勉強会をしました

ジモティーのアプリチームにて、Androidの開発をしている小林真です。

ジモティーではよく勉強会が行われます。

勉強会では、自分が新しく知ったことや、メンバーに知っておいてもらいたいことを中心に話されています。

今回は、1月の社内勉強会で私が発表した、Kotlinについて説明をしたいと思います。

Kotlinとは

https://kotlinlang.org/

• Java言語で書かれたライブラリを呼び出すことができます
• Javaの記述をより短く書けます
• Null安全などJavaにはない安全に書ける仕組みがあります
• AndroidやTomCat等、Javaのフレームワークにも対応しています

Javaでできることをより短く、安全に、便利に書けるようにした言語です。

Javaとの書き方の違い

• 変数
  • Javaで型宣言していたところはvar/valに統一できます。

java

public int i = 1;<-Kotlinではデフォルトのアクセス制限がpublicとなります
public MyObject obj = new MyObject();

kotlin

var i = 1  <- 型推測でInt型になります
val obj = MyObject() <- newが必要ない
val str : String = "foo" <- 型を指定することもできます

val

valはjavaでいうfinal(変数の変更不可)です。

変数を変更不可にし、意図しない変更を行えないほうが良いので、基本的にvalを使い、どうしても後で変更したい変数のみをvarにするのが良いでしょう。

java

public final String str = "foo"   

kotlin

val str = "foo"
str = "bar" <- コンパイルエラー

null安全

Kotlinを使う大きな理由の一つです。

「null安全」と聞いて、「nullが存在しない言語」と思うかもしれませんが、そういう意味ではないです。

「nullを入れられない変数」と「nullを入れられる変数」を明確に区別して、nullの影響範囲を最小限にします。

そして、「nullを入れられる変数」にnullを入れて、メソッド参照等をしようとした時(JavaだとNullPointerExceptionになるような動き)、 例外が発生しないような振る舞いをしてくれる仕組みです。

一方、「nullを入れられない変数」にnullを入れようとしたり、nullが入るかもしれない参照をしている場合、コンパイルエラーが出てくれます。

これにより、意図しないnull参照、代入を防ぐことができます。

• Nullが入れられる変数(nullable)には、String?のように?を追加します
• nullableのメソッドを呼び出すには、?.とする必要があります

//var nonNull1 : String = null <- コンパイルエラー
var nonNull2 : String = "foo" <- 通る
var nullable : String? = null <- 通る
var i : Int? = nullable?.length <- 落ちない(nullが入る)

?を!!にすることで「この変数は絶対nullじゃない」と宣言できます。

しかし、NullPointerが発生する穴を生むので、あまり使わない方がいいでしょう。

var nullable : String? = null
var i2 = nullable!!.length <- nullPointerException

AndroidでKotlin使ってみた

AndroidはKotlinでも書くことができます。

Javaより使いやすい言語なら、結果的に効率よく開発ができるのではないかと思い、個人で作成しているアプリをKotlin化してみました。

ここでは、良かった点、悪かった点を書きたいと思います。

ここ良かった

• 「とりあえずval」が可能

javaでfinalは目立つし、わざわざつける必要があるので、あまり使っていませんでした。

valなら、一文字しか変わらないので、「これは変更しないな〜」って思って初めてvarにする、といったコードの書き方ができます。

• useが便利
  • DBアクセス等で必要なclose処理を勝手にしてくれます
• 開発時にNullで落ちない Java -> Kotlin変換時に!!を使った時以外、Nullによる例外は発生していないです。
• 変数、メソッドが揃ってて見やすい
  • fun/var/valとみんな3文字＆型記述があとになるため、揃う
• Scalaみたく重くない
• 型推測がすごい楽
  • 型を変えたい時に、いちいち２箇所変える必要がない
• AndroidStudioの言語サポートもJavaと変わらないくらい便利になっています

ここ悪かった

• Kotlin+DataBinding+XMLではまる

DataBindingでミリ秒を時刻表示するためにのDataUtilクラスを使っていました。

Kotlinでは外から見てJavaのStaticメソッドとして扱うには@JvmStaticアノテーションが必要でした。

なのに、「DataBindingの構築に失敗しました」としかでないから、KotlinでDataBindingを使うための設定をいじったりしていました

エラーが出ても丁寧な情報がネットに載ってないので、情報を正しく得る力が必要です

• valとかnull安全とか有効に使うためには、MVCとかMVVMとかの導入が必要かなと思った

AndroidライブラリがJavaなので、Activityに処理を書くと意味がなくなります(JavaライブラリをKotlinで呼び出すときは、Nullableで値が来ます)。

そのため、View層、Model層って分けないとvarや、Nullableの変数ばかり必要になります

勉強会をしてみて

自分一人で勉強していたことを、いざ発表することとなると、結構曖昧に覚えていた知識とかがあり、確認ができていい機会でした。

iOSアプリ開発者の人と、Swiftと似ている所、違うところを話したりして、有意義な時間でした。

Kotlinをジモティーで使うか

チーム内でKotlinに関する知見をためていき、タイミングを見て移行していこうとチーム内でKotlin熱が上がっています。

現状にとどまらず、新しいことをしていくことで自分たちも、新しく入る人達も古いコードを見て悩まないようにしていきたいです。

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

ジモティーでプロトタイプ作成ツール「Adobe XD」を導入した話

はじめまして。ジモティーでデザイナーをしております藤井です。 今回は、ジモティーで導入しているプロトタイプ作成ツール「Adobe XD」について説明したいと思います。

背景

• 簡単に素早くプロトタイプを作成したい。
• 完成品に近いイメージ共有をして手戻りをなくしたい。

以上のきっかけが元で導入してみることにしました。

機能

• イラレ、Sketchのような「デザインモード」と、prottのような「プロトタイピングモード」で別れており、両方を行き来しながらこのツール一つでプロトタイプを作成することが可能です。動作に関してはアートボードが増えても非常軽いのが魅力です。

• 「リピートグリッド」という要素をまとめて繰り返し表示させる機能があり、自由に横縦方向に数を増やすことが可能で、ジモティーのようなリストやグリッドUIが多いアプリの場合は時間短縮ができ、とても便利でした。

導入効果

• デザインとプロトタイプを行き来しながら作成でき、動作も軽いので作業効率が上がりました。

• 作成したプロトタイプは同Wi-Fiネットワーク内ですぐに反映されるので、実機確認が簡単になり作業効率が上がりました。

• 実際に動きを見せながらエンジニアとコミュニケーションを取ったり、動画で保存し繰り返し確認できるので、イメージ共有の精度が上がりました。

今後の展望

今後も「Adobe XD」を使用して効率よく質の高いプロトタイプ作成を進めると共に、 手戻りの少ないワークフローを構築していきたいと思います。

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

RailsアプリケーションにCSSフレームワーク(Foundation6)を導入する

エンジニアの上垣です。

おかげさまでジモティーは日々多くのユーザー様にご利用いただいているのですが、その反面、長年の開発の歴史の積み重ねにより、CSSファイルの肥大化、複雑化が起こっており、これにより、画面作成工数の増大、ページ間レイアウトに差異ができるなどの問題が発生しています。

これらの問題を解消するために、現在、以下２つの取り組みを実施しています。

• CSSフレームワークの導入
• 既存のCSS設計手法を取り入れた記述ルールの策定・運用

フルリニューアルをかけられるのであればそれに越したことはありませんが、ジモティーのサービス規模を考えると、影響範囲が大きいので、既存サービスを運用しながら、段階的に置き換えていく手法が必要になってきます。

今回の記事では、既存Railsアプリケーションに、段階的にCSSフレームワークを導入する手順についてご紹介します。

前提

今回の手順は以下のバージョンを対象にしています。

• rails 4.2.5
• foundation-rails 6.2.4.0

また、HTMLはhamlで、CSSはSassで記述しています。

フレームワークの選定

導入実績の多さ、使えるコンポーネントの種類、documentの豊富さを主な観点に、候補として以下3つのフレームワークに絞りました。

• Bootstrap getbootstrap.com

• Foundation foundation.zurb.com

• Semantic UI semantic-ui.com

各フレームワークについて、branchを切って検証しつつ、選定を進めました。利用できるコンポーネントにほとんど差異はなかったのですが、既存のアプリケーションへの導入のしやすさ、カスタマイズ工数の少なさ、documentの豊富さなどから判断して、Foundation6 を導入することに決めました。

Foundationのインストール

現状ジモティーでは、フロントエンドのビルドツールを導入していないので、素直に gem を利用します。Foundation には foundation-rails(https://github.com/zurb/foundation-rails) というgemが提供されているので、まずはインストールします。

Gemfileに追加

gem "foundation-rails"

インストール

$ bundle install

gem のインストール後、下記コマンドを実行して、以下２つの設定ファイルを生成します。

$ rails g foundation:install

• foundation_and_overrides.scss
• _settings.scss

主に _settings.scss を編集して、既存サイトのデザインと馴染むようにカスタマイズしていきます。

CSSのエントリーファイルを作成

Foundationをインポートする、新しいCSSのエントリーファイルを作成します。サービス固有のCSSがFoundation で上書きされないように、必ずFoundationの設定ファイルの先頭でインポートしておきます。このファイルは、既存のCSSファイルに import されないように注意してください。

app/assets/stylesheets/v2/application.scss

@import "foundation_and_overrides.scss";

// 以下にサービス固有のCSSファイルをインポートする

JavaScriptのエントリーファイルを作成

Foundation は jQuery が必須なので、必ず事前に jQuery を requireします。このファイルも、既存のJavaScriptファイルからrequire されないよう気をつけてください。

app/assets/javascripts/v2/application.js

//= require jquery-1.12.4
//= require jquery_ujs
//= require foundation


// 省略

$(function(){
  $(document).foundation();
})

precompile 対象 に追加する

View から呼び出すために、作成したエントリーファイルをprecompile 対象に追加しておきます。

config/initializers/assets.rb

Rails.application.config.assets.precompile += %w[v2/application.css v2/application.js]

フレームワークを読み込むレイアウトファイルを作成

既存のレイアウトファイルをコピーして、新レイアウトファイルを作成します。stylesheet_link_tag, javascript_include_tag メソッドで先ほどのエントリーファイルを指定して、ページごとに唯一このファイルだけが読み込まれるようにしておきます。

app/vies/layouts/v2/application.haml

- # 省略
%head
  = stylesheet_link_tag "v2/application"
  = javascript_include_tag "v2/application"

- # 省略

フレームワークを適用したい action に、新レイアウトを適用

rails の controller で、フレームワーク適用対象 action の layout を指定します。

app/controllers/sample_controller.rb

class SampleController < ApplicationController
  layout "v2/application" # コントローラー内のすべてのアクションに適用

  def index
    render layout: "v2/application" # このアクションにのみ適用
  end
end
 

以上で、既存CSS, JavaScriptを汚さずに、部分的にCSSフレームワークを適用できます。

まとめ

以上、RailsアプリケーションにCSSフレームワークを導入する手順をご紹介しました。 また、今回の記事では触れていませんが、フレームワークの導入と同時に FLOCSSという設計手法を用いて、CSSルールの策定・運用も並行して進めています。

github.com

こちらについても紹介したいのですが、ちょっと長くなりそうなので、次の機会にそれらの話題に触れられればと思います。

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

iOSアプリ開発フローにリリースマネージャーを導入した話

はじめまして。ジモティーでiOSアプリ開発をしております玉井です。

今回は、ジモティーのiOSアプリをどのように開発しているか説明したいと思います。

背景

ジモティーのiOSエンジニアは3名いて、それぞれが機能追加・修正を行いリポジトリにプルリクエストを送ります。 プルリクエストのレビュアーにアサインされたら、エンジニア同士でレビューを行いマージを行います。 リリースはその時に空いているエンジニアが担当しています。

このフローで進めて行く上で、以下のような課題が出てきました。

• リリース前に必要な作業(関係者への確認会を開く等)があるが、担当者が曖昧でその進捗が不明確
• リリース後のモニタリング(クラッシュや、数字の動き等)をするルールが無くて属人化している

こういった課題を解決するために、リリースマネージャーを導入してみました。

リリースマネージャー

バージョンごとに、リリースに責任をもつリリースマネージャーを1人選びます。 リリースマネージャーは当番制でiOSエンジニアが持ち回りで担当します。

リリースマネージャーのタスクは以下のとおりです。

• バージョンに含める修正内容を決める
• 開発の進捗確認
• リリース作業
• リリース後の監視、振返り

リリースごとにタスクをチェックリストで一覧化したissueをGitHub上に作成しています。

導入効果

『誰が何をすべきか』が明確になり『リリース前に必要なあの作業、誰もやってない気がするけどどうなんだっけ？』といった悩みの解消や、リリース後のモニタリングや振返りの実施が習慣付くようになり、以前より開発フローがうまく回るようになりました。

今後の展望

• iTunesConnectへのアップロード自動化
• CI導入(Bitrise/Travis CI)

良いアプリを作るために出来ることから少しずつ改善を続けていきます。

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです

Redash + Redshift + embulkでデータ分析基盤を構築した話

はじめまして、ジモティーでCTOをしている鈴木です。先日、弊社で構築したデータ分析基盤について紹介します。

背景

仮説の妥当性の担保や、施策の効果検証のためにデータ分析は必須です。 最近ジモティーではビジネスサイドのメンバーが増えてきたことで、社内でのデータ分析が急速に進むようになりました。

これまでは、ディレクターがデータ抽出を依頼→エンジニアが指定されたデータをCSVに出力して渡すという形になっていました。 データの抽出の依頼が週に5、6件発生し、1件毎にエンジニアの工数が数時間取られるという状況です。

これによりエンジニアは本来担当しているタスクが遅延し、 ディレクターはデータ分析のためにエンジニアの作業を待たなければならないという状況でした。

これら課題を解決するために以下をゴールとしてデータ分析基盤を構築します。

ビジネスサイドのメンバーにSQLを習得してもらい、自分でデータ分析できる

またジモティーではメインのDBにMongoDBを採用しています。 MongoDBはNoSQLですので、当然そのままではSQLを叩けません。

ということでMongoDBからembulkを用いてRedshiftにデータを投入し、Redashで可視化することにします。

Redshift

AWSの提供するデータウェアハウスです。 PostgreSQLをベースとしていますので、PostgreSQL互換のSQLを実行できます。 RedshiftとPostgreSQLの細かい違いはこちらを参照してください。

他の選択肢としてはBigQuery、TreasureDataがありますが以下の点を考慮してRedshiftを採用しました。

• AWSで構築している既存サービスとの親和性
• クエリに依存せず固定額（SQLに不慣れなメンバーも実行する前提なので）
• データ量がまだそれほど多くないので安価に始められる

Redshiftクラスタの構築方法については以下のマニュアルを参照してください。

Amazon Redshift の概念的な概要 - Amazon Redshift

Redash

オープンソースのデータ可視化ツールです。標準で以下のような機能を備えています。 ※ v1.0からRe:dash→Redashに表記が変わりました。

• 複数のデータソースに対応→ 対応データソース一覧
• ビジュアライズ … クエリの結果から円グラフ、折れ線グラフ、散布図などを描画
• スケジューリング ... 保存したクエリにスケジュールを設定し定時実行できる

AWSアカウントをお持ちであれば公式からAMIが提供されていますので1分で起動できます。 http://docs.redash.io/en/latest/setup.html

起動後にブラウザでRedashインスタンスにアクセスし、データソースを設定します。

以下のようにRedash経由でSQLを実行することができます。※テーブル名、列名等はダミーです。

ちなみにRedashはデータソースにMongoDBを指定することもできますが、 非エンジニアにMongoDBのクエリを習得してもらうのは学習コストが高すぎると判断して止めました。

embulk

embulkはオープンソースのデータ転送ソフトウェアです。 プラグイン機構によって様々なデータベース/データストレージ/ファイルフォーマットに対応できます。 今回はMongoDBからRedshiftへのデータのインポートに利用します。

プラグインの一覧はこちらです。→Embulk: Plugins

今回はmongodbから取得したデータをRedshiftに投入したいので、以下のプラグインを利用します。

• embulk-input-mongodb
• embulk-output-redshift

また、MongoDBのデータはJSON形式で取り込まれますがそれをRedshiftに投入できるように列形式に展開する必要があります。 そのために以下のプラグインも追加します。

• embulk-filter-expand_json

導入効果

導入から2ヶ月経過しましたが、現在200近いクエリが登録されていて、その大半がビジネスサイドのメンバーのものです。 エンジニアがデータ抽出に工数を割くこともほぼ無くなりました。 データ分析の速度は格段に向上したと言えるでしょう。

活用を促進するために、SQLの講義を行ったり、参考書籍として「10年戦えるデータ分析入門」を紹介するといった啓蒙活動も行っています。

今後の展望

今後は以下のことにも挑戦していきたいと思います。

• 現状、DBに保存されているデータだけが対象となっているが、サーバーログやGoogle AnalyticsのデータもRedash上で分析可能にする
• Airbnb製のデータ可視化ツール Superset を試す

---

弊社では一緒にプロダクトを改善していただける仲間を探しています！

こちらでお気軽にお声がけください！

ネイティブアプリエンジニアの採用って難しいですよね。。。

ジモティーのウェブチームについてお話ししたいです