Misocaのリモートワーカーの仕事環境2019

こんにちは。@KawamataRyoです。
エンジニアになってから着々と体重が増えて、先日80kgの大台に乗りました。
大学の部活ではライト級(60kg以下)で試合に出てたのでその頃から20kgの増量。日々色々な方面で成長中です。

さて今回は、Misocaのリモートワーカーの仕事環境のお話です。
以前こちらの記事で紹介してから早2年、メンバーの入れ替わりもありリモートの環境も大分変わったと思うので、2019年度版を改めて紹介します。

f:id:mugi1:20190925141503p:plain:w30 @KawamataRyo

リモート歴 基本勤務時間
6ヵ月 8:00〜17:00

f:id:ba068082:20191021100746p:plain

仕事環境のこだわり

  • モニターアームがカッコいいと思い、無駄にディスプレイを浮かせています。キーボードの押打でめっちゃディスプレイが揺れるのが悩み
  • 椎間板ヘルニア持ちなので、デスク、椅子は良いものを使っています。昇降デスクなので時々スタンディングデスクとしても使っています
  • 隣にベンチ、腹筋コロコロがあるので、休憩時はいつでも筋トレ可能です

リモートワークに思うところ

  • リモートワークをやる前は不安だったのですが、始まってみればとても自然にコミュニケーションができて、むしろオフィスにいた頃より会話が多い気もします(ペアプロ、朝会とかで)
  • 運動不足になりがちですが、昼休みの時間を有効に使い懸垂やランニングなどしてます
  • 何より家族で朝昼ご飯を食べられて、子供との時間をたくさん取れるのが幸せです

@eitobal

(Misocaでの)リモート歴 基本勤務時間
約6年 9:00 - 18:00

仕事環境のこだわり

  • ErgoDox EZ を使っています。
  • Arctis 5 というヘッドセットを使っています。マイクが収納できるので便利です。
  • あまり、こだわりはないです…

リモートワークに思うところ

  • 週1・2日は名古屋のオフィスに行っています。どこでも働くことができるので助かっています。
  • もう少し雑談が簡単にできるようにしたいなぁと思っています。
  • 気づくと朝から1回も家の外に出ていないことがあるので、運動をするようにしています。週2回ぐらいジムで筋トレして、他の日は走っています。最近は月200km程度走るようになりました。

f:id:mugi1:20160811121142j:plain:w30 @mugi_uno

リモート歴 基本勤務時間
2年半 9:00-18:00

f:id:ba068082:20191021100811j:plain

仕事環境のこだわり

  • ピカチュウがいる
  • Blue Yeti
  • 配線を楽していい感じに隠している。オススメ (参考)

リモートワークに思うところ

  • 10年前は、将来自分がこんな働き方してるとは微塵も思ってなかったので、人生何があるかわかりませんね〜
  • 基本的にはリモートより同じ空間で仕事したい派。けど、家庭事情とかのバランスを見てこういう選択肢を取れるのはいい時代になったと思う
  • 運動不足が深刻化していたけど、最近ボルダリングに行って3年分ぐらいは運動したのでもう大丈夫!!

@hidakatsuya

リモート歴 基本勤務時間
4年 9:30-18:30

f:id:ba068082:20191021100845j:plain

仕事環境のこだわり

  • 最近31.5インチの4K ディスプレイにして快適
  • Alexa が地味に便利
  • マウス、キーボードが合っていないので検討中

リモートワークに思うところ

  • メンバーと同じ空間で働くのも好きなので、環境・体調等に合わせて選択できるということが最大のメリット
  • ただ、リモートワークに飼い慣らされてしまって年々腰が重くなっている

f:id:mugi1:20190925142042j:plain:w30 @RKTM

リモート歴 基本勤務時間
3年ぐらい 10:00-19:00

仕事環境のこだわり

  • メモリを32GBにしたのでAndroidビルドやRailsのテストを走らせるのが快適になった。
  • ディスプレイアームを使うことによって机を広く使えるようになった。おすすめ。(その空間には紙が積み上がっているけど)
  • 子どもが下の階でワーワー騒いだりするので、密閉型のヘッドセットを重宝している。

リモートワークに思うところ

リモートのメリット

  • オフィスまで片道1時間弱かかるので、その時間を他のことに使えるだけで嬉しい。家族との時間も増える。
  • 暑い・寒いでオフィス出社するかを判断したり。

非リモートの強み

  • 一緒の空間にいることで捗ることも多い(例:ホワイトボードを使ったディスカッションや、トラブルシュートなど)
  • 複雑な議題の打ち合わせをする時には、遠方の人も出張でオフィスに来てもらうこともある。
  • 使い分けできると良い。

リモートでうまくやるコツ

  • 一人でタスクを抱え込みすぎると詰まるので、積極的に「わからん!」と声を上げていくのが良い。
  • 進捗の報告なども多少過剰なぐらいでちょうど良い。SlackやGithubなどで動きがない人にはたまに声かけて詰まってないか聞いてる。

健康管理

  • 一歩も家を出ないことがあるので、夜にジョギングしたりしています。雨の日はアンクルウェイトをつけて仕事したり。最近はドラクエウォークを散歩の楽しみにしています。

f:id:mugi1:20190925141630p:plain:w30 @mizukmb

リモート歴 基本勤務時間
1年半くらい 10:00 ~ 19:00

仕事環境のこだわり

リモートワークに思うところ

私は名古屋に住んでいるので、自宅でリモート・名古屋オフィスに出社を選択できるのですが、結構気分で選んでいます。双方メリット・デメリットあるので、今日の調子を見て最大パフォーマンスを出せる環境で仕事するという働き方がもっと広まるといいなあと思っています。

終わりに & 次回予告

いかがでしたでしょうか?
最近、働き方改革で在宅勤務も増えてきてはいますが、まだ少数派ですよね。
リモートが何よりベストとは思いませんが、幸せな働き方の一つの解ではあると思います。リモートワークの知見が共有され、もっと社会にこの働き方が広がればよいなと思っています。

最後に、今個人のTwitterでリモートワーカーへの質問を募集中です。
もし、今回の記事への質問、リモートワークへの疑問などありましたら気軽にリプライ、コメントお願いします!
頂いたコメントを元に、来月あたりにリモートワークのQ&Aみたいなタイトルでまとめられたらと思ってます。乞うご期待!!

採用情報

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

Misocaメンバーに影響を受けた一冊を聞いてみた

こんにちは。@mugi_unoです。

最近デスクにピカチュウが鎮座してます。かわいい。

f:id:mugi1:20190925135039j:plain:w400

影響を受けた一冊

先日社内で「自分が今までで影響を受けた一冊って何かある?」というお題で話をしたところ、なかなかに盛り上がりました。

今回はその話を元ネタとして、Misocaのメンバーに聞いた「影響を受けた一冊」をご紹介します。

「プログラムはこうして作られる」@KawamataRyo

プログラムはこうして作られるプログラマの頭の中をのぞいてみよう

プログラムはこうして作られるプログラマの頭の中をのぞいてみよう

💬本人コメント

f:id:mugi1:20190925141503p:plain:w60
エンジニアに転職するきっかけになった本です。著者が作ったオリジナル言語でテトリスを作るのですが、他の入門書とは大きく違い、「プログラマならどう考えるか」が重点的に書かれています。エラーが出た際の考え方から、新機能の追加の際の思考の流れまで。他のプログラミング入門書では味わえないソフトウェアを作る本当の面白さがわかる本だと思います。今、エンジニアを目指して勉強中の方に特におすすめです。

「魁!!クロマティ高校」@mizukmb

魁!!クロマティ高校(1) (週刊少年マガジンコミックス)

魁!!クロマティ高校(1) (週刊少年マガジンコミックス)

💬本人コメント

f:id:mugi1:20190925141630p:plain:w60
単行本4巻の第83話の腹話術の回で初心者だからこそ良い道具を使い腹話術の真髄を極めるべきと神山が不良を説得するシーンがあり、それ以来私もプログラマーとして良い道具を使って仕事をしようと決心しました

「レガシーコード改善ガイド」@mallowlabs

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (157件) を見る

💬本人コメント

f:id:mugi1:20190925141653p:plain:w60
当時レガシーコードと戦っていたので、「レガシーコードと戦っているのは自分だけじゃない」と勇気をもらった一冊です。「テストがないコードはすべてレガシーコード」という思い切った定義から始まり、安心してリファクタリングできるように様々な方法を教えてくれる本です。ちなみに Misoca のコードはガッツリテストが書かれているのでレガシーコードではないですよ!

「エリック・エヴァンスのドメイン駆動設計」@RKTM

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

💬本人コメント

f:id:mugi1:20190925142042j:plain:w60
・開発者に閉じるのではなく、エンドユーザーと開発者が同じ用語を使って会話し、モデリングし、コードに落とし込み、保守していく思想が素晴らしい。
・個人的に、現実の業務がうまくコードに落とし込まれないことで、コードも理解しづらく、業務の変更に追随できずに苦しんできた理由がわかった。
・より良いサービスをサステナブルに開発していくために非常に役に立つ本。おすすめです!

「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」@yueno

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)
  • 購入: 68人 クリック: 1,802回
  • この商品を含むブログ (140件) を見る

💬本人コメント

f:id:mugi1:20190925142108j:plain:w60
ずっと前に勤めてた会社からもらった本。これ読むまではコードは短い方がよいと思ってた(変数名とか英字1文字とかにしてた)けど、そうじゃないんだよー、ということを教えてもらった気がする。もう随分前すぎてあんまり覚えてないけど。

「コンパイラ―原理・技法・ツール (Information & Computing)」@ryota

コンパイラ―原理・技法・ツール (Information & Computing)

コンパイラ―原理・技法・ツール (Information & Computing)

  • 作者: A.V.エイホ,R.セシィ,J.D.ウルマン,M.S.ラム,Alfred V. Aho,Jeffery D. Ullman,Ravi Sethi,Monica S. Lam,原田賢一
  • 出版社/メーカー: サイエンス社
  • 発売日: 2009/06/01
  • メディア: 単行本
  • 購入: 1人 クリック: 128回
  • この商品を含むブログ (30件) を見る

💬本人コメント

f:id:mugi1:20190925142140j:plain:w60
学生時代にこの本(1st edition)を読んで、実装と理論を結びつけながら理解を深めていった記憶があります。読みづらい部分があるし、内容的に少し古い感じもあるので今はあまり人にお薦めしていませんが、内容のある良い本だと思ってます。

「数学文章作法 基礎編」@kokuyouwind

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 基礎編 (ちくま学芸文庫)

💬本人コメント

f:id:kokuyouwind:20190930142248p:plain:w60
数学文章に限らず、わかりやすい文章を書く上での基本的な考え方がまとまっている本です。ドキュメントやソースコードを書く際に「読み手」のことを強く意識するきっかけになりました。

「悲劇的なデザイン」@torimizuno

悲劇的なデザイン ―あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?

悲劇的なデザイン ―あなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?

  • 作者: ジョナサン・シャリアート,シンシア・サヴァール・ソシエ,高崎拓哉
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2017/12/27
  • メディア: 単行本
  • この商品を含むブログ (2件) を見る

💬本人コメント

f:id:mugi1:20190925142209j:plain:w60
デザインは誰かを幸せにも不幸にでもできることを、事例を持って教えてくれる本です。誰かを傷つけない、悲しませないデザインにするには何ができるか?についても紹介されていて、読むと身が引き締まります。

「ユーザ中心ウェブサイト戦略 - 仮説検証アプローチによるユーザビリティサイエンスの実践」@kanizmb

ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践

ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践

  • 作者: 株式会社ビービット武井由紀子,遠藤直紀
  • 出版社/メーカー: ソフトバンククリエイティブ
  • 発売日: 2006/09/27
  • メディア: 単行本
  • 購入: 14人 クリック: 313回
  • この商品を含むブログ (47件) を見る

💬本人コメント

f:id:mugi1:20190925180900p:plain:w60
2006年の著。ユーザーの実際の行動を観察することでニーズを読み解き、行動に寄り添ったタイミングでアプローチする手法が具体例を伴って紹介されています。読んだ当時ユーザー中心設計は今のように一般的でなかったため、目からウロコが落ちたのを思い出します。

「ノンデザイナーズ・デザインブック」@mugi_uno

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

💬本人コメント

f:id:mugi1:20160811121142j:plain:w60
何かのデザインをするときに必ず内容を思い出しています。読むだけでいきなりイケてるオシャレなデザインに開眼できるわけではないですが、「これはひどい...」という新人類向けデザインの爆誕を防げます。日常のフロントエンドコーディングはもちろん、発表スライドや説明資料作りでも役に立っているな〜と実感しています。

まとめ

デザインからコンパイラまで多種多様でおもしろいですね。

もし興味が湧いたら読んでみてはいかがでしょうか? 私はクロマティ高校が読みたくなりました。

余談ですが、私は最初ジョジョの奇妙な冒険5部が思い浮かんだものの「でもマンガだしな..」とやめたのですが、蓋を開けてみたら2人目でいきなりクロマティ高校で、自分を強く持つのって大事だなって思いました。

採用

Misocaでは本からも学びたいエンジニアを募集しています

recruit.misoca.jp

MisocaでLT大会を開催します !!

こんにちは。@kawamata です。
先日、近所のショッピングモールの握力測定大会に出てみたら、前職(消防士)時代より握力が上がっていて驚きでした。 やっぱりエンジニアは握力が鍛えられるのですね。*1

f:id:ba068082:20190918113348p:plain

皆さん、もくテク はご存知ですか?
もくテク は弥生株式会社が1年以上主催している勉強会です。
来る10月10日19:00よりMisoca主催の「もくテク powerd by Misoca 秋のLT大会」を開催します!!
今回は、LT予定のMisocaエンジニアから内容についてメッセージが届いているので紹介します。

mokuteku.connpass.com

最高の「いってきます体験」を支える技術

@mallowlabs
スマートスピーカー活用してますか?
私の家では「アレクサ、いってきます」と Amazon Echo に呼びかけると、家中のライトが消え、サーキュレーターとエアコンがオフになり、ルンバが掃除を開始し、雨が降りそうなら Slack に通知がきます。
今回はこの仕組みの裏側(Alexa / IRKit / Node-RED / IFTTT / Google Apps Script 等) についてお話します。

VSCode x マルチカーソル x ライブコーディング

@mugi_uno
VSCodeとマルチカーソルを組み合わせた編集テクニックを実際にライブ形式でお見せします。
これを見ればVSCodeでの編集速度が5倍(当社比)速くなるかもしれない。

Misocaのパフォーマンス計測とSLOを設定した話

@mizukmb
SREチームではMisocaのリクエスト成功数やレスポンスタイムといったアプリケーションのパフォーマンスに関わる計測とSLO (サービスレベル目標) の設定をしました。
これまでの経緯や方法、設定後のチーム内での変化について発表します。

ここまで出来るよFirestoreセキュリティルール

@KawamataRyo
Firebase Firestoreのセキュリティルールはドキュメントへの認可を設定するだけでなく、スキーマの検証から、バリデーションまで出来ます。
セキュリティルールのローカルテストを交えながら、色々なセキュリティルールの設定について紹介します。


いかがでしたしょうか? アレクサからSLOまでかなりバラエティに飛んだ内容になっています。
イベントの詳細な情報はconnpassの募集ページ をご確認ください。 外部LT枠も募集中です!!
会場は東京、名古屋、Youtube LIVEを予定しています。
では、10月10日東京会場で僕と握手 !!!🤝

採用

Misocaでは情報発信が好きなエンジニアを募集しています。

recruit.misoca.jp

*1:日本一の握力の持ち主はエンジニアらしいです。 https://orcarl.com/gyotaku2/

Misocaのサービスレベル目標 (SLO) を設定するまでの道のり

Misoca開発メンバー/SREチームの id:mizukmb です。今年も最高気温40度超えの名古屋の夏を乗り切る事ができて安心しています。

今回はSREチームとしてMisocaのパフォーマンス計測を行い、開発向けのサービスレベル目標 (以下、SLO) を設定した話をしようと思います。

実際に計測をはじめる前に

すべてを計測できることは理想ではありますが、闇雲に計測するだけではどこを改善するべきか見えにくくなってしまいます。

そこで、実際に計測をはじめる前にSREとしてどこに着目するべきなのかをSREチーム内で認識合わせをするためにSRE本読書会を実施しました。

SRE本読書会の実施

SRE本とは SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム の事です。 Google - Site Reliability Engineering で無料で読むこともできます。

全ての章を読む時間は流石になかったので、SLOの設定に必要と思われた1~9章を範囲としました。

また、読書会は 『入門 監視』社内読書会を開催しました - Misoca開発者ブログ と同じ方法で進めました。Scrapboxと読書会の相性は非常に良いです(個人的感想)。

f:id:mizukmb:20190904172719p:plain
SRE本読書会Scrapboxの様子

計測箇所・可視化方法

ある程度読書会が進めたところで、並行してSREチームとして計測する箇所はどこであるか、どのように計測し可視化すればよいかを検討しました。

応答性能・安定性・運用といった様々な観点から、計測可能な数値を洗い出していきました。さらに、そこから今回のSLOに関わるものに絞って可視化を進めることにしました。以下の項目を可視化することに決定しました。

  • レスポンスタイム
    • 50, 90, 95 パーセンタイルでそれぞれ計測する
  • リクエスト成功率
    • リクエスト数もついでに可視化した

その他の項目についても可視化しようというところまでは決定していますが、ここでは一旦優先順位を下げています (例えばコードカバレッジや一日あたりのリリース数等) 。

可視化のためのツールはRedashを使用しています。Redash 自体の詳細な使い方はここでは説明しませんが、ALBのアクセスログをS3に保存してAthenaでクエリ実行したものをRedashでグラフに出すみたいなことをしています。

ちなみに、Redashサーバは自前で建てていて、これは今年の開発合宿の成果物だったりします。

tech.misoca.jp

開発向けSLOの設定

レスポンスタイム・リクエスト成功率について開発向けのSLOを設定しました。開発向けであるので公表はできませんが、既に達成していたりしてなかったりな感じです。

SLOの設定値については厳しすぎない程度に設定しました。SRE本4章で言及されていますが、SLOが厳しすぎるとチームが超人的な努力に走ってしまうリスクを抑えるためです。

さて、無事にSLOを設定することができました。今後はこのSLOと実際の値を見比べながら、SLO達成のためにパフォーマンス改善を優先するのか、あるいはもっと他の問題をエンジニアリングで解決するのかを決めていくことになります。

最後に、SLO設定後のSREチームにおける変化についてお話します。

SLO設定後の変化

SREチームが取り組む問題の優先順位をSLOベースで決めることができるようになりました。また、SLO改善系のプロジェクトにおいては改善前後の効果予測ができるようになり、プロジェクトが目指すべきゴールの解像度が上がりました。

さらに、プロジェクト終了後に他メンバーへの共有の際、「今回のプロジェクトではこの部分の改善に対してXX%の向上が見られた」といった数値ベースの報告ができるようになり、客観的に見てもどのくらい効果があったのかよりわかりやすく見えるようになったかなと思います。

まとめ

SREチームとしてMisocaのパフォーマンス計測を行い、開発向けのSLOを設定しました。結果として、SLOを軸としてタスクの優先順位を決めたり、どのくらい改善できたのかを数値ベースで共有するといったことができるようになりました。SREチームの働きも、他メンバーにより伝わりやすくなったかなと思います。

採用

SREチームは現在 私 id:mizukmbid:kokuyouwind の二人体制でプロジェクトを進めています 1 。やりたいことや課題は山積みなので、一緒に高速で信頼性の高いMisocaの基盤を整備していく人を募集しています。

recruit.misoca.jp


  1. 入れ替えや追加など、社内で担当メンバーが変動することはあります

FeatureFlagを使ってサクッとリリースする

Misoca開発チームの黒曜(@kokuyouwind)です。

技術書典7の準備があんまり進んでなくてワタワタしています。

📅 木テク

少し前の話になってしまいますが、8月8日に開催されたもくテクpowered by Misoca #2でFeature Flagを使ったリリースの話をしてきました。

以下がそのときの発表スライドです。

今回はこの発表内容をブログでおさらいしたいと思います。

🚩 FeatureFlag

Feature Flagは、機能の有効・無効をコード上で切り替えるテクニックです。(Feature ToggleやFeature Switchなどと呼ばれることもあります。)

ざっくり言うならば、以下のようにフラグに応じて機能を有効にするのがFeature Flagです。

if feature_enabled?
  process_with_feature()
else
  process_without_feature()
end

概念自体は非常に単純ですが、この仕組みを使うことで開発者による事前動作確認やデプロイなしでの機能リリース、A/Bテストなど様々に応用することができます。

応用の分類などは Pete Hodgson氏のFeature Toggles (aka Feature Flags)という記事がわかりやすいので、そちらをご覧ください。*1

🤔 フラグ管理の見直し

FeatureFlagを運用する上では「どの機能について」「誰に対して有効にするか」をうまく管理することが重要です。

Misocaではもともと「開発者のみ有効になるフラグ」を1つ用意して、このフラグを見て分岐処理することで事前確認を行っていました。

しかし、この方法では以下のような問題がありました。

  • 複数の機能で同じフラグを見るため、いずれかの機能だけを有効にした動作確認ができない
  • ユーザリリース時には分岐処理を消したデプロイが必要になり、規模によってはこのデプロイ自体が大きくなる

このため、機能ごとにフラグを簡単に追加でき、個別ユーザ単位だけではなく「全ユーザに対して一括で有効にできる」ようなフラグ管理のシステムを導入しました。

ライブラリはいくつかの事情で自作したものを使っていますが、概ねrollout gemと同じインターフェイスになっています。また、バックエンドにはRedisを使っています。

🔧 管理画面

以下のような開発用の管理画面から「現在のユーザについて機能の有効・無効を切り替え」「その機能が一般ユーザに公開されているかの確認」を行うことができるようにしています。

以下の例では「DocumentCacheのS3化」という機能が全ユーザ(100%)に対して公開されている状態です。

f:id:kokuyouwind:20190829165255p:plain

👍 メリット

上述の通り機能ごとの有効・無効を簡単に切り替えられるようになったため、新しい機能の動作確認だけではなく、複数の機能の兼ね合いなども確認しやすくなりました。

またデプロイをせずに一般ユーザへ公開できるというのが非常に便利でした。特にリリース時刻が決まっている場合CIトラブル・デプロイトラブルなどが非常に怖いのですが、Feature Flagを使うことでそういった問題を避けて確実にリリースすることができます。

さらに、データベース周りなど「パフォーマンスに影響を与えそうな変更」についても一部ユーザのみに絞ってリリースすることで、効果を検証し問題があっても素早く巻き戻せるようになりました。

📢 宣伝

MisocaではFeature Flagを使ってサクッとリリースしたいエンジニアを募集しています。

www.wantedly.com

*1:@TsuyoshiUshio 氏による和訳記事もあります. Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita

✨開発合宿の成果物を磨いて新機能にする

こんにちは、@mugi_uno です。

暑くて溶けそうです。

新機能をだしました

新機能を出したら開発ブログで何か書く、というのが自分のルーティンになりつつありますが、 先日、表計算ソフトからのコピー&ペースト機能を追加しました。

www.misoca.jp

Excelなどからコピーして、Misocaでペタッと貼り付けると一気に明細が作れるというもので、 先日開発ブログに書いた電卓機能*1と同じく、こちらも4月に実施された開発合宿の成果物がベースになっています。

とはいえ合宿の成果物でいきなりゴールしたわけではなく、リリースまでにかなりのブラッシュアップを行いました。

というわけで今回は、開発合宿の限られた時間で一人で作った機能が、新機能として正式に提供されるためにどのように磨かれていったかをご紹介したいと思います。

合宿終了時点での成果物

まず、合宿が終わった時点での状態がこちらです。 特に誰とも相談せず、思いつくままガッと実装した形です。

f:id:mugi1:20190808171413g:plain
合宿終了時点の動作イメージ

  • 行列の移動がCSSアニメーションでヌルヌル動く(合宿の成果発表時のインパクトのために作ったのは否めない)
  • タブ区切り、カンマ区切りの両方に対応できる
  • 実は全項目編集できる

などが特徴です。

UI/UXを練る

これをベースに、まずは「使いやすいUI/UXはどんなものだろう?」というのを、デザイナーの@kanizmbを中心に一緒に練ります。すると、色々と現状のままではイケてない部分が見えてきました。

列移動がパズル状態になる

貼り付けたデータの列をどの項目に挿入するかを選択するのに、ボタンをクリックでの列と列を入れ替えることで実現していました。 見た目はヌルヌル動いてオシャレですが、実際やってみると動かしたい列の隣の列も動いてしまうので、まったく直感的ではなく、かなり混乱します。

f:id:mugi1:20190808174654g:plain
列移動のややこしさに悶絶する図

まるでスライドパズルを解いているような気分に陥ります。

IQ脳トレ知育玩具 スライドパズルすうじ 15パズル

何かほかの方法で列と明細項目の紐付けが必要だな〜という話になりました。

横スクロールがつらい

表計算ソフトで作られた文書の場合、レイアウト調整などの理由から、必要のない列がデータ間に多く含まれる可能性が考えられます。(いわゆる 'Excel方眼紙' などの場合は特に顕著でしょう。)

そういったデータから貼り付けたい場合、大きく横スクロールが発生する可能性があります。

f:id:mugi1:20190808173139p:plain
横スクロールが発生して困る図

トラックパッドなどが利用できればよいですが、そうではない場合なかなかの使いづらさです。

UI/UXを見直した後のイメージ

ほかにも様々な観点からUIを見直し、次のような修正をすることで方針を固めました。

  • "列に対してプルダウンから項目を割り当てる"という形に変更する
    • 「このデータは数量だな〜」→「項目は数量を選ぼう」という操作ができた方が直感的
  • 行の移動はドラッグアンドドロップでの移動に変更する
    • 文書の明細行並べ替えUIと揃えて、操作感を統一する
  • ひと目で可能な操作がわかるようにする
    • 削除ボタンはマウスホバーせずとも常に表示して、行・列の削除できることがわかるように
    • 既存の画面で可能な操作(並び替えや削除)とUIを揃える
    • 並び替えや削除の範囲が明確になるようにレイアウトを調整する
  • 多すぎる列のデータはグレーアウトして削除だけ可能にする
    • まず不要な列を削除する、という操作をすることで横スクロールを回避する
  • Misocaのアプリケーション全体と見た目を揃える

これらを含め、修正前に一度イメージを共有し、関係者で認識のズレがないことを確認します。

f:id:mugi1:20190808175922p:plain
初期段階で見直したイメージ図

さらに使い勝手などの面から次の対応も入れることにしました。

  • データが多すぎると構築するDOMの量が多すぎてブラウザがクラッシュする恐れがある
    • 一定の列・行数で打ち切るようにする
  • 空行・空列は邪魔になる
    • 空行・空列はすべて削除する

PRレビューでの指摘の数々

見直したイメージに沿う形への修正が完了したら、PullRequestを作成し、まずは開発者でレビューしてもらいます。

コード自体に関するレビューはもちろんのこと、Misocaのレビューでは「そもそも仕様として○○は✕✕のほうがいいんじゃない?」というコメントも頻繁に見かけます。その中でも様々な意見をもらいました。

カンマ区切りいらないのでは?

最初は、表計算ソフトからの貼り付けに加えて、CSVファイル(カンマ区切り)も使えました。 合宿時点では「使えるファイルの種類多くて色々できたほうが便利でしょ!」という軽い考えでしたが、レビューの中で次の意見をもらいました。

f:id:mugi1:20190809102534p:plain

できることが増えることは一見良いことに感じますが、選択肢があれば操作時に思考や迷いを生みます。 あらためてカンマ区切りの是非について検討しました。

  • なんとなく対応してたけど、CSVファイル貼り付けるシチュエーションはかなり稀
  • 暗黙的な挙動が増え、ユーザに戸惑いを与える恐れがある
  • サポートしていることで実装が複雑化し、メンテナンスコストも増える

議論した結果、「最初のリリース時点ではカンマ区切りはサポートしない」とすることにしました。

空列・空行を勝手に削ってほしいとは限らない

「データの中の空列・空行を貼り付けた後にいちいち消すのは手間だから、こっちで除去しておこう!」 と空データをフィルタリングしていましたが、これに対して貰った指摘が次のものです。

f:id:mugi1:20190809105150p:plain

例えば普段は次のような請求書を利用していたとします。

f:id:mugi1:20190809105645p:plain:w400

貼り付ける際には「品目→単価→数量」の順番で左からセットされるのを期待し、実際にもそのように動きます。 しかし、「まったく同じレイアウトで単価は入っていない」といったデータを考えてみます。

f:id:mugi1:20190809110320p:plain:w400

単価に該当する列には何もデータがありません。 この場合、空データのフィルタリングによって「空列」と判断されて削除されてしまいます。 同じファイルから同じ範囲をコピー&ペーストしたにも関わらず、画面上で見えるデータが別のものになってしまうと、 「あれっ?なんで違う項目になるの??」と戸惑うことが予想されます。

便利だと思って入れた空データの除去フィルターでしたが、実際のユースケースを考えると混乱を招く要因になり得ることがわかりました。

除去するのは末尾の空行・空列のみとする」という方針に見直しました。 不用意に除去するより、常にある程度同じ挙動をするほうが使いやすく戸惑いが少ないという判断です。

さまざまな視点からの意見をもらう

開発者やデザイナーだけではなく、マーケティングやコールセンターの方などにも触ってもらいました。違った視点での意見がとても貴重です。

モーダルが狭い

f:id:mugi1:20190809131037p:plain

貼り付ける際に開くモーダルが小さくて使いづらいという意見です。 こちらも取り入れ、デフォルトのサイズを少しだけ大きくし、かつ拡大・縮小を可能にすることにしました。

f:id:mugi1:20190809132418g:plain
拡大・縮小を可能にした状態

数値しか入ってないとはかぎらない

確認してもらっている中で、とある意図しない挙動が発覚しました。

f:id:mugi1:20190809135135p:plain

表計算ソフトで作られた文書の場合、こちらが数値を期待している項目だとしても、本当に数値が入っているかはわかりません。

単純に単価が「10000」だとしても、一般的には次のようなバリエーションが想定されます。

  • 10000 (数値のみ)
  • 10,000 (桁区切りを含む)
  • ¥10000 (金額を示す文字付き)
  • 10000円 (金額を示す文字付き)
  • 10000(全角)
  • 10,000(全角で桁区切りを含む)

このあたりについて一部考慮が漏れていたため、うまく反映されないという動きになっていたのです。

これは、1件ずつ画面で入力する際であれば、リアルタイムで注意喚起や自動的な変換を行ってくれる仕様になっています。

f:id:mugi1:20190809134302g:plain

今回の機能の場合には一括で大量のデータが挿入されることもあり、サービス側でいい感じに変換しないとかなりの手間になることが予想されました。

最終的には、サービス側で数値変換を自動的に行うように対処しました。

f:id:mugi1:20190809135406g:plain
数値の変換を行うようになった状態

Before→After

上記以外にも細かな修正をリソースの許す限り行いました。

開始時点(合宿での成果物)と完成品(リリースされたもの)を改めて比較してみましょう。

Before

f:id:mugi1:20190808171413g:plain
合宿での成果物

After

f:id:mugi1:20190809140118g:plain
最終的にリリースされたもの

こうやって比べてみると、かなり変わっていますね。

最初の状態はパッと見ではスタイリッシュですが、使いづらいところをたくさん抱えていました。 実際のユースケースを想定し、様々な視点からの意見を参考に使いやすさを追い求めていった結果、大きくUIが変化したのは興味深いな〜と思いました。

Misocaにアカウントをお持ちの方は、ぜひ請求書の作成画面で試してみてください。

採用

Misocaでは、より良いものを作っていきたいエンジニアを募集しています

www.wantedly.com

初めてのデザイナーインターン受け入れ

夏ですね。デザイナーのとりみずのです。

北海道の道東を旅行で訪ねてから、毎日北海道のことを考え、最推しが北海道になりつつあるこの頃です。

Misoca社として、7月にはじめてデザイナーインターンの受け入れを実施したので、今回はその取り組みについて紹介します。

インターンプログラムを考える

会社としても、インターンに来られる方も、得るものがある3日間にしたかったので、それが実現できるプログラムを検討しました。

他社のインターン事例を調査したり社内で相談を重ね、最終的には、下記のプログラムで受け入れを実施しました。

  • 期間:3日間
  • 場所:名古屋本社
  • 担当:デザイナーのメンターが1名サポート
  • 内容:サービスを触り、業務上実際にある課題の改善にひとつ取り組む

▼参考にさせてもらった他社のデザイナーインターン事例

https://jobs.freee.co.jp/recruitblog/aboutus/freee_internship_ux/ https://internship.cookpad.com/2019/summer/#tenday-sixday https://cybozu.co.jp/company/job/recruitment/intern/summer2019/

インターン実施

いよいよインターン受け入れの開始です。

初日にインターンの方が来たときに、3日間という限られた時間の使い方の意識をしてもらいたかったので、まず最初にインターンプログラムのスケジュールを共有しました。

ざっとこんな感じです。

## 1日目

午前:オリエンテーション

-会社の紹介
   - 過去事前に実施されていればスキップ
- PCセットアップ
- デザイナーの業務内容の共有
- Misocaのサービスの概要について説明する
- インターンでの互いのゴールの意識合わせ
    - 本人が何を得たいかにより、実務内容やメンタリングを考慮する

午後:サービス開発実習

- Misocaを触ってみて気づきをあげる
- 課題1個選んでもらう。もしくは自分で見つけてもらって取り組む
- 成果発表のタイミングを相談し、カレンダーにいれる(デザインチーム+任意で人事やその他メンバー)

## 2日目

- デザイナー朝会に参加
 - リモートのデザイナーとの交流
 - 何時に検討案を共有できそうか相談
- レビュー依頼方法についての説明とポイントの共有
- 中間共有:レビューを体験してもらう

## 3日目

- レビュー反映
- 発表内容をまとめ
- 発表内容まとめの確認
- 成果発表
- 過去のデザインの紹介と意図を共有
- インターンの振り返り
 - KPT
 - 最初にたてたゴールのふりかえり
- 感想をもらう

オリエンテーション

1日目に実践してみて特によかったことが、2つあります。

①インターンでの互いのゴールの意識合わせ

インターン受け入れで何を期待しているか話した結果、「デザインの意図や意思の言語化のスキルアップしたい」という言葉を引き出すことができました。 さらにそこから、3日後にどうなっていれば成功と言えるのか?を続けて話し合いました。

「学校でエンジニアと一緒に何かを作る時に、伝えたものと成果物にギャップがある時がある」というエピソードを聞けたので、このインターンを終えた後はそれが解消されるよう「次に学校のチーム何かをつくるとき、認識齟齬がなくなることで、つくるスピードやクオリティがあがる」をゴールイメージとしました。

f:id:torimizuno:20190807094512p:plain

ゴールの意識合わせをしたことにより、メンターとして、「何を意識して伝えるべきか」「何にトライしてもらうか」が明確になり、私自身、3日間でやるべきことがクリアになりました。

▼参考:こばかなさんのコーチングツイート

https://twitter.com/kobaka7/status/1130266794755624961

(ゴールを明確化するのにとても役立ちました!ありがとうございます)

②サービスを触ってもらい気づきをあげる

こちらに関しては、2つの狙いで実践してもらいました。

ひとつめはドメイン理解度をあげてもらうこと。ふたつめは、プロダクトに愛着を持って考えてもらうことです。

3日間という短い期間ですが、少しでもサービスやユーザーのことを知ってもらってデザインするとしないでは大違いのプロセスになっていたと思います。

サービスに触れてもらう中で、質問が何度も出たり、気づきもまとめてもらえたので、ドメイン理解とプロダクト愛につながっているように感じました。

サービス開発実習

オリエンが終わった後はいよいよサービス開発実習です。

サービスを触って得た気づきの中から、もしくはデザイナー陣があらかじめピックアップしていた課題の中から、取り組む課題をひとつ決め、UI改善の検討を進めてもらいました。

Misocaでは、なんのためにやるのか?を明確にするために、「インセプションデッキを書く」というレームワークを採用しています。

UI改善の第一歩として、インセプションデッキを書くことにもトライしてもらいました。

レビュー

改善案がある程度固まってきたら、次はデザインレビューの体験です。

レビューは、視野を広げたり、他者を巻き込んでプロトタイプの精度を高めたり、意思決定判断材料のための手段のひとつとして活用できるものなので、インターンの方には今度どんどんレビューにチャレンジしていってもらいたい気持ちを込めて、自分が意識しているポイントを共有しました。

共有したレビューのポイント

  • レビューは対人でなく対アイデアに対してされる
  • レビューを依頼する時は、相手がその情報だけで理解できる言葉を意識して書く
  • 目的や前提も、見てもらいたいアイデアと合わせて伝える
  • 相手のレビュー意見全てを受け入れるのではなく、あくまでいち意見として自分の中で噛み砕いて捉える

レビューを経験する前はかなり緊張していたようでしたが、実際に一度デザインチームでデザインレビューを経験してからは、「自分では気づかなかったものもあって参考になったので、レビューしてもらってよかった!」とレビューへの苦手意識が緩和されているように感じたので、インターン受け入れで実施できてよかったです。

成果発表

レビュー後はレビューを踏まえてUI改善のプロトタイプのブラッシュアップを進めてもらい、最終日の午後に、成果発表を実施しました。

ここでもレビューと同様、何に取り組んでいるか前提を知らないメンバーに対しても理解できるように一連の流れからの実際に考えた検討案の成果発表を意識してもらい、4人のメンバーを前に発表してもらいました。

10分ほどの発表でしたが、横で見ていて、デザイン意図が言語化して伝えられているように感じたのと、メンバーからの質疑応答にも答えられていて、「この部分、すぐに取り入れてもいいね」という声も出たので、いい成果発表の時間になりました。

ふりかえり

サービス開発実習が終わってからは、インターン3日間の振り返りをKPTで、最初に立てたゴールについての振り返りを対面で、実施しました。

▼KPTでの振り返り

f:id:torimizuno:20190807100035p:plain

▼ゴールに対してのふりかえり f:id:torimizuno:20190809093247p:plain

ふりかえり時に、「学校で次にメンバーと何かを作る時、認識齟齬がなくなってつくるスピードやクオリティがあがりそうですか?」と尋ねたのですが、「はい!今回実際に経験したことを取り入れてやってみます!」との言葉をいただけたので、きっと身になったはず…!

まとめ

インターン終了後は、実施内容をまとめたり、受け入れを他のメンターでもできるようドキュメント化共有してしくみを整えたり、発信用にこうしてブログにまとめたりと、Misocaとしても今後会社新卒の方を受け入れられるような土台づくりの一歩の成果が得ることができたのではないかなぁと思っています。

ご協力いただいた社内のみなさん、インターンに来てくれたFさん、ありがとうございました。

私自身はじめてのインターン受け入れで緊張などもありましたが、最後にインターン楽しかったです!」という言葉頂けたのが、個人的にとても嬉しかったです。

採用

引き続きMisocaでは、一緒に働いてくれるデザイナーを募集しています!

www.wantedly.com