Waroom ロゴができるまで

Waroom ロゴができるまで

こんにちは Topotal CDO@sawa-zen です!2020年から Waroom の開発をはじめて四年が経ち、おかげさまで Waroom を使ってくれているお客様や知ってくれている方がだんだんと増えてきました。そこで皆さんにさらに Waroom について知ってもらおうということで、 CDO っぽい記事第一弾として Waroom のロゴができるまでについて語ろうと思います。

実は Waroom ロゴは僕が開発初期に勢いよく作ってしまったので社内メンバーも完成までの経緯をよく知りません。そのためこの記事は社内メンバーに向けての記事でもあります。

一般的なロゴの構成について

Waroom のロゴの説明に入る前に一般的に用いられるロゴの構成について説明します。 ロゴは「シンボルマーク」と「ロゴタイプ」の2つで構成されていることが多いです。

一般的なロゴの構成

なぜこの2つで構成されるかというと、シンボルマークを見れば会社を連想できるし、連想できない場合でもロゴタイプを読めば社名やプロダクト名がわかるといった合理的な構成になっています。ロゴタイプのみの場合もありますが、スマホの登場でアプリアイコンとしてのシンボルマークの用途が増えていきたことで、最近ではシンボルマークのある構成を多く見るようになりました。

Waroom ももちろんその構成に則っています。

なぜ「青」を使ったのか

「war room」や「インシデント」と聞いてまず連想するのは炎上している様子です。つまりは炎 🔥 です。そのため最初は赤色やオレンジ色などの暖色をイメージしていました。他にも緊急事態感を出すために黄色と黒の構成も考えていました。

ただ、インシデント対応をする場面はただでさえストレスのかかる場面にもかかわらず、使うサービスのロゴマークも黄色や赤でストレスをかけるのはいかがなものかと思い、暖色を使うのをやめました。

そこから「Resolved」を表す「緑」か、消化する「水」を連想させる「青」どちらかにしようと考えました。ただ、緑をロゴに使用してしまうと、そのプロダクトのプライマリーカラーとして使用することになります。緑は UI 上では「成功」や「決定」のような意味のあることが多いです。Waroom はインシデントのステータスを表現することを想定すると緑をプライマリーカラーとして使用するのは難しいと判断しました。

結果として青に落ち着こうとしていたところで、弊社代表の高村が「青が好きなのでプロダクトのロゴは青にしてほしい」と言われて完全着地しました。(本人覚えてるのかな)

具体的になぜあのカラーコード(#1765C1)になったかは当時のフィーリングで選んでいます。ただ、明度や彩度はWebサービスとして扱いやすそうなラインになるように選んだ覚えがあります。

シンボルマークになぜ消火栓を選んだのか?

正直シンボルマークはかなり悩みました。「war room」というプロダクト名なので「部屋っぽさ」や「チームで集って対応している感」を表現しようと四苦八苦しました。その痕跡を貼っておきます。

↑右下のやつは僕の中で仮決定したシンボルマーク

この時点ではまだ暖色にこだわっており、マークとしてもどれもしっくり来ることがなかったので考え直し始めました。

そこで、Waroom を使って対応している人たちの僕の中のイメージを絵に描いて眺めてみてみました。そのときの絵がこちら。

燃え広がっている炎に果敢に立ち向かう人々

コマンダーが指揮をとってレスポンダーが消火作業していてかっこいいですね。でも、ここに Waroom があるとしたらどこにあたるだろうか?と眺めていて気づきました。

このあたりじゃない?

あくまで対応者は人間であり、Waroom は消化活動になくてはならないインフラ的存在になっていてほしい。あのホースの先にあるとしたら消防車や消火栓なのでそのあたりをモチーフにしたいと考えました。ただ、消防車も消火栓も赤色ですが、消火栓はシルエットとしてシンプルでわかりやすく青にしてもさほど違和感が無いことに気づいたのでそっちの方向で詰めていきました。

最初はロボットの頭だったけどそれはボツに

だんだんできてきましたね。あと少し。

ロゴタイプは?

ロゴタイプは結構適当でした。出来上がったシンボルマークに対してマッチしそうなフォントを選んだ結果 Solway というフォントになりました。この時点ではバランスを整えるために文字詰めだけは行っています。

シンボルとフォントをそのままのロゴタイプを合わせた様子

最後の味付け

やや野暮ったい感じがあったので細かいラインを直しつつ、もう少しギーク感を出したく監視ツールなどでよく見る六角形を盛り込んで今のロゴが完成です!全体的に統一感が生まれましたね。

完成!

Topotal のロゴとテイストが違い会社全体で統一感が無いのはやや課題ですが、ロゴの商標登録もしているし、個人的には気に入っているのでしばらくは大きく変えることは無いと思います。以上が Waroom のロゴができるまでの流れでした!ありがとうございました!

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom(ワルーム) を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be

Waroom Meetup #1 を開催しました

はじめに

こんにちは! Topotalのkenta_hi です。

このブログは、6月4日に行った Waroom Meetup #1の開催レポートについて書きます。 想定している読み手は次のとおりです。

  1. Waroom Meetup #1に参加した方に向けて、Topotalがどんな思いで開催したのか知りたい人
  2. Waroom Meetup #1に参加できなかった方に向けて、どんなイベントの雰囲気だったか知りたい人

それでは、始めます!

Waroom Meetup#1を開催しようと思った背景

Webサービスの広がりとともにSREが普及し、さまざまな企業のSREの活動内容は勉強会やイベントを通じて発信され、SREの活動のプラクティスを知る機会が増えました。

Topotalのメンバーも発信を行っています。

その中でインシデントレスポンスの領域だけは、各社が模索しながら改善を進めておりプラクティスの共有が徐々に増えてきたものの、発表の場がまだまだ少ないと感じていました。

インシデントレスポンスを共有する場が少ないのは、インシデントレスポンスの特性にあると思います。 過去は障害が起きないこと・起こさないことが重視されていましたから、ネガティブな発信になってしまう可能性があります。また、そのシステムごとの背景もあるため、仔細な説明が難しいのではないでしょうか。

しかし、昨今ではSREのプラクティスが浸透しエラーバジェットの概念が理解されたことで、インシデントの取り扱いが変わってきました。 こういった背景とTopotalはSREコミュニティへの貢献を1つの軸として活動していることも相まって、イベントを開催することに至りました。

Waroom Meetup#1 の内容

今回は第1回ということもあり、すべてのセッションを招待制で行いました。社内で登壇いただきたい方の候補をあげ、発信している情報を確認しました。

そこから考えた今回のテーマは、インシデントレスポンスの始め方から改善のプラクティスを集めることにしました。

この理由は、これからインシデントレスポンスを始める方にも、すでにインシデントレスポンスのツールを使っている方にも有益な情報になると考えたからです。また、インシデントマネジメントSaaSを展開するWaroomとも適していました。

このテーマにぴったりなWaroomを導入と共にインシデントレスポンスの整備をしたLuup @gr1m0hさん、内製Slack Appでインシデントレスポンスの改善を進めている10X @sota1235さんのおふたりにお声がけしました。

おふたりの発表資料は、インシデントレスポンスを現場で実践したとても興味深い内容でした。

資料は以下のURLからご確認いただけます。

Luupの開発組織におけるインシデントマネジメントの変遷 @gr1m0h

speakerdeck.com

内製したSlack Appで頑張るIncident Response@Waroom Meetup #1 / Incident Response with Slack App in 10X @sota1235

speakerdeck.com

ほかには、SREに関する論文の紹介を@yuuk1tさんに共有いただきました。

#SRE論文紹介 Detection is Better Than Cure: A Cloud Incidents PerspectiveV. Ganatra et. al., ESEC/FSE’23

speakerdeck.com

Microsoftがアラーティングに対して実地で調査して問題提起した内容になります。解説をいただきながら、共有いただくとより理解が進みました。このような論文紹介は、定期開催してもらいたいなぁ〜と思っています。

最後は、TopotalからWaroomの開発秘話と今後のアップデートについて@nari_ex から共有しました。

Waroomの開発モチベーションと今後のロードマップ / Waroom development motivation and roadmap

speakerdeck.com

「つらい」インシデント対応を無くすというワードがいいなと、私は思っています。

インシデントがなくなることはありませんが、言語化した課題(質と量、連携の課題)は解決できる問題です。

この課題が少しでも減っていくことで、インシデント対応から学びを得られる機会が増えていくと私は信じています。

最後の懇親会は、皆さんが思い思いに交流できていたように見えました。お酒を飲みながら、Waroomのデモをつまみに話が盛り上がったり、開発秘話を話したり、お互いの仕事の悩みを共有したりしていました。その後、2次会には14名の方が参加し、より深い話ができたのではないかと思います。

人と人とのつながりを生み出せたと感じ、開催して良かったなと思える瞬間でした。

次回にむけて

みなさま、アンケートにお答えいただき、いろいろなご意見をいただきました。アンケートの内容も加味しWaroomMeetup#2 を企画していきたいと思います。 次回は、今回できなかった公募の発表も募集したいと考えています。インシデントマネジメントの活動の知見がある方は、ぜひお声がけください。 次回の開催は、2024年9月〜10月頃の開催を予定しています。

最後に

イベントを運営するぞ!に注力しすぎて、Blogに載せられるような写真がない問題が深刻ですね。みんなで最後に集合写真撮るかとかできなかったのが個人的にはちょっと悲しいです。

次回は、司会進行かフォトグラファーをアサインしようと思っています。

jsx-slack で Slack App を開発すると幸せになる話

こんにちは。CDO@sawa-zen です。

Topotal では Waroom(ワルーム) という SaaS を作っており、 Slack App を使った機能もあるため Slack UI を構築する場面が頻繁にあります。

ただ Slack UI の開発は Web UI などの開発と比べると開発しづらく、なんとか解決できないかと悩んでいた中で見つけたのが jsx-slack でした。 結果として劇的に開発体験が向上したので今回は jsx-slack を使用するといかに幸せになれるかをご紹介します。

https://github.com/yhatt/jsx-slack

Block Kit のつらさ

まず jsx-slack の魅力を伝える前に現状の「つらさ」をお伝えします。 Slack UI を構築するには Slack が提供してくれている Block Kit という UI フレームワークを使用するのですが、これがなかなかにシンドい。。。

  • 1️⃣ 非直感的な JSON で UI を構築する必要がある 😢
  • 2️⃣ Block Kit Builder がやや使いづらい 😢

https://api.slack.com/block-kit

1️⃣ 非直感的な JSON で UI を構築する必要がある 😢

Block Kit は JSON 形式で UI を構築します。例えばこんな UI を構築したい場合の Slack API に渡さなければならない JSON データはこちら。

構築したい UI に対して記入する JSON の量が多く感じます。また JSON のままでは直感的にレンダリングされる UI のイメージが湧きづらいです。このサンプルはかなり簡素なものなのでまだギリギリイメージできますが、フォーム系のUIが加わるとより複雑化します。このJSONをメンテナンスしていくのはかなり骨が折れます。

2️⃣ Block Kit Builder がやや使いづらい 😢

1️⃣のペインを解消すべく Slack は Block Kit Builder というエディターを用意してくれています。Block Kit Builder を使えば、API Document を確認することなく Web UI からボタンを押すだけで JSON を生成できます。生成された JSON を右側に用意されているエディターから編集もでき、作成したUIを実際に自分の Slack Workspace に送る事ができるため便利です。

ただこのエディターの挙動があやしく、意図しないタイミングでコードが消えてしまったり、UNDOができなくなるタイミングがあったりと、使っていると「キィーーーー!」と叫びたくなる事が多々あります。ここに関しては今後の改善に期待です。

ここまでで現状の Slack UI 開発のペインがざっくりわかっていただけたと思います。

jsx-slack という名の救世主

これらを解決してくれるのがこの jsx-slack です。その名の通り jsx を使ってこの JSON を作成できます。この jsx-slack を使って記述することで多くのメリット享受できます。

UI をイメージしやすい 👍

百聞は一見にしかず。先程の例で言うと以下のようなコードになります。

JSON で書いたものと比較すると圧倒的に記述量が少なく、また自分のようなフロントエンドの開発に長く携わってきた身からすると jsx で記述されているだけで出来上がる UI がイメージしやすいです。

ただ、この「イメージしやすい」というのにはもうひとつ理由があります。

HTML ライクに書ける 👍

jsx-slack はなるべく HTML ライクに書けるように設計されおり、 pimgblockquote などの HTML タグをいくつか使用できます。そのため、より親しみ深いコードで記述できイメージがよりしやすくなっています。またHTMLの知識があるだけで構築できるため学習コストも少なく感じました。

REPL が用意されている 👍

jsx-slack にも Block Kit Builder のような、ちょっと試したい時のエディターが用意されています。こちらはプレビューやボタンからUIを追加する機能はありませんが、シンプルで使いやすいエディターと Block Kit Builder でプレビューするためのボタンも用意されているため快適に構築できます。

基本的には VSCode などでコードを書くことになると思いますが、ちょっと確認したい時にはかなり重宝します。

https://jsx-slack.netlify.app/#message

まとめ

もし既に Slack App の開発をされている方であれば jsx-slack の良さが分かっていただけたかと思います。TypeScript 以外の言語で Slack App を開発されている場合でも UI の構築だけ jsx-slack に切り出すだけでも開発体験が絶対に良くなると思うのでおすすめです!

是非 jsx-slack を使って楽しい Slack App 開発をしていきましょう!

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom(ワルーム) を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be