SlackワークフローとRubotyで最高のChatOps生活を

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

富山Ruby会議が近づいてきましたが、10/23 午前11時現在、まだスライドを1枚も作ってません。4連休に着手するつもりだったんですが、シャニマスとMTG Arenaに消えました。

あ、頭の中ではできあがってるから…… あとはスライドに書き出すだけだから……(震え声)

🤖 Slackワークフロービルダー

先日、Slackにワークフロービルダー機能が追加されましたね。

これはSlack上からメニュークリックや特定タイミングで起動するワークフローを作ることで、定型的な作業を自動化できるものになっています。

f:id:kokuyouwind:20191023110125p:plain

このような画面でワークフローを定義できます。

メッセージを送るだけでなく、フォームを表示したり、メッセージ内にワークフロー起動者の名前やフォームの入力を埋め込んだりなどができるようになっています。

ちなみに、弊社の@tharaは力を授けてくれるワークフローを作っていました。

f:id:kokuyouwind:20191023112640p:plain:w400

力を求めるとこうなります。

f:id:kokuyouwind:20191023112829p:plain:w400

ニュースサイトかな?

🤔困ったところ

標準の機能だけでも定形メッセージの送信やアンケートの収集など使い所はあるのですが、外部サービスと繋がらないのでChatOpsを実現するには少々力不足に感じます。

スラッシュコマンドが使えると面白そうだったんですが、残念ながらそのまま送信されてしまいました。

f:id:kokuyouwind:20191023125434p:plain:w400

これでremindが設定されてくれれば、ワークフローからリマインドの設定や削除をしたり、/trelloコマンドを使ってTrelloのカードを作ったりなどもできそうなんですけどね。

💎Rubotyと連携させる

そこでRubotyですよ!

弊社のSlackにはRubotyのチャットボットが住んでいます。このボットは通常のメッセージを見ているため、ワークフローからのメッセージ送信でコマンドを起動できます。

f:id:kokuyouwind:20191023125926p:plain:w300

こんな感じで、普通に反応してくれます。もちろんechoのようにメッセージ内容を参照するコマンドも問題なく機能します。

f:id:kokuyouwind:20191023174316p:plain:w300

つまりワークフローとRubotyを組み合わせれば、外部サービスとの連携なども自由にできるわけですね!*1

休暇申請

Misocaでは休暇予定が他の人にわかるよう、シフトカレンダーに予定を作成するルールがあります。

f:id:kokuyouwind:20191023175045p:plain:w400

こんな感じでGoogleカレンダーに入れるルールのため、カレンダーを見れば今日だれが休みなのかわかるようになっています。*2

ただ毎回手で予定を入れるのは面倒なので、チャットボットからカレンダー予定を作れるようにしています。

f:id:kokuyouwind:20191023175644p:plain:w400

これだけでも結構便利なのですが、フォーマットを間違えると反応してくれなくて悲しいなどの事故を起こしがちです。またコマンドでは休みの開始日-終了日を指定しますが、実際には1日単位で取得することが多いためちょっと冗長な指定になってしまいます。

そこでワークフローを使うと…

f:id:kokuyouwind:20191023175859p:plain:w300

このメニューから「有給取得(一日分)」を選ぶことでフォームが開きます。

f:id:kokuyouwind:20191023180532p:plain:w300

ここに必要事項を埋めてSubmitすることで、カレンダー予定を作ることができます。

日付のところは現状だとテキスト入力です。カレンダーコンポーネントが使えるようになってくれるともっと便利になりますね。

ちなみに、作成者のコメントはこちら。

f:id:kokuyouwind:20191023180955p:plain:w400

はい。

リリース作業のワークフロー化

もう少し実用的な例でいきましょう。

Misocaでは本番へのリリース作業を「リリースしたい」「リリース開始」という2つの発言でできるようにしています。*3*4

f:id:kokuyouwind:20191024131816p:plain:w400

f:id:kokuyouwind:20191024131841p:plain:w400

こんな感じでリリース作業を行っています。

これも十分に便利なのですが、「リリースしたい」と「リリース開始」を打ち間違える事故があったり、リリース内容の見出し部分を手で書くのが結構めんどくさかったりといった点が気になっていました。

そこで、以下のようなワークフローを定義しました。縦に長いので画像を3分割しています。

f:id:kokuyouwind:20191024181636p:plain:w400f:id:kokuyouwind:20191024181648p:plain:w400f:id:kokuyouwind:20191024181658p:plain:w400

実際に使ってみると、以下のようになります。

f:id:kokuyouwind:20191024182500p:plain:w400f:id:kokuyouwind:20191024182626p:plain:w400

リリース準備が整ったら、以下のフォームにリリース内容を記入します。

f:id:kokuyouwind:20191024182845p:plain:w300

このフォームを送信すると、リリース内容が共有されたうえでデプロイが始まります。

f:id:kokuyouwind:20191024182639p:plain:w400

手でRubotyを起動していた箇所がワークフローから起動されるようになり、しかもリリースカテゴリなどもフォームを埋めるだけになりました。

left blankの部分が邪魔、そもそも手でカテゴライズしてるのがあまりイケてない、などの課題はありますが、従前と比べてミスしやすい箇所がなくなったことでリリース作業がしやすくなっています。

💬 感想

Slackワークフローは現状だと少々機能不足ですが、チャットボットを使った作業フローはそのまま置き換えることができて大変便利でした。みなさんもチャットボットと連携させて、外部サービスを絡めた作業の自動化を試してみてはいかがでしょうか。

今後は機能を強化して、ワークフロー機能のなかで「Slackコマンドの発行」「入力に応じたワークフローの分岐」などが入ってくれると使い道が広がりそうですね。とても楽しみです。

📢 宣伝

MisocaではSlackワークフローを使ってChatOpsしたいエンジニアを募集しています。

www.wantedly.com

*1:もちろんHubotとかでも問題なく動くと思います

*2:休みの理由は特に入れなくて良いのですが、自分はたまにネタに走って入れています

*3:「リリースしたい」でリリース準備が開始されてCIやステージ環境でのビジュアルテストを行い、「リリース開始」で本番へのデプロイが行われます。実際にボットがやっていることは「特定ブランチから特定ブランチへのpush」のみで、GitHub WebHookによってJenkinsやCodeDeployが起動するようになっています。

*4:ブランチを更新した際にGitコミットや差分参照URLも出していますが、これらはモザイクをかけています

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