開発環境のECSリプレイスとterraformでのコード化

こんにちは、Misoca開発チームの黒曜です。

先日シャニマスの1stライブで会場限定CDを入手したので、作業用BGMにヘビロテしています。
甜花ちゃんのアルストロメリアが特にお気に入りです。

真面目な近況としては、Rails Developer Meetup 2019に登壇するので発表準備をしてます。

railsdm.github.io

以前@lulu-ululが記事にしていたビジュアルリグレッションテストについて、構成やその後などを掘り下げてお話する予定です。
もしご興味があればセッションにお越しください。

tech.misoca.jp

🐳 環境のDocker化

Misocaのローカル開発環境はDockerで立ち上げられるように整備されているのですが、デプロイ先の環境はEC2になっていました。

これでも問題なく運用できていたのですが、以下のような課題がありました。

  • 逐次更新を積み重ねており現状の構成がわからず、新しい環境は既存の環境からスナップショットを取って立ち上げる必要がある
  • 上記に関連し、OS・ミドルウェアのバージョンを手作業で揃えており煩雑
  • レビュー環境はECSで立ち上げており、他の環境と構成に差異がある
  • 一部システムをマイクロサービス的に切り出しており、各環境でそのサービスを立ち上げ連携させていく必要がある

これらの課題をどうしていくか検討した結果、デプロイ先の環境もDockerコンテナを利用してECSに載せ替えることにしました。
合わせて、この構成をterraformで記述してコード管理できるようにし、新しい環境も立ち上げやすいようにしまています。

この記事では、ECS化でどういう構成になったか、terraformをどのように書いたかなどをまとめていきたいと思います。

🏗 大まかな構成

早速ですが、ECS移行後はこんな感じの構成になりました。*1

f:id:kokuyouwind:20190315104620p:plain

MisocaがメインとなるWebサービス、Backendが裏側で動くAPIサービスです。

概ね既存のEC2インスタンスに載っていたサービスをコンテナ化しただけですが、一部構成を変えた点があるため以下で説明していきます。

Cognitoでの認証

もともと、開発環境を外部から利用されないようmod_auth_openidcでの認証をApacheレイヤーでかけていました。

ECSへの載せ替え後は、ALB+Cognitoを使って同等の認証をかけるようにしています。 この設定はAmazon CognitoユーザープールLambdaトリガーでALB認証のメールアドレスを制限するを参考にさせていただきました。

NATゲートウェイでの外部リクエストIP固定化

利用しているAPIの中に、IP単位での許可申請を行う必要があるものがありました。

以前はEC2インスタンスごとにElasticIPを振って申請していたのですが、ECS化を機にNAT Gatewayを利用して外から見えるIPが固定されるように変更しました。

もちろんこの構成はEC2インスタンスでも可能ですが、既存のインスタンスのネットワーク構成は気軽に変更できないため、ECS化と合わせて実施することができました。

DynamoDBをマネージドサービスに変更

切り出したBackendサービスでは、データストアにDynamoDBを使用しています。

既存の環境ではリザーブドキャパシティを最低にしても負荷に対してコストが高かったため、DynamoDBローカルを使用していました。
しかし2018年11月に開催されたRe:InventでDynamoDBの従量課金が利用できるようになったため、ECSに置き換えるのと合わせてバックエンドをマネージドサービスに置き換えました。

これによりECSコンテナではデータを一切保持しない構成になったため、サービスの破棄・再生成が容易になり、Fargateに載せることもできるようになりました。*2

デプロイ時のCodePipelineソースをECRに変更

図中には示していないですが、サービスの更新にはCodePipelineを利用しています。

移行前は以下のような流れでサービスの更新を行っていました。

  1. CodePipelineでソースの変更を検知
  2. CodeBuildで静的ファイルをビルド
  3. CodeDeployでEC2上のサービスを更新

移行後もCodeBuildの処理をDockerイメージの構築に変えれば大体同じ流れにできたのですが、これも2018年11月のRe:InventでAmazon ECRをCodePipelineのソースにできるようになったため、以下のような流れにしました。

  1. CodeBuildがソースの変更を検知し、Dockerイメージを構築
  2. ECRへの変更をCodePipelineが検知し、ECSのサービスを更新

これによりソースコードをS3経由で受け渡す必要がなくなり、S3へのファイル転送にかかっていた時間を短縮することができました。

デプロイ周りについてはMulti Stage Buildを使ったビルド高速化など工夫した点が多いので、また別の記事でご紹介できればと思います。

🔧 terraformでのコード化

最初のECS環境はAWS Webコンソールから試行錯誤しつつ作ったのですが、きちんと可視化して同様構成も作りやすくするため、terraformでのコード化を行いました。

この際、ネットワークなど各環境で共有するものと、ECSサービスなど環境ごとに必要なものとがあったため、以下のように「共有リソース」「各環境で必要なリソース」を分け、それぞれを1つのterraform stateで管理するようにしました。

ディレクトリ構成は以下のようになっています。

+ misoca-infrastructure
  + misoca-dev-common
  + misoca-dev-envs
  + misoca-dev-review

環境ごとに対応するリソースの分類を以下の図に示します。 この図を使いながら、各ディレクトリで管理しているリソースを説明していきます。

f:id:kokuyouwind:20190315105147p:plain

共有リソース(misoca-common)

一番上の点線で囲った箇所が共有の構成で、この部分は単純に terraform import を使ってコードに吸い出しています。

なお、ALBは複数使用するとその分料金がかかるため、1つのALBを複数の環境で共有するようにしました。各リスナールールでドメインに基づいて環境を振り分けるようにしています。

常設環境(misoca-dev-envs)

真ん中と下はそれぞれ1つの常設環境に対応しており、真ん中が通常の環境、下は外部と連携するためにGoogle認証を外す必要がある環境です。

これらは、 misoca-environment モジュールに渡す変数でリソース定義を変えるようにしています。

module "misoca-test" {
  source = "../modules/misoca-environment"
  name = "test"
  domain = "test.misoca.jp"
}

module "misoca-test2" {
  source = "../modules/misoca-environment"
  name = "test2"
  domain = "test2.misoca.jp"
  require-google-auth = false
}

このようにreqire-google-authを渡し、モジュール側では countを使って作成するリソースを切り替えます。

variable "require-google-auth" {
  type = "string"
  default = true
  description = "use goole authentication"
}

// with google authentication
resource "aws_lb_listener_rule" "forward-to-ecs-misoca" {
  count = "${var.require-google-auth ? 1 : 0}"
  // ...
}

// without google authentication
resource "aws_lb_listener_rule" "forward-to-ecs-misoca-without-auth" {
  count = "${var.require-google-auth ? 0 : 1}"
  // ...
}

他のリソースについても環境によって異なる場合は変数に基づいて切り替えるようにしています。 これにより、misoca-environmentモジュールを使えば任意の設定で環境を立ち上げられます。

レビュー環境(misoca-review)

以前の記事で書かれたレビュー環境についてもterraformを使って管理していきたいのですが、レビュー環境はいくつ環境が必要になるか不明で、単純にコードを書いていくと管理が面倒になります。

そこで、以下のようにterraform workspaceを使って環境を立ち上げるようにしました。

module "misoca-review" {
  source = "../modules/misoca-environment"
  name = "review-${terraform.workspace}"
  domain = "${terraform.workspace}.review.misoca.jp"
}

こうしておくことで、kokuyouというworkspaceに切り替えてから適用すると kokuyou.review.misoca.jp の環境を立ち上げる事ができます。

🤔 困っていること

上記のような構成で概ねいい感じに動いているのですが、ECSの立ち上げ環境をFargateにした結果、サーバにsshしてのコマンド実行ができなくなってしまいました。

特に困るのはデータメンテナンスや開発用のrakeタスク実行、手動でのバッチリトライができないことです。 ECSタスクをコマンド上書きして立ち上げることで一応は可能ですが、vpcやセキュリティグループの設定を揃えるのが面倒なうえ、ちょっとした作業でもFargate起動の時間を待たないといけないという点が不便です。

ひとまずは以下のようなECSタスクを手軽に立ち上げるスクリプトを書いて凌いでいます。

ただ結局Fargate起動にかかる時間がかかるのと対話的な操作ができないのは不便です。

RunCommandやSessionManagerが使えなくなるのは結構痛いんですが、みんなどうしてるんでしょうかね…?

🌈 今後の展望

開発環境のDocker化を推し進めたのは良いのですが、今度は本番環境と乖離してしまっているという課題があるため、本番環境も同様の構成へ載せ替えていきたいと思います。

本番ではログや監視などもしっかり考えないといけないので、開発環境でそのあたりの設定を吟味した上で移行していく必要がありそうです。

また、レビュー環境についてはGitHubにブランチをpushしたら自動で立ち上がる、という部分まではまだ実現できていません。

こちらはJenkinsで新規ブランチのpushを元にterraformコマンドを実行させればできそうかな、と考えています。

📢 宣伝

MisocaではInfrastructure as a Codeを実践したいエンジニアを募集しています!

www.wantedly.com

*1:routerがないとかNAT Gatewayの位置がおかしいとか、いろいろ突っ込みどころがあると思いますが見逃してください🙏

*2:Fargateでは永続化ボリュームを利用できないため、永続化データは外部に持つ必要があります

Figmaでアイデア発散会をやったら盛り上がった件

こんにちは、デザイナーのとりみずです。

最近Misocaでは全社的にデザインツールにFigmaを導入しました。

Misocaではリモートの社員も多く、モバイルアプリを開発しているチームは

  • 東京…デザイナー
  • 名古屋…サーバサイドエンジニア
  • 京都…デザイナー
  • 鳥取…Androidエンジニア
  • 福岡…iOSエンジニア

という日本各地の集まりになっています。

このメンバーで、とある価値仮説に対して「俺の考える最強のアイデアぶつけあい大会」をすることになりました。 そこでFigmaを活用したところ、リモートでのアイデア発散会にとても向いていたので、その様子を紹介したいと思います。

当日までの準備

課題とターゲットをすり合わせを行い、当日のアイデア発散会までの準備に下記を宿題としました。

  • アイデア発散会の日までに各自手書きでアイデアイメージをA1の紙に書く
  • 匿名性を考慮してアイデアに考えた人の名前はつけずにおく
  • FigmaのPageに貼っておく

※この時、どういう形式で書けばいいで迷ってアイデアだしが止まってしまわないよう、サンプルを私の方で用意しました。

f:id:torimizuno:20190222180139p:plain

そして当日…

オンラインミーティングサービスのZoomでFigmaの画面を共有し、俺の考える最強のアイデアぶつけあい会のはじまりです。

このようにZoomでFigmaを画面共有しながら、ひとつひとつのアイデアを順に見ていきます。 最初は匿名性でのジャッジを想定していたのですが、説明がないとわからないアイデアもありましたので、全員が順に自分の書いたアイデアを説明する流れで共有をしていきました。

f:id:torimizuno:20190225141710p:plain

その後、各アイデアのここがよかった!を可視化するため、自分がよいと思った部分や疑問点に、Figmaのコメント機能でコメントをしていきます。 誰かがコメントすると、派生してどんどん意見が生まれていたり、ポジティブなやりとりが発生していているのを見るのも楽しかったです。

Figmaはリアルタイムで同じ画面で誰がどこを見ているかもわかるので、コミュニケーションもより取りやすいと感じました。

f:id:torimizuno:20190225141737p:plain

よかった部分の可視化の後は、似ているアイデアをグルーピングし、特長を書き出します。 この日はあくまでアイデアをぶつけ合う発散会目的でしたので、ここまで終えたところで、最後に全員で次回のアクション決めをしました。

まとめ:figmaでのアイデア発散会は、盛り上がる🎊

ミーティング後、チームのチャンネルでメンバーの感想があがっていたのですが、とてもポジティブな反応があって嬉しかったです。 もちろんアウトプットが重要ですが、会自体が盛り上がり、全員が発言しやすい環境づくりも大切だと改めて感じました。

f:id:torimizuno:20190225110810p:plain

📢採用

Misocaでは、チーム開発を一緒に楽しんでくれるデザイナー、エンジニアを募集しています!

(東京の弥生本社オフィスの拠点紹介ページもできました)

recruit.misoca.jp

Webpackerを導入してから外すまでをふりかえる

こんにちは、@mugi_unoです。

MisocaでjQuery製のフロントエンドコードを書き換え続けていた結果、技術書典6に参加することになりました。現在必死で書いております。

farewell_webpacker

さて、先日とあるブランチがmasterにマージされ、リリースされました。

f:id:mugi1:20190213111057p:plain

farewell : ごきげんよう!、さらば!
farewellの意味・使い方・読み方 | Weblio英和辞書

farewell_webpacker です。

長い間フロントエンドのビルドにはRailsのGemであるWebpackerを使ってきましたが、現在は完全に依存を外しており、純粋なwebpackビルドを行う形に書き換えました。

正直なところ、フロントエンド界隈からは否定的な意見を聞くことも多いWebpackerですが、実際にある程度の期間プロダクションで利用してみて、良いところも辛いところも両方感じることができたので、今回はそのあたりをご紹介したいと思います。

Webpacker導入に至った経緯

Webpackerを導入した際にもこのブログに記事を書いています。

tech.misoca.jp

当時は次のような課題を抱えていました。

  • browserify-railsによるビルドが致命的に遅い
  • ほぼnpmによるパッケージ管理が行われていない
  • アセットパイプラインを使うものと使わないものが混在

とはいえ、それとは別にコードベースにも

  • jQueryべったり
  • Vueが0.12
  • テストコードが存在しない

といった問題を抱えていて、フロントエンドが絡む機能開発に支障が出ていました。 そのため「まずは手っ取り早く基盤周りをいい感じにしたい」という考えから、導入コストの低かったWebpackerを採用することにしました。

🤝 Webpackerのよかったところ

初期導入の敷居が低い

Railsとフロントエンドのビルド周りを組み合わせるのはそれなりに手間です。また、Misocaの場合はフロントエンド専任のエンジニアがいるわけではなく、基本的には誰でもバックエンド・フロントエンドを通してコードを書きます。逆に言うと、フロントエンドのみに全労力を注ぐことが難しいため、シンプルで理解しやすいものが望ましいと考えました。

フロントエンドに限った話ではありませんが、環境構築を行う際には「その後にちゃんとメンテナンスしていけるか?」も重要な観点です。流行っている・使いたい、といった理由だけで導入すると後で痛い目を見る可能性もあります。(流行っている技術を使わないほうがいいということではありません。私も誰も使ってないようなイケてるフレームワークとかガンガン突っ込みたい人です。)

Webpackerが理解しやすいかと言われると正直思うところはあるのですが、少なくともGem側で道を示してくれており「レールに乗って導入しています」というのは情報共有の面では大きいメリットがあります。

また、Webpackerが提供するインストールタスクを利用することで各種設定もすぐに完了するため、「とにかくwebpackを利用したビルド環境をサクっと整えて他の作業に注力したい」という場合には大いに役立ちます。

レールに乗っている限りはコードに集中できる

Webpackerの提供するレールに乗っている限りはフロントエンド側はコードを書くことだけに集中できます。 マイグレーションが発生した場合も、基本的にはCHANGELOGの内容などを参考にしていけばさほど難しくありません。 フロントエンドが好きだったり得意なメンバー以外からすると、フロントエンドのビルド・環境設定周りは苦痛が伴うこともあるため、そこをGem側でケアしてくれるのはとても助かります。

Railsアクセス時の自動ビルドがうれしい

Webpackerはビルド時にコードのハッシュ値を保存しており、アクセス時にコードに差分が発生していると自動的にビルドをしてくれます。 (デフォルトでは開発時のみのオプションです)

「あれ、なんか動かない〜」→「フロントエンド側ビルド忘れてました」 というケースは結構発生するので、それを回避できるのは地味に便利で快適です。

🤔 Webpackerのつらかったところ

レールから外れたカスタマイズがしづらい

レールに乗っている間は快適ですが、そこから外れようとすると厳しい面が出てきます。 たとえば、webpackではwebpack.config.jsというファイルに LoaderやPluginを利用して設定を追加していくのが一般的な方法かと思いますが、 Webpackerの場合は、独自でラップされたクラスを経由してカスタマイズする必要があります。 たとえば、次のようなイメージです。

const { environment } = require('@rails/webpacker')

environment.loaders.append('json', {
  test: /\.json$/,
  use: 'json-loader'
})

environment.loaders.prepend('json', jsonLoader)

module.exports = environment

webpack.config.jsのお作法を覚えなくても良いというメリットはありますが、 そのぶん独自のカスタマイズ方法を把握することになるため、 すでにwebpackに関してある程度の知見がある場合にはコストに感じるかもしれませんし、 最初からwebpack.config.jsの書き方覚えたほうが手っ取り早いのでは?と思ってしまう部分はあります。

また、Webpackerが提供していない範囲でwebpackのカスタマイズが必要になってくると、結局はwebpack.config.js相当のものを引き剥がして書き変える必要が出てきます。

実際には次のようなコードを通してしました。

const webpack = require('webpack');
const merge = require('webpack-merge');

module.exports = function(environment) {
  const defaultConfig = environment.toWebpackConfig();
  const webpackConfig = merge(defaultConfig, {
    /* webpackの設定を独自でカスタマイズ */
  });

  return Object.assign(environment, {
    webpackConfig,
    toWebpackConfig() {
      return this.webpackConfig;
    }
  });
};

このあたりのカスタマイズにはWebpackerが内部で保持しているコードを把握しておく必要があり、 「レールに乗っていればOK!」という状態からはかけ離れてしまいます。

依存関係が見えづらい

Webpackerを使うことで、たとえばbabelを利用したECMAScriptの変換やCSSのビルドといったことは簡単に実現できます。

しかし、そのために必要な依存は@rails/webpackerの内部で閉じられているため、実際のところ何を利用しているのかが若干見えづらいことがあります。

そのため、例えばwebpackプラグインを追加しようと思った際に「すでにWebpacker内部で依存に追加されていないか?」「Webpacker内部での依存バージョンは何か?」といった情報を把握する必要が出てくるため、確認すべきものが多くてつらい、といったことが多々あります。

内部のモジュールのバージョンに引っ張られる

Babelを例に挙げると、@rails/webpacker#v3.5.5 であれば、内部で利用しているBabelは6.x系ですが、本エントリ投稿時点ではBabelはv7.3.3が最新バージョンです。 6.x→7.xの時点で必要となるパッケージ構造などに大きな変更があり、関連して、Babelを利用する他パッケージではBabel6.xとBabel7.xによって設定や挙動に変化があるものが少なくありません。

たとえば、テストフレームワークのJestはBabel6.xのサポートを打ち切っています。 https://jestjs.io/docs/en/getting-started#babel-6

こういった影響を受けて「Webpacker側のパッケージが更新されるまでは、独自で入れたいパッケージが更新できない・あるいは追加できない」といったケースが発生することがありました。(強引にやっていくこともできそうでしたが、メンテナンスコストが増大しそうだったので避けました。)

🎓Webpackerを卒業することにした

さまざまなメリット・デメリットを考えた結果、Webpackerを卒業して純粋なwebpackビルドに置き換えることにしました。

Webpackerの他に追加しているパッケージが増えてきた

テスト環境の整備などを経て、導入初期と比較するとWebpacker以外で独自で導入しているフレームワークが増えてきました。先に挙げた依存関係やバージョンの問題から、「使いたいが使えない・使いづらい」というシチュエーションが発生してきました。

開発環境のDocker化が進んだ

Webpackerの自動ビルドがとても便利で、Rails以外にwebpackプロセスを独自で立ち上げなくて良いのは大きなメリットだったのですが、最近ではDockerによる開発環境の整備が進んでおり、docker-composeを利用することでwebpackプロセスなどは特に意識せずともコマンド一発で起動することが可能になってきました。

マイグレーションコストが高くなってきてしまった

独自でのパッケージの追加や、力技でのカスタマイズを加えていったため、マイグレーションが発生した場合に、CHANGELOGなどを見るだけでは安心できない状態になっていました。 また、Webpacker外のパッケージを更新する際もWebpackerとの影響を考慮する必要があり、気を払わなければいけない対象が多く、それであれば独自でwebpackを構成してしまって自分たちで依存モジュールを完全に掌握できている方が安心だな、という考えに至りました。

結局Webpackerを採用したのはどうだった?

個人的な感想は「採用してよかった」と思っています。

今現在で言えばマッチしない状況があるのは事実ですが、導入初期のころから振り返ってみると、確実に僕たちを助けてくれた存在だったと思います。

初期の設定をWebpackerに任せたことにより、すぐにVue.jsの更新・CoffeeScriptからの脱却・テスト環境の整備といった、プロダクト的にもっと重要な他の改善作業に注力することができましたし、その間はwebpackのことを考えなくて良かったのはとても助かりました。

また、つらかった部分を幾つか挙げましたが、これらはほぼすべてこちら側でカスタマイズしたことに起因して発生しているものであり、本来Webpackerが推奨しているものとはズレており、Webpacker自体の問題とは言えません。先に述べた恩恵のことを考えると、入れ替えるコストを考えても遥かにメリットのほうが多かったと思います。

つまり、プロダクト側の状況が変化したことでWebpackerを使うフェーズからは卒業したんだな、と思っています。Webpackerに限った話ではありませんが、フレームワークにはプロダクトとの相性や、マッチする時期、旬みたいなものがあるので、定期的に見直して最新化していくのは重要ですよね。

というわけでWebpacker、今までありがとう!

📢採用

Misocaでは旬を追いかけるエンジニアを募集しています!

www.wantedly.com

続・Android版Misocaのマルチモジュール対応

みなさんこんにちは、こまたつです。
突然ですが去年のこの記事を覚えていますか?

マルチモジュール化の波にのるべくモジュール分割にとりくんだのですが、しばらくころがしてみてこの分割方法ではイマイチということがわかってきました。
人生には失敗がつきもの、良くない点を整理して次へ進もうと思います。

まず今どうなっているか

冒頭にリンクをはった記事に詳細がありますが、だいたい次のような分割になっていました。

f:id:komatatsu:20190215150308p:plain
旧モジュール分割プラン

文書ごとにモジュールが分かれています。

なにがよくなかったか

まずはこの画面をみてくれ

f:id:komatatsu:20190215150358p:plain
取引先別文書一覧

こいつをどう思う?

すごく...モジュールをまたいでいるんですね。
そもそも各文書は似通ったデータ構造をしているのでクラスも抽象化されています。
これでは文書をさわると分割した別のモジュールにも影響が出てしまい、モジュール分割の恩恵をあまり受けられません。 *1

手間だけが増えてしまいビルドも早くならないし、モジュールをまたぐ画面があるので結合度が高くかえって複雑になってしまいました。

じゃあどうするの?

f:id:komatatsu:20190215150541p:plain
モジュール分割プラン2

これがモジュール分割プラン2です。
Misocaアプリはまだ機能も少ないので、ログインなどの今後追加される機能でも絶対必要な物さえ分離できていればちょうど良さそうというのがわかりました。
秘密の新機能が気になりますよね、私も気になります。

モジュール結合では分割時に追加したものを消したり移したりすれば特に躓くところはありませんでした。
AndroidStudioの表示がおかしいな?と思ったらAndroidStudioを再起動したりcleanしたりしてみましょう。

初挑戦で不安も多かったですが実際に試してみることで、資料を読むだけじゃわからない勘所がつかめました。
時間は失ってしまいましたが、この経験は今後のアプリ開発に活かされることでしょう。

採用情報

Misocaでは一緒にチャレンジしてくれるモバイルエンジニアを募集しています。
失敗を重ねて成功を掴みましょう。

*1:これを考えた当時は見積書だけInstantAppsにできるとよさそうみたいな構想があった

Misoca のお仕事 First impression

1月から Misoca で働いている @suer です。
入社から1ヶ月間働いてみた感想を紹介したいと思います。

今までの経験と比べて驚いたことはたくさんありますが、中でもスピード感の違いはいまだに戸惑うことがあります。
そこで今回は「スピード感」をキーワードに考察してみようと思います。

写真は名古屋勤務の合間に御朱印集めで立ち寄った護国神社です。 f:id:suer:20190112113026j:plain:w500

朝会・週次振り返り

Misoca では毎朝の朝会と週次の振り返りが行われます。
Trello にアジェンダが書かれていて、また、共有事項がある人は予めカードを登録しているのでサクサク進みます。
もう慣れましたが、最初は「あれ?もう終わった?」という感じで戸惑うほどの速さでした。

また、これらのミーティングで驚いたのは、「アクションに落とす力」です。
カードから問題や課題が見つかると、すぐにアクション列に移動され、
「誰かやります?」
「じゃあ私が」
という声がすぐにかかりすぐに処理されていきます。

f:id:suer:20190203202249p:plain:w500

この動きによって課題が着実に解決されていきます。 このリズムが Misoca のスピード感を出している要因の一つなのでは?と考えています。

  • 課題は解決しなきゃいけない
  • やれることは人任せにせずに自分たちでやる

ということは当たり前のようですが、ここまで徹底して実施されているのは経験上あまりなく、Misoca の文化だなぁと感じました。

リモートワーク

Misocaでは、場所にとらわれない働き方を推進しており、リモートで働く開発者がたくさんいます。

仕事中は普段みんな Zoom で同じ部屋につないでおり、お互い顔が見える状態で働いています。 *1

f:id:suer:20190205130542p:plain:w500

顔が見えないとなにか相談したいときなど、声をかけていいものか…と余計なことを考えてしまいがちですが、お互い顔が見えていると妙な安心感があり、声をかけやすくなっている気がします。

今までの経験では、なにか相談したいときや一緒に作業したいときなどは、会議室をとって…メンバーの予定を合わせて…という感じで実施が後回しになってしまいがちでしたが、ほとんどの内容はその場で個別のビデオ会議の部屋を作ってすぐに実施・解決されていきました。

このスピード感は、むしろリモートワークの方が有利だよなぁと思うことが多々あり、いい体験でした。

Pull Request を滞留させない

週次のミーティングでやることの中に、作成されてから長い期間がかかっている Pull Request を確認する時間が設定されています。
これはとてもいい方法だなと思いました。

放置されている Pull Request があるというのは良くない状況なので、それを週次でチェックし、どうするのかをみんなで考えます。
これにより、問題があるのであればその場で対処を決め、レビューのための説明が必要なのであれば説明するなど対処することができます。 結果として、その場にとどまっていた Pull Request を、マージできるように前へ進める事ができるようになるのだと思います。

ただ、みんなレビューが早かったり、「レビューして欲しい」と声をかけることで自発的にレビューしてもらったりしていたので、 この1ヶ月働いた中で滞留している Pull Request を見ることはありませんでした。
なのでこれはあくまでも想像です。

まとめ

ここで紹介できたことは Misoca のスピード感を生み出す要因の一部であり、今後もキャッチアップしていこうと思います。

この記事で見てきたことは、ものごとを着実に前に進める力を生み出しており、それがこれまで経験したことがなかった「スピード感」という体験となったような気がします。

このスピード感についていくのは入ったばかりの身としてはなかなか大変です。
しかし、他のメンバーが助けてくれていますし、またチャレンジしがいがあります。
なんとかついていけるよう頑張っていこうと思います。

Misoca では、ものごとを着実に前に進めていきたいエンジニアを募集しています!

www.wantedly.com

*1:VR 出社している人もいて物理的な顔が見えない人もいますが、ここでは「あー、一緒に働いてるなー」くらいの意味です

🌈俺たちのCustomEmoji

こんにちは、@mugi_unoです

最近4Kモニタを買いました。あまりにも快適で「なるほど、これが人権か・・!!」と思いながら作業をしています。

SlackのCustomEmoji

ご存知の方も多いかと思いますが、SlackではCustomEmojiという機能があり、独自に絵文字を追加することができます。

get.slack.help

ここにはチームの文化や雰囲気が色濃く反映されることもあり、眺めているだけでも結構楽しかったりします。

というわけで

俺たちのCustom Emoji

今回のエントリでは、MisocaにあるCustomEmojiを紹介してみたいと思います。

なお、トータルで356個あったので、比較的利用頻度が高いものに絞って紹介したいと思います

f:id:mugi1:20190128122448p:plain:w300

同意・肯定系

f:id:mugi1:20190125164658p:plain:w40 わかるとき

f:id:mugi1:20190125164746p:plain:w40 わからないとき

f:id:mugi1:20190125164808p:plain:w40 わかるわ、ってとき

f:id:mugi1:20190125174047p:plain:w40 それな〜〜

f:id:mugi1:20190125174151p:plain:w40 おなじ気持ちですよ!

f:id:mugi1:20190128115717p:plain:w40 いいこと言ってるな〜、ってとき

f:id:mugi1:20190128120042p:plain:w40 何かを見て「良さそうだな」ってとき

他にも、わかる・わからないのパターンがありましたが、諸事情によりここには載せられません。「わかり哲也」 で検索してみてください。それです。

よくあるリアクション系

f:id:mugi1:20190125171900p:plain:w40 Looks Good To Meなとき

f:id:mugi1:20190125171937p:plain:w40 完全にLooks Good To Meなとき

f:id:mugi1:20190125175000p:plain:w40 なにかが完了した時

f:id:mugi1:20190128115904p:plain:w40 なるほど

f:id:mugi1:20190128115948p:plain:w40 OK牧場

f:id:mugi1:20190128122003p:plain:w40 アレなとき

反応がほしいけど、テキストで返してもらう程でもない、というシチュエーションはわりと多いです。 その時にサッと意思だけ伝えられるのでとても便利です。

賞賛・感謝系

f:id:mugi1:20190125173729p:plain:w40 ありがとう!

f:id:mugi1:20190125165955p:plain:w40 わーい!

f:id:mugi1:20190125165741p:plain:w40 えらい!

f:id:mugi1:20190125165738p:plain:w40 すごい!

f:id:mugi1:20190125175208p:plain:w40 めっちゃいい

f:id:mugi1:20190125170206p:plain:w40 いい動き!

f:id:mugi1:20190125165812p:plain:w40 神だわ・・・

f:id:mugi1:20190128115805p:plain:w40 むしろ仏だわ・・

f:id:mugi1:20190125174817g:plain:w40 イエーイ!!
Created by modifying "cultofthepartyparrot.com" / © 2016 John Hobbs (Licensed under CC BY-SA 4.0)

普通に 「🎉」が使われることも多いですが、その時の気持ちをサッと告げられるようにバリエーションが豊かですね。特に、過去のエントリでもご紹介した「褒めるチャンネル*1」で良く使われています。

ちなみに

f:id:mugi1:20190125170424p:plain:w40

というのもあり、ナイスムーブと組み合わせると

f:id:mugi1:20190125170424p:plain:w40f:id:mugi1:20190125170206p:plain:w40

になります。しょうがナイス。

挨拶系

f:id:mugi1:20190128120554p:plain:w40 「あがります」って言うと返ってくる。熊本弁らしい。

f:id:mugi1:20190128120702p:plain:w40 体調がアレなときに

できたとき

f:id:mugi1:20190128122204p:plain:w40 できた!!

f:id:mugi1:20190128122212p:plain:w40 できとる!

f:id:mugi1:20190128122220p:plain:w40 できとるやん!!

コンボで使われることが多いです

Misocaならではっぽいもの

f:id:mugi1:20190128120815p:plain:w40 税です

f:id:mugi1:20190128120856p:plain:w40 プロジェクト外から失礼します

f:id:mugi1:20190128121020p:plain:w40 自由に使える会議室、通称「ドブ川」

f:id:mugi1:20190125165501p:plain:w40 草が生えたとき

なおこのEmojiは、FindyさんがRubyKaigiで配布していたステッカーを元に作成させて頂いています。

PDCA

f:id:mugi1:20190128120418g:plain:w40 PDCAサイクルが回っているとき。すごい回ってる

ゴリラ

調べてたら大量に出てきました。わたしにもよくわかりません。

f:id:mugi1:20190125164913p:plain:w40 ノーマル

f:id:mugi1:20190125170659p:plain:w40 考えるゴリラ

f:id:mugi1:20190125164941g:plain:w40 無限

f:id:mugi1:20190125164949g:plain:w40 振動

f:id:mugi1:20190125165013g:plain:w40 回転

f:id:mugi1:20190125164930g:plain:w40 フィーバー

Created by modifying "Twitter Emoji (Twemoji)" / © 2018 Twitter, Inc and other contributors (Licensed under CC BY 4.0)

かんそう

些細な一言でも積極的にEmojiにしていますね。

テキストベースでコミュニケーションでは、簡単でも反応があることが大事なので、その時にCustomEmojiを駆使することで、細かいニュアンスも手早くサッと伝えることができて、とても便利です。

また、全体的に肯定・承認といったポジティブなものが非常に多く、逆にネガティブなものはほとんど無いな〜と思いました。

それに似た話として、Misocaでは

🙇‍♂️ (:bow:)

を使っているのはあまり見ません。

見た目のイメージ的には依頼や謝罪を連想させますが、頭を下げてお願いするような必要はなく、失敗したとしてもお互い様で、謝るよりもチームとして次にどうするかを皆で考えていこうな!という意思の現れかもしれません。

ただもちろん謝っちゃいけないという意味ではないので、悪いと思ったらゴメンねとは言いますが、

f:id:mugi1:20190125172753p:plain:w40

が返ってくるのも安心感があって良いです。以下は実際に私がやらかしたときの例です。

f:id:mugi1:20190125175651p:plain:w400


みなさんもカスタム絵文字を使って楽しいSlackライフを送ってはいかがでしょうか。 それでは最後に、私のオススメのCustomEmojiを紹介したいと思います。

f:id:mugi1:20190128121533p:plain

:komon_no_power:

顧問自ら登録しているあたりがとても良いですね。

参考 : 文字の絵文字のつくりかた

絵文字ジェネレーターさんを活用させて頂いております。

emoji-gen.ninja

📢採用

MisocaではEmojiラブなエンジニアを募集しています!

www.wantedly.com

🎍開発メンバーの新年の抱負

あけましておめでとうございます。Misoca開発者の@kokuyouです。

新年早々ほたるちゃんの声を聞けたので、今年もいい年になりそうです。

さて、年が明けてもう1月が過ぎそうではありますが、今回の記事ではMisoca開発メンバー有志から新年の抱負を掲げていきたいと思います。

黒曜

最近はSRE周りに興味を持っているので、

  • ユーザに安定したサービスを提供する
  • 開発者が快適に、回帰テストを保証された状態で開発できる

ということに力を入れていきます。 あと、環境を全体的にDocker移行していきたいです。

またRails Developer Meetup 2019に登壇させていただくことになったので、自身で納得行く発表にできるようちゃんと準備を進めたいと思います。

id:mizukmb

  • Rustの勉強
    • プログラミングRustを読む
    • なんかかく
  • 走る
    • ハーフマラソンは達成したい
    • できればフルマラソンも
  • 貯金する
  • 日商簿記3級合格

thara

おみくじで大吉出て「短気を起こすな」と書いてあったので、 今年の目標は「短気を戒め、身を慎む」に決まりました。

細かいところだと↓みたいな感じ

  • 個人として
    • 日報を書く(継続)
    • 1日30分以上の軽度な運動をする
    • ブログを月に1回以上書く
  • 父として
    • 暗くなる前に保育園に迎えにいく
    • 子どもを注意するときに、大きな声を出さない
  • プログラマとして
    • Ruby gemを1つ以上公開する
    • Rust crateを2つ以上公開する

id:eitoball

今年は大きな目標は立てずに細く長く過ごしていこうと思っています。以下は、必ず成し遂げたいと思っています。

  • 4月にハーフマラソンの大会に出るので完走する。
  • 11月にフルマラソンの大会に出るので完走する。
  • 50km走ってみる。
  • Elixir・Phoenix・Elm を使った何かを書く。

よろしくお願いします。

id:sunflat

  • 開発環境をDockerに移行する
  • e-Taxで確定申告する
  • ドラクエ10のクエストを全部クリアする(職人クエストは除く)

kanizmb

去年20倍界王拳でものすごく頑張ったので、今年はこんな感じでゆるりとやっていきたいと思っています。

  • 物理で人に会う
  • 怪我しない
  • 事故らない

id:mallowlabs

知識をつけるために、いろいろインプットしていく年にしたいと思います。

  • Ruby / Rails の知識をつける > Ruby Kaigi / RailsDM に参加する
  • AWS の知識をつける > Lambda (特に SAM ) を使っていろいろ作ってみる
  • 業務知識をつける > 簿記3級の勉強する

mugi_uno

富山からjsを書きまくっていた2018年でした。今年も引き続きがんばりますよ〜

  • MisocaフロントエンドのjQueryを倒す
  • 富山県以外の場所で登壇する
  • 個人で作っているNuxt.js製WEBサービスのユーザを確保する。現在1名(自分)

id:hidakatsuya

引き続きPDF周りをやっていく年になると思います。

  • Thinreports 1.0 をリリースする
    • Thinreports Editor を書き直したりもしたい
  • 前々から温めていたモバイルアプリをリリースする
  • 数学(~中学レベル)を勉強し直す
  • 4Kディスプレイを買う

こまたつ

今年は健康になりたいのでそのための様々な施策をやっていきます
AndroidアプリのMAUは10倍にします

id:RKTM

  • Kotlin頑張りたい。
    • ktorで何か作ってデプロイしたい。
    • coroutines完全に理解する。
  • パフォーマンス改善(物理)したい
    • フルマラソン完走する
    • クライミング頑張る

id:lulu-ulul

  • Ruby は引き続き頑張る
  • 自分用の趣味アプリケーションのフロントを Vue.js に置き換えていきたい
    • 大半がレガシーフロントエンド(一部 Riot.js)のままなので。
  • 開発環境(物理) 改善していきたい
  • SNS疲れ抜けてきた気がするのでそろそろ何かアカウント作る
    • どうせなら何か新しいサービス試したいなー
  • 半額セールだから半年寝かせても損しないじゃん!と思って半年以上前に買ったままの RubyMine をそろそろ試す

yueno12

  • RxSwiftを使いこなしたい
  • MVC以外のアーキテクチャを試してみたい
  • 1年健康で過ごしたい(できればちょっと痩せたい)

id:ryotaway

コツコツ積み重ねてやっていきます。

  • Rustのcrateを1つ作って公開する
  • Hypervisor.Frameworkを使った仮想マシンを作って公開する
  • 痩せる

📢宣伝

Misocaでは新年から心機一転、抱負を掲げて開発していきたいメンバーを募集しています。

www.wantedly.com