リアルで集まろうDAYで、交流を深めるワークショップを企画してみた!
どうも、 id:sawarabi です!
クリスマスと大晦日の狭間からお送りします!
今回は Low-Tech Social Network というワークショップを実施したので、それについて書こうと思います。
背景
12 月 16 日にリアルで集まろう DAY というものを開催しました!
note.com
その中で、せっかく集まるのだからチームビルディング的な企画もやりたいね、ということで実施したものになります。
企画の選定
前提
現在の会社の状況としては、ざっくり
- 徐々にアクセルを踏んでいこうとしている状態
- フルリモートの中で徐々に人が増えてきている状態
という感じになります。
また、リアルで集まろう DAY は
- 参加者は全社
(エンジニアだけでなくマーケや CS、セールス、コーポレートなど様々な職種が参加) - ワークショップの前は戦略共有会
- ワークショップの後は懇親会
となっていました。
その中で、どういうワークショップを実施すれば一番効果があるか、現状感じている様々な課題感を解決できそうか、を考えながら選定をおこないました。
候補
ゲームストーミング、という本からいくつか候補を挙げて、その中から選んでいきました。
最初候補として考えていたのは以下の3点です。
カバーストーリー 未来像を雑誌や新聞の見出しで表現するゲーム
https://www.marlin-arms.com/support/games/?p=365
良さそうな点:- これから VideoTouch がアクセルを踏んでいくにあたって、未来像を想像することで弾みがつきそう
- 職種ごとに視点が違うので、異なる職種同士でグループを組んでやることで、相互理解につながりそう
キャンプファイアー 経験談の糸を繋いでいくゲーム
https://www.marlin-arms.com/support/games/?p=570
良さそうな点:- 各個人の体験談を話してもらうことで、各々のバックグラウンドや VideoTouch 上での経験の共有をおこなえそう
- 職種を超えての相互理解、ベースの部分を固めるのに良さそう
- 昔であれば酒の場で語られた失敗談だったりの共有をおこなう場としてよさそう
事前分析 プロジェクトが大失敗をする経緯を予見するゲーム
https://www.marlin-arms.com/support/games/?p=483
良さそうな点:- これから勢いよく成長していこうという中で、あらかじめつまずきそうな部分に気づけるので、注意して進めることができそう
- 職種ごとに視点が違うので、異なる職種同士でグループを組んでやることで、相互理解につながりそう
実際に決定したもの
で、熟考を重ねた結果、こちらのワークショップを実施することにしました。
- Low-Tech Social Network
イベント参加者同士のつながりを深めるゲーム
https://www.marlin-arms.com/support/games/?p=477
https://gamestorming.com/low-tech-social-network/
https://advanced.collaboration.ai/blog/collaboration-capital-tools/2011/6/1/low-tech-social-network-gamestorming-for-collaboration.html
良さそうな点:- 仕事でのつながりだけでなく、趣味など業務外のつながりもできるので、職種を超えた関係が築ける
- リモートで失われたつながりや、それによる協力関係を構築できるのでよさそう
- かつ、このあとの懇親会の活性化にもつながるし、作った図は懇親会でそのまま使えるのでよさそう
まさかの候補にないものが選定されていますが、
- 課題感としては職種間のコミュニケーション促進が大きい
- 課題感的にはキャンプファイアが適していそうだが、キャンプファイアは異職種でやるよりも同職種でやった方が効果が出そう
- 上にあげた候補はリアルでもオンラインでもあまり効果が変わらなそう
との理由から改めて本を読み直して、後ろの懇親会にも繋がる Low-Tech Social Network を実施することにしました。
ワークショップで作成した人脈図はモノとして残るので、懇親会での話のネタになる、というのも理由として大きいです。
企画の進行
実際に当日説明に利用したスライドはこちらになります。
実際はまず最初にお酒を各自用意してから、
- 付箋に自己紹介を書く
- 付箋を模造紙に貼る
- つながりを線で結んでいく
という流れで進めました。
実際にやってみて
最初はみんな黙々と付箋を書いていたのですが、つながりを線で結んでいくタイミングで雑談しながらここ繋がるよねとか、◯◯さん〜好きなんだー、わたしもー、みたいな話が出たり、いい感じに盛り上がっていました!
あとみんな何気に似顔絵上手い!
当日ちゃんと盛り上がってよかったなーと思いつつ、一方で今、このブログを書きながら振り返ってみると、よかった点もあれば改善したい点もあるなーという思いも。
書き出してみるとこんな感じです。
よかったと思う点
- 職種を超えて会話が生まれた
- 普段接点のない人同士で会話が生まれた
- つながりを線で結んでいる最中に席の移動が自発的に発生して、会話の参加者の組み合わせが入れ替わっていた
- フルリモートで失われがちだったプライベート関連の雑談が生まれた
- 意外なつながりや、失敗談でのつながりなど普通の雑談では中々出てこないつながりが発見できた
- この後に実施した懇親会でも、席を移動しても他のグループの図が残っているので話題に困らなかった
次やるのであれば改善したい点
- 会場の都合で壁に模造紙を貼れなかったため2グループに分かれてしまった
- そのためグループでつながりが断絶してしまった
- 一つのグループでできるようにするか、あるいはグループ間を混ぜる仕掛けができるとよさそう
- 最終的に完成した図の写真と撮り忘れていたので、次回は撮りたい
改善したい点もあるものの、自分も参加者として参加した中で普段業務であまり接点がない人とも趣味だったりちょっとした失敗談だったりの話で盛り上がることができました。
なので、当初狙いとして考えていた「職種を超えたつながり」もちゃんと達成できていたのではないかな〜と思います。
また、後日アンケートを取っているのですが
- 普段話せていない人と話せた
- 懇親会で話しやすかった
- 楽しかった
などなど好評をいただきました!
今回のワークショップに限らずですが、この手のものは会場の制約の影響を結構受けるので次回からは会場の下見だったり制約を考慮した設計などを気をつけようと思いました。
普段はオンラインで miro (オンラインのホワイトボード)を使ってやったりしているので、だからこそたまにリアルでやる場合はいつもと勝手がちがうということを忘れずに、という感じですね。
最後に
VideoTouch ではフルリモートでの勤務になっていますが、その中でもコミュニケーションを促進していこう!というところで色々と模索している最中となります。
このようにリアルで集まってその中でチームビルディング施策をおこなう、というのもありますし、あるいはオンラインでもっと促進するにはどうしたらいいだろうか、ということを色々試したりしています。
まだちょっとわちゃわちゃしている感じもありますが、VideoTouch ではそんな中で一緒に試行錯誤していける仲間を募集中です!
もし興味を持っていただけましたら、カジュアルに一度お話しできればと思っています〜。
viibar.notion.site
「【VideoTouch & Henry】とあるフロントエンド勉強会」を開催したよ!
こんにちは、おにぎりの具はすじこ派、id:gaooh です! VideoTouch と社名をかえてはじめてのブログですが気張らずやっていきます。
今回とある縁がきっかけて 9/13 に Henry 社さんと合同でフロントエンド勉強会を開催させていただきました。
リアルな場での勉強会はViibar時代に何度かやったことがったのですが、完全リモートの勉強会の開催は はじめてだったのでちょっとドキドキでしたが、無事開催して事故なくおえられたのでよかったです。
余談ですが、YouTubeで配信ということでStreamYardを利用して配信しましたが。結構便利なのでおすすめです。
バックヤードという概念があるので、参加者はそこで待機しながら出番をまてますし、 配信中にロゴを出したり話す人を切り替えたり中は管理画面側でできるので、なるほどーと。
さて肝心の発表ですが、VideoTouch社からは id:mstssk と @hanzochang から発表させてもらいました。
4KディスプレイだとCSSアニメーションがぶっ壊れた話
id:mstssk からは、ちょっとレアなディープな話です。 サービスによってはクリティカルではないかもしれませんが、VideoTouchの利用用途的に撮影時、他のモニタで移して撮影することも多いので、意外と大事なんですよね。 撮影はChromeの拡張機能でやっているのですが、開発する上でも一般的なWebサービスとはまた違った気の使い方も必要で いろいろ日々キャッチアップしながら作っている中での学びからの発表でした。
FigmaのようなLayoutGridをHTML上で実装し、マークアップに活用する
@hanzochangからは元ディレクターという経歴らしい拡張機能実装のお話。 FigmaのようなLayaoutGridをHTMLで実現するためのChrome拡張機能です。
Webサービスにおいて一貫性は非常に大事ですが、CSSをくんでいると「あれ、なんかここずれてない?」みたいなことも多いです。 Chromeの開発者ツールなどで探ったりすることもありますが、結構大変です。それのサポートをしてくれます。 本人曰く、まだ絶賛開発中なので、これからの改善が楽しみではあります
VideoTouchではこれ以外にもいろいろ技術的なチャレンジをしていたり、動画の知識がない人でも 簡単に撮影、編集、配信、分析ができるようなUI/UXを目指して日々改善しています。 エンジニアはフロントに限らず絶賛募集中なので、是非是非応募いただければと。
面接まではいかないけど、なんか興味わいた、話聞きたいかなーというかたはmeetyもありますので、こちらもおまちしております!
(会社のお金で)スクラムマスター研修を受けてみた
どうも、 id:sawarabi です!
スクラムマスター研修を受けたいなーと思いつつ、ずっと思うだけだったのですが…。
先日機会があって、受けたいっす、と言ったところ、いいよ!と言われたので受けてきました!
スクラムマスター研修とは
スクラムマスターとしての基礎を身につけて、認定スクラムマスター(CSM)の受験資格が得られる研修です。
内容としてはこんな感じになります。
コース名:認定スクラムマスター研修
主催:株式会社アトラクタ
費用:220,000円 (消費税10%込み)
開催日時
5月25日(水) 13:00-18:00 スクラムの基礎を学ぶ
5月26日(木) 10:00-17:00 実際にスプリントを回してみる
5月27日(金) 10:00-13:00 スクラムマスターについて学ぶ
アジャイルをゆるく語りたい!LT で軽く発表したときのリアクションで「会社がお金出してくれるの神」というのがありましたが、実際そうだと思います。
感謝!
自分自身今後も研修やイベントに参加だったり、あるいは他の人が今後も受けられるようにしていくという意味でも、ちゃんと業務に活かしていきたいなーと思う所存です。
実際受けてみてどうだったか
アジャイルをゆるく語りたい!LT で軽く話したときのスライドは以下になります。
良かった点
ざくっと、以下があげられるかなと思います。
- スクラム開発自体の理解度が上がった
- 普段スクラム開発をする中で疑問に感じていたことを講師に質問することができた
- 例えばスプリント中にPBIが完了にならなかった場合にどうするかとか、差し込みタスクの扱い方だったりとか
- Day2 の1日の中でスプリント回してみる中で、レビューでプロダクトが改善される流れを身を持って経験できた
- 横のつながり(スクラムマスター同士のつながり)ができた
- 認定スクラムマスターになった(試験受かった)
実際に影響がでた部分
研修自体を一つのスプリントとみたときに、じゃあスプリントゴールってなんだろう?を考えて、
「自分のチームのスクラムを改善できる状態になる」
というゴールを設定しました。
じゃあ実際どういう変化があったかというと、例えば
- デイリーが2017ver から 2020ver になった(よりタスクの完了にフォーカスした形になった)
- タスク(SBI)をストーリーポイントでなく時間で見積もるようになった
- レトロスペクティブで「小さく試して小さく改善」を意識して、Try の粒度を調整するようになった
などなど。
小さく試すことで失敗したときの影響が小さくなり Try をしやすくなるというのもありますし、成功率も上がるのでチームが良くなっていっている、という感覚を持ちやすくなる、というところで「小さく試して小さく改善」をあらためて意識するようになったのは良かったのではないかと思っています。
スクラムマスター研修を受けたから変化が起きた、かどうかはまだまだこれからですが、いい意味で影響はあったのではないかなーと思います。
最後に
研修で教わるのはあくまで理想の話で、自分達のチームの理想、あるべき姿ってどうなんだっけ、じゃあ現実をどう理想に近づけていこうか、というところが難しいところでもあり、面白いところでもあるのかなーというのが直近の感想です。
一気に大きく変えようとすると大体失敗するので、そこもちゃんとアジャイルらしく、小さく試して小さく改善していければな、と思っています。
VideoTouch流 ドラッカー風エクセサイズをやってみた!
どうも、 id:sawarabi です!
先日、VideoTouchのエンジニアで、チームビルディングの一環として「ドラッカー風エクセサイズ」をやってみたので、その共有になります!
アジェンダ
- 今、我々はどこにいるんだっけ(5min)
- ドラッカー風エクセサイズとは(5min)
- 実際にやってみよう!
- 自己開示フェーズ(15min)
- 発表(5min)
- フィードバックフェーズ(10min)
- 発表(10min)
- 振り返り(5min)
1. 今、我々はどこにいるんだっけ
ドラッカー風エクセサイズは、タックマンモデルの「形成期」「混乱期」に効果があるとされています。
(タックマンモデル:チームの発達段階を4つのフェーズに分けて表したモデル)
そこでまず、我々のチームはタックマンモデルのどこにいるんだっけ?をまず確認しました。
今「自分が」いると思う場所はどこか?と投票してもらったところ、形成期の後ろの方が一名、混乱期の頭の方が二名、混乱期の後ろの方が一名、という結果になりました。
(ちなみに、一般的にチームに長くいるメンバーほど後ろの方になり、新しく入ったメンバーほど前の方になる、という傾向があります)
じゃあ「チームとして」今どこにいるんだろう?でいうと、一番前にいる人が基準になりますので、我々は今、「形成期」にいる、となります。
ドラッカー風エクセサイズは上にも書いた通り「形成期」「混乱期」に効果があるとされている、かつ我々は今「形成期」にいる、ということが確認できたので、じゃあやる意味があるね!ということで実施しました!
2. ドラッカー風エクセサイズとは
ざくっと説明すると以下のようになります。
- アジャイルサムライで紹介されている、初期のチームビルディングに効果的な手法
- 特にタックマンモデルの「形成期」「混乱期」に効果的
- 4つの質問の回答を共有することで、考えや価値観、期待のすり合わせをおこなう
- 自分が得意だと思っていること(ここだったら任せておけ!)
- どういうふうに貢献をするか
- 自分が大切に思う価値観はなにか
- 他のみんなが自分に期待していると思うこと
- ただ回答を共有するだけではなくて、
- それに対してフィードバックをおこなうことで、認識を合わせる
- この人のいいと思うところ、ここすごいなーと思うところ
- この人に期待していること
- その上でディスカッションすることで、相互理解を深める
- それに対してフィードバックをおこなうことで、認識を合わせる
既存のドラッカー風エクセサイズでは4つの質問に答えて共有するところまでですが、今回はその後で二つほど質問を追加しています。
3. 実際にやってみよう!
まず初めに「自己開示フェーズ」として、基本の4つの質問に回答して、その回答をチームに共有ということをおこないました。
- 自分が得意だと思っていること(ここだったら任せておけ!)
- どういうふうに貢献をするか
- 自分が大切に思う価値観はなにか
- 他のみんなが自分に期待していると思うこと
その上で、「フィードバックフェーズ」として、他のメンバーに対して
- この人のいいと思うところ、ここすごいなーと思うところ
- この人に期待していること
を書いてもらい、共有するということをおこないました。
ツールはオンラインホワイトボードのmiroを利用しています。
実際に出来上がったものがこちら(付箋の内容や名前はモザイクかけてます)。
実際やってみると4つの質問に回答するところで結構時間かかったりということがあったので、事前に共有して回答しておいてもらう、もありかもしれません。
4 振り返り
やってみてよかったなーと思う点として、個人的な感想は以下になります。
- 自分では強みとして認識していなかったものを強みとして指摘されることで、自分について新しい発見があった
- 自分に対する他のメンバーからの期待について、最初から認識していた部分も改めて期待をすり合わせることで、自信を持つことができた
- また、認識していなかった期待の部分について、そこを意識して今後動くことができそうだと感じた
- (他のメンバーについて)どういう背景でそういう価値観、考え方なのか、を知ることができた
じゃあチームとしてどうかでいうと、効果が出るのはこれからにはなるのですが、
- お互いの考え、価値観の背景をある程度共有できたので、コミュニケーションを取りやすくはなりそう
という印象はあって、「形成期」→「混乱期」の壁であるコミュニケーションの量(心理的安全性の確保)や、「混乱期」→「統一期」の壁であるコミュニケーションの質(本音で話す)というところが少しずつ良くなっていくのでは、と感じています。
もちろん、ドラッカー風エクセサイズやっただけでぐっとよくなるわけではなく、そこで一緒に得たものをチームで活かして改善していくことが大事なので、引き続き小さく試して小さく改善を積み重ねていく、ということを今後も引き続きやっていこうと思います!
VideoTouch一周年記念なので相互理解を深めてみた
どうも、 id:sawarabi です!
VideoTouchがリリースから一周年を迎え、チームでお祝い会を実施しました!
(一周年記念といいつつ自分が記事を書くの遅れたので、現記事執筆時点で一周年と2ヶ月くらいになっていますが…)
そのときの様子がこちらです。
note.com (上記記事の中の写真で、めっちゃ物理的に青くて広いのが自分なのですが、写真写り悪くて? 悪役っぽさが…ヒーロー倒す邪悪な作戦説明してます、って感じになってる)
で、せっかくみんな集まったのでちょっとしたワークショップを実施してみました!
他の人って普段何してるんだろ?
実際に進行する際に使った資料がこちら。
内容としては「ゲームストーミング ―会議、チーム、 プロジェクトを成功へと導く87のゲーム 」という本で紹介されている、welcome to my world というワークショップになります。
概要
他職種の人の仕事の流れを想像して書いてみるワークショップです。
やろうと思ったきっかけ
自分自身エンジニアとして普段は主に開発をおこなっているのですが、そういえば他の職種の人が実際にどう仕事しているのか、あんまり知らないなーと。
サービスは作って終わり、ではなく、開発したものがお客様に利用いただけるまで、あるいは開発の前にもさまざまな職種の人が関わって動いています。 実際、普段の開発や運用の中でも他職種、例えば営業だったりマーケだったりCSだったり、の方とコミュニケーションが発生しています。
なので、お互いのことをもう少し知る、興味をより持つ、というところができるとコミュニケーションが円滑になって全体的にスムーズになるのではと思い、このワークショップを実施してみました。
狙い
以下の2点を意識して実施しました。
- 他職種への理解度を深めること
- 今後の職種間の交流をしやすくする、深めること
進め方
(詳しくはスライドをご覧ください)
- 付箋に自分の職務の一つを書いてもらう(1min)
- よく知らない職務の人や気になる職務の人とペアを組む(1min)
- 相手の仕事の流れを自分なりに想像して図にしてもらう(フローチャートなど)(5min)
- 完成した図を相手に見せて説明する(5min)
- 相手の図が実際の仕事の流れと合っているかを確認して、相違点について説明してもらう(10min)
- 立場を入れ替えてもう一回実施
- 適当に2ペアくらいからわかったことや感想を発表してもらう
実際にやってみて
実際にやって描いてみたものの一例が以下になります(マーケ × エンジニア)。
(自分が描いたものではないですが、いい感じだったので使わせてもらいました)
自分はCSの方とだったのですが、実際やってみると相手の職務の3割くらいしかわかっていなかったなーという印象でした(あるいはそれ以下)。
当然、これをやったからすぐに他の職種の職務が全部理解できるというものではありませんが、そもそも他の職種のことを自分で思っている以上に知らないんだなーということを知ったり、その上で理解を深めようと思うきっかけ、という意味でやってよかった!と思っています。
今後も組織やチームのフェーズに合わせて、こういうワークショップというかゲームというか、を実施していければなーと!
ランチ勉強会:「人を動かす」をあらためて読んでみた
どうも、id_sawarabi です!
Viibar の開発部では隔週金曜日にお昼の時間帯で、ランチ勉強会というものを実施しています。 ※ 最近開催タイミングが変更になって、チームでの(任意参加の)リモート飲み会前の開催になりました。下記はこれを発表したタイミングでのレギュレーションになります。
レギュレーションはこんな感じ。
- 隔週金曜日お昼時間帯にどこかでやる
- ランチ食べながら(事前に買ってくる)
- 発表テーマは「フリー」。以下は一例
- 自分がよく知っていることをみんなに教える
- 最近調べたことをまとめる
- こういうカンファレンスがあったので発表内容を理解してみんなに共有する
- 最近気になっている技術があるので調べてみた
- 使っているけどよく知らない技術があったので深く調べてみた
過去のログを見てみると内容は技術の話から自転車の話、スプラトゥーンの話まで多岐に渡り、各々好きなことを話しているという感じです。
で、自分も Viibar に JOIN したしということで、ランチ勉強会でちょっとした話をしてみました。
背景
大学時代に読んでそれっきりになっていた 「人を動かす」 をあらためて読んでみて、色々発見というか、経験と照らし合わせてそうだよねーっていう部分が出てきたので話したいなーと。
「人を動かす」とは
原題:How to Win Friends and Influence People
著者:デール・カーネギー
初版:1937年
日本国内で430万部、世界で1500万部以上を売り上げている。発売から80年以上売れ続けている超ロングセラーである。
ざくっと紹介: この本がアメリカから出た、っていうのが意外に思える一冊。
アメリカといえば議論に勝って相手を打ち負かす、というコミュニケーションのイメージが強い(実際そういう面もある)が、それだと人間関係上手くいかないよね、じゃあどうするといいんだっけ、という本。
仕事で活用できそうなもの
基本、まるっと一冊役に立ちそうだなーと思いますが、その中でもいまいま改めて意識しないとなー、ちゃんとできてるかなー、と思ったものを紹介。
人は感情の生き物である
これ、具体的にどのページ、パートに書いてあったかぱっと出てこないのですが、印象に残ってるので。結局のところこれに尽きると自分は思っていて、ただこの当たり前のことを忘れている人があまりにも多いよなーと思う。
人間には感情があって、一緒に働いてる同僚も人間、上司も人間、サービスの先にいるのも人間なのだから、感情も大事にしないとダメだよね、と。
企業だと上のレイヤーにいくほど数字を求められ、また数字で人を動かそうとする印象。ただ下のレイヤーにいくほど数字じゃなくて感情で動く割合が増える(気がする)ので、そこで不幸なすれ違いが起こりがち。
実際にあった例だと、こんなのとか(p4)。
https://speakerdeck.com/sawarabi/pmtipslt-naze-menbaha-besutowojin-kusanaifalseka?slide=4
人の立場に身を置く
人を動かす唯一の方法は、その人の好むものを問題にし、それを手に入れる方法を教えてやることだ
本の中では「手紙の返事をよこさない子供に、返事を出させる」ことを事例としてあげているが、相手の立場、視点で考える、というのはコミュニケーションを取る上で大事だよなーと改めて。
相手の発言を受け止める時に、どういう立場、意図、感情でその発言をしたのか、を意識すると受け答えがスムーズになる…はず。
笑顔を忘れない
動作は言葉よりも雄弁である。微笑みはこう語るー 「私はあなたが大好きです。あなたのおかげで私はとても楽しい。あなたにお目にかかってとてもうれしい。」
これはカメラがオフの時も同じだと思っていて、顔は見えなくても声色に出るんですよね。
といいつつ、最近忘れていた気がするので、改めて笑顔でMTGに臨もうかと。
どうせ笑顔は0円だし、笑顔だと少し幸せというかポジティブな気分にもなれるしなので、ぜひ。
挨拶も同様で、「自分は敵じゃないよー、仲間だよー」というものだと思っているし、タダでできるので、コスパいい。
名前を覚える
名前は、当人にとって、最も快い、 最も大切な響きを持つ言葉であることを忘れない
人の名前を覚えるのが苦手なタイプなので耳が痛い…が、実際これは大事だと思っているので名前を覚える、あるいは間違えない工夫って大事だよなーと。
覚えるだけじゃなくて、ちゃんと名前で呼ぶことも大事。
心からほめる
人間は、誰でも周囲のものに認めてもらいたいと願っている。〜中略〜見え透いたお世辞は聞きたくないが、心からの賞賛に飢えているのだ。
お世辞を言えっていう話ではなく、「心から」ほめよう、という話。無理にほめる必要はない。
ただやっぱり褒められると嬉しい(本の中だと重要感が満たされる)し、その行動を強化する方向に動くことが多いので、小さいことでもどんどんほめる、って大事だよなーと。
ちなみに人を動かす、の中でほめることに言及しているパートが3個もある。このことからもほめるっていうのは大事なことなんだよというのが伝わってくる。
これも結構意識してやらないと、あとでFBしようとか思っていると絶対忘れるので、その場その場でイイと思ったらイイネをするのが大事。
誤りを指摘しない
フランクリンは次のように言っているー「私は人の意見に真っ向から反対したり、自分の意見を断定的に述べないことにした。決定的な意見を意味するような言葉、たとえば、"確かに"とか"疑いもなく"などという言葉を一切使わず、その代わりに『自分としてはこう思うのだが…』とか『私にはそう思えるのだが…』と言うことにした。相手が明らかに間違ったことを主張しても、すぐそれに反対し、相手の誤りを指摘することをやめた。そして、『なるほどそう言う場合もあるだろうが、しかしこの場合は、少し事情が違うように思われるのだが…』という具合に切り出すことにした。
自分自身は「お前バカじゃないの!?」とか、「それ不愉快だからやめてくれる?」とか、そんなことを言われたりしてきた過去があるのでダイレクトに言われても普通に受け止められるんですが、まあそれは例外。
誤りを指摘しない、というよりは、ダイレクトに間違いを指摘するのではなくて、相手に考えるきっかけを与えて、相手に自分で考えてもらうことが大事だよね、という話。
もちろん場面にもよるとは思っていて、緊急事態であればダイレクトに言う必要があるだろうし、typoの指摘だったり、あるいはティーチング中であればダイレクトに言ってもいいんじゃないかなーとは思ってる。
ただ相手が自分で考えて答えを出す、の方が本人の納得感も高いし、記憶に残ると言うか身に付く感じがするので、極力そちらの方がいいよねと。 (人を動かす、の他の話でも「相手自身に思いつかせる、考えさせる」はよく出てくるので、やはり大事と言うか効果的なんだと思う)
"イエス"と答えられる質問を選ぶ
人と話をする時、意見の異なる問題をはじめに取り上げてはならない。まず、意見が一致している問題からはじめ、それを絶えず協調しながら話を進める。互いに同一の目的に向かって努力しているのだと言うことを、相手に理解させるようにし、違いはただその方法だけだと強調するのである。
これ、今まで意識できていなかったのでこれからちゃんと意識してやってみようかなーと。
過去ベトナムとやりとりしていたときに近い経験があって、「お前のバグをどうにかしろ」ではなくて「我々が直面している問題を解決するために力を貸して欲しい」っていうコミュニケーションを取ると協力を得やすかったなーというのを思い出しました。
目的は同じで、その目的を達成するために一緒に協力してことに当たろう、という姿勢は大事。
ベトナムと日本、Biz側と開発側、リーダーとメンバー、色んなところで起きがちな対立を解消するのに役立ちそう。
遠回しに注意する
人を批判する際、まずほめておいて、次に"しかし"という言葉をはさんで、批判的なことを言い始める人が多い。〜中略〜ところが、"しかし"と言う言葉を聞いたとたん、今の褒め言葉が果たして本心だったのか疑いたくなる。結局は批判するための前置きに過ぎなかったように思えてくる。信頼感が鈍り、勉強に対するジョニーの態度を変えようとする狙いも失敗に転ずる。この失敗は"しかし"という言葉を"そして"に変えると、すぐに成功に転じる。
これ、自分も過去やってしまっていたなーと反省。
例えば、技術的には伸びてきた"けど"、他チームとの調整とかがもう一歩だね、とか言ってなかったかなーと。
それよりは、技術的なところは伸びてきて頼りにしてる。他チームとの調整も少しずつできるようになってきてるので、ここを来期伸ばせるとより技術が活きるようになっていいね。の方が、相手のやる気を掻き立てることができたのでは。
まとめ
この記事を書いてみて、本って一回読んだだけだと実はあまり意味がなくて、読んで実際にやってみて、その上でさらに読んで、を繰り返すことで内容が自分の血肉になっていくなーということをあらためて思いました。
あとはあれですね、チームに共有することでチームにいい影響があるといいな、というのと、共有することである意味、自分自身こういうことをやっていく!という宣言をすることになるので、普段に意識しやすくなる、と言う意味でもチーム会で共有する、はやってよかったなと思います。
Datadog Incidents を使ってみて雑感
こんにちわ、冒頭の書き出しに何をかこうか考えるのが一番時間がかる、id:gaoohです。
今回 Datadog Incidents を使ってみて思いのほかよかったのでその感想をまとめます。
そもそも、みなさん何でインシデント管理をしてますか。
よくあるパターンはタスク管理はきちんとされているけど、突発的なインシデント対応は管理されていない。 クライアントやユーザに報告のために履歴は必要に応じて記憶ベースでSlackをおってあとでまとめる。 その場でおもいつた改善策はタスク積んでおくけど、喉元過ぎれば忘れられ、棚卸しの際に「これなんのことだっけ。。。」 みたいなことになりがちではないでしょうか。
私はごめん、めっちゃよくやってた!
もちろんやることたくさんあるプロダクト開発においてすべて綺麗にできないのも事実で、実際やりきれないこともあります。 ただし中長期を考えるとこれらをおざなりにしてくことは大きな損失になりますし、できる基盤や組織をつくっていかねばなりません。
なので、現状VideoTouchではインシデント管理を monday.com でおこない、タスク管理と紐付けています。
インシデントの中身はちょっと隠していますが、以下のような感じでまとめてます。 数が多いのはなやみではありますが、だからこそ手を打っていかねばならないのです!!誰か助けて!
工夫している点としては紐付くタスクも「暫定対応」「恒久対応」「再発防止策」と分類し、きちんと最後の再発防止策まで手をつけられてるかぱっと見でわかるようにしています。また何が起因で立てられたタスクなのかを紐付けるようにしてます。
なかなか再発防止策まで手が回らないとい、とりあえずの絆創膏対応でおわってしまうのも実情なくはないですが、その実情も見える化できるメリットもあります。
また中長期での改善はなかなかすすめれらないので、これをベースの履歴として残して四半期ベースで振り返るようにしています。
現状の運用の課題
この運用によって最低限インシデント管理できているのですが、発生時に時系列でなにをしたのかの記録方法が人によってまちまちであとから振り返りにくいという課題がありました。
何をしたのかはリアルタイムではなかなか残せないので、後日別途notionでまとめています。 このあたりはユーザへの告知やビジネスサイドとの影響範囲の説明のためにも必要ですし、同日対応に参加できなかったメンバーへの共有も含めて、ある程度最初の一次対応がおわったらまとめるようにしています。
その際、何を残すのかがあいまいなので人によって概要はのこっているんだけど、ログやデータがのこっていないこともありました。 またデータも見やすさ重視で毎回スクショにとってはりつけたりしていて手間もかかってしまっていました。 もちろん何を残すのかを定義するという対策もありますが、そんな中お試しでDatadog Incidentsをつかってみたら課題を解決できそうで、かついろいろメリットが大きそうだったのでまとめてみました
Datadog Incidentsを使って感じたメリット
インシデント管理として残す情報のフォーマット化
「なにがおきたか」「インパクトは(影響範囲)」「なぜおきたか」 これがデフォルトのフォームとして用意されています。また追加でフィールドは足したり削ったりもできます
notion でもテンプレート機能を使えばできなくはないですが、履歴や更新タイミングなどふくめてすべて残るのは強い。
インシデント発生時のモニタリング情報を簡単にまとめられる
なにか障害が発生したときにDatadog上の情報をみて状況を把握していくということをやるわけですが、「どこをどうみてどう判断したか?」 というのは正しく切り分けをする際に非常に大事ですし、ここは人によって知識差がでやすいのでなるべくチームに共有していうべき情報だと思います。
それが正しく行えないとわかりやすくインフラ周りが属人化していきます。
かといってこの辺は職人芸的な部分も含まれていて、一緒にハイスキルの人とアラート対応をして師弟関係的に伝授していく部分も多いです。
その間をなんとか埋めていきたいと考えたときに、誰もまだ対応していない障害に対しての瞬発力的なものは、実際の対応を経験して培いながら、既に一度対応したものは誰でも対応できる状況にするというのが一番の近道です。 一度やったことに関したは先駆者たちが作った道があるので、その道にそって調べていけばいいことも多いわけですし。
なので「どこをどうみてどう判断したか?」は過去を先駆者たちの動きを学ぶためにも非常に大事な資産なのですが、障害対応をしながら、それらを残すためにはなかなか難しい。かといってあとから思い出して整理するのは腰が重いですしね。
これらの課題に対して、Datadog上でサーバのモニタリングをしている場合、そのモニタリング情報をインシデントのタイムラインに追加するのことがさくっとできちゃいます。
よい!
表示しているグラフからワンクリックでできるので手間がないため、対応しながら追加していくのも慣れてしまえばそこまで苦ではないはず! ただ追加するのが苦でなかったとしても、追加するのを忘れるのはありえるので、そのあたりは場数を踏みながら慣れるしかないでしょう。
Slack 連携
インシデントについて特定のチャンネルに通知するのはもちろん、インシデントごとにチャンネルをわけて対応することも可能です。 今のViibarの規模だと1つのチャンネルで完結しちゃってますがサービスの規模が大きくなったり、チームの規模が大きくなった際でも便利そう
まとめ
まだ使い切れていない機能も多いですし、試しにやってみたところで本格的な活用はこれからですが、大枠よさそうなので今後活用してければとおもってます。
インシデント管理は胃が痛くなりますが、サービスが成長していく中でうまれるプロダクトの技術的な課題や運用課題を中長期的な目線でみながらあーでもないこーでもないと考えて解決していくことって独特の楽しさですよね!
ではでは!