エイプリルフールのいつものやつではありません。
今年の3月に株式会社はてなにSREとして入社して3か月が経ったので、自身の振り返りも兼ねてブログを書いています。 SREのオンボーディングの雰囲気に関しても、このブログでお伝えできるといいかなと思っています。
自己紹介
id:taxintt前職は株式会社ビザスクという会社で主にCore SREとして働いていて、はてなに転職してからは監視SaaSのMackerelの開発チ－ムでEmbedded SREとして働いています。 前職ではGCPを利用していて、AWSは趣味で少し触る程度でキャッチアップが必要だったので、そのあたりから振り返りを始めてみようと思います。
ちなみに、はてなのプロダクトごとの技術スタックは下記のペ－ジを見ると雰囲気を掴んでもらえるかと思います。
入社前
入社前にはAWSコンテナ設計・構築[本格]入門を読みつつ、ハンズオンの中で構築するサンプルアプリケーション用のAWS環境をTerraformで書き直していました。 環境はECS on Fargateの構成でECRやCodeDeploy含め関連するAWSのサービスを幅広く利用するので、AWSのコンテナ環境周りのキャッチアップにはちょうど良かった印象があります。
AWS周りの知識のキャッチアップに関しては、この本にだいぶ助けられました。
あとは、前職ではMySQLだったのでPostgreSQLのキャッチアップをしたり、SREとしての業務の中で比較的初期に触りそうな技術に慣れておくように動いていました。
入社後も引き続きキャッチアップは進めていますが、立ち上がりの時期に学習コストを最小限にできたのは良かったと思います。
入社後
入社後は、 Mackerel チームのスクラムイベントに参加しつつ、SRE用のオンボーディングタスクを割り当ててもらいました。 前職でスクラムの経験はあったのでなんとなくの雰囲気はイメージしてましたが、スプリントプランニングなどのイベントの進め方やコミュニケーションのスタイルの違いに慣れる必要がありました。
入社直後の立ち上がり時期には、AWSなど比較的慣れている技術を使って仕事をしながらスプリントでの仕事のリズムを作って、慣れてくると目の前の仕事により集中できるようになると考えていて、そのように動いていた記憶があります。
Mackerel開発チームでの仕事の雰囲気は 
id:lufiabb さんのブログも参考になると思うのでぜひどうぞ。
developer.hatenastaff.com
スプリントの中ではPWG (Performance Working Group)と呼ばれる会も開催されており、アプリケーションエンジニアやSREsを含めた開発チーム全体でSLOの準拠状況や最近のパフォーマンス状況を確認する機会もあります。
いわゆるアプリ/インフラという区分ではなく、開発チーム全体でプロダクトとしての信頼性について確認・議論する機会があるのは印象的でした。
PWGに関しては下記のブログ(2015年)にも詳細がありますが、PWGの主旨は変わっていないように感じます。
また、サービス開発チームを横断する形で社内のSREsが集まるSRE標準化委員会もあり、チームを跨いでSRE文脈で社内の技術標準を整備する機会もあります。 SRE標準化委員会の詳細に関しては、下記のpodcastのエピソードでも語られています。
日々の過ごし方に関してもう少し話すと、MackerelのSREsとは同期的に会話する時間を入社直後から設けてもらっているので、不安なく仕事ができています。 京都に本社オフィスがあり、対面で会話する機会が多くない点は気にしていた部分でしたが、入社後もSREs含めた開発チームと心理的な距離を感じることもなかったです。
この部分の不安が解消されていたのはオンボーディング期間において大きかったと思います。 不安をそこまで感じなかった背景として、Slackでのテキストコミュニケーションが活発に行われていることも要因の一つとしてありそうです。
開発チームにjoinした後も、開発チームのメンバーから声かけしてもらいPWGの書記をやるなどできることの範囲を広げたり、SRE標準化委員会といったチームの枠を超えたコミュニケーションの機会を提供してもらったりと適度にストレッチ目標を置きつつ仕事をさせてもらっていると実感しています。
オンボーディングしぐさ
同期的なコミュニケーションの機会について触れましたが、メリットは他にもあって、タスクの進め方や技術課題に対する捉え方・優先度、物事に対する期待値をすり合わせる機会を作れたことです。 このあたりから、オンボーディング時に自分が心がけていたことも少し書いてみます。
オンボーディングの内容に関してはこちらが参考になります。 developer.hatenastaff.com
今何をやっているか、何で詰まっているかや疑問点をテキストで残して、デイリーで会話することは一番重視していました。 これは、Working out loudの実践がベースにあって、特にリモート下においては作業状況や思考のプロセスが見えづらいし非対称性が発生するので、気持ち多めくらいでテキストとして残すようにしています。 blog.studysapuri.jp
他には、Pull RequestのDescriptionには修正内容やその背景・意図を書くようにするし、ReviewerとしてPRレビューをする際には確認した内容をコメントで残したりしています。
この行動にはもう一つの意味があって、私は転職に伴い利用する技術スタックが大きく変わったので、各種サービスの仕様について理解した内容を示す意味でもやっています。
「私が適切に理解していない」ことを指摘してもらうためには、「私はxxxだと理解しています」と開示することが一番手っ取り早いのではないかなと。
上記とは別に、技術課題に対する捉え方・優先度、物事に対する期待値など機微のある事項は同期的なコミュニケーションの中で会話するようにしていました。 社内のドキュメントなどから把握できるケースもあると思いますが、自分で自信を持って判断できないうちは会話する方に倒しています。
もう一つ、オンボーディング期間中に先述の通り開発チームの他メンバーから声かけしてもらいできることの範囲を広げたり、タスクを自発的に拾うことで小さな成功体験を重ねるようにすることも心がけていました。 注意点があるとすれば、技術課題に対する優先度は認識しておいた方がベターだと思います。 SREsひいては開発チームにおける貢献の意味合いでの成功体験を重ねるとして、技術課題に対するチームとしての優先度とずれて貢献度合いが下がってしまうのは双方にとって勿体無いからです。
成功体験は開発チームで仕事していくことに対する自信にもつながるので、オンボーディングで受け入れられる側としても意識しつつ3ヶ月を過ごしていました。
オンボーディングにおける小さい成功体験を重ねる話は 
id:onk さんのブログにも書いてある3ヶ月で3連勝がイメージしやすいと思います。
onk.hatenablog.jp
自分がチームでやっていけそうという感覚を手に入れるために、できるだけ短期間で成功体験を積んで貰いたい。更に単発じゃなくて3連発で成功すると「このチームで良かった！」と思えるんじゃないか。そのためにチームがちゃんと応援する。オンボーディングタスクに対して、チームメイトが積極的に関与していく状態でありたい。
最後に
3ヶ月経っても日々キャッチアップ中ですが、少しづつ行動の幅を広げて開発チーム・プロダクトの成長・改善も考えて行動していく所存です。
また、このブログではてな入社後のオンボーディングの雰囲気が少しでも伝わっていると嬉しいなと思います。
宣伝
というわけで、無事に3ヶ月経過しましたという話でブログ自体は終わりなのですが
ここまで読んでいただいている方は多少なりとも、はてなのSREに興味を持ってくださっている方だと思います。そうですよね? ね?
そんな皆様のために、はてなのSREが何をやっているのかがわかる便利リンクを貼っておきます。
カジュアル面談もご興味があればぜひ申し込んでみてください。 技術的な話や、他のSREsの働き方に関して本記事に書いてある内容より深い内容や違った話が聞けると思います。
