DMMプラットフォームのマイクロサービスアーキテクトグループのエンジニア募集について

このドキュメントは何?

このドキュメントは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プラットフォーム内の各チームのコードレビュー（Goのみ）

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

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

認証認可には直接関係ありませんが、"DMMプラットフォーム内の各チームのコードレビュー"を実施しているのは特徴的な点だと思います。 これは毎週決まった時間を確保して、各チームのGoのコードをレビューしています。 これは業務というよりも「やりたかったらやってもいいですよ」という感じのボランティア活動のようなものです（ボランティア活動といっても残業して活動するわけではないです）。 他チームのコードをレビューすることで、アプリケーションアーキテクチャに関するスキルを伸ばすことできます。

コードレビューを担当したエンジニアの中には、レビュー過程で得た知見を以下のようにアウトプットしてくれている人もいます。

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

SREチーム

SREチームはDMMプラットフォームのインフラ領域を担当するチームです。 SREというとGoogleのSREをイメージするかもしれませんが、マイクロサービスアーキテクトグループのSREは以下の職種を兼任している形になります。

  • SRE
  • プラットフォームエンジニア
  • クラウドインフラエンジニア

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

中長期的に見るとクラウドインフラの構築やプラットフォームエンジニアリングが落ち着いてくるので、 そのタイミングで本来のSREとしての業務に集中できるような環境になっていると思います（ただ、そのときにはチームもある程度拡大している想定なので、組織体制が変わっていると思います）。

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

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

SREチームは前述の通り、クラウドインフラの構築とプラットフォームエンジニアリングに注力しています。 現在はクラウドインフラの構築は落ち着いており、 k8sのエコシステム導入（サービスメッシュなど）やk8sを利用する際に必要になる周辺の仕組みを構築しています。

k8sを利用する際に必要となる周辺の仕組みというのは"k8sのマニフェストを管理する仕組み", "共通インフラの権限管理の仕組み" などです。 これらはk8sではなく、TerraformやCIを作り込むことによって実現しています。

Developer Productivity Team

Developer Productivity Teamチームは "認証認可チームが担当する認証認可領域"、"SREチームが担当するインフラ領域" 以外の領域を担当し、DMMプラットフォームの開発効率向上を目指すチームです。

マイクロサービスアーキテクトグループが設立された当初、Developer Productivity Teamは存在しておらず、 認証認可チームが認証認可領域以外のあれこれも幅広く担当していました。 例えば以下です。

  • 負荷試験基盤の開発
  • Datadogの利用ルール統一
  • リリース前検証ルールの策定 & 推進
  • テスト戦略の作成 & 推進
  • Findy Teamsによる各チームの開発効率可視化 & 改善

しかし、DMMプラットフォーム内で認証認可領域のニーズが高まったことで、 今まで通り認証認可チームが認証認可領域以外に工数を割くのが難しくなってきました。

そこで認証認可チームは認証認可領域に特化させるために新しく設立されたのがDeveloper Productivity Teamというチームです。 前述の通り、Developer Productivity Teamチームは認証認可領域、インフラ領域以外の領域を担当するので、 守備範囲がとても広いチームとなります。

当然扱う技術も多岐にわたります。 認証認可チームのようにサーバサイドエンジニアに特化するわけでもなく、 SREチームのようにインフラ領域に特化するわけでもなく、 組織の開発効率を向上させるために手段を選ばず適切な技術を扱う必要があります。

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

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

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

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

  • 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
  • Confluence
  • Google Workspace

認証認可チーム独自のテクノロジースタック

認証認可チームはオンプレにPHP, Javaで書かれたレガシーなアプリケーションが存在するので、 （リプレイスが完了するまでは）共通のテクノロジースタックに加えて以下を利用することがあります。

  • Java
  • PHP
  • オンプレ環境
  • CircleCI
  • Jenkins

SREチーム独自のテクノロジースタック

特にありません。

Developer Productivity Team独自のテクノロジースタック

特にありません。

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

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

  • 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に相談可能なので、 「アウトプットしてみたい」というやる気さえあれば大丈夫です。 資料作成も業務時間を利用することができます。

デメリット

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

マイクロサービスアーキテクトグループは以下のチームに分かれており、 それぞれ守備範囲が決まっています。

  • 認証認可チーム
  • SREチーム
  • Developer Productivity Team

そのため「フロントエンドからインフラまで全部担当したい」というゼネラリスト志向のエンジニアはマッチしません。 むしろ「特定の領域を極めたい」というスペシャリスト志向のエンジニアがマッチします。

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

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

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

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

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

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

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

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

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

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

twitter.com

meety.net

中途採用の応募について

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

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

就業型インターンとは?

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