sister team に join したきっかけと SRE としての取り組み

こんにちは。sister で SRE(Site Reliability Engineer) としてお手伝いしている chaspy です。

本記事では僕が sister team に join する経緯、そして僕が専門としている SRE の分野でどのように貢献したかの技術的な側面を説明します。

sister 利用対象ユーザーである IT 業界の女性にとってはサービスを知ってもらうきっかけに、小規模のサイトを運営している人にとってはサイト信頼性をどのように考えれば良いかヒントを得てもらえればと思います。

サービスオーナーのだむはさんとは、女性エンジニアのキャリアストーリーをまとめたサイト womaneng.jp を立ち上げた際に、記事を掲載する経緯で知り合いました。

もともと、僕個人が Software Engineer として働く中で、この業界に貢献できることを探していて、ジェンダーギャップに関する根深い問題に対して、（理系・Computer Science 専攻・大学院卒・男性という、属性だけ見れば）圧倒的マジョリティである自分にできることは何か、と考えたときに、やれることとして手を動かしたのが womeneng.jp でした。

だむはさんがやっている sister もまた、この問題に対しての打ち手としてのサービスでした。何かしらの形で応援できたらいいなと思っていた矢先に、セキュリティについて悩んでいた様子だったので、リプライをしつつ、セキュリティ面含めてリファクタリング、テストコード、パフォーマンス、セキュリティ、CI/CD など自分が得意とする領域で貢献できないか？ということを DM で打診したら、ぜひということで受け入れてもらえました。

こういった業界のジェンダーギャップに対する問題に対して自分ができることをやりたい、というモチベーションも半分はあるのですが、もう半分は、こういう個人開発のような小規模のフェーズで自分のスキルや専門性がどれほど役に立つのか確かめてみたかったという興味でした。

sister は業界マイノリティである「女性」のためのスキルシェアサービスです。

『sister』は女性のロールモデルが少ないIT・Web業界に特化した女性向け(自認も含む)キャリア/スキルシェアサービスです。

その運営・開発に業界マジョリティの男性である自分がいることが、ユーザーにとって悪い影響を及ぼさないか？ということが気になって、公表すべきか悩んだ時期がありました。

一方で、この問題は女性だけで考えていてはダメだとも考えています。最終的に「女性エンジニア」という言葉が使われなくなる世界を目指すためには、女性以外の全ての人がこの問題を考える必要があるでしょう。マイノリティにとって声が出しづらい、話せる人が少ない現状を打破するために一時的な（過渡期としての）措置として女性専用コミュニティ・イベントのようなゾーニングは確実に必要です。その状況を超えて理想的な世界を目指すには、この問題を考える男性を増やす必要があるはず。自分が関わることを公表することで、小さくても状況を変えるきっかけになるのではないかと考えました。

だむはさんにもこの懸念を打ち明けたときにも、ポジティブな反応をもらえたので、（結局表立ってアウトプットをするのは今回がはじめてではあるんですが...）公開することにしました。

さて、ここまでは僕が sister に関わることになったきっかけを話しました。ここからは具体的な貢献内容について話します。Site Reliability Engineering（あるいはそれをロールとする人を指す Site Reliability Engineer）とは何なのでしょうか。

1行で言うと「Google が提唱した、"サイト信頼性"をコントロールするために、従来のシステム運用業務を Software Engineer によって組織とシステムをスケーラブルにする技法・ロール」のことです。よくわかりませんね。

本当に知りたいひとはいろいろ調べてもらえばと思いますが、「システムを当たり前に使えるようにする」ために何でもやる人、みたいな感じの解釈でもいったん大丈夫です。

さて、sister が「当たり前に」使えるためには一体何を考えて、何を行えば良いのでしょうか。どこに貢献の余地があったのでしょうか。

Repository を check out して、First Contribution を終えたあと、ざっくり最初に取り組んでいく内容を考えました。書いた当時の Issue をそのままはってみます。

SRE は「システムが当たり前に（ユーザーの期待通りに）使える」状態を目指すと言いました。直接的には「セキュリティインシデントを起こさない」「応答速度やシステムエラー率を低く抑える」ことが思い浮かびますが、現実はここに手をつける前にやるべきことがたくさんありました。

Security や Performance、Availability といった品質特性は非機能要件です。しかしこれらは機能開発をやっているだけでは向上しないどころか、機能開発をすることによって引き起こしてしまうことでもあります。（わかりやすい例で言うと、コードに何も変更しなければエラーは発生しませんし、何か変更するからこそバグを産んでしまう可能性が増える）

しかし、機能開発を行わなければユーザに新たな価値を提供することはできません。そこで、非機能要件の改善を行う前に、まずは機能開発を安心して行える、言い換えると、以下のようなことができる状態を目指したいと考えました。

• 修正ミスを本番環境に出す前に気付けるようにする
• 本番で修正ミスが起きてもすぐ気づくことができる
• 本番で修正ミスが起きた場合、その原因を調査可能にする
• 本番で修正ミスが起きた場合、その修正をなるべく早くリリースできる

これらを実現するために、「Testing」「Observability」「Developer Productivity」という領域に注力することにしました。

このように、「SRE」どこからやっていくかを考える上で、それが1人で作った個人開発サービスであれど、適用できる順番・ラダーのようなものはあると考えています。以下は今ラフに書き下ろしたものですが、そこまで外してはないのではないかと思います。

1.立ち上げ時期（sister はここ）

• Developer Productivity (Local Development)
• CI/CD (UnitTest, Release Engineering)
• Observability (Monitoring, Logging, Tracing)

2.本番運用まで（チーム規模〜10人）

• Continuous Security Update(Dependabot, Renovate)
• Performance Improvement
• Data Protection

3.本番運用開始〜拡大時期（〜50人）

• Service Level Indicator / Objectives の策定
• Incident Response
• QA / E2E Automation
• Performance Measurement

現実はそれぞれの要素を行ったり来たりして個別の問題を解決していくわけですが、少なくとも 1 と 2 の範囲は最低限やっておかないと安心してユーザにサービスを使ってもらえませんし、価値を届ける機能開発を満足に行うことも難しいでしょう。

「SRE」といえば「SLI/SLO」がコアコンセプトとしてあげられますが、実際そこに行き着くまでにはたくさんやるべきことがあると思います。それを実体験とともに確認できた良い経験になりました。

課題は本当にたくさんあります。ライブラリアップデートも最新に追随できているとは言えませんし、それを安心して行うためのテストコードもまだ足りていません。コードカバレッジも見えるようにしたいですし、リファクタリングをしたほうが良いところもたくさんあります。パフォーマンスも気になるところがいくつか残っていますし、アーキテクチャを変更したほうが良い部分も見つかっています。

さらにこれらシステム運用的な側面だけでなく、「プロダクト」的に考えてサービスを成長させていくことも必要だと感じています。具体的には本番環境のユーザの挙動をきちんと計測し、仮説を立てて、数値を追いかけて改善していくというアプローチができているとは言えません。

僕は sister が　IT 業界のジェンダーギャップの問題を少しずつ解消していけるポテンシャルのあるサービスだと信じています。今後も微力ながらあらゆる面で貢献していきたいと考えています。

本記事では業界マジョリティである僕がなぜ sister に関わることになったのか、そのきっかけと、僕の専門である SRE を個人開発規模の sister においてどう適用していったのかを説明しました。

sister ではユーザー、特にメンターになってくれるお姉さん役を募集しています。あなたの経験は必ず誰かにとって役に立つはずです。とはいってもどのようにメンタリング・コーチングすれば良いかわからない、自分が何を話せるかわからない、お金をもらえることができるかわからない、と不安に思う方もいると思います。そういう方はユーザーコミュニティ Slack に入ってください。運営チームやすでにメンターをやっている仲間がサポートします。