新メンバーも今日から大活躍！SREが支えるスケールし続ける組織のオンボーディング

開発生産性カンファレンス 2025(https://dev-productivity-con.findy-code.io/2025)の登壇資料です。

Transcript

1. ©MIXI 新メンバーも今⽇から⼤活躍！ SREが⽀えるスケールし続ける組織の オンボーディング 株式会社MIXI みてね事業本部 みてねプラットフォーム部 SREグループ マネージャー 本間 匡晃 #開発⽣産性con_findy
2. 2 ©MIXI • 趣味はキャンプ、スニーカー収集、筋トレ • 娘が2⼈(5歳と2歳)います • 前回の健康診断で「君アメフトやってるで しょ？え？やってないの？じゃあ痩せないと いけないよ」と⾔われダイエットを決意 • 現在 -3kg みてね事業本部 みてねプラットフォーム部 SREグループ マネージャー 本間 匡晃 複数の会社でバックエンドエンジニア ~ SREとして経験を積み、 ⼦供が⽣まれたことをきっかけに⾃⾝もユーザーだったサービスに関わりたく転職 2022年~ 家族アルバム みてねのSREとして従事 ⾃⼰紹介 @HonMarkHunt X @honmarkhunt
3. 3 ©MIXI MIXI GROUP の事業領域 エモーションと コミュニケーションで 「⼼もつながる」場と機会を 創造し続けます。 MIXI GROUPは、 ただ「つながればいい」という効率的な機能の提供ではなく、 歓喜や興奮、温かな思い、幸せ、居⼼地の良さの共有を通じて、 その先に、もっと深くて濃く豊かな、⼼のつながりを⽣み出すような、 サービスの開発‧提供を⽬指しています。 現在、スポーツ‧ライフスタイル‧デジタルエンターテインメント の3つの領域で事業を展開しており、 それぞれの主な事業内容は右の通りです。 また、近年の投資活動の拡⼤と重要性を勘案し、 FY2023からはスタートアップやファンド出資等の投資活動を事業化しました。 スポーツ事業 プロスポーツチーム運営および 公営競技ビジネスの推進 ライフスタイル事業 インターネットを活用し、 人々の生活に密着したサービスの提供 デジタルエンターテインメント事業 スマホゲームを中心としたゲームの提供 3つの領域で “「心もつながる」 場と機会” を創造する事業を推進
4. 4 ©MIXI 主な事業‧サービスのリリース年表 求⼈情報サイトをリリース 1997 2004 2013 2014 2015 2019 2020 2021 2022 2024
5. 5 ©MIXI About BUSINESS SPORT スポーツ事業 DIGITAL ENTERTAINMENT デジタルエンターテインメント 事業 LIFESTYLE ライフスタイル事業 and more...
6. 6 ©MIXI MIXIではコミュニケーションを⼀緒につくる仲間を募集しています。 We are hiring!! 採用情報 https://mixigroup-recruit.mixi.co.jp/ MIXI 採⽤ ＼ 様々なポジションで積極採用中 ／
7. 7 ©MIXI モチベーション • オンボーディングに関して概念的な話はあるが具体的な事例はあまり出ていないように感じた • 組織やアーキテクチャにあまり影響を受けずどの組織でも適⽤できる • (AI周りの話が多そうなので箸休めになれば) 1. 家族アルバム みてね(以下、みてね)のオンボーディングの仕組みとカイゼンの歴史 2. 誰もがつまづきやすい個別の開発環境構築の⼯夫 本⽇お話しする内容 2つ合わせて誰もが初⽇から活躍できる環境 ゴール • 参考になる事例があれば1つでも持ち帰ってみなさんに実践していただくこと
8. ©MIXI 家族アルバム みてねの組織
9. ©MIXI 9 (引⽤) 家族アルバム みてね 事業紹介 / Our Business https://speakerdeck.com/familyalbum/our-business (2025/06/23 閲覧) プロダクト紹介 「家族アルバム みてね」は撮影したお子様の写真や動画を家族・親戚内だけで安全にシェアしていただくサービス。 国内外を問わず2,500万人以上の方にご利用いただいています。
10. ©MIXI 10 (引⽤) 家族アルバム みてね 事業紹介 / Our Business https://speakerdeck.com/familyalbum/our-business (2025/06/23 閲覧) 組織紹介 組織規模も年々拡大しており現在は100名を超える組織 その中でSREグループはEmbedded SREのような形ではなく独立して各開発チームの支援を行う また、開発環境の提供などPlatform Engineeringも兼ねている
11. ©MIXI よくある課題
12. ©MIXI 12 よくある課題 こんなSlackチャンネルがあっ たんだ 同じ日に入社したAさんが 自分の知らないツールを知って た 早く活躍したいのに 個別の開発環境構築が 作り終わらない... 入社1ヶ月目の人
13. ©MIXI 13 今⽇お話しすること 既存オンボーディングの組織拡大に伴う内容の陳腐化 サービス規模拡大に伴うコードベースの肥大化によって個別の開発環境構築の手順が複雑化
14. ©MIXI 14 今⽇お話しすること 既存オンボーディングの組織拡大に伴う内容の陳腐化 サービス規模拡大に伴うコードベースの肥大化によって個別の開発環境構築の手順が複雑化 それぞれの課題への対策を順番に紹介します
15. ©MIXI オンボーディングへの取り組み
16. ©MIXI 16 オンボーディングの課題 • 各グループ/チームごとにオンボーディングが存在 • 共通部分のメンテナンス性が悪い • チームごとの独立したオンボーディングによって受講者間に知識差が発生 • ドキュメントの散乱 • 自分の役割に必要な知識にアクセスできない • 1ページのドキュメントに箇条書きでやることを記載 • 完了・進捗を把握しづらい • そもそも誰が更新するのか明確ではない • 気付いた人がホスピタリティで修正する
17. ©MIXI 17 オンボーディングの課題 • 各グループ/チームごとにオンボーディングが存在 • 共通部分のメンテナンス性が悪い • チームごとの独立したオンボーディングによって受講者間に知識差が発生 • ドキュメントの散乱 • 自分の役割に必要な知識にアクセスできない • 1ページのドキュメントに箇条書きでやることを記載 • 完了・進捗を把握しづらい • そもそも誰が更新するのか明確ではない • 気付いた人がホスピタリティで修正する そもそもオンボーディングの理想形とは ...?
18. ©MIXI 18 理想のオンボーディング オンボーディング受講者が以下の 3つの状態を満たしていること チームの⼀員として受け⼊れられている感覚 社会的受容(Social Acceptance) ⾃分の役割‧責務がクリアになっている 役割の明確さ (Role Clarity) ⾃分ならこの仕事をやり遂げられるという⾃信 ⾃⼰効⼒感 (Self-Efficacy) (引⽤) Newcomer Adjustment During Organizational Socialization: A Meta-Analytic Review of Antecedents, Outcomes, and Methods https://pdxscholar.library.pdx.edu/cgi/viewcontent.cgi?article=1026&context=busadmin_fac (2025/06/23 閲覧)
19. ©MIXI 19 理想のオンボーディング チームの⼀員として受け⼊れられている感覚 社会的受容(Social Acceptance) • チームのコードレビュー⽂化に安⼼して参加できる • 「こんなこと聞いても⼤丈夫かな…？」と質問をためらわない • チームの雑談やコミュニケーションに気軽に⼊れる Social Acceptanceを 満たせていない...！！
20. ©MIXI 20 理想のオンボーディング ⾃分の役割‧責務がクリアになっている 役割の明確さ (Role Clarity) • 「担当するコードの責任範囲はどこか？」 • 「どういう流れでプルリクエストを出すべきか？」 • 「このチームの技術スタックは何か？」 • これらが明確になっている状態。 Role Clarityを 満たせていない...！！
21. ©MIXI 21 理想のオンボーディング • 「開発環境を⼀⼈で構築できる」 • 「最初の簡単なチケットを⾃⼒で完了できる」 • 「⾃信を持って最初のプルリクエストを出せる」状態。 ⾃分ならこの仕事をやり遂げられるという⾃信 ⾃⼰効⼒感 (Self-Efficacy) Self-Efficacyを 満たせていない...！！
22. ©MIXI 22 カイゼン 　　 コンテンツの差による完了時の人によっての知識差が発生 　　 自分の役割には必要な知識にアクセスできない 　　完了・進捗を把握しづらい 　　 全てのドキュメントを 1箇所に集約 　　 事業部・グループ固有の手順も同一箇所に集約し、フィルターして個別の内容作成 　　個別のページの作成により完了の明確化
23. ©MIXI 23 カイゼン 全てのドキュメントを 1箇所に集約  チームごとに⽤意していたコンテンツや有⽤なドキュメントを1箇所に集めてシラバスとして定義 
24. ©MIXI 24 カイゼン 事業部・グループ固有の手順も同一箇所に集約し、フィルターして個別の内容作成  全てのカリキュラムを含むシラバスからフィルターを⽤いて個⼈⽤のオンボーディングページをカスタマイズ
25. ©MIXI 25 カイゼン 個別のページの作成により完了の明確化  個⼈ごとにカスタマイズしたシラバスを作成することで、「カリキュラムが全て完了 = オンボーディングが完了」 とステータスを明確化
26. ©MIXI 26 現在のオンボーディング みてねではNotionを利用しているためDatabaseやフィルターなどの機能を使っていますが、 ほとんどのドキュメントツールはテンプレート機能があるため、同じことはできる想定です。 また、スプレッドシートでも代替可能です。 チーム個別管理から全体一括管理へ 個人ごとに最適化されたオンボーディング
27. ©MIXI 27 [補⾜] ドキュメントの陳腐化対策 (まだ完璧には運⽤できていませんが) 全てのカリキュラムに、更新の責任をもつ管理者を設定 カリキュラムに「オンボーディングへのフィードバック」が 含まれているため それぞれ管理者が内容を最新化して内容が古くなるのを防ぐ
28. ©MIXI 個別の開発環境への取り組み
29. 29 ©MIXI • 主にAWSを利⽤ • アプリケーション基盤はEKS(Amazon Elastic Kubernetes Service)を採⽤ • EKS上で複数のRailsアプリケーションが稼働 • メインで⽤いるアプリケーションはモノレポで管理されている ◦ 概ねこのアプリケーションを起動できればOK ◦ 大きな機能サービスごとに一部マイクロサービスとして切り出されている みてねの環境 AWS Account EKS Cluster Namespace A Namespace B Main Application Other Application Other Application Other Application Amazon Aurora S3
30. 30 ©MIXI • 主にAWSを利⽤ • アプリケーション基盤はEKS(Amazon Elastic Kubernetes Service)を採⽤ • EKS上で複数のRailsアプリケーションが稼働 • メインで⽤いるアプリケーションはモノレポで管理されている ◦ 概ねこのアプリケーションを起動できればOK ◦ 大きな機能サービスごとに一部マイクロサービスとして切り出されている みてねの環境 AWS Account EKS Cluster Namespace A Namespace B Main Application 概ねこれが⾃分の環境で 起動できればOK
31. 31 ©MIXI 環境構築の課題 • みてねは10年⽬を迎えるプロダクト • コードベースも⾮常に⼤きい • 必要なミドルウェアやそれらのバージョン管理 ◦ FFmpeg, ImageMagick, などなど… • いわゆる「おま環」依存のサポートの困難さ • デザイナーの負担増 ◦ みてねではLP作成やデザイン修正などでデザイナーもGitを触る文化 ◦ 初めてターミナルを触る人も多い中上記の状態はあまりにもハードルが高い
32. 32 ©MIXI 環境構築の課題 • みてねは10年⽬を迎えるプロダクト • コードベースも⾮常に⼤きい • 必要なミドルウェアやそれらのバージョン管理 ◦ FFmpeg, ImageMagick, などなど… • いわゆる「おま環」依存のサポートの困難さ • デザイナーの負担増 ◦ みてねではLP作成やデザイン修正などでデザイナーもGitを触る文化 ◦ 初めてターミナルを触る人も多い中上記の状態はあまりにもハードルが高い ⾃⼰効⼒感 (Self-Efficacy) が満たせていない 環境構築も できないのか
33. 33 ©MIXI Sandbox環境の導⼊ • EKS上に個⼈個⼈の作業環境(Deployment)を作成 • Deploymentのテンプレート(Helm)はSREが管理 • Visual Studio Codeなど任意のエディタでRemote SSHをして開発 • 個⼈設定⽤のyamlファイルを作成するのみ
34. 34 ©MIXI Sandbox環境の導⼊ • EKS上に個⼈個⼈の作業環境(Deployment)を作成 • Deploymentのテンプレート(Helm)はSREが管理 • Visual Studio Codeなど任意のエディタでRemote SSHをして開発 • 個⼈設定⽤のyamlファイルを作成するのみ Engineer/Designer ミクシ子さん ミクシ子さん用 Sandbox 設定ファイル 環境作成処理 AWS Account Aさん用 Sandbox Bさん用 Sandbox 作成 Remote SSH
35. 35 ©MIXI [補⾜] Sandbox環境の構成 AWS Account EKS Cluster Namespace A Engineer/Designer Deployment ミクシ子 Main App FFmpeg, ImageMagick, etc… Deployment Other ミクシ子さん push 検知 ArgoCD template(Helm charts) remote SSH
36. 36 ©MIXI Sandbox環境によるカイゼン   個別環境におけるトラブルシュートが簡略化された   0から個⼈の開発環境⽴ち上げて開発着⼿まで1時間程度で実施可能   各種関連ツールのバージョンの統⼀    More • EKSアップグレードなどの際に全員の環境が⼀時瞬断するので事前の調整やアナウンスが必要 • 海外から開発する際にSandboxのEKS Clusterは東京リージョンで稼働しているので操作が快適ではない 36
37. 37 ©MIXI [補⾜]その他の⼯夫‧検討事項 • Codespacesの利⽤も検討した ◦ GitHub製のオンライン開発環境 ◦ Sandboxに比べて常時稼働せず従量課金なのでコスト優位性があると判断した ◦ 認証周りや開発時の体験などを総合的に判断し、Sandboxに機能追加することで導入は見送りした • Go製のCLIツールを提供し、AWSの認証やSandoxの起動/停⽌などを容易に⾏える • 開発が⾏われない業務時間外(⼟⽇含む)はSandboxを停⽌し不要なNodeを削減し、 コスト削減を⾏っている • SREが直接Sandbox(pod)にSSHしてサポートを⾏うことができる • 個々のyamlによるカスタマイズが可能 ◦ 起動時間の個別設定 ◦ 利用するimageの更新 ◦ x86_64 (amd64) と aarch64 (arm64) の切り替えも可能
38. ©MIXI まとめ
39. 39 ©MIXI ⼀元管理と個別提供で最⾼のオンボーディング まとめ 個別の開発環境(Sandbox)でDay1から活躍できる ↑2つの施策を合わせて新メンバーの開発⽣産性を最⼤限に引き上げる
40. ©MIXI