インターンでメインプロダクトのデプロイ基盤改善を実現ー「使われ方」を意識した開発体験の向上ー

Mio

Posted on 7/31/2026

はじめまして。

2026年1月に、カナダの公立カレッジから同じ都市にあるSFU（Simon Fraser University）という4年制大学に編入し、Computer Scienceを専攻しているMioです。

編入後、最初の学期を終えたタイミングで一度日本に戻り、6月から7月末までの2か月間、プレイドのDeveloper Experience（DX）チームでインターンをさせていただきました。

これまでインターンをした経験はなく、今回初めて組織に所属してエンジニアリングに取り組みました。

私のバックグラウンド紹介
Developer Experienceチームについて
プレイドのインターンに参加した理由
本番に「設定だけ」を反映できるようにしたい
- 背景：なぜ設定だけを反映したいのか
  - 既存のデプロイはどうなっていたのか
  - 何が問題だったのか
  - どのように解決しようとしたのか
  - 設計・実装で考えたこと
  - 最終的にどうなったのか
  - まとめ —「動く」だけではない開発者体験
最後に
- これからインターンに挑戦する方へ
  - 余談

私のバックグラウンド紹介

私は、20歳でカナダへ渡るまで英語はほとんど話せず、Computer Scienceに関する知見もほぼありませんでした。

渡航後にESLで英語を一から学びながら、基礎的な数学の勉強を独学で始め、現地のカレッジへの進学をきっかけにComputer Scienceを学び始めました。このように、経験のないところから一つずつ理解を積み重ねてきた経験は、今の自分の学び方や、新しい領域でもまず挑戦してみる姿勢につながっています。

現在はカナダの大学でComputer Scienceを専攻しながら、授業で学ぶだけでなく、AIを活用した個人開発やWebサイトの開発・運用にも取り組んでいます。自分で必要な技術を調べながら、試行錯誤して実際に動くものを作ることを通して学んできたことが、これまでの自分の大きな特徴だと思っています。

一方で、個人開発ではアプリケーション側に触れることが多く、インフラやデプロイ、大規模な開発環境についてはあまり経験がありませんでした。そこで今回のインターンでは、そうした自分にとって新しい領域に挑戦し、実際の開発組織でどのようにサービスや開発基盤が運用されているのかを学びたいと思い、参加しました。

Developer Experienceチームについて

今回のインターンでは、上で説明したように私の希望、そしてご縁があり、Developer Experience（DX）チームに所属しました。

DXチームは、プレイドの代表的なプロダクトであるKARTE関連の機能開発を直接担当するチームではありません。開発者がより安全に、効率よく、そして気持ちよく開発できるように、開発環境や開発体験を改善することを目的としたチームです。

私が所属していた期間は、私を含めて5人ほどの小規模なチームで、メンバー全員がほかのチームや業務と兼任しながら活動していました。

実際に開発や運用の現場に関わることで、

このCIはなぜ時間がかかっているのか
この作業は本当に毎回人が判断する必要があるのか

といった、日々の開発体験の中にある課題を見つけ、改善していきます。

そのため、チームの業務範囲はかなり広く、CI/CD、デプロイフロー、Terraformなどを使ったインフラ管理、開発用CLI、社内の運用フローなど、プロダクト開発を支えるさまざまな領域に関わります。このようなDXチームのタスクの特徴柄、チーム開発というよりは、個人開発に近い形状で様々なタスクに取り組みました。

プレイドのインターンに参加した理由

プレイドのインターンには以前から興味を持っていました。

プレイドでインターンをしていた先輩から話を聞いたことに加え、過去に公開されていたインターンブログを読んだことがきっかけです。

インターンであっても、実際のプロダクトや開発基盤に関わり、自分で課題を考えながら改善を進めている記事が多く、「自分もこの環境で働いてみたい！」と思うようになりました。

実際に参加してみると、期待していたとおり、インターン用に切り離された小さなタスクだけを、限られた権限の中で担当するわけではありませんでした。社員と大きく変わらない権限と責任を持ち、周囲にも影響する実際の課題に取り組ませていただきました。

また、Claude CodeやCursor、Codexなど、さまざまなAIエージェントを活用して開発を進められる環境だったため、開発スピードを上げながら幅広いIssueを担当できました。

例えば：

GitHub Actionsのバージョン更新・統一やRenovateによる自動更新運用の導入
Hotfix機構などのデプロイ基盤の改善
DatadogのTerraform stateの分割
既存の共通デプロイフローに載っていなかった Cloud Run 系システムを、共通のリリース運用へ統合するための基盤整備
ペネトレーションテスト等の脆弱性診断をするための新たな環境の要件整理・設計・構築

などなど、様々なイシューに取り組みました。

すべてをご紹介することは難しいため、この記事では、インターン序盤に携わったタスクの中でも、所属していたDXチームらしい「開発者の体験」を意識して進めたものを紹介します。

本番に「設定だけ」を反映できるようにしたい

はじめに（この章の流れ）

「本番で動いているプログラム本体（コンテナイメージ）は変えずに、設定だけを変更する」

言葉にすると単純ですが、既存のデプロイフローでは、設定だけを切り離して反映することはできませんでした。

この章では、プレイドデプロイ基盤について知らない方にも内容を追ってもらえるように、まず既存の仕組みから順番に説明していきます。

また、今回のタスクや実装を理解するには、次の点を整理する必要があります。

プレイドでは、アプリケーションをどのようなデプロイフローで本番環境へ反映しているのか
評価環境と本番環境の違いを、どのように管理しているのか
なぜ「設定だけを変更したい」ときにも、アプリケーションの更新が含まれてしまうのか

そこで、まずはGitOpsやKustomize、マニフェストといった、基盤を利用した社内でのデプロイの仕組みを紹介します。

その前提を知ってもらった上で、本番環境で動いているアプリケーションのバージョンを変えずに、ヘルスチェックや環境変数などの設定だけを反映する仕組みを、どのように設計・実装したのかを紹介します。

この章全体は、次の流れで進みます。

プレイドの既存のデプロイフローを説明する
なぜ設定だけを反映できなかったのかを整理する
解決方法をどのように検討したのかを紹介する
実装中に見つかった課題と、その修正を説明する
完成した仕組みと実際の使い方を紹介する

社内のコードや運用についての事前知識は前提とせず、必要な用語や仕組みを説明しながら進めます。

背景：そもそも、なぜ設定だけを反映したいのか

今回取り組んだのは、緊急時にコンテナイメージは変更せず、設定の差分だけを安全に本番環境へ反映できるようにするIssueです。

ここでいう設定とは、次のようなものです。

ヘルスチェックの条件
環境変数
CPUやメモリの上限
Pod数などの実行環境に関する設定

これらはアプリケーションのプログラムそのものではありません。しかし、障害対応中には、設定を変更するだけでサービスを一時的に復旧できることがあります。

例えば、ヘルスチェックの条件が厳しすぎてPodが起動できない場合、その条件を一時的に緩めることで復旧できるかもしれません。

今回のIssueの背景には、インシデント対応時にこの「設定だけを変更する」という操作ができず、止血が遅れてしまったという課題がありました。

まずは、　なぜインシデント時に設定だけをすぐに反映できなかったのかを説明するために、既存のデプロイの流れから紹介します。

実際の設計と実装から読みたい方は、「3. どのように解決しようとしたのか」まで進んでください。

1. 既存のデプロイはどうなっていたのか

1.1 従来のデプロイの流れ

プレイドでは、本番環境への反映をGitOpsで管理しています。

Gitリポジトリに書かれた定義を正として、その内容を環境へ反映する仕組みです。

対象のリポジトリには、大きく分けて次の2種類の情報が書かれています。

どのプログラムを動かすかコンテナイメージのタグなど、アプリケーションのバージョンを表す情報です。
そのプログラムをどのように動かすかヘルスチェック、環境変数、CPUやメモリなど、実行環境に関する設定です。

通常のリリースでは、新しいプログラムと、それを動かすために必要な設定をまとめて本番へ反映します。

その際、環境ごとのマニフェストを生成するために使っているのが、Kustomizeです。

1.2 Kustomizeを使ったマニフェスト生成

プレイドでは、Kubernetes上でアプリケーションを動かすための設定を、マニフェストと呼ばれるYAMLファイルで管理しています。

ただし、評価環境と本番環境では、動かすアプリケーションの構成は似ていても、イメージタグや環境変数、Pod数など、一部の設定が異なります。

環境ごとにすべてのマニフェストを個別に管理すると、同じ内容を複数箇所に書くことになり、修正漏れや環境間のずれが起こりやすくなります。

そこで、マニフェストの共通部分と環境ごとの差分を分けて管理できる、Kustomizeという仕組みを利用しています。

大まかには、次のような構造です。

共通の定義（base）
├── Deployment
├── Service
└── 共通の設定

環境ごとの上書き（overlay）
├── evaluation
└── production

共通の定義を土台として、評価環境では評価環境用のoverlayを、本番環境では本番環境用のoverlayを重ねます。

この記事で登場するgenerateとは、kustomize buildを中心に、共通定義と環境ごとのoverlayを組み合わせて、実際にKubernetesへ反映できる最終的なマニフェストを生成する一連の処理を指します。

※厳密にはKustomize以外の前後処理も含みますが、この記事ではまとめてgenerateと呼びます。

つまり、本番デプロイでは、おおまかに次の処理が行われます。

共通の定義を読み込む
本番環境用のoverlayを適用する
本番環境へ反映する最終的なマニフェストを生成する
生成されたマニフェストを本番環境へ反映する

プレイドにおけるKubernetesのデプロイ基盤がどのように作られてきたかについては、過去のエンジニアブログ Our seeking to stable k8s deployment. でも紹介されています。

※当時の構成を紹介した記事のため、現在とは異なる部分もありますが、GitOpsやマニフェスト生成を採用した背景を知るための参考になります！

大まかな流れは次のとおりです。

このフローで重要なのが、本番へ出す前に、必ず評価環境へ先にデプロイするというルールです。

新しいイメージは、まず評価環境へデプロイされます。そこで動作を確認したあと、同じイメージを本番環境へデプロイします。

これにより、評価環境で確認していないプログラムが、いきなり本番へ反映されることを防いでいます。

1.3 リポジトリと本番環境のタグが一時的にずれる

評価環境へ新しいイメージをデプロイすると、新しいイメージタグがリポジトリ上の定義に書き込まれます。

ただし、その時点では本番デプロイはまだ行われていません。

そのため、評価環境へのデプロイ後から本番デプロイまでの間は、一時的に次の状態になります。

リポジトリには、評価環境で確認中の新しいタグが書かれている
本番環境では、まだ一つ前のタグが動いている

例えば、次のような状態です。

場所	動いている、または定義されているタグ
リポジトリ	`v2`
評価環境	`v2`
本番環境	`v1`

v2は評価環境へはデプロイされていますが、まだ本番環境にはデプロイされていません。

この記事では、このようにリポジトリ上のタグと、実際に本番で稼働しているタグが異なる状態を「タグの差分がある状態」と呼びます。

これは異常な状態ではなく、評価環境で確認してから本番へ出すという運用上、意図的に発生するものです。

問題になるのは、このタイミングで本番の設定だけを変更したくなった場合です。

2. 何が問題だったのか

2.1 なぜ「設定だけ」を反映できなかったのか

本番環境へ反映するマニフェストは、リポジトリに書かれた定義をもとに生成されます。

そのため、タグの差分がある状態で環境変数やヘルスチェックなどの設定を変更し、通常どおり本番へ反映すると、設定だけではなく、リポジトリに書かれている新しいイメージタグも一緒に反映されます。

先ほどの例で考えると、本番ではまだv1が動いています。

ここで、ヘルスチェックの設定だけを変更したいとします。

しかし、リポジトリにはすでにv2が書かれているため、その定義から本番用マニフェストを生成すると、次の2つが同時に含まれます。

ヘルスチェックの変更
イメージタグのv1からv2への更新

つまり、担当者としては設定だけを変更したいのに、通常のデプロイを実行すると、まだ本番へ出す予定ではなかったv2まで一緒にデプロイされてしまいます。

止血のために設定だけを変更したいにもかかわらず、意図していないプログラム（イメージ）の更新まで巻き込んでしまうわけです。

かといって、イメージの更新を避けるために本番への反映自体を止めると、必要な設定変更も行えず、障害対応が遅れてしまいます。

実際に、証明書の期限切れに伴うインシデント対応の中で、本番で動いているイメージタグを維持したまま、マニフェストの設定だけを切り替えたいという場面がありました。

しかし、当時のデプロイフローにはそのための操作が用意されておらず、止血までに時間がかかってしまいました。

そこで今回、タグの差分がある場合でも、次のどちらを行うか明示的に選択できるようにしました。

本番で稼働中のイメージタグを維持し、設定だけを反映する
既存の流れどおり、リポジトリに書かれた新しいイメージタグと設定をまとめて反映する

ここからは、この仕組みをどのように設計し、既存のデプロイフローへ組み込んだのかを紹介します。

3.1 最初に考えた案

最初は、タグをどのように退避し、現在本番で動いているタグへ戻すかという処理を中心に考えていました。

そのため、機能の入口については、設定だけを反映するための専用コマンドを新しく作るというシンプルな案から始めました。

必要なときに専用コマンドを実行し、タグを現在本番で稼働しているものに固定したうえで、設定差分だけを生成するというものです。

単体の機能としては分かりやすく、実際に動かすこともできました。

しかし、メンターさんとの会話を通して、実際の運用を考えると、この実装にはいくつか問題があることに気づきました。

普段使わない専用コマンドであるため、実装者以外から認知されにくく、本当に必要な緊急時に存在を思い出してもらえない可能性がある
通常のデプロイと設定だけのデプロイで入口が分かれると、片方だけが古くなったり、壊れたりする可能性がある
ローカル操作とCIで異なる経路を通ると、同じ操作のつもりでも結果が変わる可能性がある

そのため、タグを戻す処理そのものだけでなく、その処理をデプロイフローのどこへ置くべきかを考え直すことになりました。

3.2 既存のデプロイCLIへ組み込む

最終的には、専用コマンドを一つ増やすのではなく、すでに全員が使っている既存のデプロイCLIへ機能を組み込む方針に変更しました。

既存のデプロイ処理では、ローカルからの実行やCIなど、さまざまな実行経路が、最終的にKustomizeを使って環境別のマニフェストを作るgenerate処理へ集まります。ここでいうgenerateは、前述したとおり、kustomize buildを中心に環境別の最終的なマニフェストを生成する処理です。

そこで、生成処理の直前に、config-onlyが必要な状況かどうかを判定する処理を追加しました。

主に確認する条件は、次の3つです。

条件	コード上の判定
本番環境向けの生成である	`environment === 'production'`
リポジトリと稼働環境のタグに差分がある	`detect(...)`が返す`targets`
今回の変更に設定差分が含まれている	`t.coupling`

まず、本番環境向けの生成処理の直前に、config-only用の前処理を呼び出します。

if (environment === 'production') {
  // 本番 generate の直前に判定を1段入れる
  await prodConfigOnly.applyConfigOnlyPrePass(
    components,
    configOnly,
    { generate },
  );

  await generateSystems(
    'production',
    components,
    outputDirname,
  );

  // ...
}

前処理の中では、タグの差分と設定差分を確認し、config-onlyを実行するかどうかを決定します。

const mode = resolveConfigOnlyMode({ flag, isTTY });

if (mode === 'no') {
  return; // 通常デプロイ。検知もしない
}

const targets = await detect(components, { generate, io });
const coupledTargets = targets.filter((target) => target.coupling);

if (coupledTargets.length === 0) {
  return; // 設定差分がなければ何もしない
}

let decision;

if (mode === 'yes') {
  decision = 'config-only';
} else {
  decision = await prompt(targets);
}

if (decision === 'deploy') {
  return;
}

if (decision === 'abort') {
  throw new Error('config-only: 中止しました');
}

// 本番用の定義だけを、現在稼働しているタグへ戻す
for (const target of targets) {
  write({
    leafKustPath: target.leafKustPath,
    driftList: target.drift,
  });
}

条件を満たし、config-onlyが選択された場合は、マニフェストの生成に使う本番用の定義を、現在稼働しているタグに合わせます。

ここで変更しているのは、生成元となる本番用の定義であり、この時点で稼働中の本番環境をロールバックしているわけではありません。

タグを合わせた状態でマニフェストを生成することで、まだ本番へ出したくないイメージの更新を含めず、設定変更を中心とした差分を作れるようになります。

使い方としては、専用コマンドを新設するのではなく、既存のコマンドに--config-onlyというオプションを追加しました。

新しい操作方法を覚えてもらうのではなく、普段使っているコマンドの振る舞いを、必要なときだけ切り替えられるようにしたことがポイントです。

4. 設計・実装で考えたこと

4.1 どの定義を書き換えるのか

タグを現在稼働しているものへ戻す処理自体はシンプルですが、どの定義を書き換えるかは慎重に考える必要がありました。

共通の定義を書き換えてしまうと、本番環境だけでなく、評価環境で使用するタグまで巻き戻ってしまいます。

そのため、タグを書き換える対象は、本番環境用の上書き層（overlay）だけに限定しました。

本番用のoverlayに現在稼働しているタグを書き込み、その状態でgenerateすることで、評価環境の定義には影響を与えず、本番環境向けの設定差分だけを生成できます。

4.2 上書きによって消える候補タグをどう扱う？

もう一つ迷ったのが、本番用のoverlayを書き換えることで消える、これから本番へ出す予定だった新しいタグの扱いです。

最初は、元のタグを別のファイルへ退避し、次の通常デプロイで復元する案を考えました。

しかし、退避や復元の処理を追加すると、次のようなことまで考える必要があります。

退避ファイルをどこで管理するか
複数の操作が重なった場合にどうするか
復元に失敗した場合にどうするか
どのタグが正しい状態なのかをどう判断するか

小さな機能のために、新しい状態管理の仕組みを持つことになってしまいます。

そこで、既存のデプロイ運用をもう一度見直しました。

本番環境へ新しいイメージをデプロイする前には、必ず評価環境へのデプロイが行われます。そして、評価環境へのデプロイが実行されると、リポジトリ上のタグも新しいものへ進み直します。

この前提があるなら、消えたタグを特別に退避しなくても、次の評価環境へのデプロイによって自然に回収できます。

最終的には、退避や復元の仕組みを持たず、次の流れにしました。

本番環境用のタグを、現在稼働しているタグへ戻す
その状態でマニフェストを生成する
設定差分だけを本番へ反映する
次の評価環境へのデプロイで、タグを再び前進させる

独自の復元処理を増やすのではなく、既存の運用フローを通ることで、自然に元の状態へ戻るようにした形です。

4.3 本当に設定差分があるかをどう判断するか

タグがドリフトしているだけでは、「設定だけを変更したい状況」とは判断できません。

単に、評価環境で確認済みの次のイメージを、本番へデプロイしたいだけの可能性もあります。

そこで、本番環境用の定義を書き換える前に、一度一時ディレクトリへマニフェストを生成し、本当に設定差分が含まれているかを確認する前処理を追加しました。

これによって、次の2つの状態を区別できるようになりました。

タグのドリフトだけがある
タグのドリフトに加えて、設定差分もある

設定差分がない場合にはconfig-onlyを提案せず、通常のデプロイフローをそのまま通ります。

4.4 ローカルとCIで振る舞いを変える

--config-onlyには、auto、yes、noの3つのモードを用意しました。

値	振る舞い
`auto`	対話可能なローカル端末では、条件を満たした場合に選択肢を表示する
`yes`	対話せず、config-onlyを実行する
`no`	config-onlyの検知や処理を行わず、通常どおりデプロイする

ローカルでの操作では、必要に応じて利用者へ確認できます。

一方、CIでは対話できないため、autoが指定されていても、勝手にconfig-onlyへ切り替わらないようにしています。

緊急時の操作を簡単にしつつ、自動実行の中で意図しない判断が行われないようにするためです。

4.5 config-onlyを選んだのに、一部のタグが更新されてしまう問題

config-onlyの最初の実装では、設定差分が見つかった対象だけを、現在本番で稼働しているタグへ戻していました。

一見すると十分に思えます。ですが、このCLIでは、1回のgenerateで複数のシステムやコンポーネントのマニフェストをまとめて生成できるため、設定だけを変更したい対象に加えて、設定差分がなくタグの差分だけがある対象も同じ生成処理へ含まれることがあります。

具体的にはこんな感じです。以下のように、AとBをまとめてgenerateするとします。

対象	本番で稼働中	リポジトリ上の候補	設定変更
A	`v1`	`v2`	あり
B	`v3`	`v4`	なし

ここでconfig-onlyを選んだ場合に期待する結果は、Aの設定差分だけを変更し、AとBのタグはどちらも現在のまま維持できることです。

対象	期待する生成結果
A	タグは`v1`のまま、設定だけを変更する
B	タグを`v3`のまま変更しない

しかし、最初の実装でタグを固定できていたのは、設定差分があるAだけでした。

Aはconfig-onlyの処理対象になるため、タグがv1へ戻されます。一方、Bには設定差分がなかったため処理対象にならず、リポジトリ上の候補タグv4を含むマニフェストがそのまま生成されます。

つまり、Aの設定だけを反映するつもりでconfig-onlyを選んだにもかかわらず、同じ実行に含まれていたBのイメージまでまとめて更新されてしまう実装になっていました。

この問題を受けて、次の2つの対象を分けて扱うように修正しました。

config-onlyを提案するか判断する対象：設定変更がある対象
config-onlyが選ばれたあとにタグを固定する対象：同じ実行に含まれ、タグに差分があるすべての対象

Aに設定変更があることをきっかけにconfig-onlyを提案し、config-onlyが選ばれたあとは、AだけでなくBのタグも現在本番で稼働しているものへ固定します。

これにより、config-onlyを選んだ実行では、対象全体のイメージタグを動かさず、必要な設定変更だけを反映できるようになりました。

5. 最終的にどうなったのか

5.1 全体の処理フロー

5.2 実際の実行の流れ

例えば、次のコマンドを実行します。

node --run generate -- --env production --systems microservice-a

--config-onlyを省略した場合は、autoとして扱われます。

ローカル端末で、タグのドリフトと設定差分の両方が検出されると、次のような選択肢が表示されます。

設定変更を反映しようとしています。
ただし、現在稼働中とは異なる候補タグも検出されました。

対象: microservice-a / production-04
  microservice-a-web      現在: 4921e2b  →  候補: ae64a61
	microservice-a-worker   現在: 4921e2b  →  候補: ae64a61

実行内容を選択してください:

  c) 設定のみ反映 (config-only)
     設定だけを更新します。タグは現在のまま変更しません。

  d) 設定とタグを反映 (deploy)
     設定を更新し、アプリの稼働タグも候補タグに更新します。

  a) 中止 (abort)
     何も変更しません。

選択 [c/d/a]: c

config-onlyを選択すると、対象となる本番用の定義が、現在稼働しているタグへ書き換えられます。

[INFO] [prod_config_only] config-only: microservice-a/production-04 を稼働中タグへ巻き戻しました

対話を行わず、明示的にconfig-onlyを実行することもできます。

node --run generate -- \
  --env production \
  --systems microservice-a \
  --config-only yes

この場合は選択肢を表示せず、config-onlyの処理が実行されます。

[INFO] [prod_config_only] config-only: microservice-a/production-04 を稼働中タグへ巻き戻しました

まとめ ―「動く」だけではない開発者体験

今回のタスクでは、単に「設定だけを反映する処理」を実装すればよかったわけではありません。

なぜ設定とタグが一緒に反映されてしまうのか
例外処理をどこへ置けば、緊急時にも忘れられずに使えるのか
既存のデプロイルールを壊さず、どのように元の状態へ戻すのか
CLIで選択した内容と、実際に生成される差分をどう一致させるのか

こうしたことを一つずつ考える必要があり、そのために、まずは既存のデプロイ基盤を理解するところから始めました。

インターンの初期にこのタスクを担当できたことで、デプロイの仕組みやGitOps、マニフェスト生成の流れに対する理解が大きく深まりました。このときに得た知識は、その後に取り組んだ別のタスクでも役立ち、よりスムーズに調査や実装へ入れるようになりました。

「処理が動くかどうか」だけではなく、利用者が選んだ内容と、実際に生成される差分が本当に一致しているかを何度も確認しながら実装を詰めていったのも印象に残っています。

今回のタスクで最も難しかったのは、新しい機能そのものを実装することよりも、専用コマンドとして切り出していた処理を、既存CLIの意味や使い方を壊さずに組み込むことでした。

最初に作った専用コマンドから、既存CLIへ組み込む方針へ大きく変更したのは、緊急時にも普段と同じ操作感で使えて、必要な例外処理が、忘れられにくい正しい場所で実行されるようにするためでした。

この経験を通して、実装者の視点だけで設計するのではなく、これからその機能を使う開発者の立場に立って考えることの大切さを学びました。

一般的なプロダクト開発でユーザー体験を大切にするのと同じように、開発者向けのツールや基盤でも、利用者が迷わず、安全に、期待どおりの操作ができることが重要です。

機能が存在するだけではなく、必要な場面で自然に見つけられ、安心して使える状態まで設計する。

今回のタスクは、Developer Experienceを考えるとはどういうことなのかを、実装を通して学べた経験でした。

最後に

今回、まだまだ未経験なことが多く、未熟な私を信じてチームに迎え入れてくださった皆さんに、心から感謝しています。

特に、日々メンターとして気にかけて支えてくださった大矢さんには、技術的なことだけでなく、タスクの進め方や考え方についても、本当にたくさんのことを教えていただきました。本当に本当に、ありがとうございました！

また、同じDXチームの皆さん、ランチや1on1で助言をくださった方をはじめ、インターン期間中に関わってくださったすべての方に感謝しています。短い期間の中でいただいた言葉やアドバイスは、忘れないように書き留めています。インターンが終わったあとも、これを読み返しながら活用しこうと思っています！

プレイドで経験した初めてのインターンは、間違いなく、私のエンジニア人生における一つのターニングポイントになりました。

改めて、プレイドと、関わってくださったすべての皆さん、本当にありがとうございました！！

これからインターンに挑戦する方へ

この記事を読んで、プレイドでインターンをしようか迷っている学生の皆さんへ。

一文で表すなら、自由度が高い分、自分から動けば動くほど、経験できることがいくらでも広がるような環境だと思います。

とにかくプレイドは、本当に良い環境、良い会社でした！！興味がある方には、ぜひインターンに挑戦してみてください！絶対に後悔しません！

余談

オフィスにある技術書を借りて読めたり、オフィスの設備やモニター、チェアが快適だったり、貸与されるMacBook Proのスペックが高かったり…インターン環境としては良すぎるぐらい、とても充実していました。何よりも、様々な経歴の尊敬できるエンジニアの方々と話せる機会を、自分から1on1を組んだりイベントに参加して作っていけるような、そんな伸び伸びとした環境でした！

インターンでメインプロダクトのデプロイ基盤改善を実現 ー「使われ方」を意識した開発体験の向上ー

目次