トップ > インターン > 1ヶ月インターンのロードマップ設計 〜メンターとしての工夫〜

1ヶ月インターンのロードマップ設計 〜メンターとしての工夫〜

インターン マネジメント

サムネイル

はじめに

プラットフォーム開発本部 第３開発部 共通基盤グループ 認可チームの shion0625 です。

2025年9月の1ヶ月間、インターン生を受け入れました。 私は新卒2年目で初めてメンターを担当しました。

テーマは「PGO（Profile-Guided Optimization）を用いた認可APIのパフォーマンス改善検証」でした。

インターン生が執筆した成果物はこちらです：PGO活用による認可APIのパフォーマンス改善検証レポート

この記事では、「1ヶ月という限られた期間で、インターン生に成果を残してもらう」 ために、メンターとして何を意識し、どのように設計したかをお伝えします。

これからメンターをする方、特に初めてメンターを担当する方の参考になれば幸いです。

なぜ「成果物を残す」ことにこだわったのか

実は、私自身も学生時代に1ヶ月の短期インターンを経験しています。

そのときは、小さめのタスクをこなす日々でした。
「実際の現場でエンジニアがどう働いているか」の解像度は上がりましたが、何かをやり遂げた実感は薄く、終わった後に「自分は何ができるようになったかな？」と感じたことを覚えています。

この経験から、担当したインターン生には目に見える成果物を残してほしいという思いがありました。就活の際にも「こういうことをやりました」と胸を張って言えるような、そんな経験を提供したかったです。

インターン受け入れの課題

インターン生を受け入れることになったとき、以下のような課題がありました。

  • 期間が限られている：1ヶ月（実質4週間）
  • テーマの難易度が高い：PGOという技術を0から学び、実際の検証環境で検証し、チームに共有し、最終的に技術記事にする
  • メンターの知見不足：導入方法や検証方法が最初は全くわからなかった

「1ヶ月で何ができるのか？」「中途半端に終わってしまわないか？」という不安がありました。

しかし、限られた期間だからこそ、計画的に設計する必要がありました。

ロードマップ設計：ゴールから逆算する

ゴールを先に定義する

もっとも重要なのは、ゴールとなる最終成果物（技術記事）を先に定義しておくことです。

インターン生を受け入れる前に、技術記事の全体構成と、各項目で何を書いてほしいかまで作成しました。

最終成果物 = 技術記事

## はじめに
  → なぜPGOが必要なのか？本記事のゴールは何か？

## PGOの仕組みと導入の目的
  → インライン展開・デバーチャライゼーションなどの仕組み
  → 効かないケース（I/O待ち、CPUバウンドな処理など）

## 検証手順・検証結果
  → ベースライン測定、PGO適用後の測定、グラフ・表による比較

## 考察・まとめ
  → 効果が出やすい/出にくい条件、得られた知見、今後の課題

なぜ詳細に書くのか？

  • 調査・検証をする際に「何を調べればいいか」が明確になる
  • メンターとインターン生の間で認識のズレを防げる
  • 迷った時に立ち返る場所になる

ゴールから逆算したロードマップ

最終成果物から逆算して、5週間のロードマップを設計しました。

Week 5: 記事レビュー・公開準備
   ↑
Week 4: 執筆
   ↑
Week 3: 本格検証 → チームに共有
   ↑
Week 2: 開発環境構築・検証手順書作成
   ↑
Week 1: PGOの基礎理解（座学 + ローカル検証）

各週で何を達成すべきかを明確にし、さらに日ごとにGoalを設定しました。

メンター自身が先に学ぶ

インターン生の受け入れ前に、私自身がPGOを一通り勉強しました。

完璧に理解したわけではありません。しかし、大枠を理解しておくことで、「何がわからないか」を把握でき、各タスクの想定時間を見積もれるようになりました。

工夫1：Goalを具体的に設定する

抽象的なタスクは渡さない

チームリーダーからのレビューで、「このタスク、抽象的になっていないか？」と指摘を受けることがありました。

具体例を以下に挙げます。「PGOについて調べる」というタスクは、何をどこまで調べればいいかが不明確であり、抽象的であることが分かります。

❌ 抽象的 ✅ 具体的
PGOについて調べる 「PGOって何？」と聞かれた時に3行で説明できる
プロファイルを理解する pprofの取得/読み方を説明できる
検証する PGOありビルドでレイテンシが改善したか数値で示せる

想定回答を先に考える

チームリーダーから印象に残ったアドバイスがあります。

「質問を用意する際は、先に回答を想定してから質問を設定する」

そうしないと質問が抽象的になり、要領を得ない回答になってしまったり、質問の意図が伝わりにくくなるという指摘でした。

実際に設定した質問例：

  • PGOが効きやすい/効きにくい条件は何ですか？
  • CPUプロファイルを取得することで、どのような調査ができますか？
  • net/http/pprofとruntime/pprofの違いは何ですか？

例えば、「PGOが効きやすい/効きにくい条件は何ですか？」という質問に対しては、以下のような回答を想定していました。

効きやすい条件： CPUバウンドな処理が多い、頻繁に呼び出される関数（ホットスポット）がある
効きにくい条件： I/Oバウンドな処理（DBアクセス、ネットワーク通信など）、すでに十分に最適化されているコード

回答を想定しておくと、質問自体が変わる

回答を想定せずに質問を作ると、質問自体が抽象的になりがちです。

想定回答なしで作った質問 想定回答ありで作った質問
質問 PGOについて調べてください PGOが効きやすい/効きにくい条件は何ですか？
返ってくる回答 PGOの仕組み、歴史、他言語での事例など幅広い内容 CPUバウンド/I/Oバウンドなど、今回の検証に直結する内容
問題点 何をどこまで調べればいいかわからない 検証対象の認可APIに当てはめて考えられる

回答を想定しておくことで、「この回答を引き出すには、どう質問すればいいか？」と逆算でき、質問自体が具体的になります。

所要時間も明記する

各タスクには所要時間も明記しました。

- ドキュメントを読む（1時間）
- 手元で動かす（1時間）
- 調査結果をまとめる（30分）
- 15時に1次レビュー

目安より遅ければサポートに入る、早ければ深掘りの質問をするなど、メンターの判断材料になります。

工夫2：全てをドキュメントにメモしてもらう

調査・検証のタスクの際には、事細かにメモしてもらいました。

実際に作成してもらったドキュメント：

  • 日報
  • PGO調査（日付ごとの調査メモ）
  • 検証手順書
  • 検証結果

「背景」を書くことが特に重要

メモを残す際に特に意識してもらったのは、「背景（Why・What）」を必ず書くことです。

❌ 背景なしのメモ
- pprofでプロファイルを取得した
- default.pgoというファイルが生成された

✅ 背景ありのメモ
【背景】PGOビルドに必要なプロファイルを取得するため
【やったこと】pprofでプロファイルを取得した
【結果】default.pgoというファイルが生成された

背景を書くことで、以下のメリットがあります。

  • 調査の目的が明確になる：何のためにこの調査をしているのか、自分自身で整理できる
  • 後から見返したときにわかる：1週間後に見返しても、何を調べていたのか一目でわかる

メモがあったから助かった場面

質問に論理的に答えられた

私がインターン生に質問をした際、メモを見ながら論理的に説明してくれました。「なぜこの方法を選んだのか」「他に検討した方法は何か」といった質問にも、メモを参照しながら根拠を持って答えられていました。

メモがなければ、「なんとなくこうしました」という回答になっていたかもしれません。

メモが記事に直結した

インターン生が書いた記事の「検証手順」セクションは、調査中に残していたメモがほぼそのまま使われています。 メモを「後で記事にする前提」で書いてもらっていたので、執筆はスムーズに進めることができていました。

工夫3：コミュニケーション方法を途中で変えた

最初は、朝イチのミーティングで今日やることを確認し、その後はテキストベースでやり取りする形式でした（リモートワークだったため）。

しかし、途中でこの方法を変更しました。

変更前の課題

  • テキストだと説明が長くなりがち
  • インターン生側から質問しにくい雰囲気になっていた
  • 時間が限られている中で、非同期のやり取りは効率が悪かった

変更後

  • 朝と夕方にミーティングの時間を設ける
  • 同期的に作業する時間を増やす（画面共有しながら作業など）
  • すぐに質問できる環境を作り、雑談もできるようにした

通常の社員であれば、業務内容をある程度把握しており、複数のタスクを並行して進めています。そのため、同期的なやり取りが多いと逆に効率が落ちることもあり、テキストベースのコミュニケーションが適していることが多いです。

一方、インターン生は状況が異なります。業務内容を把握していない状態からスタートし、扱うタスクも基本的に1つです。そのため、積極的に同期的なコミュニケーションを取ることで、むしろ作業効率が上がると学びました。

最初から同期的なコミュニケーションを設計しておけばよかったと反省しています。

チームリーダーとの連携

ここまで紹介した工夫は、私一人で考えたわけではありません。ロードマップやタスク設計は、チームリーダーにレビューしてもらいました。

  • 最初の1週間：毎日Discordでレビュー
  • 2週目以降：1週間分をまとめてレビュー

チームリーダーから印象に残っているアドバイスは、「インターン生は1ヶ月の期日でいなくなってしまうので、リスケや延長ができない」 ということ。

通常の業務であれば、スケジュールが遅れても調整できます。しかし、インターンは期日が決まっています。だからこそ、レビューポイントを細かく設けて早期に軌道修正できるようにする必要がありました。

新卒2年目で初めてのメンターでしたが、チームリーダーのサポートがあったからこそ、やり遂げることができました。

実際にやってみて

うまくいったこと

最終成果物を残せた

インターン生の執筆した技術記事が、DMM Developers Blogに公開されました。

PGO活用による認可APIのパフォーマンス改善検証レポート

記事の中で、以下の成果が報告されています：

今回の検証の結果、Topgun APIにおいて、PGOはAverage/p50の改善はほとんど見られなかったものの、運用上の安定性に直結するp99のレイテンシー改善に効果があると実証されました。

チームへの貢献

検証結果をチームに共有した結果、1ヶ月ほど試験的にPGOを導入することになりました。

インターン生の成果がチームの意思決定に貢献できたことは、大きな成功だと思います。

インターン生の声

インターン期間中、インターン生からいくつかフィードバックをもらいました。

  • 「手順書を詳細に書く経験は今までなかったので印象に残った」
  • 「負荷試験基盤やKubernetesを触るのが初めてで楽しかった」

手順書を詳細に書くことは、エンジニアとして働くうえで重要なスキルです。インターン期間中にこの経験ができたのは良かったと思います。

想定と異なった点と学び

検証結果のインパクトが想定と異なった

PGOを検証した結果、Average/p50においては有意な差は見られませんでした。これは、対象の認可APIがすでに高度に最適化されていたことの裏付けでもあります。

理由は、認可APIがすでに十分に高速化されていたからです。

  • キャッシュを活用しており、処理が高速です
  • CPUバウンドな処理がほとんどなく、シンプルな処理に最適化されている
  • レイテンシが高いエンドポイントはI/O処理がボトルネックであり、PGOの効果が出にくい

認可APIは、DMMのプラットフォームにアクセスする際に必ず通る場所であり、RPSが非常に高いシステムです。インターン生の記事でも報告されているように、インターン期間中の最大RPSは6140 RPSでした。そのため、すでに高速化のための最適化が施されていました。

ただし、p99のレイテンシー改善には効果があり、運用上の安定性に直結する成果は得られました。

学び： テーマ選定の段階で、「この技術がこのシステムに効果があるか」の仮説検証をもっと深くやるべきと学べました。

次にメンターをするなら

今回の経験を踏まえて、次にメンターをする機会があれば以下を意識したいと思います。

  1. テーマ選定時に効果の仮説検証をする
    「この技術がこのシステムに効果があるか」を事前に検証し、インパクトのある成果が出やすいテーマを選ぶ

  2. コミュニケーションは最初から同期で進める
    リモートでも、朝夕のミーティングや同期作業の時間を最初から確保する

  3. 最終日に振り返りミーティングを設定する
    インターン生から「良かった点・改善点」を正式にフィードバックしてもらう時間を設ける

まとめ

ポイント 具体的な行動
ゴールから逆算 最終成果物（記事の目次）を先に作成
具体的なGoal 想定回答を先に考えてから質問を設計
全てをドキュメント化 調査・検証の内容を細かくメモし、チームの知見に
コミュニケーション リモートでも同期的な時間を意図的に確保
チームリーダーとの連携 ロードマップやタスクを毎日〜週1でレビュー

今回紹介したゴールから逆算するアプローチは、インターンに限らず、普段の業務やチームメンバーの育成にも応用できると感じています。

これからメンターを担当する方、特に初めてメンターをする方の参考になれば幸いです。

プラットフォーム開発本部では、一緒に働く仲間を募集しています。 ご興味のある方はこちらへ！ dmm-corp.com