このドキュメントは何?
現在もエンジニアを募集しているのか?
DMMプラットフォームとは?
マイクロサービスアーキテクトグループとは?
マイクロサービスアーキテクトグループが設立された背景
マイクロサービスアーキテクトグループの組織体制
利用するテクノロジースタックとツール
- 各チーム共通となるテクノロジースタック
- 各チーム共通となるツール（技術領域以外のもの）
リモートワーク環境におけるコミュニケーションツール
マイクロサービスアーキテクトグループの開発の進め方
どのような人を求めているのか?
マイクロサービスアーキテクトグループに参加するメリデメ
- メリット
- デメリット
  - ゼネラリスト志向のエンジニアにはマッチしない
  - 開発作業だけしていたいエンジニアにはマッチしない
pospomeとのカジュアル面談について
中途採用の応募について
学生向け就業型インターンの応募について
- 就業型インターンとは?
- 就業型インターンの応募について
よくある質問

このドキュメントは何?

このドキュメントはDMMプラットフォームのマイクロサービスアーキテクトグループという開発組織に関するドキュメントです。 pospomeがカジュアル面談で話す内容をまとめています。

主に採用を目的としたドキュメントになります。

現在もエンジニアを募集しているのか?

結論から言うと募集しています。

中長期的に見るとエンジニアは異動や退職によってチームを離れることになるので、そもそも募集を停止する予定がないです。ただし、チーム状況によって採用者数や求めるレベル感は変わります。

どのチームも募集中なので興味のある方はカジュアル面談でお話しましょう。

DMMプラットフォームとは?

DMMプラットフォームについて説明する前にDMM全体の組織構造についてザックリと説明します。

DMMは多くのWebサービスを運営しており、（実際のものとは異なりますが）各サービスごとに部署が存在します。各部署には技術面の決定権が与えられており、部署ごとに自由に開発体制や開発方針を決めることができます。 DMMプラットフォームというのは、こういった部署の1つになります。

/DMM.com
    /動画配信部
    /電子書籍部
    /オンラインサロン部
    /DMMプラットフォーム部

補足
>各部署には技術面の決定権が与えられており
こういった側面により「DMMではこうやっています」という技術の話ってあまりないんですよね。
「DMMプラットフォームではこうやっています」
「電子書籍部ではこうやっています」
みたいな部署単位の話になりがちです。

セキュリティ部やインフラ部のような組織横断で活動する部署もあったりするので、
そういった部署だと「DMMではこうやっています」と言えるかなと思います。

ということで、DMMプラットフォームはDMMの各種サービスで共通利用される機能を提供する部署のことです。例えばDMM会員のマイページや決済用のWebAPIを開発しています。領域としては主に以下を扱います。

DMM会員の認証認可
DMM会員の情報
決済
DMMポイント
不正対策
カスタマーサポート

2022年10月の現在で所属しているエンジニアは120名ほどなので、 1つの部署とはいえ、それなりに大きな開発組織となっています。そして、開発規模の関係上、2016年頃からマイクロサービスアーキテクチャを採用しています。 2022年10月の現在で約30~40のマイクロサービスが存在しています。

マイクロサービスアーキテクトグループとは?

マイクロサービスアーキテクトグループの目的はDMMプラットフォームの開発効率とセキュリティレベルを向上させることです。具体的には120名のエンジニアが共通利用するツールや仕組み（エコシステム）を開発・運用します。

マイクロサービスアーキテクトグループが設立された背景

マイクロサービスアーキテクトグループが設立された背景はシンプルで、「120名のエンジニアが共通利用するツールや仕組み（エコシステム）が存在しなかったから」というものになります。

背景については以下にまとまっているので興味のある方は読んでみてください。

マイクロサービスアーキテクトグループの組織体制

マイクロサービスアーキテクトグループの内部は以下のチームに分かれています。

認証チーム
認可チーム
プラットフォームチーム
SREチーム
Developer Productivity Team

それぞれのチームについて説明します。

認証チーム

認証チームはDMMプラットフォームの認証を管理するチームです。（中長期的には変更があるかもしれませんが）主に以下の機能を開発・運用します。

DMM会員の認証
社内システムの認証
マイクロサービス間通信の認証
レガシーアプリケーションのリプレイス

認証チームという名前の通り、メインで担当するのは認証領域です。 DMM会員の認証だけでなく、社内システムやマイクロサービス間通信など、 DMMプラットフォーム内のありとあらゆるリソースに対して認証を提供します。

認証というと地味な印象を受けるかもしれませんが、認証チームが管理する認証基盤はDMMの中でも最もミッションクリティカルであり、負荷の高いアプリケーションです。認証基盤が落ちると、DMMの全サービスが落ちます。高い可用性と低いレイテンシが必須なので、サーバサイドエンジニアとしてチャレンジングな環境だと思います。

認可領域にはレガシーなアプリケーションが存在します。これらはオンプレで動作しており、Java で書かれているので、クラウド化し、Goでリプレイスしている最中です。

リプレイスは大変なイメージがあるかもしれませんが、レガシーアプリケーションへの機能追加などはストップしており、リプレイスにフルコミットしているので、意外とスピード感を持って取り組めています。

DBにはTiDBを採用しているので、分散DBに興味がある方は楽しめるかもしれません。認証チームのTiDBの活用については以下が参考になります。

扱う領域は認証ですが、職種としてはサーバサイドエンジニアになります。

認可チーム

認可チームはDMMプラットフォームの認可を管理するチームです。（中長期的には変更があるかもしれませんが）主に以下の機能を開発・運用します。

認可サーバの開発・運用
社内外向けDeveloper Siteの開発・運用

認可チームという名前の通り、メインで担当するのは認可領域です。 OAuth 2.0, Open ID Connect を実装している認可サーバの開発・運用が主な業務です。認可機能はDMMの各種サービスで利用されており、DMM全体を支える重要な技術領域となっています。

実は認可チームが管理する認可基盤も認証チームと同様にDMMの中でも最もミッションクリティカルであり、負荷の高いアプリケーションです。認可基盤が落ちると、DMMの全サービスが落ちます。認証チームと同様にサーバサイドエンジニアとしてチャレンジングな環境だと思います。

認可領域にはレガシーなアプリケーションが存在します。これらはオンプレで動作しており、PHP で書かれているので、クラウド化し、Goでリプレイスしている最中です。

認証チームと同様にDBにはTiDBを採用しており、レガシーアプリケーションへの機能追加などもストップしいます。

扱う領域は認可ですが、職種としてはサーバサイドエンジニアになります。

プラットフォームチーム

プラットフォームチームはDMMプラットフォームのインフラ領域の開発・運用を担当するチームです。

DMMプラットフォームにはインフラ領域のエコシステムが存在しなかったこともあり、現在は共通利用できるクラウドインフラ（AWS, GCP）の構築やプラットフォームエンジニアリングを優先的に取り組んでいます。

（中長期的には変更があるかもしれませんが）主に以下の機能を開発・運用します。

k8sを中心とした共通インフラの構築・運用
k8sのエコシステム導入・運用
GCP/AWS上のリソース構築
共通インフラの利用者ワークフロー構築・改善
CD Pipeline の構築・運用
インフラ費用の最適化

現在はk8sのエコシステム導入（サービスメッシュなど）やk8sを利用する際に必要になる周辺の仕組みを構築しています。周辺の仕組みというのは"k8sのマニフェストを管理する仕組み", "共通インフラの権限管理の仕組み" などです。これらはk8sではなく、TerraformやCIを作り込むことによって実現しています。

プラットフォームチームの社外アウトプットは以下にまとめています。

www.pospome.work

SREチーム

SREチームはDMMプラットフォームの可用性を可視化・改善を担当するチームです。

DMMプラットフォームはDMMの各種サービスから利用される共通機能を開発する関係上、可用性が低下してしまうと、多くの損失が発生してしまいます。この損失を可能な限り防ぐのがSREチームの役割です。

国内の企業で "SRE" というと、実質クラウドインフラエンジニアだったり、プラットフォームエンジニアだったりするケースが多いと思いますが、 DMMプラットフォームのSREチームはシステムの可用性と信頼性にフルコミットするチームです。

主に以下のような活動をします。

SLI/SLOの導入
各チームの運用改善（Embedded SREとしての活動）
インシデント管理の改善
機会損失額の可視化と改善
障害対応ワークフローの改善
DMM全体の可用性改善

SREチームは可用性に関係のある領域を横断的に担当しますが、特徴的なのが "DMM全体の可用性改善" です。マイクロサービスアーキテクトグループの各チームはあくまでDMMプラットフォーム内の活動に閉じていますが、 SREチームだけはDMM全体の可用性改善に取り組んでいます。数百人のエンジニアが所属する組織に統一的な仕組みやルールを導入するのは難易度の高い取り組みになりますが、その分エンジニアとしてのスキルアップやエンジニアリングの面白さを体験することができると思います。

Developer Productivity Team

Developer Productivity TeamチームはDMMプラットフォームの開発効率向上を目指すチームです。組織の開発効率を向上させるために手段を選ばず適切な技術を扱う必要があります。例えば以下のような活動をします。

各チームのコードレビュー（Go言語に限る）
負荷試験基盤の開発
E2Eテスト戦略の策定 & 推進
ユニットテスト戦略の策定 & 推進
Findy Teamsによる各チームの開発効率可視化 & 改善

チームの特徴として "DMMプラットフォーム内の各チームのコードレビュー"を実施している点があります。ソフトウェア開発の主な作業はコーディングであり、コード品質は開発効率に直結するということで、 Developer Productivity Teamではコード品質の向上に注力しています。他チームのコードをレビューすることで、アプリケーションアーキテクチャに関するスキルを伸ばすことできます。コードレビューを担当したエンジニアの中には、レビュー過程で得た知見を以下のようにアウトプットしてくれている人もいます。

利用するテクノロ ジースタックとツール

ここでは各チームで利用するテクノロジースタックとツールについて説明します。

各チーム共通となるテクノロ ジースタック

マイクロサービスアーキテクトグループでは以下のテクノロジースタックを利用します。

Go言語
GCP/AWS
k8s(GKE & EKS)
Datadog
ArgoCD
GitHub Enterprise Cloud
GitHub Actions
Terraform
Pager Duty
Autify

ただし、それぞれのテクノロジースタックの利用頻度と得られる習熟度はチームによって異なります。

例えば認証チームはGo言語を利用したサーバサイド実装がメインなので、Go言語の利用頻度が高く、得られる習熟度も高くなりますが、 SREチームはCloud FunctionsなどのFaaSにてGo言語を利用したスクリプトを書く程度です。一方でSREチームはk8sの構築から運用まで担当するので、k8sの利用頻度が高く、得られる習熟度も高くなりますが、認証チームはマニフェストファイルを書く程度です。

各チーム共通となるツール（技術領域以外のもの）

マイクロサービスアーキテクトグループでは以下のツールを利用して開発を進めます。

Zoom
Slack
Discord
JIRA/ZenHub
Confluence
Google Workspace

リモートワーク環境におけるコミュニケーションツール

マイクロサービスアーキテクトグループはリモートで業務をしています。リモートワーク環境のコミュニケーションツールは以下です。

Slack
Discord
Zoom

マイクロサービスアーキテクトグループの開発の進め方

マイクロサービスアーキテクトグループではスクラムを採用しているので、スクラムイベントベースで開発が進んでいきます。

Daily Standupによる進捗確認

Daily Standupというミーティングを毎日実施し、チーム内のタスクの進捗共有をしています。困っていることを共有したり、成果物の中間レビューを依頼したり、雑談をすることもあります。比較的自由にコミュニケーションを取れる場です。

Daily Standupの時間は大体30min程度です。時間帯はチームによって異なりますが、11:00 ~ 17:00に収まるようになっています。

プランニングによる作業実行計画

マイクロサービスアーキテクトグループは2週間スプリントなので、 2週間に1回プランニングを実施します（次の2週間で何をやるのか計画する）。

新規タスクの優先度確認ミーティング

マイクロサービスアーキテクトグループでは週一で新規タスクの優先度確認ミーティングをしています。

マイクロサービスアーキテクトグループでは「何かやりたいことや改善したいことがあったら自由にJIRAチケットを切る」という文化があり、 1週間で数枚の新規JIRAチケットが作成されます。

優先度高くやった方がいいものから、優先度の低いものまで様々なチケットがどんどん作成されていくので、週に一度それらを確認し、優先度高く対応するかどうかを判断しています。対応するかどうかは各チームのテックリードが判断します。

KPTミーティング

マイクロサービスアーキテクトグループでは毎週KPTミーティングをしています。 KPTというのは Keep, Problem, Tryを出し合うというアレのことです。

本来であれば業務上の Keep, Problem, Try を出し合い、良かったことは継続し、問題点は改善するための議論をすると思うのですが、マイクロサービスアーキテクトグループのKPTでこういった議論をすることはほぼありません。

なぜかと言うとマイクロサービスアーキテクトグループは日々の"Daily Standup"や"新規タスクの優先度確認ミーティング"によって、 KPTに相当する議論をリアルタイムで実施していることもあり、わざわざKPTの時間でそれらを共有する必要性がないからです。

結果的にマイクロサービスアーキテクトグループのKPTはチームメンバー同士のコミュニケーションの場として機能しており、プライベートであったKPTを共有し合う時間帯となっています。

見ているアニメの話
新作ゲームの話
筋トレの話
最近飲んだお酒の話

リモートワークということもあって、こういったコミュニケーションの場を意図的に用意するのも悪くないなと思っています。

個人の判断で必要に応じてミーティング

スクラムイベント以外にも必要に応じてチームメンバー同士でミーティングをしています。「ここが分からないから教えて欲しい」的なトラブルシューティングが主な目的となっていますが、それに限らずチームメンバー同士で自由にやりとりしています。

Slackで「今話せますか?」というメッセージを送って随時相手の都合を確認することが多い気がしますが、予めGoogleカレンダーの空いている時間帯に予定を入れておくことも可能です。

どのような人を求めているのか?

カジュアル面談で「どのようなエンジニアを求めていますか?」と質問されることがあります。

結論から言うとpospomeは"基礎力のある人"という言い方をしています。

"基礎力のある人"というのは明確な定義があるわけではなく、面接した人全員が「この人ならチームで高いパフォーマンスを出してもらえそう」と感じた人を採用するということです。「パフォーマンスを出せそう」と感じたのであればGo言語が使えなくても、k8sを触ったことがなくても問題ありません。

チームにはシニアエンジニアからジュニアエンジニアまで幅広い層が所属していますし、チームが抱えるタスクの難易度も様々なので、決して狭き門というわけではないです。

マイクロサービスアーキテクトグループに参加するメリデメ

マイクロサービスアーキテクトグループにおいて特徴的なメリットとデメリットを説明しようと思います。

メリット

マイクロサービスアーキテクチャに携わることができる

DMMプラットフォームではマイクロサービスアーキテクチャを採用しています。

マイクロサービスというのは開発規模の大きさによって難易度が大きく変わりますが、 100人を超えるDMMプラットフォームのマイクロサービスは、それなりに大きな規模なので他社ではなかなか経験できないものになっていると思います。

組織的な技術戦略に携わることができる

一番のメリットは100人を超える開発組織の技術戦略を考えることができることかなと思っています。技術力だけではなく、ドキュメンテーションスキルやコミュニケーションスキルなど、エンジニアとして活動していく上で必要となるスキルを全体的に向上させることができます。

前述したとおりDMMプラットフォームでは、マイクロサービスアーキテクチャを採用しているので、 "組織的な技術戦略 = マイクロサービスアーキテクチャの技術戦略" であることが多いです。マイクロサービスを経験すると分かると思いますが、マイクロサービスというのは1つのマイクロサービスを開発・運用しているだけだとモノリスとあまり変わりません。通信周りの技術的課題が増える程度だと思います。

しかし、マイクロサービスアーキテクチャの技術戦略を担当する立場になると話が違ってきます。「この規模の開発組織の開発効率やセキュリティレベルをどのように向上させるのか?」を考えることになるので、一般的なWebアプリケーション開発とは違ったスキルが必要になります。組織の特性や現在の状況によってどういった技術戦略を選択すべきか、どういった世界を目指すのかが変わってくるので、なかなか面白い領域だと思います。

CTOやアーキテクトなどのエンジニアの1つ上のレイヤを目指す人にはマッチする組織だと思います。

アウトプットの推奨について

本記事のチーム紹介でいくつかチームとしてのアウトプット（ブログや登壇資料）を載せていますが、マイクロサービスアーキテクトグループではアウトプットを推奨しています。

「推奨している」と言っても、人によってはなかなかハードルが高いと思うので、 pospomeから「xxx をアウトプットしませんか?」という打診をしています。当然強制ではないです（実際に断っているメンバーもいます）。

具体的に何をアウトプットするのか?
どういったアウトラインにするのか?
内容に間違いはないか?

という部分も必要に応じてpospomeに相談可能なので、「アウトプットしてみたい」というやる気さえあれば大丈夫です。資料作成も業務時間を利用することができます。

デメリット

ゼネラリスト志向のエンジニアにはマッチしない

マイクロサービスアーキテクトグループは "スペシャリスト集団による品質の高いプロダクト開発" をコンセプトとして持っているので、「フロントエンドからインフラまで全部担当したい」というゼネラリスト志向のエンジニアはマッチしません。むしろ「特定の領域を極めたい」というスペシャリスト志向のエンジニアがマッチします。

＊大きな規模の組織になると、ある程度分業制で開発を進めるのが一般的だと思うので、マイクロサービスアーキテクトグループ特有の話ではないかもしれないです。

開発作業だけしていたいエンジニアにはマッチしない

マイクロサービスアーキテクトグループは組織的な技術戦略を策定・推進していくという性質上、開発作業だけでなくドキュメンテーションやコミュニケーションに時間を割く必要があります。

例えばプロダクトの開発からリリースまでの流れをザックリ書くと以下になります。

組織内の課題を確認するために各チームとコミュニケーションを取る。
PRD, Design Doc を書く。
開発する。
利用者向けの利用ガイドを書く。
リリースする。
利用者に対してプロダクトの利用を促す（サポートする）。

必要に応じてというのが前提にはなりますが、 1,6番は各チームとのコミュニケーション作業になり、 2,4番はドキュメンテーション作業になります。

マイクロサービスアーキテクトグループで開発するプロダクトや機能は、基本的に各チームに利用してもらう必要があるので、利用してもらうためのコミュニケーションやドキュメンテーションは欠かせません。

そのため「開発作業以外のことをしたくない」という方はマッチしません。

pospomeとのカジュアル面談について

マイクロサービスアーキテクトグループに興味のある方はMeetyとTwitterのDMにてカジュアル面談依頼が可能です。

中途採用の応募について

以下のURLから応募することができます。

SREチーム
https://dmm-corp.com/recruit/engineer/123/
プラットフォームチーム
https://dmm-corp.com/recruit/engineer/3600/
SREチーム以外のチーム（応募フォームを統一しています）
https://dmm-corp.com/recruit/engineer/822/

学生向け就業型インターンの応募について

就業型インターンとは?

DMMでは"DMM Guild"という学生向けのインターン制度があり、 DMM内に存在する実際の業務タスクを特定期間（今だと2週間）こなしていくというものになっています。
https://dmm-corp.com/recruit/intern/engineer/guild/

しかし、それ以外に就業型インターンというものもあります。就業型インターンは"特定のチームに入ってインターンをする"というもので、要はアルバイトのようなものです。時給制でお給料が出ます。

DMM Guildは比較的短期間で時期が固定されていますが、就業型インターンは1年中募集しているアルバイトのようなもので "週3で半年間", "週4で1ヶ月" みたいな形で比較的長期間のインターンが可能な制度となっています。インターン中は特定のチームに入って一緒に作業してもらうことになるので、 DMM Guild よりも実際の開発業務に近い形で開発を経験することができます。

対象は大学在学中の学生となっているので、それ以外の方は対象外となっています。

就業型インターンの応募について

以下から応募することができます。
https://dmm-corp.com/recruit/intern/engineer/working/

就業型インターンはインターンを受け入れることができる開発チームの中から配属先を選ぶことになりますが、もしマイクロソフトサービスアーキテクトグループでインターンしたい場合は、応募後の人事とのやりとりで「マイクロソフトサービスアーキテクトグループでインターンしたい」と言ってもらえると話が早いかと思います。ただし、インターンの受け入れには書類審査や面談があるので、必ずしもインターンできるとは限りません。

よくある質問

リモートワークですか?

現在はリモートで作業しています。 PCや書類も基本的に配送で完結するので、出社する機会はないと思います。ただし、フルリモートというわけではないので、会社の判断（業務命令）で出社する可能性はあります。

オフィスに出社できますか?

許可を取れば出社できます。ただ、会社全体がリモートに移行したこともあり、フリーアドレス席や備品が限られているので、自宅の方が快適に作業できると思います。

残業はありますか?

デッドラインがあるようなプロジェクトにアサインされると残業が発生する可能性はあります。ただ、実績としてpospomeは今のチームで残業が必要になったことはないです（作業のキリが悪くて残業することはあります）。

新しい技術を採用することは可能ですか?

可能です。

ただし、決定権は各チームのテックリードにあるので、テックリードに承認をもらうために解像度高く具体的なメリデメを提示する必要があります。さすがに「使いたいから」では通りません。

どのような福利厚生がありますか?

福利厚生は以下にまとめられています。
https://dmm-corp.com/recruit/benefits/

エンジニア向けのものは以下です。
https://inside.dmm.com/entry/2019/01/15/dmm-tech-empowerment