DeNAの「挑戦させてくれる」文化に飛び込んでみた

DeNAの2週間の学生向け短期就業型インターンシップに参加しました、三好と申します。

「DeNA Engineering Blog」をご覧の皆さんの多くは、DeNAの技術や働き方に興味を持ってくださっているのではないでしょうか。とくに学生の皆さんの中には、DeNAへの就職を検討している方や、社内の環境がどのようなものか具体的にイメージできていない方もいらっしゃるかもしれません。

本稿では、私がDeNAのインターンシップで体験した挑戦を促す文化と、活発な技術学習環境についてご紹介します。とくに、未経験の技術領域に挑戦させていただいた経験や、社内の技術勉強会のリアルな雰囲気、そしてそこから得られた学びをお伝えできれば幸いです。

インターンシップにおける挑戦と学習

タスク選択

私のインターンシップでの主なタスクは、ある社内システムの手動で管理されていた既存のAWSインフラをTerraformによってコード化することでした。AWSやTerraformに触れた経験はほとんどありませんでしたが、興味があったのでこのタスクを選択しました。DeNAでは経験の有無にかかわらず、意欲があれば積極的に挑戦させてもらえる環境があると思います。

このタスクを進める中でとくに役立ったのは、過去のGitHub上のやり取り・議論を参照することでした。手動で構築されたインフラをコード化する際、なぜその構成になったのか、どのような課題があって現状の形に至ったのかを理解することは非常に重要です。関連するコミット履歴やPull Requestでの議論を確認することで、インフラの現在の構成だけでなく、その意思決定の背景や歴史的経緯まで理解できます。より適切でセキュアな構成に変更する作業も並行して進めましたが、現在の構成を選択した経緯がわかっていると考えやすかったです。

循環参照問題の発生と解決

Terraformによるコード化を進める中でmodule間の依存関係による循環参照の問題に直面しました。

ディレクトリ構成はベストプラクティスを参考にこのような形となっています。

.
├── environments
│   └── dev
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
└── modules
    ├── cloudfront
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ├── s3
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ... # その他のモジュールが続く

今回対応した社内システムはCloudFront + S3で静的ファイルをホスティングする構成を採用しています。CloudFrontにはオリジンとしてS3を設定し、S3はCloudFrontのみからのアクセスを許可する設定にしていました。CloudFrontやS3はそれぞれ cloudfront module, s3 module として切り出していたため、2つのモジュール間でTerraformがリソースを作成・更新する順序を決定できないエラーが発生していました。

# CloudFront module
resource "aws_cloudfront_distribution" "main" {
  origin {
    domain_name              = var.s3_bucket_domain_name # オリジンにS3を設定
    origin_access_control_id = aws_cloudfront_origin_access_control.main.id
    origin_id                = "S3-${var.s3_bucket_name}"
  }

  # ... 

}

# S3 module 
resource "aws_s3_bucket" "main" {
  bucket = "intern-blog-test-bucket"
  
  # ...

}

resource "aws_s3_bucket_policy" "frontend" {
  bucket = aws_s3_bucket.main.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowCloudFrontServicePrincipal"
        Effect = "Allow"
        Principal = {
          Service = "cloudfront.amazonaws.com"
        }
        Action   = "s3:GetObject"
        Resource = "${aws_s3_bucket.main.arn}/*"
        Condition = {
          StringEquals = {
            "AWS:SourceArn" = var.cloudfront_arn
          }
        }
      }
    ]
  })
}

# environments/dev/main.tf
module "cloudfront" {
  s3_bucket_domain_name = module.s3.bucket_domain_name
  s3_bucket_name = module.s3.bucket_name

  # ...
}

module "s3" {
  cloudfront_arn = module.cloudfront.arn
  # ...
}

対応としてはmodule間の相互参照を解消するために、s3 module から main.tf にCloudFrontのarnを参照するリソースを移しました。

# S3 module 
resource "aws_s3_bucket" "main" {
  bucket = "intern-blog-test-bucket"
  
  # ...

}

# environments/dev/main.tf
module "cloudfront" {
  s3_bucket_domain_name = module.s3.bucket_domain_name
  s3_bucket_name = module.s3.bucket_name

  # ...
}

module "s3" {
  # ...
}

resource "aws_s3_bucket_policy" "frontend" {
  bucket = module.s3.bucket_id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowCloudFrontServicePrincipal"
        Effect = "Allow"
        Principal = {
          Service = "cloudfront.amazonaws.com"
        }
        Action   = "s3:GetObject"
        Resource = "${module.s3.arn}/*"
        Condition = {
          StringEquals = {
            "AWS:SourceArn" = module.cloudfront.arn # Change here
          }
        }
      }
    ]
  })
}

これにより terraform apply が通るようになります。CloudFrontのarnを参照するS3関連のresourceを cloudfront module 側に定義したり、その逆（S3のarnを参照するCloudFront関連のresourceを s3 module 側）に定義したりする方法も考えられます。この方法でも循環参照は解決できますが、設定箇所が分散し追いにくくなるため採用しませんでした。

得られた学びと知見

この一連の経験を通じて、AWSやTerraformの理解はもちろん、意思決定を残す/参照することの重要性を認識できました。とくにIaCにおける依存関係の循環はTerraformに限らず発生する可能性がある問題だと思うので、対処法について考える良い経験になったと思います。

また、未経験の技術領域であっても、自ら課題を設定し、解決に向けて試行錯誤するプロセスを経験できました。DeNAのインターンシップは単に技術を学ぶだけでなく、エンジニアとしての問題解決能力を養う貴重な機会となったと思います。

活発な技術勉強会文化

DeNAのインターンシップでとくに印象的だったのは、社内の活発な技術勉強会文化です。想像していた以上に多くの勉強会が開催されており、その多様性とオープンさに驚かされました。

多様な勉強会

DeNAではAndroidやSwift、Unity、フロントエンド、サーバーサイド、パブリッククラウドなど、幅広い技術分野をカバーする勉強会が定期的に開催されています。毎週開催されるものも珍しくなく、参加したいと思えば常に何かしらの学習機会がある状態でした。珍しいものではvimの勉強会があるようです。社内wikiに勉強会の情報がまとまっているので、気になったものがあればふらっと参加できます。

形式も多様ですが、その分野の最新のアップデートやブログを追ったりスライドを用意して発表したりする形式が多いようです。私が参加したGoの勉強会では、Go Conference 2025の発表のスライドを見ながら全員で議論し、内容をキャッチアップしていました。

オープンな参加と交流

偶然にもインターンの参加中にゲームバックエンドの勉強会が開催されており、（インターン業務はゲーム事業とまったく関係ないのですが）勉強会に参加させていただくことができました。この勉強会には他社のエンジニアの方も参加・発表されており、懇親会では複数社間での技術交流が盛んに行われていました。また、前述した定期的に開催されている勉強会の一部は社外のエンジニアも参加可能なオープンな形式で開催されているなど、勉強会を内向きにせず、なるべく参加者を広げていく雰囲気を感じることができました。

私が参加した2つのGoとゲームバックエンドの勉強会はどちらも非常にカジュアルな雰囲気で、インターン生である私も気軽に質問したり、意見を述べたりできました。ベテランエンジニアの方々も、参加者の疑問に対して丁寧かつ親身に答えてくださるため、技術的なハードルを感じることなく参加できました。異なるチームのエンジニアや社外の参加者との交流ができ、自身の専門分野以外の知識を広げ、学びを深める貴重な経験となりました。

まとめ

DeNAでのインターンシップを通して多くのことを学び、エンジニアとして大きく成長できました。

インターンシップでの主要な学びは以下の通りです。

未経験の技術領域であるAWSやTerraformへ挑戦し、課題を達成したこと
Terraformの循環参照問題という具体的な技術課題に直面し、その解決プロセスを通じて実践的な技術力を身につけたこと
過去のGitHub上のコミット履歴や議論を読み解くことで、インフラの歴史や意思決定の背景を深く理解し、インフラ構成の裏側にある意図を読み取る力を養ったこと
多様なテーマの勉強会が高い頻度でオープンに開催されており、誰もが気軽に学び、交流できるDeNAの活発な技術勉強会文化を肌で感じることができたこと

インターンの経験を通じて、DeNAのエンジニアリング文化は、新しい挑戦を積極的に推奨し、社内外の知見を共有し合うことで常に学習し続けることを志向する非常にポジティブな環境であると感じました。

2週間という短いインターン期間でしたが、技術的なスキルはもちろんのこと、課題解決へのアプローチや、チームでのコミュニケーションの重要性、DeNAの文化など、多くのことを学ぶことができました。今後もこのインターンシップで得た学びを活かし、技術的挑戦を続け、社会に貢献できるエンジニアを目指していきたいと思います。

最後までお読みいただき、ありがとうございました。