（会社のお金で）スクラムマスター研修を受けてみた
どうも、 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）
- 立場を入れ替えてもう一回実施
- 適当に２ペアくらいからわかったことや感想を発表してもらう
実際にやってみて
実際にやって描いてみたものの一例が以下になります（マーケ × エンジニア）。
（自分が描いたものではないですが、いい感じだったので使わせてもらいました）
自分は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円だし、笑顔だと少し幸せというかポジティブな気分にもなれるしなので、ぜひ。
挨拶も同様で、「自分は敵じゃないよー、仲間だよー」というものだと思っているし、タダでできるので、コスパいい。
名前を覚える
名前は、当人にとって、最も快い、 最も大切な響きを持つ言葉であることを忘れない
人の名前を覚えるのが苦手なタイプなので耳が痛い…が、実際これは大事だと思っているので名前を覚える、あるいは間違えない工夫って大事だよなーと。
覚えるだけじゃなくて、ちゃんと名前で呼ぶことも大事。
心からほめる
人間は、誰でも周囲のものに認めてもらいたいと願っている。〜中略〜見え透いたお世辞は聞きたくないが、心からの賞賛に飢えているのだ。
お世辞を言えっていう話ではなく、「心から」ほめよう、という話。無理にほめる必要はない。
ただやっぱり褒められると嬉しい（本の中だと重要感が満たされる）し、その行動を強化する方向に動くことが多いので、小さいことでもどんどんほめる、って大事だよなーと。
ちなみに人を動かす、の中でほめることに言及しているパートが３個もある。このことからもほめるっていうのは大事なことなんだよというのが伝わってくる。
これも結構意識してやらないと、あとでFBしようとか思っていると絶対忘れるので、その場その場でイイと思ったらイイネをするのが大事。
誤りを指摘しない
フランクリンは次のように言っているー「私は人の意見に真っ向から反対したり、自分の意見を断定的に述べないことにした。決定的な意見を意味するような言葉、たとえば、"確かに"とか"疑いもなく"などという言葉を一切使わず、その代わりに『自分としてはこう思うのだが…』とか『私にはそう思えるのだが…』と言うことにした。相手が明らかに間違ったことを主張しても、すぐそれに反対し、相手の誤りを指摘することをやめた。そして、『なるほどそう言う場合もあるだろうが、しかしこの場合は、少し事情が違うように思われるのだが…』という具合に切り出すことにした。
自分自身は「お前バカじゃないの！？」とか、「それ不愉快だからやめてくれる？」とか、そんなことを言われたりしてきた過去があるのでダイレクトに言われても普通に受け止められるんですが、まあそれは例外。
誤りを指摘しない、というよりは、ダイレクトに間違いを指摘するのではなくて、相手に考えるきっかけを与えて、相手に自分で考えてもらうことが大事だよね、という話。
もちろん場面にもよるとは思っていて、緊急事態であればダイレクトに言う必要があるだろうし、typoの指摘だったり、あるいはティーチング中であればダイレクトに言ってもいいんじゃないかなーとは思ってる。
ただ相手が自分で考えて答えを出す、の方が本人の納得感も高いし、記憶に残ると言うか身に付く感じがするので、極力そちらの方がいいよねと。 （人を動かす、の他の話でも「相手自身に思いつかせる、考えさせる」はよく出てくるので、やはり大事と言うか効果的なんだと思う）
"イエス"と答えられる質問を選ぶ
人と話をする時、意見の異なる問題をはじめに取り上げてはならない。まず、意見が一致している問題からはじめ、それを絶えず協調しながら話を進める。互いに同一の目的に向かって努力しているのだと言うことを、相手に理解させるようにし、違いはただその方法だけだと強調するのである。
これ、今まで意識できていなかったのでこれからちゃんと意識してやってみようかなーと。
過去ベトナムとやりとりしていたときに近い経験があって、「お前のバグをどうにかしろ」ではなくて「我々が直面している問題を解決するために力を貸して欲しい」っていうコミュニケーションを取ると協力を得やすかったなーというのを思い出しました。
目的は同じで、その目的を達成するために一緒に協力してことに当たろう、という姿勢は大事。
ベトナムと日本、Biz側と開発側、リーダーとメンバー、色んなところで起きがちな対立を解消するのに役立ちそう。
遠回しに注意する
人を批判する際、まずほめておいて、次に"しかし"という言葉をはさんで、批判的なことを言い始める人が多い。〜中略〜ところが、"しかし"と言う言葉を聞いたとたん、今の褒め言葉が果たして本心だったのか疑いたくなる。結局は批判するための前置きに過ぎなかったように思えてくる。信頼感が鈍り、勉強に対するジョニーの態度を変えようとする狙いも失敗に転ずる。この失敗は"しかし"という言葉を"そして"に変えると、すぐに成功に転じる。
これ、自分も過去やってしまっていたなーと反省。
例えば、技術的には伸びてきた"けど"、他チームとの調整とかがもう一歩だね、とか言ってなかったかなーと。
それよりは、技術的なところは伸びてきて頼りにしてる。他チームとの調整も少しずつできるようになってきてるので、ここを来期伸ばせるとより技術が活きるようになっていいね。の方が、相手のやる気を掻き立てることができたのでは。
まとめ
この記事を書いてみて、本って一回読んだだけだと実はあまり意味がなくて、読んで実際にやってみて、その上でさらに読んで、を繰り返すことで内容が自分の血肉になっていくなーということをあらためて思いました。
あとはあれですね、チームに共有することでチームにいい影響があるといいな、というのと、共有することである意味、自分自身こういうことをやっていく！という宣言をすることになるので、普段に意識しやすくなる、と言う意味でもチーム会で共有する、はやってよかったなと思います。
Datadog Incidents を使ってみて雑感
こんにちわ、冒頭の書き出しに何をかこうか考えるのが一番時間がかる、id:gaoohです。
今回 Datadog Incidents を使ってみて思いのほかよかったのでその感想をまとめます。
そもそも、みなさん何でインシデント管理をしてますか。
よくあるパターンはタスク管理はきちんとされているけど、突発的なインシデント対応は管理されていない。 クライアントやユーザに報告のために履歴は必要に応じて記憶ベースでSlackをおってあとでまとめる。 その場でおもいつた改善策はタスク積んでおくけど、喉元過ぎれば忘れられ、棚卸しの際に「これなんのことだっけ。。。」 みたいなことになりがちではないでしょうか。
私はごめん、めっちゃよくやってた！
もちろんやることたくさんあるプロダクト開発においてすべて綺麗にできないのも事実で、実際やりきれないこともあります。 ただし中長期を考えるとこれらをおざなりにしてくことは大きな損失になりますし、できる基盤や組織をつくっていかねばなりません。
なので、現状VideoTouchではインシデント管理を monday.com でおこない、タスク管理と紐付けています。
インシデントの中身はちょっと隠していますが、以下のような感じでまとめてます。 数が多いのはなやみではありますが、だからこそ手を打っていかねばならないのです！！誰か助けて！
工夫している点としては紐付くタスクも「暫定対応」「恒久対応」「再発防止策」と分類し、きちんと最後の再発防止策まで手をつけられてるかぱっと見でわかるようにしています。また何が起因で立てられたタスクなのかを紐付けるようにしてます。
なかなか再発防止策まで手が回らないとい、とりあえずの絆創膏対応でおわってしまうのも実情なくはないですが、その実情も見える化できるメリットもあります。
また中長期での改善はなかなかすすめれらないので、これをベースの履歴として残して四半期ベースで振り返るようにしています。
現状の運用の課題
この運用によって最低限インシデント管理できているのですが、発生時に時系列でなにをしたのかの記録方法が人によってまちまちであとから振り返りにくいという課題がありました。
何をしたのかはリアルタイムではなかなか残せないので、後日別途notionでまとめています。 このあたりはユーザへの告知やビジネスサイドとの影響範囲の説明のためにも必要ですし、同日対応に参加できなかったメンバーへの共有も含めて、ある程度最初の一次対応がおわったらまとめるようにしています。
その際、何を残すのかがあいまいなので人によって概要はのこっているんだけど、ログやデータがのこっていないこともありました。 またデータも見やすさ重視で毎回スクショにとってはりつけたりしていて手間もかかってしまっていました。 もちろん何を残すのかを定義するという対策もありますが、そんな中お試しでDatadog Incidentsをつかってみたら課題を解決できそうで、かついろいろメリットが大きそうだったのでまとめてみました
Datadog Incidentsを使って感じたメリット
インシデント管理として残す情報のフォーマット化
「なにがおきたか」「インパクトは（影響範囲）」「なぜおきたか」 これがデフォルトのフォームとして用意されています。また追加でフィールドは足したり削ったりもできます
notion でもテンプレート機能を使えばできなくはないですが、履歴や更新タイミングなどふくめてすべて残るのは強い。
インシデント発生時のモニタリング情報を簡単にまとめられる
なにか障害が発生したときにDatadog上の情報をみて状況を把握していくということをやるわけですが、「どこをどうみてどう判断したか？」 というのは正しく切り分けをする際に非常に大事ですし、ここは人によって知識差がでやすいのでなるべくチームに共有していうべき情報だと思います。
それが正しく行えないとわかりやすくインフラ周りが属人化していきます。
かといってこの辺は職人芸的な部分も含まれていて、一緒にハイスキルの人とアラート対応をして師弟関係的に伝授していく部分も多いです。
その間をなんとか埋めていきたいと考えたときに、誰もまだ対応していない障害に対しての瞬発力的なものは、実際の対応を経験して培いながら、既に一度対応したものは誰でも対応できる状況にするというのが一番の近道です。 一度やったことに関したは先駆者たちが作った道があるので、その道にそって調べていけばいいことも多いわけですし。
なので「どこをどうみてどう判断したか？」は過去を先駆者たちの動きを学ぶためにも非常に大事な資産なのですが、障害対応をしながら、それらを残すためにはなかなか難しい。かといってあとから思い出して整理するのは腰が重いですしね。
これらの課題に対して、Datadog上でサーバのモニタリングをしている場合、そのモニタリング情報をインシデントのタイムラインに追加するのことがさくっとできちゃいます。
よい！
表示しているグラフからワンクリックでできるので手間がないため、対応しながら追加していくのも慣れてしまえばそこまで苦ではないはず！ ただ追加するのが苦でなかったとしても、追加するのを忘れるのはありえるので、そのあたりは場数を踏みながら慣れるしかないでしょう。
Slack 連携
インシデントについて特定のチャンネルに通知するのはもちろん、インシデントごとにチャンネルをわけて対応することも可能です。 今のViibarの規模だと1つのチャンネルで完結しちゃってますがサービスの規模が大きくなったり、チームの規模が大きくなった際でも便利そう
まとめ
まだ使い切れていない機能も多いですし、試しにやってみたところで本格的な活用はこれからですが、大枠よさそうなので今後活用してければとおもってます。
インシデント管理は胃が痛くなりますが、サービスが成長していく中でうまれるプロダクトの技術的な課題や運用課題を中長期的な目線でみながらあーでもないこーでもないと考えて解決していくことって独特の楽しさですよね！
ではでは！
転職ドラフトで27社から指名をもらった中で、Viibar に入社した理由
どうも、 id:sawarabi です。 昨年の2月ごろから業務委託のエンジニアとして Viibar に JOIN し、11月に正社員として JOIN しました。
11月に転職するにあたり転職ドラフトでなんと27社から指名をもらったのですが、その中でなんで Viibar に入ったの？というところを書いていこうと思います。
3行でまとめると
- 価値観が合うから（ミッションビジョン、中で働く人のキャラクターなど）
- 人、組織の成長に投資を惜しまないから
- 我慢強かったから
詳しく
今回の転職活動は以下のような流れで進みました。
- 在職中に転職ドラフトに参加する
- 転職ドラフトで27社から指名をいただく
- 27社と（在職中の2週間で）カジュアル面談をおこなう
- 軸と合いそうな8社に絞って面接に進む
- 並行して業務委託として働いていた Viibar とも話をする
- 最終的に Viibar 含む3社から内定をいただく
本当はカジュアル面談のタイミングは有休消化に入っているはずだったんですが、最後にこれやってーというのを断りきれずに、終業後や昼休みを利用しての連続カジュアル面談というカオスな感じに。
最終的に幸運なことに3社から内定をいただくことができたのですが、どこもいい企業だったのでどこに入社するか、は本当に迷いました。
コピーロボットがいたら全部に入社できるのにーとか、でも本人は家でゲームかなとか、そんなことを考えたりとか。
まあ現実的に一社に絞り込まないといけないよね、というところで、以下の基準で改めて熟考。
この基準は転職活動初期からある程度考えていたものの、転職活動の中でより言語化されていい感じになったものになります。
- 環境：ライフワークバランス、年収、テレワークなど
- 軸：自分が大事にしたい価値観、今回の転職で達成したいこと
- リスク：そもそも三年後に会社が残っているか、プロダクトが成功しそうか、など
比重としては、
- 環境：10%
- 軸：70%
- リスク：20%
という感じ。
幸か不幸か独身で養うものは自分と猫くらいなので、あまり年収などにはこだわらず、リスクも取れるよねということで、自分の軸にマッチするかどうか、を重めにみていました。
で、その基準で考えたときに Viibar がどうだったかというと、こんな感じでした。
環境
- 年収はシンプルに上がる（ここは他の2社も同じ）
- テレワークが「選べる」（出社してもいいし、しなくてもいい）
- ワークライフバランスも良さげ（業務委託としてSlack見ていて、全体的に残業少ない印象だったり、休みが取りやすい印象だったり）
軸
ここはちょっとボリュームあるので、少し細かめに。
価値観が合うこと（ミッションビジョン、中で働く人のキャラクターなど）
この辺は、半年くらい業務委託として一緒に働いてみて、また2か月くらい MTG などに出まくって、合うなーと感じました。
印象としては、素直な人が多い、という感じ。
Biz 側、エンジニア側、ともにコミュニケーションは楽というか、変に疲れるとかはないかなーという印象でした。
人、組織の成長に投資を惜しまない
Viibar では外部からスクラムマスタを入れて、組織としてスクラムを勉強、身に付けようとしています。
スクラム導入は最近多いのですが、ちゃんとお金を払って、メンバーの時間も投資してしっかりとそこをやっていこうという企業は珍しいなーという印象でした。
また、その流れでスクラムマスタの研修受けたいといったら、あっさりOKがもらえました（自分に余裕がなくて忘れてましたが、そろそろ受けよう…）。
書籍購入制度もあります（最近どこもやってる気はするけども）。
業務委託として参加していたときに学んだスクラムやチームビルディングの話とか、Viibar での経験が既に他社の面接で活きた、ということもありました。
他社の面接で Viibar の志望度が上がるという謎現象があったり。
結構これが自分としては大きかった気がします。
プロダクト作りに関われる
開発は開発だけやっていればいい、ではなくて、Biz 側、エンジニア含めて全員でプロダクトを作っていくんだ！という意識を MTG に参加していると感じました。
実際 Viibar では、スプリントレビューで実際のお客様を巻き込んで新機能のレビューなどをおこなっていてそこにエンジニアもがっつり関わっていますし。
自分自身は開発だけしていたい、ではなくて、ビジネスにもしっかり関わっていきたいタイプなので、惹かれたポイントの一つでした。
チーム作りの本当に初期の段階から関われる
ある程度の規模の企業だと既に人が居て、その人たちとどうやっていくか、という話になります。
一方、Viibar （というか VideoTouch）ではまだ人が少ないので、どういう人が欲しいか、を考えて採用するところから関与できます。
あとチーム作りについても勉強会をやってたりとか、勉強して、かつ実践しやすい環境が整っているのもポイントでした。
（組織的に）我慢強い
副業探す際に転職ドラフトで6社からオファーもらったんですが、Viibar 以外は「いつ正社員で来れる？」とか、急かす感じが強かったんですよね。
そもそも業務委託のみで、転職は考えてないことを明記してたんですが…。
そんな中、Viibar だけがその辺の話を全くせずに話をしてくれたんですね。
また実際に週一で業務委託として働き始めてからも、Viibar からはその話（正社員云々）は出してこなかったです。
いい意味で我慢強い組織だと思いますし、ちゃんとこちらのことを考えてくれているなーというのが伝わってきたのも入社を決めた理由の一つだった気がします。
リスク
スタートアップというところもあり、当然リスクはあります。
どんなに年収があがろうと、貴重な経験ができそうであろうと、入社して１ヶ月で会社が潰れたら何にもならないですしね。
じゃあ Viibar はどうだったかというと、
スケールするかどうか
当然ですが、スケールするかどうかは賭けの部分もありますよね。
例えば自分は将来的なキャリアパスとして EM、VPoE を目指しているのですが、スケールしなかった場合マネジメント対象のメンバーが増えないので、経験も積めません。
なので、下手したら怒らせて内定がもらえないかも…、という覚悟で色々突っ込んだことも聞いたのですが、怒らずにちゃんと答えてくれました。
で、その上で自分は自分が JOIN するプロダクトである VideoTouch がスケールすると判断したので JOIN した、となります。
その際、自分は業務委託として既に半年以上 JOIN していたので結構バイアスかかってるよなーと思い、人と壁打ちしたりして極力客観的に判断できるように工夫したりしました。
30代という働き盛り真っ盛りの貴重な時間を数年分投資することになるので、なんなら今持っている全財産この会社に投資しても後悔しないか、くらいの勢いで考えた結果の判断です。
（プロダクトとして）整っていない部分が多い
スタートアップといいつつ Viibar は少し事情が違っていて、設立は2013年と既に結構長く続いている会社だったりします。
なので、スタートアップでありがちな環境がガチで整っていない、ということはなく、例えば PC の手配だったり社内システムや環境だったりは既に整っている状態となります。
一方で、VideoTouch というプロダクトでいうとまだまだ整っていない部分が多い状態です。
じゃあそれって悪いことだっけ？でいうと、自分のやりたいことと「整っていない＝これから求められること」がマッチしていたので、やりたいことができる（しかもやったら喜んでもらえる）と言う意味で、自分にとって美味しい状況だなーと思いました。
ただ整っていない部分に自分がストレスを感じたり、やりたいこととアンマッチだったりすると辛いので、そこは一つリスクかなーと思ってチェックしていました。
最後に
そんなこんなで、自分は Viibar に入社を決めました、という話になります。
当時のメモを割とそのままに書いているので自分の考えが結構ダイレクトに書いてあったりでちょっと恥ずかしかったりもしますが…。
転職の際の判断軸というところで少しでもご参考になれば幸いです。
GitHubでよく使っている機能まとめ
Viibarのエンジニアの id:mstssk です。
Viibarの開発部では、発表者を持ち回りにして好き勝手なことを発表しあう社内勉強会をやっています。
発表内容は本当に好き勝手でよく、初めて発表担当が回ってきたときは延々Splatoonの話をしたりしたんですが、今回は「もっとみんなGitHub使いこなそうぜ」という内容にしました。
※この記事はZennにも投稿しています。
id:mstssk がGitHubを使うにあたって日常的に使っている機能などなどです。 社内勉強会のために書き出したものをちょっとだけ清書して投稿しています。
定期的に確認するページ
| ページ | URL |
|---|---|
| 通知 | https://github.com/notifications |
| レビュー依頼 | https://github.com/pulls/review-requested |
| 自分が担当のIssue,PR | https://github.com/pulls/assigned |
| 自分へのmention | https://github.com/pulls/mentioned |
ただし、仕事では特定のOrganizationだけにスコープを絞りたいので、次のようなURLをブックマークして使ってます。
https://github.com/pulls?q=is%3Aopen+user%3AViibar+assignee%3Amstssk
Pull Request の Draft 機能
PRをDraftにしておくことで作業中であることを明確にできます。
Draft機能ができる前はPRのタイトルに [WIP] と入れたりしていました。
ただし、DraftのPRでもレビュアー設定をしたら、レビュアー設定された人に通知が飛びます。 不必要にノイズを飛ばさないよう、レビューできる状態になってからレビュアーは設定しましょう。
自分をアサインする
機能というか習慣です。
https://github.com/pulls/assigned のページを活用して自分が現在携わっているものを一覧しやすくするためにも、作業中のIssueやPRには基本的にちゃんと自分をアサインするべきです。
アサインするのを忘れがちなのなら、 https://github.com/apps/auto-assign のような自動でアサインするBotを使ってもいいです。
PRをレビュー依頼を出す前にrebaseする
これも習慣やお作法の類です。 トピックブランチで作業している間にベースブランチが進んでいるとかはよくある話なので、動作確認してレビュー依頼出す直前にrebaseしておきましょう。
$ git fetch $ git rebase origin/master topic $ git push origin topic --force-with-lease
Permalink
GitHubリポジトリ上のファイルの特定の箇所を指し示す時、そのブランチの変更に関わらず一定になるPermalinkを使いましょう。
- 🙅: https://github.com/mstssk/rollup-plugin-cleandir/blob/master/index.ts#L4
- 🙆: https://github.com/mstssk/rollup-plugin-cleandir/blob/04506eb3e1ac2336a4e7f35dc1bfe0be622ee0e7/index.ts#L4
タグの場合ならこういうURL https://github.com/mstssk/rollup-plugin-cleandir/blob/v1.0.0/index.ts#L4
Blameしながら親コミットをたどる
Blameの画面で、そのコミットが適用される前のコミットに移動するリンクがあります。 どういう経緯で変更が行われたのか参照するときに便利です。
ただし、コミットログが雑にされている場合もあり、どちらかというと次のコミットからPRをたどる方法の方をよく使ったりします。
コミットが所属するPRを参照する
各コミットのページには、そのコミットが含まれているブランチやタグ、PRへのリンクがあります。 このリンクからPRを見に行く事で、どういう目的で手が加えられたか参照できます。 私が所属するプロジェクトでは、コミットログについてはあまり口を出さないが、すくなくともPRではどういう目的の実装なのか書いていたり関連するIssue Trackerへのリンクが貼られているかもレビュー時にチェックすることで、最低限は実装の由来を将来辿れるようにしている事が多いです。
Organizationごとに別のメールアドレスに通知する
仕事用とプライベートとでGitHubアカウントを分けていない場合、仕事のOrganizationのリポジトリに関連する通知がプライベートのメールアドレスに届いても困ります。
GitHubは所属しているOrganization別に通知先メールアドレスを切り替える事ができます。 仕事用のメールアドレスをGitHubアカウントに追加して、会社のOrganizationだけ仕事用のメールアドレスに切り替えておきましょう。
2FAはアクセストークンをパスワード代わりにするよりSSH keyで
GitHub アカウントを2FAにしておくと、リポジトリにpushする時にパスワードを求められたりしてびっくりしたりしつつアクセストークンを設定したりしたものですが、今はマシン別にSSHキーを準備して済ませています。
リポジトリをcloneするときもSSH形式で行っておくとスムーズです。
トークン使う方法でも同じくらいシンプルにできるかもしれませんが、自分はSSH keyで済ませるほうがしっくりきたので。
Security Alerts
依存関係の脆弱性アラートとDependabotの自動バージョンアップPR作成は有効にしておきましょう。
依存の依存の依存パッケージに脆弱性アラートが上がったときなんかは複雑すぎてDependabotがエラーになってたりしますが。
GitHubリポジトリのwatch
リポジトリ内のファイル名で検索
あれ？あそこどうなってたっけ？と思った時に手元でIDE立ち上げるより、GitHubリポジトリ上でファイル名で検索したほうが早いこともあります。
「Go to file」ボタンでもいいですが、 t でショートカット起動を覚えておくと楽です。
他のショートカットなどはこちら。
Schedules reminders
https://github.com/settings/reminders/
SlackとGitHubを連携させておくと、チームのチャンネルに通知したりもできますが、個人用にスケジュールを決めたリマインダーも設定できます。
id:mstssk の場合は、毎日特定の時間にチームのチャンネルにレビュー待ちなどの通知がくるのとは別に、レビュー依頼が出されたらリアルタイムで通知してくれるようにもしています。
PRのレビュー時の便利機能
☑️ Viewed
レビュー対象のファイルが多い場合に特に使います。 ☑するとそのファイルが折りたたまれてくれるので、他のファイルの確認に集中できます。
Hide whitespace changes
空白のdiffを無視して表示してくれます。
インデントが変わってるだけなど、不必要なdiffを無視してレビューできます。
昔から隠し機能としてURLに ?w=1 を付けるとwhitespaceのignoreができたのですが、あるタイミングでちゃんと機能としてUIに搭載されました。
Suggested changes
レビューで具体例を挙げてこう直すといいよ、と伝える場合に使える機能です。 ちょっとしたtypoの指摘などにも使えます。 レビュイーはそのまま取り込むことも出来ます。 あくまでPRとして出されたdiffの中でしか使えないので、周辺のコードも含んだ大きめの変更指摘なんかには使えません。
GitHub外の機能
Octotree https://www.octotree.io/
現在開いているリポジトリ・ブランチの内容をツリー表示してくれます。 特定のファイルを見たいわけでなく、上からたどって探したいときなんかに重宝します。
