ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

SRE NEXT 2023 で登壇した #srenext

してきました。楽しかったー。

sre-next.dev

登壇後記

実はプロポーザル募集が始まった8月頃、登壇へのモチベーションは枯渇していました。というのも(自分のスライド作成の技術が向上していないとも言えるのだが)準備の時間が割りに合わないと感じていたからです。これは今後再開するときは再度見直したいところ...。本業もあって、家庭の時間も必要で、健康維持の時間も必要で、可処分時間をどう投資するかをいい年なので色々考えると、登壇は”しばらくやめる”ということにしました。楽しさも知っているし、実際 SRE NEXT 終わったあとはすごくいい気持ちだったので、登壇は麻薬やな... などと思いました。

(業務として登壇するのだから)業務時間でやればいいじゃん、と言うのは簡単だしごもっともであるし、自分も所属メンバーにはそう言います。ただ、業務と登壇資料作成どちらが大事かなんて比べられないわけで、結局”業務を捨てる"ことができなかった自分は単に労働時間が膨らむ形になってしまっていました。

とのっけからネガティブな感じになってしまったんですが、そんな後ろ向きな状態でも SRE NEXT のプロポーザルは気がついたら書き始めていました。僕にとって思い出深く、大切な大切なカンファレンス。もしプロポーザル落ちたらそのときはそのとき、新しい世代へバトンタッチだな、通ったのなら、まだ自分に共有できることがあるな、と思い出しました。

プロポーザルの段階でかなり濃いめのアウトラインを書いていたので登壇自体は楽でした。今後出す人の参考に現物を記事の最後に晒しておきますね。

この登壇内容は、僕が2年間 SRE チームのマネージャとして過ごした期間の集大成のようなものでした。SLI/SLO として信頼性を開発チームで観測していく世界についてはある程度は僕がマネージャになる前から根付いていました。今でこそ Platform Engineering の認知が高まっていますが、我々も以前より信頼性と開発生産性、両方で開発チームをサポートするために Enabling / Platform Engineering 両面に取り組んでいました。

ここで語られなかったこともたくさんやりますが、僕が最も重要視し、注力したのが「開発チームからうまくフィードバックを得る」ことでした。Enabling だろうが Platform だろうが開発者の声を聞き、自分たちで何をやるかを決め、その結果を計測・観察し、次の計画につなげる。言葉にすれば当たり前に聞こえてしまうのですが、僕たちにとっては新しい挑戦でした。

そしてこれらの活動がうまくいったのは単なる方法論 / プラクティスがうまくいっただけではないことはわかっていました。簡単に真似ができない、だからこそみんな苦労している。だからその土台となる組織文化に着目し、考察した発表にまとめました。

結果として登壇内容で語られたことはほぼ全て所属メンバーの高い技術力とソフトスキルによってなされたものです。こういったものを僕の口で発表することは最初は抵抗あったのですが、所属組織の成果を代弁するのは何ら変なことではなかろう、マネジメントの成果の出し方の1つであろうと言い聞かせて話していました。

結果多くの方に来場いただき、感想を残していただき、ありがとうございました。当日の Twitter も、ブログで言及していただいているものも全て目を通しております。

本当にこの気持ちです。

懇親会も楽しかったです。アツい思いをぶつけてくれた VTRyo さん、お久しぶりの Nari さん、廊下で会って懇親会でもキャリアや業務について語れた t-jun さん、登壇後よりご一緒させてもらえた @yuta_k0911 さん、いつも仲良くしてくれている @donm_ri さん @a0i さん、全然暇ですよ!などと供述していた katsuhisa さん(安心感ある)グロービス _yukin01 さん、リアルでは久しぶり minamijoyo さん、その他懇親会で同じテーブルでお話しした皆さんありがとうございました!またどこかで会いましょう。

カンファレンススタッフとして room B を担当いただいた taxin_tt さん、shotaTsuge さん(ご近所!)ほか全てのスタッフの皆さん、本当にありがとうございました!

これから

登壇をやり切ったおかげでバチっと切り替えて 10/1 から新しい責務をやっております。

SRE のプレイヤーもマネージャも引退した後どうするのか、というのは以下の記事に書いたとおり、開発部長をやっております。部長なんて照れくさい、Senior EM だ!といってたけどなんやかんや社内呼称というのは強いもので、"部長"の自認も高まってきました。

blog.chaspy.me

社内 Public になってから1ヶ月、正式任用から1週間経った。忙しすぎて死ぬ、みたいなことは特段なく、順調に(?)職責変更と、責務を果たすために下準備を行なっています。

基本的には担当領域について、エンジニアリングを経営に接続することが責務だと思っている。(実際に数値責任を持つではなく、あくまで"接続"(橋渡し)が責務である)

この1ヶ月はとにかくいろんな人と話しまくっている。隣接の部署、あるいは新しくマネジメント対象になるメンバーと。新しい人と、自分にとって新しいことを知るのはとっても面白い体験で、そういう意味ではこのロール変更は自分に向いている面もあると思った。

ひとまずこれまで関与してこなかった会計用語の習得と、事業の現状を把握し、その現状に対して開発組織として貢献できることを探し、それを組織戦略、技術戦略に落とし込む、というのを直近やっている。あと FinOps は関係者と会話し進め始めている。開発生産性の経営への接続も、仕込みをちょっとずつやっている。

見るべき範囲が増え、変数が増え、これまで以上に緊張感は増すが、まずは半年、しっかり走りきろうと思います。

引き続きいろんな人とお話ししたいです!オンラインでもオフラインでも、声かけてください!


おまけ:出したプロポーザル


タイトル
開発者とともに作る Site Reliability Engineering

発表概要
SRE の実現には、SRE という Role を持つ人だけでは成し遂げられません。プロダクト開発を行う組織の場合、プロダクト開発者と緊密な連携が必須です。その場合、SRE Team がいかにプロダクト開発者の直面する課題をどれだけ深く理解し、その要求を適切に定義できるかが鍵となります。

開発チームの要求を理解するためには以下の3種類のアプローチが有効です。
直接のフィードバックを受け入れる
継続的にコラボレーションする
実際の現場を体験し、開発者の立場を理解する

そしてこれらを実現するためにはマネジメント上の工夫だけではなく、オープンで避難のないコミュニケーションや、定期的なふりかえり、そして適切なフィードバックを行うといった組織文化が必要不可欠です。

本セッションではこれらのアプローチの具体的な実践例と、それを支える組織文化に関する実例を詳しく紹介します。SRE チームと開発チームの両方のマネージャを経験を持つ私の独自の視点を通じて、プロダクト開発組織全体で SRE を効果的に実践するヒントを持ち帰っていただければと思います。

聞いた人が得られるもの
SRE チームが実現すべきことを開発者から得る方法
SRE チームとプロダクト開発者のコラボレーションを支える組織文化の作り方

発表の詳細
アウトラインです。

Google Docsに貼り付けやすい形で以下のように変形できます。

---

自己紹介

この発表のまとめ(伝えたいこと)

1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。

導入 / これまでのあらすじ

- **SRE NEXT 2020, 2022 の話**
- **スタディサプリ SRE の歴史**  
  - 2018 chaspy 入社  
  - 2020 SLO コンセプトを組織に導入  
  - 2021  
    - SRE チームの Vision / Mission / Value 策定 [リンク](https://blog.studysapuri.jp/entry/sre-vision-mission-values)  
    - Terraform, Kubernetes など基盤の進化, 負荷試験基盤の構築など
- **スタディサプリ小中高の組織規模やプロダクトについて**

この2年間の SRE チームが目指していたこと

- **課題: SRE チームがやることは、SRE チームが決めていた**
  - 適切な課題設定ができない可能性  
  - 再現性がないと感じていた  
- **開発者からフィードバックを得る / フィードバックサイクルを回す**
- **複数のアプローチを試す**
  - 過去事例: [マネジメントによるSREの実現](SRE を実現するための組織マネジメント / Management to achieve SRE - Speaker Deck)

事例紹介

1. フィードバックを得る

- **SRE サーベイの実施**
- **「月間SRE」として、毎月の SRE からの Updates を開発チームが多く参加する勉強会で共有、フィードバックをもらう**
- **2週間開発チームに SRE が入って密にコミュニケーション(Embedded SRE パターン)**

2. コラボレーションする

- **新機能リリース前のデプロイパイプラインの構築**
- **技術戦略グループで議論**
  - [CNCF2023 での発表予定](https://event.cloudnativedays.jp/cndf2023/talks/1866)

3. 実際に体験する

- **短期留学(開発メンバーとSREメンバー)**
- **SRE マネージャが開発マネージャを兼任**

これを可能にする組織

- **マネジメントの工夫**
- **組織文化**

マネジメントの工夫

組織文化について

- **フィードバックのスキル**
  - 360 feedback について
  - あらゆるシステムやプロセスへのフィードバック
- **率直に・非難なくコミュニケーションすること(Blameless)**
- **あらゆるものを振り返る文化**
  - [ふりかえりの文化について](https://blog.studysapuri.jp/entry/2022/02/19/sre-retrospective-culture)

まとめ
1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。



SRE サーベイの質問内容


Slack ID (GitHub ID)
所属チーム
関わっているサービス
ロール
自分たちのチームは自己完結化できていると感じますか?        
自分たちはいい感じにサービスを運用できていると感じますか?
何ができていればサービスを自分たちで運用できている、と言えますか?        
よりプロダクトを良くしていくためには、何がボトルネックですか?
もし、最近直面した SRE に関連しそうな課題/問題があれば教えて下さい

自分たちはいい感じにサービスを運用できていると感じますか? (2)        
普段の開発の中で最もストレスを感じている工程・手順は何ですか?
開発の工程の中で、これが速くなったら嬉しいという部分はありますか?        
自分たちのサービスにおいて、負債だと感じている / 消し去りたい要素は何かありますか?
あなたは、以下のツール等をどの程度理解していますか(詳細のコンポーネント別に質問)

現在の(SREが開発/運用している)プラットフォームは良くできていると思いますか
現在の(SREが開発/運用している)プラットフォームで分からないことがあったら、何を見ますか?
今のプラットフォームにあって便利な機能や、よく使っている機能があれば教えてください
現状の SRE の対応や取り組みに満足していますか?        
SRE の対応や取り組みについての要望/コメントがあればお願いします        (問い合わせをしたことがあれば) 
対応の速度や質に満足していますか?
SREの問い合わせ対応について要望/コメントがあればお願いします
サーベイについて何か要望/コメントがあればお願いします
SREチームから依頼があるとき、どのような形で連絡/依頼されると良いですか?



参考リンク
所属組織のブログ
Web 開発者目線での、SRE が作る開発基盤について
スタディサプリのWebアプリケーションはこうやって開発されている
AWS Dev Day 2023 Tokyo で スタディサプリのDarklaunch について発表してきました
開発生産性を支えるデータベースリストアを SRE が作った事例 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog
SRE メンバーが開発チームに入り、リニューアルプロジェクトのリリース前にプレモーテムをファシリテーションした話 「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog
著者自身のアウトプット
Web Application 開発の EM を兼務することになった Web Application 開発の EM を兼務することになった - ツナワタリマイライフ
SRE とプロダクト開発の EM を兼務して半年経った  SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ
開発チームに実際に入ったからこそ見えた課題と SRE としての経験を活かした事例 『スタディサプリ 中学講座』における E2E Test の運用と計測による改善 / Improved E2E testing through measurement - Speaker Deck

Senior Engineering Manager になった

過去形で書いたが正式任用は10月から。昨日社内にアナウンスされた。ソワソワしているのはようやく落ち着いた。

入社してからの経緯はここで振り返った。

blog.chaspy.me

一応社内の肩書きは「部長」であるが、ソワソワするので自称は Senior EM で行く。(それでいうと EM もそもそも社内の役職には存在せず、GM (Group Manager) であった)

部を2つに分割し、前任が持っていたものの半数を受け持つことになった。スタディサプリ小中高の BtoC 領域と、横断組織のいくつかを担当する。システムは共通部分も多いし、横断を見ているというのもあるし、技術戦略も見ているので BtoB のことは知りませんよ、となるわけもなく、なんだかんだ全体のことを見ていくことになる。

主務の担当メンバーの数は52名で、まぁかなりの責任のポジションである。数が全てではないし、数名だろうが誰かの人生に関与する意味では管理職の責任自体は変わらない。ただ、良くも悪くも影響範囲・影響力はある。恐ろしさがないといえば嘘になる。

責務は中間管理職の仕事と、技術組織の Engineering Management の仕事がある。どっちも未知の仕事だが、今は新しいことを学べること、経験できることにワクワクしている。

具体的にどうしていくかはこれからいろんな人と会話し、特にマネージャとのミッション策定を通じて実行していくことになる。

特に今は技術戦略と FinOps に関心がある。スタディサプリという事業に、技術組織が、システムが長期的に価値を生み出し続けるには何が必要なのかを考えたい。SRE を経験してきた身から、FinOps - ファイナンシャルチームと協力し、全てのチームがコストに説明責任を持ち、リアルタイムレポートを見て意思決定する世界(それが今の会社において本当に理想かの模索からではあるが)は挑戦していきたい。それを支えるためにブランディング、採用、メンバーの活躍と組織づくりもやっていく。

呼称について、社内から部長と呼ばれるのはそうなのでいいが、やっぱり Senior Engineering Manager がしっくりくる。たとえば以前だと VP of Engineering なのかもしれないが、別に副社長じゃないし、ただの1社員に過ぎない。求められることのレベルが変わるのはそうだが、やっぱり Engineering Management を主務としてやりたい。そしてそのために、直接的には今所属する、優秀な Engineering Manager たちの活躍をサポートしたい。それが目指したい姿とも合っている。間接的に、EM の活躍を通じて、全てのメンバーが活躍できる組織にしたい。

仕事が増えるということは、減る仕事もあるということで。長年勤めた SRE チームから卒業することとなる。僕より遥かに優秀な後任にお任せすることができて本当に嬉しく、ほんの少し寂しい。だけど任用当時目安にしていた2年という期間で引き継げたのは良かったと思う。このチームのおかげで僕は昨年開発のマネージャにチャレンジできたし、その経験がこの人事にも生きていると思う。

プロダクトセキュリティについても僕がオープンしたポジションで、無事2名採用できてチームとして独立することができた。ここは引き続き僕がマネージャとして担当し、SRE チームと協力しながらプロダクトのセキュリティ施策の要件定義と実装をする。将来的には DevSecOps もやっていきたい。また、僕が元々担当していた契約 SaaS のアカウントマネジメントの自動化にも取り組みたい。

brand.studysapuri.jp

この人事が正しかったかどうかは時が判断するだろう。前任ともなぜ自分なのか?はちゃんと会話した。運が6割、やる気が3割、実力が1割ぐらいだろうと思っている。うち運は半分が後任を作れたこと、もう半分が誰かに渡さないといけない状況になったこと(ポジションが生まれたこと)だ。というわけで僕にとっては運に恵まれたが、期待を含めて任せていただいているということなので、期待に応えられるように頑張ります。

信頼して任せてくれた前任と、受け入れてくれる仲間に感謝しながらがんばります。楽しみながらやりたい。

というわけで飲みにいきましょう!かこつけてめでたいワイワイするのもよし。CTO / VPoE / EM の方との繋がりも増やせたらなと思います。よろしくお願いします。

勉強会参加メモ - Workers Tech Talks #1

https://workers-tech.connpass.com/event/287490/

GraphQL Server on Edge

speakerdeck.com

  • GraphQL server をコンテナでやるとして、初手 Cloudrun を選ぶとして、
  • cloudfrare workers という選択肢
  • 許容しなければならないこと
  • gcp 主体から cloudfrare 主体に書き換えることができた
  • (kysely, SQL builder. schema から型を生成する. DB migration のために prisma と合わせて使う)
  • メリット
    • デプロイが8分から1分
    • コールドスタート 5秒から200ミリ
    • コンピュータリソースあたりの単価は高め(起動時間が減ることで結果的にサーバ費用は1/10に減ったとのこと)
  • デメリット
    • nodejsが必要な場合は別途サービス作らないといけない
    • tcp はリクエスト処理しているときだけ接続可能
  • まとめ
    • API サーバとしては実用的な状況
    • cloud frareにロックインするが、メリットはある
  • ユースケースを見極めれば十分に使えるという事例だった

Gyazo の素朴な Workers

scrapbox.io

  • Gyazo のユーザは北米に多いので gcp us-central に origin
  • 素朴だけど明日から真似できる例として発表
  • 画像をキャプチャ、画像は png として url でアクセスできるが、
    • 再度アクセスすると上に gyazo と表示される
  • 解決したい課題
    • 画像直リンシェアされると gyazo.com に辿り着けない
  • Cloudfalre proxy を CDN として使う
    • 「人間が見てそう」なら画像バイナリの代わりに html を返す
  • 100行ぐらいの素朴な実装
  • cloudfrare worker proxy mode で使えるなら簡単に使える
  • 従来アーキテクチャでの nginx/lua で持っていた logic をなくせるのはメリットとして大きそうだった

Cloudflare Workers + R2で低コストで画像配信を移行した話

speakerdeck.com

  • Cloudfront + S3 に対するソリューションの1つとして Cloudfrare Workers + R2 ケースの紹介
  • r2
    • s3互換
    • s3に劣る部分はある、当てはまらない場合は検討できる
      • IAM/トークン単位でのアクセス制御できない
      • バケットのバージョニングできない
      • S3 Glacier のようなストレージクラス概念ない
  • 円安でのコスト増加への対策
  • これまでの構成
    • cloudfrontの後ろにnginx、basic auth、s3の構成だった
  • そもそもr2配信でworkers必要?
    • public buckets機能がでたのでシンプルな配信なら不要
  • workers を使うとpath mappingなど複雑な処理がedgeでできる
  • キャッシュは?
    • kv を検討したが、従量課金でコストかかる
    • cache api を使った
  • コストより柔軟な画像リサイズなどやりたいなら cloudfrare imagesを使うと良い
  • 移行の際はトラフィック料金がシビア
    • s3とr2はダブルライトした
  • 他スピード早くメモが追いつかず。移行のtipsがめっちゃ詰まってた
  • ペインを移行によって解決できていてすごい
    • コスト削減含め

Server Side JavaScript のためのバンドル最適化

speakerdeck.com

  • (前提破壊)制限が5MBから10MBになった
  • サーバサイドでバンドルするメリット
    • 起動高速化
    • CI
    • セキュリティ
  • デメリット
    • sourcemap で複雑化
  • v8 isolate で120MBのメモリを割り当ててスクリプトを実行
    • chrome のタブ1つに相当
  • パフォーマンスバジェットという考え方
    • バンドルサイズの上限をチームで合意しようね

gRPC Client on Cloudfrare Workers

speakerdeck.com

  • gRPC を cf-worker で動かす事例

まとめ

Cloudfrare Workers が何かもわからない状態で行ったので豊富な事例を聞いて活用方法はいろいろあることがわかった

勉強会参加メモ - 【有料プランユーザー様限定×オフライン】MagicPodユーザーLT会

trident-qa.connpass.com

普通に会社名義で出たので会社ブログを書けという話だが、個人の学びとして他の人の発表で感じたことメモしておきたいので書く。

MagicPodでFlutterアプリをテストする

Flutter から遠い生活をしているので特に思ったことはないが、サポートできる Platform を増やすことは E2E Test SaaS ベンダーとしては重要だが、Flutter という Native から1段階 wrap しているものをサポートするのはかなり苦労があるんだなーと思った。

MagicPodで始める がんばらない回帰試験の自動化

speakerdeck.com

  • 自動化の導入コストは当然かかる
  • MagicPod のベストプラクティスは知らなかった
  • 実際に経験してみて自動化が難しいものとそうでないものを切り分けられたのは良い学びだと思う
  • kintone 普通に metrics を食わせて表示できるんだーってのがびっくり
    • 後の自分の発表言うことないな、ってなっちゃった
  • issue ちゃんと書いているの大事

『スタディサプリ 中学講座』における E2E Test の運用と計測による改善

所属チームのこれまでの軌跡が話されてよかった 合わせてブログ書きたい 「開発チームが自ら自動テストを書き、メンテしている。QA はサポート」というのはもっとアピールしたい。 質疑でも補足したけど tatto さんの丁寧なサポートと品質リードへのファシリテーション、そういった役割を踏まえて組織したマネジメントが合わさって成し遂げられていることだと思う

自分の資料はこっち

speakerdeck.com

github.com

「計測されていると、改善したくなる」が一番言いたかったことかもしれない。

あと Web だからか、E2E が15分ってめっちゃ短いほうなのね、ってわかったw

そういえば Duration seconds 的なのも API で取れると嬉しいと言う話をして issue を書いてもらった。

github.com

みてねの安定リリースを支えるMagicPod活用状況

speakerdeck.com

  • QA からはじめて開発チームに認知が広がったのはいい話
  • 共有ステップを使いこなすのすごいと思うけど、副作用もあると思った
    • 共有ステップの管理とその周知はどうやっているのだろう
    • QA チームが少人数だとコミュニケーションでうまくやれるのかもしれない

高い開発生産性を実現するために取り組んだMagicPodの利活用

speakerdeck.com

  • 実行方法の整理は見事で、特にデプロイ前と定期実行でテストケースを分けている点は見習える点があるなと思った
  • Jimbo さんと懇親会でも話したけど、デプロイ前はマジで重大障害につながるクリティカルなところだけにすることで、開発速度を止めない
    • 逆にそれ以外定期実行の「最悪3時間」で気づけるものはデプロイブロックしない、というのは言うは易しというか、うまく問題起こさずにできているのはすごいと思う
    • CI で PR マージ前実行でも5分ならまぁ我慢できるなと思う

自動テストを社内へ浸透させた話

speakerdeck.com

  • 手動テストと自動テストをどう棲み分けるのか、そのガイドなり考え方なりを発信するのは大事だと思う
    • 100% は無理
  • 特にレコチョクさんの扱うような音楽再生みたいな、メディアが関わるものは難しいですよね

まとめ

懇親会も楽しかったです。ありがとうございました。 発表させて、といって当日までつなげてくれたコミュニティマネージャの田上さん、懇親会で会話させていただいた伊藤 CEO 他みなさんありがとうございました。

引き続きよろしくお願いします。何かあったら Issue 書きます。

勉強会参加メモ - 開発生産性 Conference

dev-productivity-con.findy-code.io

From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework

  • SPACE フレームワークはかなり有益だと思った
  • あらゆる metrics・評価指標自体の評価ができるメタフレームワーク
  • DORA のページがある DORA | DevOps Research and Assessment
  • SPACE Framework
    • S: Satisfaction and well-being
    • P: Performance
    • A: Activity
    • C: Communication and collaboration
    • E: Effectivity and flow
  • 多面的に評価できるので、トレードオフを考えられるので良い
  • 特に flow に入れるかどうかは satisfaction にも影響を与えると思う
  • 計測方法はヒアリングしかないなーと思うのでここをうまくやりたい

組織をスケールさせるためのFour Keysとチームトポロジー

speakerdeck.com

  • 適切な摂理面の探索、どうすればいいんでしょうねぇ
    • バリューチェーンでわけても上流下流が密に影響する場合そこで分けられないのはそうだと思う
    • 戦略的にモノリスにしているのは賢いと思う
  • ダブルループ学習を推奨するのは良さそう
    • 結局やって学んでいくしかない

なぜ Four Keys を改善するのか? 〜How ではなく Why を重視したメトリクス改善活動〜

speakerdeck.com

  • 発表が上手だった
  • 資料もわかりやすい、参考にしたい
    • 伝えたいことが1スライドで明確
    • 文字だけでなくアイコンは図を使っている
  • 0から最終的にオーナーシップを渡せるまでの旅路が描かれていた、これからやる人は参考にできそう
  • 各メトリクスはつながっているの、そうなんですよね

The Metrics Key: Connecting Product, System, Team

speakerdeck.com

  • 1番聞けてよかったセッション
  • DMM さんは組織規模的にも先を行っているので参考にしている
  • 基本の基本で「計測」かなりちゃんとしていおる印象、ここまでできてないなぁと反省
    • 工数、予算、品質の観点で調査していてすごい
  • "「不確実性が高い」という言葉を計画、計測、学習を適切に行なっていない言い訳にしない” 肝に銘じます
    • 可観測性と再現性を作る、100回言いたい
  • Metrics の整理が素晴らしかった
    • 事業、プロダクト、システム、チーム
    • 事業、システム、組織、という整理を自分でしていたが、プロダクト軸と、それぞれの指標例が載っていてありがた
  • 有効稼働率を計測しているのは驚いた、できる気がしない。..
    • 勤怠管理ツールと接続するとは。..

これからのソフトウェア開発 "GitHub x AI" による生産性革命

copillot X は相当便利だなーと思った 早く使いたい。

行政府の開発生産性向上のアプローチと、目指す未来

各自治体で分かれている中で DX を進めていくのは並大抵のことではない、尊敬の念です。

大規模言語モデル時代の開発生産性

資料だけ見ました。素晴らしかった。

speakerdeck.com

  • 開発生産性の3つのレベルと組織の関係 p19 がわかりやすい
    • 開発部の目標、事業の目標はわけて考えないといけない
  • p24 もわかりやすい
    • Engineering Manager, Product Manager, Sales/Maketing Manager の役割がよくわかる
    • GP = Gross Productivity
  • p34 定性目標、定量目標、「健全化指標」という整理もよかった
  • AI 時代に関連すると、AI エージェントが何をし、人間が何をやるのかを理解して取り組む必要がある
    • 実際にツールを書いて検証していてすごい

まとめ

所属会社でもこの領域に取り組んでいるため良質なインプットを得られてよかった。 自分の取り組みを省みて、今後の方向性を考えたい。

勉強会参加メモ -【PLAID×NewsPicks共同開催】ABテストの理論と実践〜成果にコミットするプロダクト開発〜

uzabase-tech.connpass.com

参加した。ちょうど今年の2月からプロダクトエンハンスを A/B テストを活用するチームを立ち上げたばかりで関心の高いトピックだった。

中身も非常に学びが多く、開催してくれて本当に感謝。

動画も残っていて感謝。

www.youtube.com

ABテストのための統計的検定理論(序論)

統計的検定理論について理解が浅いままやっている(所属組織については専門のデータアナリストについてもらっている)ので、その入り口として非常にありがたかった。紹介された本も買ったのでこれから読む予定。

最初に紹介されていたスライドはこれ。

blog.recruit.co.jp

  • ABテストとは
    • ABテストとは分析の一種である
    • 「分けて、比較する」が分析
  • AB テストの前提条件
    • どちらに割り振られるかはランダム
    • 片方に割り振られたらもう片方には割り振られない
    • 2つの群で同時に実施される
    • ABC テスト
      • うっ
  • AB テストの結果の見方
    • 量ではなく CVR をみていく
    • 棒グラフで出してもあまり意味がない、スケールを変えればどうとでも見れるので
    • 何をもって近い、遠いかを判断するには「統計的仮設検定」が必要になる
    • 「CVR の発生確率」を分布していく、重複が離れていくと有意と言える
  • 注意点
    • サンプルサイズを大きくすると、確率分布が尖る(幅が小さくなる)
    • サンプルサイズを大きくすると、小さな差でも有意になってくる
  • 統計的仮設検定の手順
    • ABの差が棄却域が有意水準より離れていれば棄却できる、と考える
    • 差があるといえる確率を検出力という

時間があったら話すことを聞きたかった!続編に期待。

120回分のABテスト結果を分析して見つけたアンチパターン/成果が出たパターン

約2年で120回、すごい。

  • 失敗事例から学ぶ
    • いつまでも終わらないABテスト
      • Android ではじめて、あとで iOS で適用すればいいのでは?ー>サンプル数が足りないのでいつまでも終わらない
      • わかる...
      • サンプル母数が少ないと改善サイクルが遅くなる
      • 人数が多いプラットフォームで先にやるべき
    • 差分が少ないテスト
      • これ難しいですね。差分が大きすぎるとどの要素が効いたかわからないという問題はありそう
      • あまりに些細すぎると、効果は出ないというのはありそう
  • 成功事例
    • 施策のタイミングを考える
      • ユーザが感情が動くタイミングでやる   * インストール直後の初期画面 -> プレミアムを訴求する
        • サブスク開始後に通知許諾を促す
        • 良さそう
    • 判断に必要な情報を整理して伝える
      • めちゃくちゃ大事。..
      • 結局いくらお得なのかを整理する、やりたい
      • 解約画面で訴求するのいい例だと思った
        • もしやめて、また入ると高くなるよ、ということを通知   * 値段だけじゃなくても解約防止のための情報を伝えるのは大事
  • サービスの種類や特性によって違う、それはそう
    • これが難しいし実験あるのみというところだなと思った
    • 実験サイクルを回し、学習量を増やすことが一番大事だと思った

Notionを軸にABテストを効率化する

Notion, 仕事では使っていないんだけど、データベースになるのでテンプレート + 結果の分析に役立つなーと思いました

A/B テスト自体のテンプレートは GitHub Issue Template を使っているけど、分析はそのまま使えないので確かになーと思った。

A/B テスト自体の分析ができるほど施策ができてないなーというところはぐぬぬとなりつつ、いずれ必要になるので考えておきたい。

AB テストの if 文の残留はタスクマネジメント上しっかり Issue 化しているので忘れずにできているなと思った。

ただ全体的に自動化の余地はあるので、Zapier 使うとか知見共有するよとかそういうのは真似していきたい。

質疑応答

  • KPI の分解についてはかなりできてないなと思った
    • 実際売上に近い、課金率を目標に取っている
    • 課金率を KPI ツリーに分解し、より近いところを目標していくことで高速にサイクルを回せるようになると思った

まとめ

  • A/B テストテーマの勉強会、めちゃくちゃありがたかった、またやりたい
  • 自分たちも発信できるようにしないとなーと思った、ブログ書こう。。。

入社してから5年

前回 https://blog.chaspy.me/entry/2022/12/24/120000

約半年ごとに書いている勤続(?)エントリー。ついに丸5年となった。

節目ということもあり、5年を振り返ってみる。

5年間を振り返る

1年目

2018/06-2019/05

とにかくパフォーマンスが出なかった。出なかった、というか、低かった、というのが正しい。求められる期待値と現在のギャップを正しく認知できず、間違った方向にがむしゃらで、パニックゾーンだった。

今でもたまに思い出す。辛い時期だった。

半年経ったころから Microservices Readiness な仕組みつくりをはじめたり、deis からの Platform 移行にともなう Kubernetes の勉強会や、起きる変更を文章にしたり、特別講習と呼ばれる live サービスのインフラを担当したりと、少しずつ自分ができることが増えてきた。

同時にオンボーディングカルチャーを WebDev と一緒になって醸成した。

ブログ筋があったおかげで、わかることもわからないことも文章にするスキルがこの時自分を助けてくれた。

SRE Lounge のコミュニティに顔を出したり、同僚と勉強会に行ったりの時間が癒しだった。

2年目

2019/06-2020/05

自分でできることも増えてきた。ユーザも増え、パフォーマンスの問題を顕在化してきた。MongoDB のスケールアップのための負荷試験をやったり、Kubernetes 上で HPA を導入したりしていたかな。

あとは SLO をやっていくんだ、と宣言して、最初は1人でコツコツと、それから開発チームと一緒に少しずつ。現れる技術的問題をクリアしながら"文化を作る"体験をしたのは自分にとって稀有な経験だった。

この時の体験は最善だったとは思わない。もうやらないし、もうやれないな、とも思う。しかし組織としての仕組みがない中で個人が1つのことを成し遂げることができる土壌そのものの尊さを感じたのを覚えている。

英語を真剣にやっていたのもこの時期だと思う。悔しい思いをたくさんした。嬉しい思いもたくさんした。現地に行って会話したこと、それがリモートであれ普段の仕事のしやすさにつながること、今、時代柄見直されていることだが、オフラインコミュケーションの重要さを実感した。

1番ハードに働いていたと思うし、でも夢中だった時期だと思う。

3年目

2020/06-2021/05

Lead Engineer というタイトルがついた。チームが前に進むためにできることを考えた。とにかく考え尽くした。

言語の壁もあった。チームメンバーの価値観の違いもある。SRE チームの担当範囲の広さもある。難しかったが、この頃からメンバー全員と1on1をはじめて、課題解決に時間を割いた。

同時に IC として技術力の壁を1つ超えられたのもこの時期かこのちょっと前だったように思う。"技術力が課題"という言葉に、これ以上の解像度を持っていなかった。

しかしとにかくコードを書くことをミッションにしたり、"わからなさ"をわかることができた、この認知の変化によって自分が技術的に成し遂げられることが格段に変化した。

https://blog.chaspy.me/entry/2021/05/08/120000

Platform に関する大きな変更にもチャレンジした。company wide に影響する migration をサポートをもらいながら主体的に成し遂げられたのは自信につながった。

この頃から"エンジニアリングでビジネスに貢献したい"という気持ちが強くなってきていた。

4年目

2021/06-2022/05

この頃はマネジメントの割合が増えてきていた。もちろん OSS を書くなどコードを書く機会は増やしつつ、いかに組織の課題を fact をもとに解くのか、計測するのか。SRE は何を目指すべきなのかを考えていた。

そして10月からは EM になった。

この頃は組織全体の技術戦略にも関わることになり、視座が一段上がったように思う。そのことが SRE としての活動の幅を広げるにも役立った。

5年目

2022/06-2023/05

SRE だけでなく web チームのマネージャーも兼任することになり、マネジメントとしての難易度を一段上げた。

リクルートグループ入りしたこともあり、交流も増えた。大企業での泳ぎ方みたいなのはわりと適応能力があったみたいでなんとかなっている。

マネジメントをうまくやればやるほど、自分個人の成果が見えづらくなる、マネージャーあるあるだが、そういったことはあまり気にせず、自分の成長できる環境を自分で作っていけたと思う。

このときやりたかった Web 技術そのものを仕事でやることは残念ながらほとんどできていない。まぁ、複数グループ兼任してたらマネジメントだけで終わるのはそれはそうよね。

そのことが今後足枷になるのかはわからない。ただ、評価する立場としては技術との距離はこれ以上離れてはならないと思うので、1軍のコードは書かないまでも、2軍3軍のコードを書く、副業で書くなどして食らいつきたいし、自分自身も技術を楽しみたい。

今後

10月で SRE のマネージャーをやって2年である。2年で引退するつもりだったが、Web のマネージャーもはじめたため寿命が伸びた。

今自分が1番面白いと思うのは"Engineering Management"だ。これは文字通りであり、マネージャーという仕事が面白いとか、人と話すのが楽しいとかという側面ではなく、どのように技術をビジネスに活かすのか、ここにより直接的に関与できる立場にある。

変わらず国内と海外の両方のビジネスを支えていきたい。

国内については SRE と開発チーム両方見れる立場として、技術戦略をよりうまくなる、3年後5年後のサプリの未来を作ることに貢献したいし、それを主体的に行う Engineering Manager や Lead/Senior Engineer をサポートしたい。

海外についてはインフラ面でビジネスが継続できるようコストや開発生産性でサポートしていきたい。

外部コーチングを受けることで自分の強みはある程度わかってきた。広く見て、仕組みを作って、ひとりひとりの成長をサポートして、重要な課題について、レバレッジポイントを見つけて介入したい。そういうことを、もうしばらく今の組織でやる。

それ以外の個人的な興味だと、プロダクトエンハンスをA/Bテストをやって仮説検証をやるチームの検証サイクルを爆速にしたいと思っており、これを成し遂げるには超えるべき壁がたくさんあるので、自分が貢献できるポイントも多いと感じている。やっていきたい。

次の10月で Engineering Manager 3年目になる。引き続きよろしくお願いします。飲みに行きましょう。