Webpacker is installed 🎉 🍰

こんにちは、@mugi_uno です。

庭に花壇を作ったところ変に日焼けをしてしまい、半袖で外に出るのが恥ずかしいです。

つい最近、Misocaのフロントエンド周りのビルドをWebpackerを利用したものに置き換えました。 様々な知見が得られたので書いてみたいと思います。

Webpacker?

フロントエンド用のビルドツールであるwebpackRailsから簡単に使えるようにするためのRubyGemsです。

github.com

f:id:mugi1:20170619094144p:plain

Rails5.1からはこのWebpacker経由で、rails new の際に同時にwebpack用の設定ファイルを生成することもできます。

流行りのフロントエンド環境を構築しようとする際、最近ではwebpackを利用するケースが多いですが、実際にはES6やReactなどが混ざることも多く、慣れていないと設定するだけでもなかなか敷居が高いです。

さらに、Railsと組み合わせる場合には、アセットパイプラインとの兼ね合いをどうするか?などといった課題も登場するため、考えるだけで鼻血が出そうになります。

Webpackerを利用することで、その辺りをいい感じに解消してくれるというわけです。

Misocaでの導入理由

browserify-rails めっちゃ時間かかる問題

もともとはアセットのビルドに browserify-rails を利用していましたが、ビルド時間がMisoca内で問題になっていました。キャッシュによる高速化が効いてはいるものの、何かの拍子にフルビルドが走ると数分待たされることも。

CIでも上記の影響を受けるため、開発効率にあまりよろしくない影響を与えていました。

(開発効率が落ちた図) f:id:mugi1:20170609181108p:plain f:id:mugi1:20170609181116p:plain f:id:mugi1:20170609181127p:plain

なんとかしたい

最初はbrowserify-rails自体のチューニングを検討しましたが、webpackでのビルドを一度試してみたところ、そもそもフルビルドでも20秒くらいで終わることがわかりました。

MisocaではRails5.1を導入済みだったのもあり、Webpackerを使って本格的に導入を試みることに。

webpackerがやってくれること

※以下内容は rails@5.1.1/webpacker@2.0 を前提としています。

大きく分けると以下の3つかと思います。

  1. rakeタスクの提供
  2. ボイラープレートの生成
  3. viewヘルパーの提供

rakeタスクの提供

Webpackerを追加すると、いくつかのrakeタスクが利用可能となります。 特徴的なものを簡単にご紹介します。

webpacker:install

ボイラープレートを生成する。(後述)

webpacker:check_node / webpacker:check_yarn

webpackerの実行には Node.jsとYarnが一定バージョン以上である 必要があります。

このタスクで、システムに必要なバージョンのNode.js/Yarnがインストールされているか検証できます。

webpacker:verify_install

webpacker:check_node/webpacker:check_yarn などを実行し、Webpackerによるビルドが可能な状態かを検証できます。

ちなみにブログタイトルの「Webpacker is installed 🎉 🍰 」は、このタスク成功時の出力結果です。

f:id:mugi1:20170616133609p:plain

webpacker:compile

bin/webpack を呼び出し、webpackビルドを実行します。 その際に RAILS_ENVの値を参照し、各環境に応じたビルドを実行してくれます。

また、実行前には自動的に webpacker:verify_install によるチェックが行われます。

assets:precompile からのコールについて

以下は assets:precompile のenhanceで事前タスクとして登録されています。

  • yarn:install
  • webpack:compile

これにより、例えば既存のデプロイプロセスなどで assets:precompile を実行していれば、そこでwebpackビルドが自動的に実行されます。

ただ、ここで実行されるyarn:install については、デフォルトでは --pure-lockfile が付与されないので、意図しないバージョンによるビルドが行われてしまう可能性がある点に注意が必要です。

Misocaでは、デフォルトの yarn:install タスクをオーバライドし、--pure-lockfile が付与されるように一手間加えています。

ボイラープレートの生成

webpacker:install を実行すると、webpackに必要な各種ファイルが自動的に生成されます。

  • webpack.config.js に相当するファイル群
  • ES6ビルド用のbabelrc
  • パス設定などを集約したYAMLファイル(webpacker.yml
  • などなど

また、Misocaでは利用していませんが、一部ライブラリに特化した形でのインストールも可能です。

  • webpacker:install:react
  • webpacker:install:vue
  • etc..

これにより、ES6+Reactなどを利用したフロントエンド開発を行うための環境を手早く構築することができ、ダイジェスト付きのjs生成なども簡単に行うことができるようになります。

viewヘルパーの提供

Sprocketsの場合は javascript_include_tag が提供されていますが、同様にWebpackerでは javascript_pack_tag が提供され、Webpackerによってビルドされたファイルを利用する場合はこちらを利用する必要があります。

(スタイルシート用に stylesheet_pack_tag もあります。)

導入のために行った作業

方針設定

がむしゃらに始めると迷宮に入っていくかもしれません。今回は「Webpackerの導入」にフォーカスしたいため、以下のような方針にしました。

  • jsのみを対象とし、cssは対象としない
  • ビルドを通すため以外のコードの書き換えは行わない

assets/javascripts 配下を webpackのentryとする

webpackはビルドの起点をentryとして設定に記述する必要がありますが、デフォルトでは javascript/packs 配下になっています。

そのままだと既存資産のjsファイルすべてを javascript/packs 配下へ移動する必要がありますが、Webpacker導入作業中もプロダクト開発は行われているため、頻繁にコンフリクトが発生することが予想されました。

さすがにつらいので、entryに assets/javascripts を加えることで、導入完了後にあらためて移動だけを行うことにしました。

shared.js に以下のようなコードを加えて、entryにObject.assignでマージすることで対応します。

const assetsPath = 'app/assets/javascripts';
const assetsEntry = sync(join('app/assets/javascripts', extensionGlob)).reduce(
  (map, entry) => {
    const localMap = map
    const namespace = relative(join(assetsPath), dirname(entry))
    localMap[join(namespace, basename(entry, extname(entry)))] = resolve(entry)
    return localMap
  }, {}
);

//= requireをCommonJS(またはES6 modules)に書き換え

Sprocketsで依存解決をしている場合、jsまたはcoffee内に以下のような記述が存在する可能性があります。

//= require jquery-ui
//= require_tree ./lib

これらは、CommonJSの require や、ES6 modulesの import/export を使った形に書き換える必要があります。

require('jquery-ui')
require('lib/foo')
require('lib/bar')
require('lib/baz')

なお、拡張子を省略した場合にうまくロードされない場合、config/webpacker.yml 内の extensions に追加する必要があります。

依存関係の解決をnpm利用に変更

必須ではありませんが、上記 //= require でロードされていたライブラリを、npmモジュールを利用するように変更しました。

地道に各ファイルのバージョンを調べ、同バージョンを yarn add していきます。

ただ、gemが提供しているjsファイルをrequireしていることもあります。その際は、jsのみがnpmモジュールとして提供されていないか確認し、

  • 提供されている → そちらを利用するように変更
  • 提供されていない → jsファイルのみを抽出して解決するか、フルパスで require する。

とした手順を踏んでいきました。

よく利用されているものでいえば、jquery-ujs などは単体で提供されています。

github.com

グローバル参照を解決

値がグローバル定義されているのを前提としているコードがある場合、グローバルに値を明示的に定義しないとアクセス不可となることがあります。(jQuery/$ などがよくあるケースだと思います。)

今回はグッとこらえてグローバル依存自体は残しました。意見のある方はこちらからどうぞ!

共通でロードするjsファイルがあれば、その先頭に以下のようなコードを足すだけで参照可能となります。

global.$ = global.jQuery = require('jquery');

なおMisocaで導入した際には、さらに以下のような対応も行っています。

  • ライブラリ群のみを個別の jsファイルに抽出した別ファイルとした。
  • ProvidePlugin を利用した、ライブラリから別ライブラリの参照。

ひたすらviewヘルパを置換

javascript_include_tag をひたすら javascript_pack_tag に置き換えていきます。

基本的には置き換えるだけで問題ないですが、javascript_include_tag の場合は複数スクリプトを単一タグでロードできるのに対し、javascript_pack_tagの場合はエラーとなるため、そこだけは分割する必要があります。

<%= javascript_include_tag('foo', 'bar', 'baz')%>

<%= javascript_pack_tag('foo')%>
<%= javascript_pack_tag('bar')%>
<%= javascript_pack_tag('baz')%>

foremanによる起動設定

開発時には、jsファイルを監視した上で自動ビルドしたくなりますが、その場合、rails serverとwebpackで二つのプロセスの起動が必要です。

単純にターミナルを2つ開くなどして起動してもいいですが、READMEには foremanを利用した方法が記載されています

こちらも併せて導入しておきました。

(基本的な導入手順はREADMEの記述のままなのでここでは割愛します。)

インクリメンタルビルドについて

webpackを利用したインクリメンタルビルドには2つの方法があります。

  • bin/webpack-dev-server
  • bin/webpack --watch

bin/webpack-dev-server を利用した場合にはホットリロードが有効になるなど、動作に違いがありますが、 好みや環境によってどちらを利用するか選択すれば良いと思います。

キャッシュを有効にしたいなどの理由から、Misocaでは bin/webpack --watch をデフォルトとし、foremanで利用するProcfileに記載しています。

ちなみに、webpack-dev-server では待ち受けポートがrails serverとは別(デフォルトでは8080)となりますが、このあたりは bin/webpack-dev-server や webpack用の設定ファイル内でいい感じに吸収してくれるので、特に意識しなくても大丈夫です。

まとめ

上記の他にも環境や既存のコードベースに応じた修正を行う必要があるかと思いますが、 導入にあたりコアとなった作業は以上です。

地味な作業も多かったですが、コツコツがんばりました。

最終的なdiffはこんな感じです。↓
+の部分はほとんどが yarn.lock ですが、なかなかのボリュームですね。

f:id:mugi1:20170616132756p:plain

成果としては、開発時の待ち時間も軽減され、なかなか良かったのではないかと思います。

Webpacker自体に関してですが、実際にはWebpackerが生成するボイラープレートに賛否両論あったりもするようです。個人的には、今まではRails+フロントエンドの環境構築は人それぞれだったものが、Rails Wayとして示されたこと自体が一つのメリットだと考えています。

カスタマイズしようと思った場合には、最終的にはある程度フロントエンド側の知識も必要となりますが、うまく使えれば様々な恩恵を受けられるかもしれません。

採用

MisocaではフロントエンドLOVEなエンジニアを募集中です!

MisocaのCI構成まとめ

こんにちは。4月からMisocaにjoinしました、tkykです。京都市内からリモートで働いています。盆地特有のねっとりとした暑さをやり過ごしつつコードを書いている今日この頃です。

f:id:tkykmw:20170609182049j:plain

さて、今回はMisocaのCI(Continuous Integration)環境がどうなっているか、その全体像を紹介したいと思います。

そもそもCIの目的とは?

ソースコードの一部に対する変更が、アプリケーション全体の動作を壊してしまっていないか、常時チェックするのが目的です。

そのために何をしているか

CI専用のサーバに、変更点を含むソースコード全体をチェックアウトして、依存ライブラリのインストールと必要な前処理を行い、すべてのテストを実行します。

すべてのテストがエラーなくpassしたことをもって、CIが通ったとしています。

Gitを使った開発フローとの統合

MisocaはGitHub上で開発を行なっているため、CIのプロセスもGitHubと密に連携しています。

リポジトリに新たなブランチをpushするたび、ブランチごとにCIが自動で実行されます。ブランチがPullRequestに紐づいている場合には、CIの結果がそのPullRequestに通知されます。

MisocaのCIを支えるツールたち

GitHubにpushしてから、CI結果が届くまでの流れはこのようになっています。

f:id:tkykmw:20170612132821p:plain

今のところMisocaではSaaS系のCIサービスは使用せず、EC2上に直接システムを構築しています。理由は、必要な性能(特にDBのI/O性能)を得るためのコストがかかりすぎるためです。

Jenkins

CIシステム全体を統括するのが、Jenkinsの役割です。

  • CIの実行方法を決定する
  • CIの実行結果を開発者に提供する
  • CIに関わる様々なタスクを実行する(例: テスト用DBのクリーンナップ)

など、多くの役目を担っています。ジョブの内容はGroovyコードで記述し、リポジトリの中で一体管理しています。

Jenkins の master/slave構成

多数のビルドを並列して実行できるようにするため、Jenkinsは1台のmasterと複数台(現時点では2台)のslaveで構成されています。またslaveそれぞれが同時に複数(現時点では2)のビルドを実行するよう設定されています。

現在のMisocaでは、masterはいくつかの重要なジョブのために予約されており、各CIジョブはslaveでのみ実行されます。

GitHubとの連携を担う GitHub Branch Sourceプラグイン

GitHub上での開発フローと、JenkinsによるCI実行とを統合するのが、GitHub Branch Sourceプラグインです。

このプラグインリポジトリに対するpushを検知し、ブランチごとにジョブを作成して、CIを実行します。PullRequestに対して結果を通知するのもこのプラグインの役割です。

rrrspec

rrrspecは、rspecを分散実行するためのソフトウェアです。

Misocaでのrrrspecの運用方法については、@kokuyouwindが書いた記事を参照してください。

rrrspec運用のためのInfrastructure as Code

上の紹介記事にある通り、rrrspec workerインスタンスはAuto Scalingによって増減します。すなわちいつでも起動・停止される可能性があるということです。よってworkerインスタンスは、起動してすぐにrrrspecクラスターに参加できるだけの、準備万端の状態で起動しなければいけません。

そのため、あらかじめ必要な設定・データをすべて盛り込んだAMIをつくっておき、Auto Scalingの起動設定でそのAMIを指定しています。

AMIは、VagrantChefを使って構成し、packerを用いて作成します。Auto Scalingやスポットインスタンスの設定はterraformによって管理しており、これらを一式まとめた構築レシピをGitで管理しています。

まとめ

こうしてCI環境が整備され、常時整合性に目を光らせているおかげで、我々エンジニアは安心してコードに手を入れられるようになっています。

採用

Misocaでは安心安全なCIのもとでコードを書きたいエンジニアや、CIシステムそのものを改善したいエンジニアを募集中です。

de:code 2017 に参加しました

こんにちは、Misoca開発チームの @corocn です。最近ようやくNintendo Switchゼルダを入手できました。楽しいですね、山登り。

今回は、2017/05/23〜24 に東京で開催された、de:code 2017 に参加しましたので、気になったトピックを紹介します。

Misocaは親会社の弥生株式会社と一緒に、ブース出展していました。当日は沢山の方にお越し頂きまして、ありがとうございました。Misocaのメンバーは水色の331Tシャツを着て立っておりました。

ノベルティーとして、タンブラーやTシャツをお渡ししていました!

全体の感想

Hololensの父、アレックス・キップマンの基調講演もあり、とにかくVRが推されてたという感想です。 Buildで発表されたfluent designもVRな未来に目を向けたデザインですね。 VR推しな3日間でしたが、私はWebアプリケーションやマネジメントの話を中心に聞いてきました。

前夜祭

前夜祭はデブサミとの共同開催でした。本編と同じ会場で開催されたのですが、裏側ではリハーサルが行われていたようで、スタッフはピリピリしているようでした。

  • 前夜祭の基調講演は、IoTのガジェットやダンスへの応用、VRのゲームなどエンタメ系の話が中心で、1/8タチコマの実物を見ました。めっちゃ欲しい。

  • Cerevoさん「90名ほど社員がいるが、採用人件費は0円」*1という話は驚きでした。

  • 「こんな面白いプロダクト作ってるんですか!一緒に働きたいです!」みたいな流れで採用しているようで、良いな〜と思いました。

本編の事前受付ができたので、可能ならば行ったほうが良いと思いました。おかげで基調講演は1番前に座れました。

day1

f:id:corocn:20170529163310j:plain

DO17 セゾン情報システムズのCTO 小野氏による、伝統的SIerにおけるモダン開発への挑戦

セゾン情報システムズの小野さんのセッション。

余談ですが、小野さんとは以前一緒にゲーム*2をしていたので、久しぶりに会えて良かったです。

CT02 War is over : ブラウザエバンジェリスト達とWebの未来を語ろう

Microsoft, Google, Mozillaエヴァンジェリスト達によるセッション。

  • 戦争が終わるのかぁ。長かったなぁ。という期待を胸に聞きました。

  • 実際、各ブラウザベンダーは足並みを揃えるようにしているようで、新機能のリリース情報は大体同じタイミングでブログが書かれるという話をしていました。

  • Web Components や PWA (Progressive Web Apps) の話が中心で、Polymer2.0を紹介していました。YoutubeもPolymer使って実装してあるみたい。

ちなみに「React」って単語は一言も出てこなくて、ブラウザベンダーの目指している未来がよく分かるセッションでしたね。時代はWeb Componentsだ!という感じ。実際に戦争が終わったかは謎です。

day2

f:id:corocn:20170529162817j:plain

MW09 TypeScript の概要と Language Server Protocol

トップゲートのわかめさんによるセッション。

  • TypeScript自体は、Dart等に比べてロックインのリスクも少なそうだから採用したそうです。
  • TypeScriptとBabelの比較の話が聞けるかな?と思いましたが、TypeScriptを触りだしたのがBabelが主流になる前だったようで、「良くわからない。宗教戦争だ!」でした。
  • 生のJavaScriptにも触れていたけど、時代が追いついてない。で終わりました。

  • LSP(Language Protocol Server)を初めて知りました。

  • LSPはエディタやIDE向けのアダプタで、エディタと言語サポートを切り離していこうぜ。という理解です。
  • 実際に補完候補の終端に のemojiを出すデモを見ました。

先日、GoogleがTypeScriptの採用を発表したことで話題になりましたね。実はTSには触れたことがないので、触ってみようと思います。

MR16 Build 2017 Updates ~ Application UI Design

Microsoftの高橋忍さんによるセッション。

  • Buildで発表されたfluent designの話の振り返り。抽象的な単語が多くでてきて、分かり辛かったとのこと。
  • トロデザインは「デザインが目的を達成する」というコンセプトで進めていて、フラットデザインを採用していたという話。
  • メトロでブルースクリーンが綺麗になりましたね(にっこり)という話が笑いを誘っていましたね。

  • fluent designは、2D、3D両方に適合するデザインコンセプトを持っていて、最初から3Dでの使用感を想定して作っていこうぜ!と感じています。

自分たちが提供しているサービスがどのように3Dと付き合っていくかを考える良い機会でした。

まとめ

以上、ざっくりですが気になったトピックを紹介してみました。

大きなカンファレンスに参加するのは実は初めてでしたが、新しい技術に触れたり、リアルで交流をするのは大事だなぁと思いました。来年も参加できたら嬉しいなあと思っています。

f:id:corocn:20170529175019j:plain:w400

採用

Misocaでは新しい技術で世界を変えたいエンジニアを募集しています!

*1:採用人件費という単語のスコープは不明です。

*2:World of WarcraftのFarEastというギルドで遊んでいました。

RuboCop とつきあう方法

こんにちは、元主夫の id:eitoball です。約5年ほどの試用期間*1を経て、今年4月から、Misocaにてフルタイムで開発しています。時事ネタは特にないですが、この夏に発売予定の Starcraft: Remastered を楽しみにしている今日この頃です。

今回は、本格導入してから、2年半になる RuboCop というツールについての話をしたいと思います。

RuboCop とは?

f:id:eitoball:20170526093756p:plain

RuboCop は、Rubyのコードが、コーディング規約に沿って書かれているかを静的にチェックしてくれるツールです。コーディング規約は、 Ruby Style Guide が、ベースとなっています。

RuboCop の導入

Gemfilerubocop gem を追加して、bundle install しました。rubocop と実行すると最初は、多くの警告が出てしまうので、rubocop --auto-gen-config で、.rubocop.ymlrubocop_todo.yml という設定ファイルが作成されました。.rubocop_todo.yml 内では、一旦、全ての検知項目が、無効にされていました。

Jenkins で、CIをしているので、rubocop を実行して、警告がある場合は、ビルドを失敗とするようにしました。 rubocop-checkstyle-formatter を開発して、Checkstyle 形式で警告を出力して、Jenkins の Checkstyle プラグインで、違反箇所が、Jenkins の UI から、分かるようにしました。

f:id:eitoball:20170526094327p:plain

無効にした警告の有効化

一旦、無効にした検知項目は、少しずつ有効にしていきました。できるだけ早く全ての検知項目を有効にして、違反するコードを増やさないようにしたかったので、次の方針で有効にしていきました。

  1. 可能な限り、RuboCop がデフォルトで有効にする。
  2. 1行の文字数などの検知項目は、とりあえず、その時点での最大値を使って有効にする。最大値が、他と比べて、極端に大きい場合は、マジックコメント(# rubocop:disable ...)で、その箇所のみを無効にする。
  3. 警告を修正する場合は、 rubocop -a で自動修正して、手動で修正する必要な箇所は、マジックコメントで、特定の箇所のみ無効にする。

検知項目を有効にする場合は、有効にするプルリクエストを作成して、チームによるレビューを経て、マスターブランチにマージしていきました。わかりやすくて、チームの合意が簡単に得られそうなインデントや行末の不要な空白などのレイアウト関連の警告は、5つ程度まとめて有効にしていきました。ハッシュの記法など議論が起こりそうな警告や変更が多い警告の場合は、1つずつ有効にしました。

f:id:eitoball:20170526102409p:plain

RuboCop の更新

RuboCop の更新に伴い、新しい検知項目が増えていきます。Misoca では、bundle update して、使用している gem を週に1回更新するようにしていて、RuboCop の更新は、大体月に1回程度です。新しい指摘項目が増える場合は、一旦、それらを無効します。それから、前述の方針で、できるだけ早く全ての指摘項目を有効にしていきます。

最新のバージョンを使う上で、注意したいのは、RuboCop の不具合や誤検知です。その場合は、問題のありそうな警告を無効にして、次のバージョンまで様子を見るのも良いと思います。もしくは、修正して、プルリクエストを出すのも良いと思います。同僚の id:mzp や僕は、プルリクエストを出して、貢献しました。

github.com

github.com

github.com

RuboCop を導入したメリット

RuboCopを導入してからは、プルリクエストでのレビューコメントで、記法についての指摘をすることが、無くなり、変数やクラス名についてを考えるとか他の重要なことについての時間を使うことができるようになりました。また、規約に関する指摘は、人からより、機械からの方が、角が立たなくて、心理的な負担がなくなりました。

さいごに

Misoca では、コーディング規約を守ってコードを書きたい几帳面な開発メンバーも募集しています。ご興味ある方は、是非、応募して下さい。

*1:事実は、家庭の都合で、パートタイムで開発していました

React・Reduxはじめました

こんにちは!
Misoca開発チームのめろたん(@renyamizuno_)です!

暖かくなってきて眠いですね。

最近は、「0.8秒と衝撃。」というバンドが活動を終了するってことを聞いて、まじかーとなってます。

はい。

今回はMisocaでReactを使い始めたことについて書きたいと思います。

React

詳しく書かないですが、ReactはFacebookで作られたユーザインタフェースを構築するためのライブラリです。

github.com

仮想DOMでJS界隈を賑わせていましたね。

class HelloMessage extends React.Component {
  render() {
    return <div>Hello {this.props.name}</div>;
  }
}

ReactDOM.render(
  <HelloMessage name="John" />,
  document.getElementById('container')
);

JSのなかにXMLみたいな感じでタグを書けるJSXっていうのも特徴的かなと思います。

jQueryとかでそこらじゅうでDOM操作してわけがわからなくなる。ということがなくなってとても良いですね。

どこにつかっているのか

tech.misoca.jp

ここで紹介されている、受発注機能の画面でReactを使っております。

f:id:renya-mizuno:20170515143533p:plain

当時から機能も足されて画面もリニューアルされてだいぶ変わってますね。

この画面は上の「Misocaへ戻る」以外はすべてReactで作ってます。

またこの画面に限ってはSPA (Single Page Application)として作られており、見積書とかを開くとナウい感じで開きます。

stateの管理はReduxを使っています。

github.com

Reduxにした理由は一番使われてるのでは?という感じですかね…。

Redux DevToolsはとても助かりました。

おすすめです。

よかったこと

大きい利点はUIをコンポーネントで管理できるようになったことですね。

今までのUIの実装はなんかジェンガをやっている感じでなんとか崩さないように、みたいな印象でしたがコンポーネントで管理できるようになったので、他のコンポーネントに気を使うことが殆どなくなってよかったですね。

またJSXのお陰でそのコンポーネントがどういう見た目・DOMで、何を行うものなのかがわかりやすくなったのでよかったです。

つらかったこと

Reactはまだわかりやすいかと思うのですが、Reduxが関わってきた瞬間にわけがわからなくなってしまいつらかったです。 とくに最初はよくわからず、connectを大量に行ってしまいそのまま進めてしまっていて、再描画があらゆるところで発生してパフォーマンスが相当悪くなっていたりしてました。

またアニメーションを行おうとすると簡単にはできず厳しいことが多々ありました。

github.com

これを使うといい感じにアニメーションさせることができるのですが、CSS命名規則にBEMとかをつかっていると上手くマッチせずこのためにそこだけ特例で命名規則を捻じ曲げる必要があったりしてちょっと気持ち悪い感じがあります。

まとめ

Reactをつかうことで、jQuery等でやってたDOM操作地獄が無くなるのはとてもいい感じでした。

とはいえ天国かというとそういうわけではないので、世の中難しいなぁという感じです。

frontend-temple.connpass.com

今回はざっくり書いたのですが、上のイベントでもう少し詳しい話をしようと思いますので是非いらしてください!

採用

MisocaではReactでナウいWebアプリケーションを作っていくぞ〜!というメンバーを募集しています!

リモートワークは一つの手段

 こんにちは、Misoca開発チームの @corocn です。自動車部品メーカ、SIerを経て、joinしました。最近はfactorioというゲームに嵌り、気づいたら連休が終わっていました。

Misocaのリモート事情

 Misocaでは、場所にとらわれない働き方を推進しており、フルリモートで開発しているメンバーが多数参加しています。

 同時期にjoinしたメンバーが4人ほどいるのですが、そのうち3人がフルリモートワーク、1人(私)がオフィスワークとなりました。2017年5月現在のメンバーの居住地を地図に表してみました。

f:id:corocn:20170510182023p:plain

 愛知は本社があるため人数多めですが、バリエーション豊かになってきました。色んな地域のメンバーが増えるといいなあと思っています。*1

フルリモート前提の組織づくり

 スムーズなコミュニケーションのために、Misocaでは以下のようなツールを使っています。

  • 社内チャット: Slack
  • ビデオ/音声通話: Google Hangouts, Slack Call, Zoom, Screenhero, Skype
  • 文章化: esa
  • タスク管理:Trello

 ミーティングはGoogle Hangoutsをメインで使用し、1on1のミーティングはSlack callを使ったり、ペアプロする時はScreenheroを使ったり等状況によって使い分けていたりします。普段の会話は、Slackでワイワイやってます。

f:id:corocn:20170414161022j:plain

 オフィスにいるメンバーは、常設してある巨大ディスプレイと会議用の広範囲集音マイクを使用して参加しています。マイク感度が高いので、リモートからの挨拶に対して、自分の席から挨拶を返すことができて、同じオフィスで働いているように感じさせてくれます。

働く場所は関係なかった

 普段オフィスで働いているメンバーも、都合に合わせてリモートワーク選択できます。私も毎日オフィスにいるのですが、実は先日初めてリモートを試しました。

「いつもと変わらず仕事ができている。なんだこれは。すごいぞ。」

と嬉しくなりました。場所を変えてもいつも通り働ける。 オフィスがあるとはいえ、前提がリモートだからこそできることだなあと思いました。今後も、雨の日などはリモートで働こうと思っています。

全員オフ会

 たまには、リモートの人も含めて全員で集まろうや!ということで こちらの記事でも触れているように、オフ会が開かれました。当日は全員がオフィスに集まって、写真を撮ったり、普段リモート経由でしかやり取りしていない相手とペアプロをしました。

「リアルでは初めまして!」

という会話が面白かったです。

目的はリモートにあらず

 リモートワークを導入したぜ!で終わっていませんか?

 目的は良いプロダクトを世の中に送り出すこと、そのために個人、チームが最大のパフォーマンスを発揮できることだと思っています。

 パフォーマンスを最大化できる環境は人それぞれで、家族のそばで働くこと、地元で働くこと、逆に、自分はオフィスにいたほうが良い。なんて人もいると思います。まつもとゆきひろ氏も語っているように、「ちょうどいい」は人それぞれなんです。

「仕事があった」のが最大の理由だけど、人口が大きすぎず、小さすぎず、(私にとって)ちょうどいい感じの都市だったのが20年住み続けた理由のような気がします。それぞれの人がじぶんの「ちょうどいい」を見つけられるといいな。 私が松江にUターンした理由 – Yukihiro Matsumoto – Medium

 その選択肢の1つとして、リモートワークが選べるのが良いのではないでしょうか。

採用

Misocaでは「ちょうどいい」を大切にするエンジニアを募集しています!

*1:愛知に本社、島根に松江オフィスがあります

再ジョインしてから10ヶ月間、Misoca内で起こった事

どうも、Misoca開発チームの @snowsunny です。

昨年の7月にMisocaに再ジョインした話を書かせて貰った者です。

tech.misoca.jp

自分の都合で、4月いっぱいでまたMisocaから旅立つ事になったので、今回は再ジョインのまとめとして、10ヶ月間でMisoca内起こった事、思った事を書いていきたいと思います。

人が増えた!!🎉

10ヶ月間で一番変わったなーと思う所であり、Misoca開発チームの文化に大きく影響を与えていると思います。

昨年の7月から今年の5月までで、開発者の人数が倍近く増えています!

自分が入った時点では、オフィスにある机や椅子、モニターにも空きがあったのですが、現在はそれでは足りなくなってきて新たな机、椅子、モニターが増えました。

オフィスにくる人だけでもその状態なのですが、リモートワークで働かれる方も増え、朝会等でGoogleハングアウトを開くと右下に多くの人のカメラ映像や、アイコンが映っていて「人増えたなー」と実感しています。

新しい人達がもたらす空気はとても新鮮で、それによって社内のコミュニケーションやプロセス、コードの見直し等、色々な事がドンドン改善・修正されていきました。

Misocaに入るまでは、同じ顔ぶれの少人数でずっと開発をする事が多かった自分としては、とても楽しい体験でした。

プロジェクトの概念の導入

これが導入されるまで、Misocaでは開発チーム全体での朝会や、ふりかえり、タスクの相談等を毎朝行っていたのですが、全てを一括で行っていた為、冗長に感じる事があり開発チームの中で大分負担になってきていました…。

そこで大きな目標に合わせて細分化された、プロジェクトと言う概念が導入されました!

プロジェクト毎に朝会やふりかえり、相談を行う事で、冗長に感じる時間を無くし、ミーティングの時間を大幅に縮小する事ができました。

前述の人が増えた事によって出来る事が増え、現在Misocaでは開発だけで4つのプロジェクトが同時進行しています。

この概念はずっと生き続けていて、現在のMisocaの開発には必要不可欠な物になっています!

詳しくは下記の記事をご覧下さい。

tech.misoca.jp

スクラム開発の実践

プロジェクトに分かれた事で、開発プロセスとして新たな試みを行いやすくなり、受発注プロジェクトで試験的に始まったのがスクラム開発でした。

前職でスクラム開発を行っていた人が居て、その人を中心にやり方が整備されて皆で実践していった感じです。

具体的には全員でプランニングポーカーでストーリーポイントを見積もって、スプリントのベロシティーを計測してバーンダウン&アップチャートを作って進捗確認をしたり、スプリントレビューで成果を振り返ったりしています。

最初は受発注プロジェクトだけで使われていた手法だったのですが、受発注でのノウハウが開発チームに共有され、現在は他のプロジェクトでもそのプロジェクトに合った方法に変えながらスクラム開発が行われる様になってきました。

こう言う新しい実験的な試みをドンドンやらせて貰えるMisocaの開発環境は本当に素晴らしいなーと思います!

自分としては「スクラム開発」って言う名前だけは知っていたのですが、実際に使ってみた事は無くとても新しい体験でした。 特にプランニングポーカーでの見積もりで全員の認識の齟齬を無くしたり、バーンダウン&アップチャートを作って進捗確認するのはとても分かり易く良いやり方だと思うので、Misocaを出た後の仕事でも是非活かしていきたいな思っています!

その他

  • Ruby会議のスポンサー参加
  • Ruby biz大賞受賞
  • 一つの終わりと新たな始まり
  • 弥生からの友
  • Misocaボードゲーム
  • 受付水漏れ騒動
  • 自動ドア粉砕事件
  • 初めてのゴルフ場 雨のち晴れ

等々、他にも色々あったですが、それはまた別の機会に。

まとめ

再ジョインして10ヶ月経ちましたが、その10ヶ月間で、Misocaの開発プロセスや環境は大きく変わっています。 もう最初にどんな感じで開発を進めていたのかハッキリ思い出せないくらいです…w

そしてその変化は良くなる為の物であり、Misocaは現在進行系で変化し続けています。 1年後くらいのMisocaの開発環境は、また大きく違うより良いものになっているんだろうなーと確信しています。

こう言う変化を続けるMisocaで働けたのは、開発者としてとても楽しく、とても良い経験になりました。

5月からMisocaを離れるのですが、Misocaで得られた経験を活かして違う仕事に邁進していこうと思います!💪

Misocaの皆様へ

再ジョインしてからの10ヶ月間、ご迷惑をおかけする事も多かったと思うですが、色々な経験をさせて頂いて感謝の念でいっぱいです。

またどこかでお会いする機会があったら仲良くしてやって下さい。

本当にありがとうございましたー! 👋 😊