サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2 id="はじめに">はじめに</h2>

EXNOA プラットフォーム事業 プロダクト本部 基盤チームの井原です。 
私は2021年8月に入社なのですが、最近はフルリモート勤務ということもあり、体重の増加に怯える日々を送っています。

さて、今回は基盤チームとして初めての執筆なので、基盤チームについての紹介と、具体的な開発事例を交えた働き方や、今後の展望などを紹介させていただきます。

<h2 id="基盤チームでやっていること">基盤チームでやっていること</h2>

<img alt="" height="540" src="https://image.dmm-corp.com/zr0irrg5jka3usaun0fknjcr4h23" width="600" />

<center>
&nbsp;
</center>

一般的に「基盤チーム」というと、データ基盤やサービス基盤、開発基盤、技術基盤というような文脈を頭に浮かべる方が多いと思います。

EXNOAのプラットフォーム事業、プロダクト本部における基盤チームでは、「各ビジネスの業務を加速させるため、プロダクト間・プロダクト内の問題解決のため調査・設計・開発・サポートを行う」という方針のもと、「開発基盤」や「サービス基盤」といった部分に対する業務を行っています。&nbsp;

具体的に扱っている基盤システムとしては以下のようなものがあります。

<ul>
	<li>CIやCDを行うためのシステム</li>
	<li>ログ基盤</li>
	<li>認証に関するシステム</li>
	<li>開発者それぞれに割り当てる開発環境　などなど</li>
</ul>

今回はこの中で、認証に関するシステムの紹介をしつつ、基盤チームでの働き方をご紹介します。

<h2 id="認証認可基盤システムの開発">認証・認可基盤システムの開発</h2>

<img alt="" height="360" src="https://image.dmm-corp.com/amzokzn9j946dozg4hdmev514i0x" width="600" />

<h2 id="認証認可システムの乱立">認証・認可システムの乱立</h2>

EXNOAに限らず、組織の規模が大きくなるに伴って部署の数も増えていきます。そして部署の数が増えるほど、内部で業務に使われるシステムやサービスの数も同様に増えてしまいます。

特に現代のエンジニアが開発を行うにあたり、自分のローカルPCの中で開発が完結するということはまれで、GitHubを始めとした外部のサービスを利用することは当たり前の状態になっています。

&nbsp;

そういった複数のシステムに対する認証・認可の機構として、EXNOAでは元々Azure AD(Active Directory)を導入しています。

ただ、これまでこのAzure ADでの認証・認可が行われるのはDMMグループ全体で利用しているシステムに限られ、内部のエンジニアが開発したシステムでAzure ADを利用することはできていませんでした。

つまりそれぞれのシステムごとに独立した認証・認可の仕組みを導入していたのです。

加えて、それぞれのシステムでAzure ADを利用すること自体はできたのですが、許可されているのは認証機能のみで、認可については詳細なコントロールができませんでした。

具体的な例で言えば、ログインするための認証に関してはAzure ADにフェデレーションすることで機能を任せることができますが、ログインした後の「このユーザーは一般ユーザーなのか、管理ユーザーなのか、承認などを行うことができる権限を持たせていい役職なのか」といった認可情報をAzure ADから取得するところまではできていなかったのです。

&nbsp;

そこで基盤チームでは、内製システムでもAzure ADでのログインを手軽に利用できるようにし、かつ認可のコントロールを行うことができるよう、まずは基盤チームで開発したシステムにその仕組みを取り入れ、そこから各プロダクトごとの開発チームに展開していこうと考えました。

<h3 id="認証認可基盤の開発">認証・認可基盤の開発</h3>

認証・認可基盤の開発・展開をしていくにあたり、CI/CDに利用しているJenkinsサーバのソリューション化という案件を、今回のリーディングプロジェクトとすることに決定しました。

当時、プロダクト本部には一つの巨大なJenkinsサーバがありました。

その巨大なJenkinsサーバにはトータルで500近いジョブがあり、10以上のチーム、150名近いメンバーが触っていたため、ジョブ実行の混雑はもちろんのこと、ジョブそのものの管理も限界に達していました。

そこで基盤チームではこの問題を解決するため、それぞれの開発チームごとに独立したビルド・デプロイのシステムを開発・提供しようとしていました。

単なるビルドのみであればそれほど必要にはならない認可の機能ですが、デプロイを行うとなると、誰でも実行できてしまうようでは困ります。

そのため認可は必須となるものの、前述のようにAzure ADを利用する場合、認可が利用できません。

そこで取った手段は「Azure ADは認証としてのみ使い、認可に関してはAmazon Cognitoを利用する」というものでした。

<img alt="" height="654" src="https://image.dmm-corp.com/kyiaffmxp27kybsv2gxoqejokn0w" width="622" />

&nbsp;

これにより、開発したビルド・デプロイシステムは「全社で利用しているAzure ADの仕組みでログインが可能（パスワードなどを別途設定する必要はない）で、それぞれのメンバーごとに詳細な権限を設定した認可を行うことができる」という仕組みで提供することができるようになりました。

導入に関しても、この仕組みはAmazon Cognitoを利用しているだけなので、Cogtnitoを通常使用するのと同様の手順で導入するだけで、特に難しいことはありません。

<h3 id="各開発チームとの調整">各開発チームとの調整</h3>

ここまでで基盤そのものの開発はできてきました。しかし、そのままでは導入することができません。

それぞれの開発チームごとに権限の設定をする必要があるためです。

これに関しては基盤チームだけで解決できるものではないので、それぞれの開発チームに対してヒアリングを行い、どういった権限設定を行うべきかを洗い出していく、といった調整を行いました。

&nbsp;

また、今回の案件はCI/CDのソリューション案件であるため、既存ジョブの移行などもありました。

こちらについても権限設定と同様に、それぞれの開発チームからのヒアリングや調整といった基盤チーム特有の動き方が必要となり、部署を横断した組織ならではの働き方の特徴が現れていると言えます。

<h3 id="認証認可基盤の導入">認証・認可基盤の導入</h3>

こうしてCI/CDのためのソリューションとして開発したシステムに対し、認証・認可基盤を導入した状態で各開発チームに展開することができました。

本来であれば各開発チームそれぞれのサーバでアカウントを作成・管理しなければいけないところですが、認証・認可基盤によってAzure ADでのアカウントでそのままログインすることができるようになりました。

&nbsp;

そしてこの認証・認可基盤のシステムはAmazon Cognitoを中心に置いているため、今後、認証や認可が必要なシステム開発があった際にも気軽に連携することができます。

特に社内システムの開発において認証・認可は不可欠なので、今後も活躍の機会は存分にあると考えています。

&nbsp;

<h2 id="基盤チームとしてのミッション">基盤チームとしてのミッション</h2>

<img alt="" height="600" src="https://image.dmm-corp.com/8460c4ls4e2185d3nvnd4bdckov7" width="600" />

基盤チームの業務の一例として認証・認可基盤を紹介しましたが、ここまでで基盤チームとして重要となる3つの要素が出てきました。

&nbsp;

1つはプロダクト開発の経験値です。「その環境においてプロダクト開発を行うにあたり、どんなエコシステムが必要になるのか、そして今は何が足りないのか、それを満たすために何ができるのか」といったことを、あらゆる可能性から導き出すことが求められます。今回の例では「既存のシステムではそれぞれ独自に認証・認可の機能を作っている」「できることなら一つにまとめたい」「Azure ADを使うことはできる」といった現状の分析から、「認可の機能が足りない」「AWSのAmazon Cognitoを利用すれば満たすことができそう」という結論を導き出すために必要な要素でした。

&nbsp;

もう1つは上記のような仕組みを実現するための技術力。基盤チームでは、例えば論文を読んでそれを実装するとか、数学的な分析に基づいてMachine Learningのモデルを作成するといった高度な作業は発生しません。しかし、上で述べたような、「必要なものを必要なだけ構築するための技術力」は必要になってきます。

&nbsp;

最後に、コミュニケーション能力です。基盤チームの仕事はどうしてもチームや部署を横断する業務が多くなるため、そういった基盤チームの外の人間とのやり取りが発生します。基盤チームには基盤チームのスケジュールや考えがあるように、各チームにもスケジュールや考え、都合があります。そうした中で、各チームとうまく連携していくためのコミュニケーション能力も外せない要素となっています。

&nbsp;

上記のことから、今まで培ってきた開発における経験値や技術力を、今度は開発メンバーに対して提供していくことにより組織全体の開発体験や品質の向上を図っていく、というのが基盤チームのミッションとなります。

<h2 id="基盤チームの今後">基盤チームの今後</h2>

基盤チームの今後の取り組みについては、まずは開発した各種基盤システムを、まだ導入が進んでいないチームに対し、導入支援していくことが挙げられます。

基盤システムは作っただけでは何の意味もなく、開発チームを始めとしたプロダクトのフローに組み込まれる必要があります。

そのため、基盤システムの開発が完了した後は、まず各開発チームへの周知を行って存在を知ってもらい、導入してもらうためにドキュメント化や説明を適宜行っていきます。

依頼をベースとした作業であればいいのですが、基盤チームが主体となってヒアリングから進めているような案件では、日々各プロダクトのメンバーから情報収集を行い、独りよがりのシステム開発になってしまわないよう留意していかなければなりません。

<h2 id="まとめ">まとめ</h2>

ここまでで基盤チームで扱っているシステムや業務、どういった仕事をしているかなどを紹介させていただきました。

基盤システムも一つのプロダクトであり、ユーザーがコンシューマーではなく社内のエンジニアという違いはあれど、プロダクトを成長させるために必要なことは同じではないでしょうか。

一般に「エンジニア」という単語で言われるような働き方とはまた少し違った世界ではあるとは思いますが、私たちのような「エンジニアのサポートをするためのエンジニア」の仕事に興味を持つ方が一人でも増えていただければ幸いです。

&nbsp;

最後に、EXNOAではゲームプラットフォーム「DMM GAMES」の基盤システムを共に改善していける仲間を募集しています。ご興味のある方は以下の募集ページをご確認ください。

<a href="https://dmmgames.co.jp/recruit/" target="_blank">DMM GAMES｜RECRUIT</a>

DMM GAMESプラットフォーム横断的なシステム開発から見る基盤チームの働き方

シェア

関連する求人

関連する記事

関連するサービス

DMM GAMESプラットフォーム 横断的なシステム開発から見る基盤チームの働き方

シェア

関連する求人

関連する記事

関連するサービス

DMM GAMESプラットフォーム横断的なシステム開発から見る基盤チームの働き方