はじめに

はじめまして、2024年11月から2週間の内定承諾前の学生向け短期就業型インターンにソフトウェアエンジニアとして参加していました、26卒の岡田 龍樹です。 情報系の学科に所属する学部3年の大学生です。

普段はAIエンジニアとしてモデルの開発、モデルのAPI化などを行っています。ソフトウェアエンジニアとしては、サマーインターンシップでの経験程度で、詳しいわけではありません。AIエンジニアとしての経験からユーザーに近い形での関わり方に興味を持ち、実際の社員との交流の機会を求めて今回のインターンシップに参加しました。

インターンの中で行ったタスクについて紹介します。DeNAに興味を持つ方々に、ぜひ読んでいただければ幸いです。

このブログを読むことで何を知ることができるのか

• 取り組んだタスクの内容
• 会社の環境に関する情報

どのようなタスクに取り組んだのか

どのようなタスクを行うかの決定プロセス(Day 1)

インターンシップ初日に社内ツールを紹介され、エンジニアリング室が管理運用するプロダクトの改修を行うことを伝えられました。いくつかのプロダクトと、それに関連するissueの状況を共有いただき、自分が関与できるプロダクトを検討しました。その結果、ユーザーに価値を届けられること、そしてユーザー数が多いためにインパクトが大きいことからQuickMTGに関わることに決めました。

issueは大きく分けて2つに分類されます。1つはMySQLのアップデートなど、ユーザー価値には直結しにくいが必要なもの。もう1つは、運用中に寄せられたユーザーの声を解決するissueとして、今回私は後者を担当しました。

関わったQuickMTG関連のissueは以下の通りです。

1. 推薦ロジックの改善：会議室の収容人数を比較するロジックが欠如しており、自動予約が行われていない問題を改善したい
2. 他オフィスへの対応：渋谷オフィスだけでなく、他のオフィスにも対応できるようにしたい
3. お気に入り場所やフロアデフォルト設定など優先度設定の導入：人数に適した会議室を選ぶ際に、ユーザーの移動が少なくなるように、複数のフロアがある場合には優先したいフロアを設定できる機能や、お気に入り場所を優先予約できる機能を加えることで、オフィス内の移動距離を短くする工夫をしたい

QuickMTGとは

QuickMTGは、DeNAの2024年度新卒エンジニア研修で「社内で使えるプロダクト」をテーマに生まれた、社内の会議室予約に関する問題を解決するためのSlackアプリです。主要なユースケースとしては以下があります。

• Slackアプリから容易に会議室予約が可能（最短で3秒！）
• 利用したい時間や人数を入力するだけで、自動的に適切な会議室を選んで予約する
• ホーム画面からワンクリックで1人用のミーティングスペースの予約が可能

タスクについて

タスクを進めるための整理

状況を把握した上で、どのようなタスクを行うべきかのアイディアを出し、課題や疑問点を整理しました。

• アイディア
  • Google Calendarの会議室情報を使用して会議室のデータを取得し、自動で現在の渋谷オフィスに対応したマスターデータと同形式に整形することで、全国のオフィスに対応し、より多くのユーザーをカバーできるのではないか？
• 課題仮説
  • 権限の問題で会議室の情報を取得するのが困難である
  • Google Calendarの会議室情報が未整備
• 疑問点
  • 現在のマスターデータはCSVで管理されているが、どのように作成されているのか？
  • なぜマスターデータには渋谷オフィスに加え、横浜オフィスのデータが含まれているのに、システムは対応していないのか？

開発者ヒアリング(Day 2, 3)

上記で整理した疑問点について開発者の方にSlackでヒアリングを行いました。回答は以下の通りです。

• 回答
  • 会議室データをAdminAPIを使って外部から参照する許可が得られず、代わりに生データをマスターデータを管理しているIT部門から取得し整形している。将来的にプロダクトが使われ続けるようだったら、IT部門からGoogleのAPIをラップしたAPIを提供予定
  • 渋谷オフィス以外のオフィスには、UXの大幅な変更、QAの確保、引き継ぎのためのリファクタリングが必要だが、時間が足りず他のタスクに割かれてしまっていた

上記の回答を受け、データを自動で整形するスクリプトがあると便利だと考え、その開発を検討しました。また、他オフィス対応をするためにソースコードを修正し、他オフイスへの拡大とオフィス移転の際の早期対応を図ることにしました。

検証として以下を確認しました。

• 自動でデータを整形できるスクリプトは、一部手動修正箇所があるので半自動の形式なら実装が可能
• 他オフィスへの対応のためのソースコード改修は、渋谷オフィスに特化したロジックが多く含まれており、リリースを含めた工数を考えると今回の期間では難しい

結果として、他の方針に変更し、次のタスクとしてお気に入り場所やフロアデフォルト設定など優先度設定による予約アルゴリズムの改善にすることにしました。

UI(Day 4)

お気に入り場所やフロアデフォルト設定による予約アルゴリズムの改善に向けて、GitHub issueでアイディアを整理し社内ユーザーからフィードバックを得ました。その結果、下記のようなユーザーニーズが得られました。

• オフィスがフリーアドレスだが、よく座る座席がある程度決まっているため、近くの会議室を選びやすいように複数のお気に入り場所を設定できるようにしたい
• 設定したお気に入り場所に優先順位が付けられると嬉しい

これを元に、 Slackの実装可能なUI を参考にデザイン案を作成しました。

• ホーム画面に設定ボタン
• お気に入り場所の設定画面

サーバーサイドロジック(Day 5, 6, 7)

上記のUIで取得したデータを用いたアルゴリズムの案を整理し、メンターの方からレビューをいただきました。

レビューいただいた、サーバーサイドのロジックに加え、UI案の実装に約3日間かけました。

ローカルQA(Day 8)

テストコードを作成しようと思いましたが、既存のテストコードの把握、DBなどの外部処理が発生するため、mockの作成などに時間がかかると考えました。 そのため、実装した機能ごとに確認すべきパターンを整理したQAシートを作成し、ローカルでの動作確認を行いました。

PR (Day 8)

feature/ ブランチにてPRを作成しました。DBに挿入して良い値のvalidation追加など微修正が必要な箇所をレビューコメントとしていただき修正しました。

リリースフロー確認(Day 8)

既存のREADMEの内容を確認して、リリースフローを把握しました。以下の手順で進められたため特段難しいことはありませんでした。

1. GitHubリリースを行うと自動でGitHub Actionsが走り、コンテナイメージのビルドとプッシュが行われる
2. 安全性の観点からリビジョンのトラフィックを手動で変更
3. QAでの動作確認

リリース後のQA(Day 8)

ローカルQA での検証項目をリリース後にも確認したところ、なぜか既存の予約ロジックが動作してしまう問題が発生しました。そのため、リリース前のバージョンへロールバックし、原因の調査と対策を検討しました。

調査、対策(Day 8)

調査の結果、以下のことが判明しました。

• リリース後のQA時のオフィスの会議室予約状況だと追加した予約ロジックですべてエラーが発生し、既存の予約ロジックが動作していた
• 各フロアごとに会議室を取得する際、予約可能な会議室がないフロアが存在するとエラーとなる仕様であったため、予約が既存ロジックでのみ行われていた

対応策として、フロアごとに会議室を取得する際のエラー時にはそのフロアをスキップし、全フロアで取得できなかった場合には、既存の予約ロジックで予約可能な部屋がないことを通知する方針に変更しました。また、エラーハンドリングを強化し、エラー発生時にログ出力することで、原因究明を容易にするようにしました。

今回のバグ検出から以下を学びました。

• エラー処理にはログ出力をし、原因特定をしやすくする
• エラー時の処理内容をしっかりと整理しておく

幸い今回の不具合はユーザーにエラーメッセージが表示されない範囲であり、早期発見かつ個人的な学びも多かったため、有意義な経験となりました。

バグ修正後のQA(Day 8)

上記の対応を行った後に、ローカルQAとリリース後のQAを行いました。この際には、 ローカルQA での検証項目に加え、先ほどエラーが発生していた箇所もテストしました。

無事リリースを終え、Slackで機能リリースの連絡をしたところ、多くの社員の方からスタンプなどで反応をいただき、取り組んでよかったと感じました。

その他、会社の環境について

メンターの方について

インターンシップの期間中、エンジニアと人事の方がメンターとしてサポートしてくださいました。エンジニアの方からは、インターン中のタスクの進め方、アイディアや実装方針に対するレビューを受け、毎日の終わりにはその日の活動の整理や、良かった点と悪かった点についてフィードバックをいただきました。これにより、自分の思考を整理し、強みと弱みを再認識する機会を得ることができました。

人事の方は、ランチなどを通じて他の社員との交流の場を提供してくださり、希望する職種や分野の社員との面談を調整していただきました。このおかげでDeNAについての理解を深め、自分がどのように関わっていきたいかを具体化できました。

ランチなどで交流した社員の方について

メンターの紹介を通じて、さまざまな事業部の方々と交流でき、エンジニアとして携わりたい技術領域や関わり方についてのイメージがさらに具体化しました。イメージが固まった段階で、そのような方々とお話しできるようメンターにも紹介を依頼し、1on1などを通じて多くの出会いが実現しました。この交流を通じて、DeNAで働く際の具体的なイメージがつかめたと思います。

また、多くの方々がはじめての交流にもかかわらず、私の興味や悩みに親身になって話を聞き、経験に基づいたアドバイスをいただき、大変感謝しています。

初対面でのコミュニケーションに不安を感じていましたが、社内にある「 TALENTBASE 」というサービスで各社員の自己紹介ページが見られたため、相手のことを理解した上で安心して話すことができました。

さらに、内定承諾をしている25卒の方から声をかけていただき、相談機会を設けてもらったこともとても有意義でした。

オフィス環境、開発環境について

労働環境については、社内がフリーアドレスであることと、とくに感動したのは設置されている椅子の快適さです。ランバーサポートが優れており、姿勢の悪さからくる腰痛がほぼなくなりました。このように環境にしっかり投資しているDeNAには感心しました。

オフィス以外の開発環境についてですが、QuickMTGを含む社内プロダクトを見ると、Dockerを多用している印象があり、サーバーサイドはGo、フロントエンドはTypeScriptが主流でした。また、エディターとしてVS CodeとGitHub CopilotやCursorを使うことが多いようです。QuickMTGの開発中にCursorを用いており、リポジトリ全体を参照して質問の回答やコード生成を行うcodebase機能を活用したことで、開発生産性が高まりました。

※[メンター補足]: 新卒エンジニア研修で開発するプロダクトに関しては、研修後に引き継ぐエンジニアリング室の保守・運用工数を小さくするためにある程度似たような構成になるようにしています。DeNAでは、部門や事業部それぞれが目的に対して最適な技術を採用しています。

おわりに

最後に、インターンシップ期間中メンターをはじめ、ユーザーヒアリングや1on1に関わってくださったすべての皆さんに感謝いたします。多くの学びと経験の機会をいただき、本当にありがとうございました。

そして、このブログを最後までお読みくださった皆さんにも感謝いたします。長文になってしまいましたが、それだけ濃密な2週間だったということだと思います。この貴重な経験を多くの方が味わえるよう願っています。興味を持たれた方は、ぜひ参加してください。