wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

価値観の相互理解を深める取り組み【バリューズカード】

執筆者:SRE シラト

対象読者

・チームビルディングに興味がある
・ウェイブエンジニアの取り組みに興味ある

はじめに 

仕事でメンバー間のトラブルが多いと感じていませんか?
原因は、価値観の相互理解が不足していることかもしれません。

ウェイブでは、メンバー同士で価値観の相互理解を深めるために、様々な取り組みを実施してきました。
・期待マネジメント(ドラッカー風エクササイズ)
・シャッフル 1 on 1
・RPGジョブ診断
・etc

今回は、新しい取り組みとして、AnimeFestaの開発チームで、バリューズカードを試しましたのでご紹介いたします!

余談ですが、現在シラトは、Embedded SRE として、AnimeFesta チームに参加中です!

バリューズカードとは?

webブラウザ版(無料)or 実物カードの2種類あります!
概要は以下の通りです。

Wevox values cardは、個人の価値観を引き出すことができるカードです。
チームメンバーと価値観を共有し合うことにより、メンバー同士の相互理解を深めることができます。
相互理解が深まるほど、心理的安全性が確保されエンゲージメント向上が期待されています。 wevox.io

使い方

公式ルール『①自分自身の価値観と相互理解』に、以下の独自ルールを追加しました。
・手札は常に公開する。
・手札のワードの意味を、どう解釈しているか共有する。
・手札を入れ替える際、『なぜ、そのカードを入れ替えたのか?』を共有する。

抽象度の高いワードは、メンバー間で意味の解釈が異なることがあります。
意味を共通認識にするルールの追加は、話が盛り上がるので、オススメです!

また、今回は4名で実物カードを使用し、1時間程度かかりました。

結果

所感

ミウラ

・メンバーが大事にしている価値観が様々で、考え方を聞くと「なるほどな〜」と相互理解が進んで楽しかった。
・意外と何を残すかの取捨選択が難しい(笑)
・取捨選択する際の考えをお互い話しながら進めていたのですが、その過程が特にメンバーの考え方が出ていて面白かった!

シラト

・今まで実施した相互理解を深める取り組みでは、表に出てこなかった価値観を知ることができてよかった。
・仕事で関わる頻度が低いメンバー同時で実施すると、より一層効果がありそうな印象。
・『〇〇さんが【愛】を捨てた?!』みたいに、盛り上がりポイントが多いのもよかった(笑)。

トミナガ

・一緒に仕事をしていく中で、相手の行動や発言など、自分とは異なることがあったりしますが、価値観を知ることで、その行動の意図がわかったりして、より仕事がしやすくなった気がします!
・他メンバーの価値観カードの残し方で「意外!」と思うものもあれば、「ぽい!!」ってなるものあったりと楽しくて、また違うメンバーや違うタイミングでもやりたいと思っています!

ヒラヤマ

・『チームで個人の価値観を共有する』ということをやったことがなかったのでとても新鮮だった。
・一緒に仕事をするだけでは、見えてこない、知り得ないメンバーのことがわかってとてもいい機会だった。

おわりに

webブラウザ版だと無料で試すことができるので、気になった方、ぜひ、お試しください!
新メンバー加入時に活用すると、アイスブレイクにもなって良さそうですね🤗

エラーバジェットが枯渇しても新機能開発を止めない運用を開始しました!

執筆者:SRE シラト
・SRE 2年生になりました!!!
・DevOpsの文化浸透を目指してます!
・最近、散歩ポケモンGOを始めました。

対象読者

・SLO/エラーバジェットの導入検討している、運用を行っている人

はじめに

SLO/エラーバジェットの運用ハードルが高いと感じていませんか?
私自身、運用を開始しても形骸化しないかとても不安でした。

数ヶ月前からCoolmicで運用を開始しましたので、意識したこと、所感についてお話しいたします!

※ SLO/エラーバジェットの説明やアーキテクチャのご紹介はありません

運用で意識したこと

1. プロダクトチーム全体を巻き込む

例えば、SREが単独でSLOを設定して運用を開始したらどうなるでしょうか?

👮‍♀️SRE「最近、TOPページの表示速度遅いから改修した方がいいかも!」
🧑‍💻他チーム「対応します!(まだ遅くないから大丈夫だな)」

個人、チーム間で、デッドラインの認識が異なると何もアクションしなくなり形骸化が加速してしまいます。

重要なのは、

『チーム全員で顧客目線の信頼性を定義、可視化して、共通認識にする』

ことだと思います。当たり前のことかもしれませんが、他のチームも巻き込むことはとても大切なのに、忘れがちだったりします。

2. エラーバジェットが枯渇しても復旧対応を必須にしない

調べてみると大きく2つの事例がありました。

①新機能開発を止めて復旧作業を優先する
②エラーバジェットが枯渇したらチーム全体に共有して、復旧作業を優先するべきか判断する

以下の理由から②での運用を開始しました。

設定したSLOが正しいとは限らない

SLO/エラーバジェットは、顧客目線で設定した運営側の数値でしかありません。
あくまで仮説で設定した数値なので、必ず復旧作業をする必要があるかというと、いささか疑問を感じました。

重要なのは、

『エラーバジェットが枯渇したから復旧作業をする』

のではなく

『顧客からの信頼度が下がるから復旧作業をする』

ことだと思います。 エラーバジェットが枯渇したら一度立ち止まって、判断するフェーズがあってもいいかと思いました。

3. ダッシュボードをいい感じにする

ダッシュボードがかっこいいとやる気でませんか?
完全に個人的な気持ちの問題なので、論理的な視点もなにもありません!

所感

1. 推測するな、計測せよ

実際、可視化してみるだけでも「あれ、このページって他のページと比較すると表示速度が遅いんですね」という声が上がりました。
可視化されていないと「気が付いたらパフォーマンスが悪化していた・・・。」という状態になりかねません。

2. 判断コストを削減できる

エラーバジェット運用を行う最大のメリットかと思います。
パフォーマンス改善するべき?バグ修正するべき?の判断においては、かなり需要な指標ですね!

3. 数値を見る文化に助けられた

少し話が脱線しますが、Coolmicには、朝会で売上数値などを確認する文化があります。
朝会で、エラーバジェットの枯渇状況を確認するので、毎日問題がないか確認することになります。
そのため、SREが関与せず、エラーバジェットが枯渇しそうになると、タスク化されます。

改めていい文化になったと感じました!

おわりに

運用の正解はないと思うので、定期的に運用を見直そうと思います。
正直もっと早く導入すればよかったと反省しつつ、判断コストが削減できるのはいいですね!

トップに戻る