読者です 読者をやめる 読者になる 読者になる

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

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

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

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

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

背景

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

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

JIRAとは

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

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

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

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

JIRAの良さ

Kobito.RTkna4.png

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

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

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

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

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

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

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

運用のコツ

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

ワークフロー

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

工数見積もりの見える化

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

JIRAコメントでの進捗共有

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

エピックの活用

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

振り返り

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

まとめ

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

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

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

Kotlin勉強会をしました

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

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

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

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

Kotlinとは

https://kotlinlang.org/ f:id:jmty_tech:20170203174553p:plain

  • Java言語で書かれたライブラリを呼び出すことができます
  • Javaの記述をより短く書けます
  • Null安全などJavaにはない安全に書ける仕組みがあります
  • AndroidTomCat等、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処理を勝手にしてくれます f:id:jmty_tech:20170203174438p:plain
  • 開発時にNullで落ちない Java -> Kotlin変換時に!!を使った時以外、Nullによる例外は発生していないです。
  • 変数、メソッドが揃ってて見やすい
    • fun/var/valとみんな3文字&型記述があとになるため、揃う f:id:jmty_tech:20170203174527p:plain
  • Scalaみたく重くない
  • 型推測がすごい楽
    • 型を変えたい時に、いちいち2箇所変える必要がない
  • 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が多いアプリの場合は時間短縮ができ、とても便利でした。 f:id:jmty_tech:20170112130837p:plain

導入効果

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

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

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

今後の展望

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

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

エンジニアの上垣です。

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

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

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

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

前提

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

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

フレームワークの選定

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

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

Foundationのインストール

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

Gemfileに追加

gem "foundation-rails"

インストール

$ bundle install

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

$ 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上に作成しています。

f:id:jmty_tech:20161227105206p:plain

導入効果

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

今後の展望

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

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

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

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

背景

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

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

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

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

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

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

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

f:id:jmty_tech:20161219115748p:plain

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インスタンスにアクセスし、データソースを設定します。

f:id:jmty_tech:20161219100157p:plain

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

f:id:jmty_tech:20161219101048p:plain

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

embulk

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

プラグインの一覧はこちらです。→List of Embulk Plugins by Category | Embulk

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

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

導入効果

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

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

今後の展望

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

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

ジモティーにジョインする醍醐味

サーバサイドチームでマネージャーをしている橋本と申します。

ジモティーで開発する魅力を社内外に発信したいという機運が弊社エンジニアの中で盛り上がり、今日からジモティーTechBlogがスタートしました。

エンジニアメンバーそれぞれが、インフラからフロントエンドまでの個別の技術的な要素や開発プロセスなどエンジニアの文化面での要素など書きたいことがあるようですが、これらはそれぞれで伝えたい事があるメンバーに書いてもらおうと思っています。是非、楽しみにしてください。

今回、私がジモティーで開発する魅力を書くにあたって、何を書くのが一番良いか考えてみました。 私自身が7月からジモティーにジョインして、約半年経とうととしていますが、 自分がジモティーにジョインしてからすごいと思ったことや、気づいた点を書くのが一番なのではないかと思いました。

ベーシックに、あくまでベーシックに

書きたいポイントははたくさんあるのですが、今回はジモティーが開発においてベーシックな部分をベーシックに貫いているところをご紹介しようと思います。

サイトの構成は本当にWebサービス業界ではベーシックなサーバサイドはAWS上でNginx + RubyOnRailsを運用しています。

バックエンドのDBの構成少し変わっていて、メインのDBはmongodb、決裁系などのミッションクリティカル性が高い部分についてはRDS Auroraを利用する構成になっています。

f:id:jmty_tech:20161227121918p:plain

この構成自体は特に珍しい点はないのですが、この構成で月間でユニークユーザーで約640万のリクエストを捌いているのがすごいところです。 ジョインした時に弊社のCTOの鈴木に「すごいですね」と言ったところ、

「すごくはないです。あるリソースをスケールアップ/アウトしても、他のリソースが、というようにボトルネックは常に移り変わるので、負荷テストで次のボトルネックを探し対応するということ繰り返しです。」 ということでした。

鈴木曰く、ベーシックにやっていればこの繰り返しでここまでは行けるけれど、MongoDBをここまでのリクエストをさばけるようにするのが一番大変だったようです。

他にも弊社のエンジニア達によって、開発をスピードアップをするための施策が数々行われています。

  • githubをハブとしたプルリクエストとレビューによる開発フロー
  • Circle CI 、Side CI、 を用いたリリースブランチへのマージ後のソースコード検証と自動テストとデプロイの半自動化。Blue Green Deploy
  • CloudFormationによるインフラのソースコード
  • データ分析基盤としてのRedshiftの利用(弊社の鈴木がこの件で記事を書いています)

ちなみに、インフラについてはDockerも開発環境構築に一部使っているだけなのですが、もう少し本番環境で使っていきたいねという話をしています。

Ruby biz グランプリ特別賞を受賞

橋本が会社に入って最初の仕事がRuby bizグランプリへの応募でした。この募集要項を見かけて、鈴木に「やりましょう!」と言って、応募書類を弊社のビジネスチームのメンバーと相談しながら作りました。

おそらく、弊社が行っている社会的意義の高いサービス(本当に日本全国津々浦々様々な方にご利用いただいています!)とRubyRuby on Railsの高い活用度合いから受賞を狙えるのではないかと目論んだからからです。

特に弊社の場合、KPIベースに開発施策を決めてその達成に向けて走りながら開発を進めますが、社内で見せるモックアップや高速な検証プロセス(大体2週間位で回しています)をRubyRuby on Railsが支えてくれています。

おかげさまで、最終選考に残り、惜しくも大賞は逃しましたが社会的意義の高さが評価されて、特別賞を受賞することができました。 弊社のエンジニアは現在15名いますが、鈴木は2〜3名だった頃からもくもくと作ってきたかいがあったと喜んでおりました。

f:id:jmty_tech:20161227123051j:plain

下のトロフィーは今社内で飾られていますが、受賞の誇りを胸にさらにサービスをよくしていくよう頑張っていきたいと思います。 f:id:jmty_tech:20161227123135j:plain

さて、弊社のエンジニア体制、来年1月から17名体制となります。 今後の成長に向けて、一緒に働いてくれる人を募集しています。 ご興味のある方は、是非下記までお問い合わせください。

株式会社ジモティーの採用/求人一覧 - Wantedly