本記事はEngineering Manager Advent Calendar 2025の10日目です。
アドベントカレンダー記事を書き始めてから累計で10年になりました。
はじめに
EMになってから100日の間にやったことという記事を良く目にすることがありました。
着任した最初の短期間で組織の信頼を得るための動きはとても重要なので、関心も高いのだと思います。
途中の中長期に着目した記事はあまり見たことがない気がしたので書いてみる次第です。
自己紹介
わたしは、合同会社DMM.comで二次元事業のエンジニアリングマネジメントに携わっています。
今年でIT業界歴22年、組織マネジメントは合計して10年ほどになります。
所属する二次元コンテンツ事業が、社内表彰イベント（DMMアワード）で社業の発展への貢献を称えられ大規模案件やビジネス部門にて3年連続受賞の快挙を達成することが出来ました。
本記事は、事業成長を下支えしてきた開発組織がどんなことをしてきたのかの備忘録でもあります。
前提、文脈
1000日の期間
仮に1000日を休日を含んだ期間として365日で計算すると2年9ヶ月ほどとなり、純粋な営業日で1000日だと約4年2ヶ月ほどになります。
本記事ではこの辺りの厳密さは排して、大まかに22年～25年の約3年間とさせて頂きます。
事業のフェーズと状況
0→1のような事業フェーズで表現すると、二次元コンテンツ事業は100→110のフェーズで、拡大期とも表現できます。
属する業界の中ではNo.2の立ち位置で、No.1を目指した成長が求められている状況でした。
システム背景
20数年の長期間に渡って運営してきている大規模サービスです。
直前の期まででは、複数事業で共有するインフラ部分が多かった問題の解消が進み、複数事業が1つの商品DBにまとまっていた課題の解消も実施されました。
これらのおかげで、それぞれの事業独自での改善を進められる土台が整った状態でした。
組織として成し遂げたこと
この3年間は順調に採用が進み開発組織規模も2倍以上になったのですが、本記事では文化面にフォーカスします。
サービス成長に伴うシステム整備と人員増に伴うプロセス整備を数多く進めてきた中でも、大きく3つの観点をピックアップしました。
1. 技術的負債の持続的解消と未来への備え
サーバーサイドのフレームワークリプレイスを初めとして、順々にプロダクト毎で技術的負債の解消を進め、着実に完了してきました。
そして比較的新しい技術に追いついた際にも、定期的なバージョンアップサイクルを作らないと負債化してしまうため、一定の保守に割く時間配分は必ず合意・確保して、インフラ・バックエンド・フロントエンドの全方位で解消を進めています。
技術的負債の堆積は開発スピードの低下や停滞に直結してくるため、事業成長スピードを落とさない・加速させることに主眼を置き、解消に類するPJやタスクの必要性と重要度を説明しています。
複数の新規開発や改善を同時並行で進めているため、手戻りを起こさないよう1つ1つに見通しを立てコンフリクトを調整することが重要です。全てが順風満帆に来た訳ではありませんが、何らかの失敗をした際にも同じ失敗を繰り返さないように振り返りやポストモーテムで掲げた再発防止策の追跡など細心の注意を払っています。
更なる成長に向かって、いますぐは大丈夫でも今後障害になりそうな箇所へ、先んじて対処するための分析や準備も進んできました。
昨今はAI活用も準備の一環として捉えて業務プロセスへの浸透を多方面で推進しています。
2. モニタリングの浸透
チームパフォーマンスとシステムパフォーマンスの両面を継続的にモニタリングしています。
開発チームのパフォーマンスを測るためにはFour Keysを用いており、二次元コンテンツ Tech meetupのLTでも紹介させて頂きました。
サービスのシステムパフォーマンスはNewRelicにてSLI/SLOの形で計測し、SRE領域を管轄するチームにて毎日確認し異常を発見した際は開発チーム全体へ周知したり・原因だと疑われるリリースがあれば担当へ連絡する運用がなされています。
これらの測定結果は、隔週の開発チーム全体の定例において可視化したり一定期間毎にまとまった成果を振り返ることで、パフォーマンス向上のための改善施策等を実施した際の効果が想定した通りに出ているかどうかを確認しています。
3. 属人化を減らす取り組み
特定の誰かに業務負荷が偏る状況を解消するため、属人化軽減策を1歩ずつ進めました。
チーム体制を、担当プロダクトで分割することにより認知負荷を下げオンボーディングに要する時間も短縮され、更にチーム内でもいくつかの小チームとしてまとまって動くユニット制を取り入れることでタスクアサイン・相談におけるマネジメント負荷を軽減しています。
チームが分割されたことで、各プロダクト毎に異なる課題にも各チーム毎で独立して改善施策を進めることができ、トライアルを経てうまくいった施策が他チームに横展開されるなど好循環が生まれています。
直近では、ソースコードを含む成果物レビューにおけるレビュー品質を向上させるための取り組みもスタートしています。
夜間休日における障害対応では、以前から対応マニュアルを整備するサイクルは作れていたものの、新しい担当者に対するオンボーディングとして障害検知から協力要請の流れを事前に日中で訓練する施策も導入されるようになりました。
自らリードした取り組み
振り返ってみてインパクトが大きかったと感じている主要な2つをピックアップしました。
1. ドキュメントの公式化
ナレッジベースとしての情報管理ツールはConfluenceを使用しているのですが、組織要因での様々な変化を経てメンテナンスされていないページが散在してしまい、オンボーディングに悪影響が出ていたり保守運用の観点でも看過できない状態でした。
何度かディレクトリ型の整理も試みたものの、内部環境を鑑みて運用に耐えられるルールが決まり切らなかった中、外部で公開されているサービスのドキュメントや各種SNSのアカウントにて「公式」と表現されることからヒントを得て「このページは管轄主体が責任を持ってメンテナンスしている・していく」という宣言・お墨付きをすることで、対象のページを信頼できる状態に保つルールとして「公式化」を発案し運用が定着できました。
2. セキュリティ観点の強化
属人化を減らす一環でもあるのですが、集合知ではなくトップダウンで進める必要があるため、ガイドラインとルールを整備しました。
従来より社内横断のセキュリティ専門部署が存在し一部のドキュメントは参考情報として提示頂いていたのですが、適用可否は各組織に委ねられているためルール化しきれていなかった点に対処したものです。
昨今はAI活用におけるMCP利用に対しても注視を続けています。
自身が中長期を過ごす上で意識していること
まずビジョンを掲げ、このままやれば出来ると感じた時から次の目標を立てておくことです。
この3年間の初年度に入る前段階の時点で以下のビジョンを掲げていました。
・定量：プロジェクトを並行して〇本回せる組織
※実際には具体的なプロジェクト本数を明示していますがここでは割愛させて頂きます。
・定性：新卒が配属できる組織
弊部署では一定の年数において新卒の配属がされていない状態でした。
システム状況を含めた様々な観点において新卒が健全に育つ状態と言い難いというのが配属受け入れに至らない理由でしたが、明確な課題意識をマネジメント陣が持ち改善行動を続けた結果、昨年・今年と連続で配属が叶う形になりました。
達成が見えた段階で、以下の組織ビジョンを新しく掲げています。
・良いEXを元に、専門性を駆使して期待に応え続ける
1度掲げて終わりでは無く、半年毎のキックオフにて意図を解説しつつ繰り返し言い続けることで、色々な改善のための施策が何に繋がっていたのか・繋げようとしているのかを出来る限り伝わるように心掛けています。
おわりに
なんでもやれるDMMの中でも
二次元コンテンツ事業では、まだまだ新しい仲間を募集しています。
https://dmm-corp.com/recruit/engineer/1264/
少しでも興味を持って頂けた方は、過去のアドベントカレンダー記事もご参考ください。