MIXIと「家族アルバム みてね」について

本間：MIXI GROUPは「心もつながる場と機会の創造。」をテーマに、3つの事業軸でサービスを展開しています。現在の事業領域はスポーツ事業、ライフスタイル事業、デジタルエンターテインメント事業の3つです。

家族アルバム みてねは、撮影したお子様の写真や動画を家族・親戚内だけで安全にシェアするコミュニケーションサービスです。2015年のリリース以来、今年で10年目を迎える成熟したサービスとなっています。現在、国内外で2,500万人以上のユーザーにご利用いただいており、利用者数は継続的に成長しています。



サービスの成長に伴い、開発組織も拡大を続けています。現在、みてね事業だけで100名を超える組織となっており、この規模感での組織運営が求められています。

私たちSREチームの特徴は、各開発チームにSREが所属するEmbedded型ではなく、独立した組織として各開発チームを横断的に支援する体制を取っていることです。また、近年注目されているプラットフォームエンジニアリングの領域についても、SREが兼務する形で取り組んでいます。

組織図における赤い小さな四角で示されているSREが、独立した立場から各開発チームの技術的な支援を行っています。

よくある課題

新しいメンバーが入社した際に直面する課題について、具体的な事例から見ていきましょう。

まず、アクセス可能な情報は豊富に存在するものの、知らない情報も数多く含まれているという問題があります。例えば、「こんなSlackチャンネルがあったんだ」ということを、入社から半年や1年が経過してから初めて知るケースは珍しくありません。

さらに深刻な問題として、同じ日に入社した中途採用の同期であっても、知識習得に大きな差が生まれてしまう現象があります。同一のスタートラインに立ったはずなのに、「あの人はなぜこんなにいろいろなことを知っているのだろう」といった状況が発生します。

また、開発環境の構築段階でつまずくケースも頻繁に見られます。環境構築が予定通りに完了せず、エラーが発生して一日で作業が終わらないという経験は、多くのエンジニアが直面する課題です。



これらの現象を分析すると、根本的には2つの主要な課題に集約されます。

まず、オンボーディングの内容が実態に即していない、または情報として不十分であることが挙げられます。この結果、オンボーディングプロセスを完了した後も、新メンバーが即座に活躍できる状態に達していないという問題が発生します。

開発環境構築の手順が複雑化し、かつ難易度が高くなっていることも課題です。これらの課題認識を踏まえ、私たちは体系的な改善アプローチを検討し、実装してきました。

オンボーディングへの取り組み

オンボーディングの課題を解決するため、まず従来の仕組みの問題点を整理し、理想的なオンボーディングの定義を明確にした上で、具体的な改善策を実装していきました。

私たちの組織では、従来各グループやチームごとに独立したオンボーディングプロセスが存在していました。この分散型のアプローチには、いくつかの構造的な問題がありました。



組織レベルでは、各チームが独自のオンボーディングを持つことで、共通部分のメンテナンス性が著しく悪化していました。例えば、入社してすぐに行う手続きやツールの申請といった全社共通の作業であっても、各チームが独立したドキュメントを管理しているため、情報の更新や統一が困難でした。

また、チームごとの独立したオンボーディングによって、受講者間に知識差が発生するという問題も顕在化していました。あるチームではSlackチャンネル一覧を提供している一方で、別のチームでは開発環境の手順のみを提供するといった具合に、コンテンツの充実度にばらつきがありました。

運用面では、ドキュメントが散乱し、自分の役割に必要な知識にアクセスできないという問題も深刻でした。検索すると関連情報が大量にヒットするものの、どれが本当に必要な情報なのかを判別することが困難な状況でした。

進捗管理の面では、1ページのドキュメントに箇条書きでタスクを記載する形式を取っていましたが、完了状況や進捗を把握しづらいという課題がありました。また、ドキュメントの更新責任者が明確でなく、気付いた人がホスピタリティで修正するという属人的な運用になっていました。

課題の解決に向けて、まず理想的なオンボーディングとは何かを学術的な根拠に基づいて定義しました。組織社会化に関する研究論文を参考に、オンボーディング受講者が3つの状態を満たしていることが理想的であると設定しました。



第一に社会的受容、つまりチームの一員として受け入れられている感覚です。具体的には、チームのコードレビュー文化に安心して参加でき、「こんなこと聞いても大丈夫かな」と質問をためらうことなく、チームの雑談やコミュニケーションに気軽に参加できる状態を指します。

第二に役割の明確さ、すなわち自分の役割・責務がクリアになっている状態です。「担当するコードの責任範囲はどこか」「どういう流れでプルリクエストを出すべきか」「このチームの技術スタックは何か」といった基本的な疑問に対する回答を持っている状態を意味します。

第三に自己効力感、つまり自分ならこの仕事をやり遂げられるという自信を持っている状態です。「開発環境を一人で構築できる」「最初の簡単なチケットを自力で完了できる」「自信を持って最初のプルリクエストを出せる」といった具体的な行動に対する自信を指します。

理想のオンボーディングを実現するため、3つの主要な改善策を実装しました。

最初の改善として、チームごとに分散していたオンボーディングコンテンツを1箇所に集約し、「シラバス」として体系化しました。Notionのデータベース機能を活用し、各コンテンツを構造化して管理できるようにしました。このシラバスには、「みてねの事業を知る」「みてねの人を知る」「みてねの機能を知る」といった全社共通のコンテンツから、「Slackの歩き方」「ツールの申請方法」といった実務的な内容、さらに各チーム固有の手順まで、すべてのカリキュラムを包含しています。



次に、全てのカリキュラムを含むシラバスから、フィルター機能を用いて個人用のオンボーディングページをカスタマイズする仕組みを構築しました。具体的には、「全体受講対象」「特定事業部対象」「特定チーム対象」といった条件設定により、その人に必要なカリキュラムのみを抽出したページを自動生成します。これにより、各個人が受講すべき内容が明確になり、不要な情報による混乱を避けることができます。



最後に、個人ごとにカスタマイズしたシラバスには、各カリキュラムの完了チェックボックスを設置しました。「カリキュラムが全て完了 = オンボーディングが完了」という明確な基準を設けることで、進捗状況の可視化と達成感の向上を図りました。



今回の改善では、NotionのDatabase機能やフィルター機能を活用しましたが、これらの機能はほとんどのドキュメントツールに存在するテンプレート機能で代替可能です。また、スプレッドシートを使った実装も十分に可能であり、組織の既存ツールに合わせて柔軟に適用できる汎用的なアプローチとなっています。

また、オンボーディングの最終段階に「オンボーディングへのフィードバック」というカリキュラムを含めることで、受講者からの改善提案を収集し、それぞれの管理者が責任を持って対応する仕組みを構築しました。この仕組みにより、ドキュメントの陳腐化を防ぎ、常に最新の情報を提供できる体制を整えています。

個別の開発環境への取り組み

みてねは主にAWSを利用しており、アプリケーション基盤としてEKSを採用しています。EKS上では複数のRailsアプリケーションが稼働していますが、メインで用いるアプリケーションはモノレポで管理されています。

このメインアプリケーションが、みてねの主要機能のほとんどを担っており、概ねこのアプリケーションを自分の環境で起動できれば開発作業が可能になります。大きな機能やサービスごとに一部マイクロサービスとして切り出されている部分もありますが、ローカル開発においてはメインアプリケーションの立ち上げが最重要課題となります。



みてねは10年目を迎えるプロダクトであり、この長い歴史がもたらす技術的な複雑さが環境構築の障壁となっていました。

コードベースが非常に大きくなっており、必要なミドルウェアとそれらのバージョン管理が複雑化していました。写真や動画を扱うサービスという特性上、FFmpegやImageMagickといった専門的なミドルウェアが必要で、これらの適切なバージョンの組み合わせを個人の環境で再現することは容易ではありませんでした。

いわゆる「おま環」問題による個別環境でのトラブルシュートの困難さも深刻でした。同じ手順を実行しても、個人の開発環境の違いにより異なる結果が生じるため、SREチームによるサポートが非常に困難でした。

さらに、みてねの組織文化として、デザイナーもLP作成やデザイン修正においてGitを操作する文化があります。初めてターミナルを触るデザイナーにとって、複雑な環境構築手順は大きな負担となっていました。

これらの課題を解決するため、私たちは「Sandbox環境」と呼ぶクラウドベースの個人開発環境を導入しました。この名称は弊社での内部的な呼び名です。

Sandbox環境の基本的な仕組みは、EKS上に個人個人の作業環境をDeploymentとして作成することです。DeploymentのテンプレートはHelmを使用してSREが管理し、Visual Studio CodeやIntelliJ IDEAなど、任意のエディタのRemote SSH機能を使用して開発作業を行います。

利用者が行う作業は、個人設定用のyamlファイルを作成してGitHubにプッシュするだけです。このファイルをArgoCD が検知し、事前に準備されたHelmテンプレートを使用してSandbox環境を自動構築します。構築完了後は、Remote SSH接続により、すべての依存関係が整った状態の開発環境にアクセス可能になります。



Sandbox環境の導入により、複数の具体的な改善効果が得られました。

個別環境におけるトラブルシュートが大幅に簡略化され、ゼロから個人の開発環境を立ち上げて開発着手するまでの時間が約1時間程度まで短縮されました。各種関連ツールのバージョンが統一されることで、バージョン起因の問題が解消されました。

一方で、現在も課題が残っています。EKSのバージョンアップなどの際には全員の環境が一時瞬断するので、事前の調整やアナウンスが必要になります。また、海外から開発する際に、SandboxのEKS Clusterは東京リージョンで稼働しているため、操作が快適ではないという問題があります。



そのほか、運用面では様々な工夫を施しています。GitHub Codespacesの利用も検討しましたが、認証周りや開発時の体験などを総合的に判断し、Sandboxに機能追加することで導入は見送りました。

Go製のCLIツールを提供し、AWSの認証やSandboxの起動・停止などを容易に行えるようにしています。開発が行われない業務時間外はSandboxを停止し不要なNodeを削減して、コスト削減を行っています。SREが直接Sandbox環境にSSHしてサポートを行うことも可能になり、リモートワーク環境での技術支援が効率化されました。

個々のyamlによるカスタマイズも可能で、起動時間の個別設定、利用するimageの更新、x86_64とaarch64の切り替えなどに対応しています。

まとめ

今回ご紹介した2つの取り組みを通じて、私たちは新メンバーが初日から活躍できる環境の構築を実現しました。

まずは、「一元管理と個別提供による最高のオンボーディング」です。従来のチーム個別管理から全体一括管理への移行を実現しました。

次に、「個別の開発環境（Sandbox）でDay1から活躍」です。従来数日を要していた環境構築を約1時間に短縮し、技術的なハードルを大幅に削減しました。

これら2つの施策を合わせることで、新メンバーの開発生産性を最大限に引き上げることができました。環境構築や情報収集に費やされていた時間を本来の業務に充てることで、組織全体のアウトプット向上に寄与しています。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です