DENTAKU

こんにちは、 @mugi_uno です。

娘が保育園で私の似顔絵を描いてくれました。
黒いメガネがオシャレで、とてもよく描けていました。

ちなみに私はメガネはかけてません。誰の顔を描いたの。

電卓機能

先日Misocaに電卓機能を実装しました。

www.misoca.jp

f:id:mugi1:20190718175926p:plain

この機能は、2019年4月に行った開発合宿*1の成果物が元になっています。

「たかが電卓、されど電卓」ということで、リリースまでに様々な知見やハマりどころがあり、とても楽しかったです。 今回はこの電卓機能がリリースされるまでのお話です。

🤔なぜ電卓?

「Webサービスなんだから小計とか合計は自動で計算されるのに、なんで電卓なんか必要なの?」と思うかもしれませんが、 文書を作成するときには、意外と些細な計算が必要となることが多く、

  • 10%引きにした単価にしたい
  • 総額3万円からの差額を明細に含めたい

といったケースがよくある例です。

従来のMisocaでは、これらの計算はユーザ側で物理・あるいはアプリなどの電卓を用意する必要がありました。 そしてそこから結果をまた画面上で入力する必要があり、とても面倒です。転記時に間違えるリスクも増えてしまいます。

請求書を作る体験の中にシームレスに電卓が組み込まれていることで、 ストレス無く文書を作ることができるようになるというわけです。

...と、前々から考えていたものの、なかなか「おっしゃ気合い入れて電卓作るぞ!」とはならないものです。 そんな中ちょうど開発合宿があり、ガッとプロトタイプを作ってみたところ社内でも評判が良く、ブラッシュアップしてリリースしよう!という運びとなりました。

📚電卓を知る

正直言うと「電卓なんて押された数字で四則演算できればいいだけでしょ〜」程度に軽く考えていましたが、 実際作るために様々な電卓の仕様・挙動を調べていると、なかなかに奥が深くて面白かったです。

ボタン

電卓に ボタンがあるのをご存知でしょうか。私は存在自体に気付いていませんでした。 これを利用すると、「特定の値のN%引きの値」などを簡単に算出できます。

2 0 0 2 0

と入力すると、240 が結果として得られるのです。便利ですね。

しかし、この挙動は電卓のメーカーによって違いがあり、たとえばCASIO製の電卓の場合には

2 0 0 × 2 0 %

と入力する必要があります。 Misocaで機能実装するにあたって、どの挙動に揃えるかの検討が必要でした。

最終的には、多くの電卓の挙動である

2 0 0 2 0

240 が得られる方式を採用しています。

計算順序

次の順番でボタンを押したときの計算結果が、電卓によって異なります。

1 0 0 5 × 2

ほとんどの一般的な物理電卓では、掛け算・割り算の順番は考慮されずに (100 + 5) × 2 扱いとなり、結果は210 です。 しかし、例えばiOSに搭載されているデフォルトの電卓アプリなどの場合は、式全体を考慮して 110 になります。

Misocaでは物理電卓側に寄せて、この場合は 210 となるようにしています。

💪使いやすさを追求する

機能追加するなら、せっかくなら使いやすい便利なものにしたいですよね。 内部の多くの人に触ってもらい、さまざまな感想をもらいつつ動作を調整していきました。

⌨️キーボード入力対応

最初はマウスなどで電卓をポチポチクリックして操作するのみのイメージだったのですが、 以下の感想をもらいました。

f:id:mugi1:20190719133151p:plain:w400

確かにそのとおりだな〜と思い、キーボード入力でも動作するように拡張しました。 しかし、軽い気持ちで始めたら色々とハマって大変で..

key / code / keyCode が環境で色々と変わる

JavaScriptで入力されたキー情報はkeyDownやkeyUpといったイベントから KeyboardEvent.key / KeyboardEvent.code / KeyboardEvent.keyCode といった値を参照する方法がよく知られていますが、 これらの値はブラウザによって一部に差異があり、個性の強いわんぱくブラウザではまったく違う値を返すこともあります。

また、たとえば keyCode はキーボードのJIS/US配列によって、期待値とズレる可能性があります。*2 US配列のHHKBを愛用している私だけ挙動が違っていて大変でした。

というわけで開発中は、Windows/MacOS × Chrome/Safari/FireFox/Edge/IE11 × JIS/US といった多数の組み合わせで確認しつつ、 どの環境でも自然に動かせる最適解を見つけるためにひたすら試行錯誤を繰り返していました。

最終的にはこんな感じで動作するように仕上がりました。

f:id:mugi1:20190719141643g:plain:w500

🔧細かな動作調整

ほかにも様々な動作調整を行いました。

  • 電卓の開閉のショートカットキーは何が良い?
  • すでに入力されている状態で電卓を開いたら?
  • 文字選択状態で電卓を開いたらどうする?
  • 100 / 3 * 3 の結果は何になるべき?
  • などなど..

あまり華やかではありませんが、頻繁に使うことになる可能性も高い部分なので、 ストレスを感じない使いやすいものを目指し、コツコツと地道な修正・改善を繰り返します。

🎉リリース

そんなこんなで、先日無事に機能リリースできました!

昨年に引き続き*3、 今年も合宿の成果をプロダクションへのリリースに繋げることができたので、個人的にはとても満足なプロジェクトでした。

合宿の価値が証明されつつあるので、来年あたりはハワイでの開発合宿に期待したいと思います。

採用

Misocaでは使いやすさを追い求めるエンジニアを募集しています

www.wantedly.com

「斧を研ぐ時間」エンジニアリングフライデーという試み

こんにちは Misoca 開発チームの id:mallowlabs です。最近は ドラえもん のび太の牧場物語 にハマっています。使っている道具のグレードを上げるために、牧場はそっちのけで鉱山にこもって鉱石を掘り出す毎日です。

さて、先日の 軽減税率・区分記載請求書対応のリリース は開発チームにとっても比較的大きなリリースでした。そのため、リリースの直前には、このリリースに関係しないコミットは master ブランチにマージを控えることになり*1、自然と開発メンバーが普段使っているツールの整備や自由研究が行われることになりました。 ふりかえりで、このいわゆる「斧を研ぐ時間」がよかったという声が複数出たため、この時間を狙って作ってみようという TRY が生まれて「エンジニアリングフライデー」という試みが生まれました。 今回はこのエンジニアリングフライデーについて紹介したいと思います。

エンジニアリングフライデー

プレミアムフライデーにちなんで、その月の最終金曜日に開発メンバーがプロダクトの開発以外のことを行う、という取り組みです。 特に細かいルールは設けず、

  1. 事前にやろうと思っていることを Scrapbox に書き出す
  2. 16時になったら成果発表をする

ということだけ決めて実施してみました。

f:id:mallowlabs:20190711151254p:plain
Scrapbox の様子

エンジニアリングフライデーの成果

様々な試みが行われましたが、例えば以下のような改善が行われました。

  • 気になっている箇所のリファクタリング
  • CI の高速化
  • フロントエンドのテストのカバレッジを CI で表示
  • Lint のルールの整備
  • BigQuery で分析した結果を Redash で可視化
  • Trello / GitHub / esa の URL を Slack に貼ったら展開
  • etc...

たった一日でしたが目に見える成果が数多く出て驚きました。 「やってよかった」という声が複数出たため、また次回もやってみようということになりました。 「合宿より誘惑が無いから逆に捗るのでは?」という意見もあり、一日とはいえ大きな進捗を感じたメンバーが多かったようです。 残念ながら日程の関係で参加できなかったメンバーからも「次回は絶対参加したい」という声が上がりました。

次回のエンジニアリングフライデーもどんな成果が出るか楽しみです。

Trello / GitHub / esa の URL を Slack に貼ったら展開

ちなみに私の成果は「Trello / GitHub / esa の URL を Slack に貼ったら展開」です。 せっかくなのでオープンソースにしています。

AWS SAM で簡単に動かせるので試してみてください。

f:id:mallowlabs:20190708175939p:plain
展開の動作イメージ

採用

Misoca では斧を研ぐ時間も大切だと思っているエンジニアを募集しています。

www.wantedly.com

*1:master へのマージを控えるという人の意識に頼った運用はミスが生じかねません。現在、大きな機能変更をしながらも、master へのマージを可能にする仕組みを構築・運用中です。詳細は後日このブログで公開予定です。

Misoca メンテナンス画面の裏側

Misoca の開発をしている id:mizukmb です。

先日、Misocaでは軽減税率8%の入力、および区分記載請求書の形式に対応しました。今回のリリースはシステム全体に関わる大規模なものとなったため、リリース作業中の時間はWeb・API・iOS/Androidアプリ全てのサービスを停止し、メンテナンス中としていました。

これまでMisocaではサービスを長時間停止させたメンテナンスやリリースをほとんど実施しておらず、メンテナンスモードを簡単に切り換える機能はありませんでした。加えて、今回のリリース作業の時間においては、下記を実現する必要がありました。

  • 一般ユーザからはMisocaサービスにアクセスさせたくない(メンテナンス中として見せたい)
  • 開発者など、特定の条件を見たすユーザの場合は、メンテナンス中でも本番環境にアクセスして動作確認ができるようにしたい
  • 外部連携するシステムによっては、メンテナンス中でもアクセスを止めたくない

そこで、今回のリリースに合わせて上記の要件を満たすメンテナンスモード機能を実装しました。本ブログでは、メンテナンスモード機能の紹介や、実際のメンテナンス画面などをお見せしていきたいと思います。

メンテナンスモードの仕様

メンテナンスモードの有効・無効の切り換え方法として以下の2パターンを用意しました。

  • スケジュール実行による有効・無効の切り換え
  • 手動による有効・無効の切り換え

メンテナンスモードの状態は上記2パターンをORで判定しています。ですので、どちらかが有効になっていればメンテナンスモードになりますし、どちらも無効にならない限りはメンテナンスモードは停止しません。

こうした仕組みにした理由は、メンテナンスの時間を延長した場合にスケジュールの時間を変更するよりも簡単にできるようにするためです。

また、メンテナンスモードの状態管理はRailsアプリケーションに持たせています。調査の段階では、ロードバランサで制御する方法も検討しましたが、先に述べた要件を満たすためには、現行のシステムでは実装コストが非常にかかるということが分かったので、Rails内で制御する方法に決定しました。1

設定方法

スケジュールの設定

メンテナンスモード設定用のYAMLファイルに時間を書きます。デプロイすると、指定した時間内はメンテナンスモードが有効になります。

開始・終了時間の設定は2つ以上設定できないようにしました。メンテナンス自体は頻繁に行われるものではないため、高機能にさせすぎず実装をシンプルに保つためです。

# メンテナンスモードの有効・無効を設定する
# `start_time` `end_time` に記述する日時のフォーマットは以下の通り。タイムゾーンはJSTとする
#   YYYY/MM/DD hh:mm:ss
production:
  start_time: 2019/06/18 05:00:00
  end_time: 2019/06/18 06:00:00

手動の設定

手動のON/OFFはThorタスクを使うようにしました。誤って使われないように、こちらの機能は実行できる権限を持つ人を限定しています。

特定ユーザのアクセスを許可するための設定

メンテナンス中に開発者を含む特定ユーザがアプリケーションにアクセスして動作確認できるように、ホワイトリスト方式でアクセスを許可するIPアドレスやHTTPヘッダを指定できるようにしました。

# メンテナンスモードの有効・無効を設定する
# `start_time` `end_time` に記述する日時のフォーマットは以下の通り。タイムゾーンはJSTとする
#   YYYY/MM/DD hh:mm:ss
production:
    (snip)
    ips: ['XXX.XXX.XXX.XXX', 'YYY.YYY.YYY.YYY']
    header:
      name: 'X-Foo-Bar'
      value: 'value'

これにより、前述の

  • 開発者など、特定の条件を見たすユーザの場合は、メンテナンス中でも本番環境にアクセスして動作確認ができるようにしたい
  • 外部連携するシステムによっては、メンテナンス中でもアクセスを止めたくない

を実現しました。

実際の様子

f:id:mizukmb:20190702145424p:plain
メンテナンス画面

全てのページで上記画面を表示するようにしました。メンテナンス情報は別ページを見てもらうようにリンクを貼っています。サービスによってはツイッターの公式アカウントを載せているところもあるみたいです。速報値を伝えるためにこうした情報は外に置いておくことが重要だと思います。

HTTPステータスコードは 503 Service Unavailable を返しています。

おわりに

メンテナンスモードの仕組みについて紹介しました。調査の段階で得た気付きとして、他サービスのメンテナンス画面を調べようとしてもそんな都合良くメンテナンス中のWebサービスは見つからないということです。Herokuがメンテナンスモード機能2を提供しているため、社内のHeroku上で動いているサービスをメンテナンスモードにして参考にしていました。

採用

Misocaのサービスをメンテナンスしてくれる人を募集しています。

recruit.misoca.jp


  1. 根本原因を解決することも検討しましたが、一旦スコープから外しました

  2. https://devcenter.heroku.com/articles/maintenance-mode

画像を使ったテストでリリースサイクルをあげる

こんにちは、MisocaでAndroidアプリを作っている @k0matatsu です。

MisocaのAndroidアプリではリリース前に通常10営業日のテスト期間を設けています。
おおよそ1ヶ月に1回リリースを行っているため、開発期間の半分がテストに費やされていることになり機能追加にさける時間が圧迫されています。

そこで、品質を落とさずにテスト期間を圧縮するために画像のdiffによるテストを導入しました。
これにより表示を確認するテストケースは大幅に削減できます。

spoonを使ったスクリーンショットの取得

f:id:komatatsu:20190624193113j:plain

画像のdiffによるテストを導入するためにspoonというソフトウェアを使いました。
これはAndroidの開発を行っている人にはポピュラーな選択肢だと思います。
この記事では詳しい使い方などは説明しませんが、ネットにたくさんの知見がありますので興味を持たれた方は調べてみてください。

espressoやUI Automatorを使って画面表示や遷移を行い撮影したい状況を作り、spoonを使ってキャプチャするという方法でスクリーンショットを撮影しています。
撮影されたスクリーンショットはdiffの比較がしやすいようにスクリプトでまとめています。
本当はreg-suitなどを使って見やすくしたかったのですが、最初から完璧をめざしているとなかなか導入できないので、ひとまずgithub上で見比べることができることをゴールとしました。

ほかにも次の点については導入段階では対応しない判断を行いました。

  • 通信処理のモック化
    • これはチャレンジしていたのですがハマってしまったので諦めました
    • スクリーンショットの撮影は日に何度も行うわけではないので決まった環境で実施する運用でカバーするものとします*1
  • 画面表示のバリエーション網羅
    • 税の設定や金額で多岐にわたるバリエーションがあるため断念しました
    • 徐々に範囲を拡大したいと思っています

一方で、テストの安定性については妥協せず進めました。
UIの絡むテストだと表示の待ち合わせなどで成功率がさがりがちですが、偶発的に失敗するテストは信頼感を損ないます。
テストが信頼できないと人間による確認の手間が発生してしまい、メリットが薄まってしまうのでこの点はこだわりました。
今はテストコードが原因で偶発的に失敗するようなテストはリポジトリにありません。

恩恵について

この画像のdiffによるテストが適用されたバージョンはまだ開発中なので具体的に何日短縮できたのかはまだ明らかになっていませんが、多くのテストケースが削減できそうなので期待を寄せています。
テスト工数の削減はリリースサイクルをあげるだけでなく、人間でないと判断が難しい作業にリソースを集中させられるメリットがあります。
UIテストにおいてテストケースのメンテナンスコストがよく問題視されますが、毎バージョン変更が入るような画面はほとんど無いはずです。
テストが自動化されることで些細な変更でも「変更した部分だけ確認しよう」ではなく、すべてのテストケースを確認しやすくなります。
このような変化が品質の底上げにつながると信じています。

MisocaのAndroidアプリもカバレッジはまだまだ低いですが、効果の高い部分から地道に自動テストの範囲を拡大しています。
私はこういった基盤的な作業が好きなのですがMisocaにはAndroidエンジニアは私しかおらず、普段はサーバーサイドエンジニアに手伝って貰っています。
たしかに品質も大事なのですが、フリーランスの商取引における課題はまだまだ山積しています。
これらの課題を解決し、フリーランスの方々が安心して自分の業務に集中できる環境を構築すべく新たな機能の設計開発にももっともっと取り組みたいと思っています。

Misocaでは私の背を守りバリバリと価値を形にしてくれるAndroidエンジニアを募集しています。

recruit.misoca.jp

Twitterなどでお声がけいただければ普段の様子などお話できますのでぜひご気軽ににお声がけください。

追記: テスト対象とした画面について

Twitterにて対象とする画面について質問がきたのでこちらに追記します 。

画像のdiffによるテストの導入は普段の作業の合間に少しずつ進めていました。
この作業に割ける時間は少なかったので、テストを書いてもすぐ修正することにならないように、変更頻度の低そうな設定画面のキャプチャからはじめました。
次いで全画面のファーストビューのスクリーンショットを撮ろうとしているのが今の状態です。
今後は再現させるのが難しいエラーの表示から優先的に範囲を広げていこうと思っています。
これは元の目的がテスト期間の削減なので、簡単にテストできる正常系よりも再現手順の面倒な準正常系を自動化したほうがテスターの負荷がさげられると考えているためです。

*1:ユニットテストは既にモック化されているのでこの判断になりました

名古屋Ruby会議04登壇 & もくテク開催のお知らせ

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

最近HitogataでVRアバター出社をはじめました。

f:id:kokuyouwind:20190605155611p:plain

上段真ん中でキラッ☆としてるのが自分です。

かわいい女の子になれて楽しいのですが、Windowsでしか動かず作業用Macと2台体制になってしまうのが地味に不便です。WSL2が来たらWindowsにちゃんと開発環境を構築しようかな…

名古屋Ruby会議04

もう今週末に迫ってしまいましたが、6月8日に大須演芸場で名古屋Ruby会議04が開催されます。

f:id:kokuyouwind:20190605164528p:plain

自分が「入門 関数型-ish プログラミング on Ruby 」という胡乱なセッション名で登壇するほか、Misocaから他に@KawamataRyoがスポンサーLTを行います。他の登壇者の方々も豪華メンバーですね。

前回の名古屋RubyKaigi03も大須演芸場で開催されたのですが、登壇者のめくりがあったり、2階席が椅子ではなく桟敷席になっていたりと、独特の雰囲気で非常に面白いです。

すでに枠が埋まってしまっていますが… 当日までに枠が空く可能性もありますので、未登録の方はよければキャンセル待ちにご登録いただければと思います。

会場で会えるのを楽しみにしております。大須演芸場で僕と握手!

もくテクpowered by Misoca #1 リモートワーク座談会

そしてそして、明けた木曜日の6月13日には、もくテクpowered by Misoca #1 リモートワーク座談会が開催されます。

f:id:kokuyouwind:20190605164410p:plain

こちらは名前の通り、Misoca主催の勉強会です。もくテクは弥生株式会社が1年以上主催しているものですが、今回はそれのMisoca主催バージョンになります。

毎回いろいろなトークテーマを取り上げていく予定で、初回は「リモートワーク座談会」です。リモートワークに関するあれこれを、Misocaのメンバー数名でパネルディスカッションする形になっています。

会場も秋葉原・名古屋・松江・富山と各地から参加でき、さらにはYoutube Live配信もありと、リモートワークをある意味体現したものになっています。

こちらもよろしければぜひお越しください。

宣伝

Misocaではコミュニティイベントを盛り上げていきたい 方を募集しています!

www.wantedly.com

『入門 監視』社内読書会を開催しました

2019年1月〜5月上旬の間、『入門 監視』という本の社内読書会を週一で開催しました。

www.oreilly.co.jp

今回は、社内読書会開催に至ったきっかけや実際の進め方、社内読書会を通じての学びやその後のアクションについてお話したいと思います。

社内読書会をはじめたきっかけ

この本が予約開始になった時に、目次を読んで内容に興味を持ったことと、社内でも展開できれば今以上に開発チームとして監視についての十分な知識や体制が作れるかも、と思ったのがきっかけです。

任意参加にして、毎週金曜の18時から一時間程度で読書会をやりましょうと社内で参加者を募り、本が発売したその週から社内読書会を開催しました。

社内読書会の進め方

ざっくり、以下の流れで進めました。

  • 本を黙読する (35分くらい)
    • 毎回、1章ずつ読み進めていた
  • 参加者から一言ずつ感想をもらう (5分くらい)
  • 参加者全体による感想戦 (適当に満足するまで)

気軽に参加できることを目標に、事前に読んでおくということはしませんでした (もちろん個人でどんどん読み進めるのはOK) 。

また、弊社では名古屋・松江オフィス勤務だけでなく親会社である弥生本社(東京秋葉原)や自宅からのリモートワークで各地から仕事をしてる社員もいることを考慮して、Zoomを使ったビデオ通話で集まるようにしました。普段のミーティングも基本ビデオ通話なので、特に違和感なく進められました。

さて、本を黙読する と書きましたが、もくもくと読み進めている中で、実はとある場所でメンバー同士議論や感想を交わしていたのでした。

Scrapboxを活用した非同期かつ互いに干渉しない読書と議論の両立

その場所とはScrapboxというドキュメントサービスです。

本の内容に関する感想や疑問に思ったことなどは、Scrapboxのプロジェクトページに参加者みんなで書き込むようにしました。

scrapbox.io

Scrapboxを採用した理由としては

  • 複数人のリアルタイム編集ができる
  • 箇条書きが書きやすく、メモやコメントに良さそう
  • テキストベースにしてオフィス・リモート間のコミュニケーションコストを統一させる
    • 口頭ベースだとどうしても物理にいる人同士がつよくなってしまいがちなので

があり、黙々と読みつつ分からなかったり気になったことはScrapboxにみんなで書き込むというスタイルは読書会と相性が良いのではないかと思ったからです。

また、/shokai/ぜんぜんわからん分野をゆるく読書会する という記事の中でScrapboxを使った読書会について書かれていて、うまく活用できるような雰囲気を感じ取りました。

実際に使ってみると、読書中はみんな黙って本を読んでいるので集中できるし、でも実際はScrapbox上で気になったことを書いていたり、質問を書く・回答するといったことが行われていて、読書会として非常に新鮮な体験で、快適に読書を続けられることができました。

ビデオ通話だと小さな声で近くの人に相談するということが難しく(マイクを通して話すとどうしても音量が大きくなる)、読書に集中してる人の邪魔をしたくない気持ちから口頭ベースの相談や感想がやりにくくなってしまいます。テキストベースにすることでこうした問題を解消でき、数あるドキュメントツールの中でも同時編集可能・気軽に箇条書きで書ける特徴を持ったScrapboxは読書会にはピッタリなツールであったと個人的には思いました。

f:id:mizukmb:20190529134212p:plain
メモの一部。このようにアイコンを後ろに付けることで会話してる雰囲気が出て楽しい

学び、アクション

最初は、インフラ分野にちょっとだけ興味があるのでまあ読んでおくかぐらいの気持ちでいたのですが、読み終わると、特に私達のようなWEBサービスを開発・運用する開発者たちは、フロントやアプリケーションといった領域を問わず読んで損はない内容だなと思いました。

なかでもビジネスの観点で監視をするという視点は、目から鱗の内容でした。ビジネスと連動させてアプリケーションやサーバの状態を見るということに気付けたことが個人的には本を読んだ中で一番良かったかなと思います。

また、読み終えた後に何かアクションにつなげていきたいと思い、以前からやろうと構想していた『Mackerelのグラフにアプリケーションのリリース日時を記録する』を導入してみました。これは、『7章 アプリケーション監視』にある ビルドとリリースとパイプラインの監視 を実行に移したものになります。

f:id:mizukmb:20190528202433p:plain
構想を書いた社内のesa記事

終わりに

入門 監視という本の社内読書会の開催とその進め方、学びやアクションについて書きました。

全体のページ数も多くなく、『入門』というタイトルにふさわしい良い一冊であると思います。

採用

監視や読書が好きな方を募集しています。

www.wantedly.com

「Misocaのリモートワーク」を支える仕組み

こんにちは。 今年4月にMisocaにジョインしました@KawamataRyoです。

最初に自己紹介を。
少し変わったキャリアで消防士歴が6年、エンジニア歴は1年と半年です。*1
入社後は、こちらの記事のTypeScript化や、開発合宿の副産物(Print.jsを使った印刷ダイアログ表示)のリリースを行ったりしていました。
今は茨城県からフルリモートで開発をしています。

リモートワークはメリットだけではなくネガティブな意見を聞くこともあります。
私自身、エンジニアとしての経験が浅いだけに入社前はリモートワークに不安がありました。
ですが、今はとても充実した開発ライフを送っています。
それもMisocaのリモートワークの仕組みのおかげだと思ったので、今回紹介します。

f:id:ba068082:20190523062444j:plain
昼休みに走っている家の近所のランニングコース。どこまでも続く田んぼ道。

常時接続のWebミーティング

出勤から退勤までZoomのwebミーティグRoomに常時接続しています。
こちらのRoomは名古屋オフィスにも繋がっており、常にオフィスの様子が見られます。
  
「リモートワーク = 孤独」というイメージが強かったのですが、Misocaの場合はそんな事はないですね。
顔の見れる関係?なので、詰まった時なども気軽に質問しやすいです。

f:id:ba068082:20190523134356p:plain

ペアプロ・モブプロ文化

Misocaはペアプロ・モブプロが盛んでワイワイ開発しています。
入社前はもっと黙々と開発すると思っていたのですが、 自宅にいる妻に「仕事中なのに、笑いすぎじゃない??」と小言いわれるほどワイワイしてます。

主に2〜4人でZoomに繋いでプログラミングすることが多いです。
あとはVSCodeのLiveShareを使ったりもします。
モブ・ペアでやることで初期キャッチアップのコスト削減、コードの属人化の排除など利点が多いなと思いました。
もちろんずっと繋いでいるわけではなく、一人で黙々と開発する時間も十分あります。

f:id:ba068082:20190523135940j:plain

今の気持ちを共有する分報

current_(名前)というslackチャネルを開設し、その時思ったことなどを随時共有しています。*2
そちらでつぶやいた内容は、全員がメンバーに入っているcurrent_allチャネルに流れ、そこで皆の今の状況がわかります。
こちらのつぶやきから詰まっている状況が共有され、ペアプロ・ペアオペに発展していくなどもあります。
あとはここから始まる雑談も多いですね。 リモートワークのつらみとして「雑談できなくて辛い」というのを聞くことがありますが、Misocaでそれを感じたことはないです。

f:id:ba068082:20190523155152j:plain

毎日の朝会・週次の振り返り(KPT)

毎日、全員参加の朝会があり連絡・相談事項の共有などを行います。
(11:30から開催なので、もはや昼会な気もしますが。。)
前述した常時接続のZoomで行います。
以前の記事でも紹介した通り、タスク管理ツールのTrelloを使い効率的に進めています。

またプロジェクトごとに週次の振り返り(KPT)もあり、問題点の共有、改善策の提案なども行っています。

f:id:ba068082:20190523160530j:plain

誰でもどこでも働ける会社

物理オフィスが名古屋と松江、東京(弥生オフィスの一部スペース)にあり、いつでもそちらへの通勤が可能です。
Misocaはリモートワークの会社というより、誰でもどこでも働ける会社というのが正しいですね。
また、年に一度の全員オフ会の時は、名古屋オフィスに皆で集合します。
今年の全員オフ会は、こちらの記事で紹介されています。

f:id:ba068082:20190522091954j:plain
全員オフ会時の名古屋オフィス。この後皆で紙飛行機ワークショップを行いました。

おわりに

以上、Misocaのリモートワークを支える仕組みでした。

来る6月13日19時30〜から、「もくテク powerd by Misoca」にてリモートワークの座談会を行います。
東京、名古屋、松江、富山サテライト会場(自宅)の4拠点から、普段の仕事の感じでZoomのRoomに集合してパネルディスカッションを行います。

今回の記事で紹介した内容以外にも、リモートワークを効率的に進める知見など幅広く共有できると思うので、ぜひ興味あればご参加ください。(私もリアルで登壇します)

mokuteku.connpass.com

Misocaではリモートワークでも幸せに働きたいエンジニアを募集中です。

www.wantedly.com

*1:詳しいキャリアはこちらよりhttps://note.mu/ryo_kawamata/n/n4fc0fa900314

*2:分報が必須なわけではないです