はじめに

こんにちは。
10月の1ヶ月間インターンシップに参加させていただいた moto です。

期間中はニフティライフスタイル株式会社のライフバリュー部に所属し、
「ニフティ温泉」施設詳細ページのUI/UX改善を担当しました。

実務でのWebフロントエンド開発の流れや、
インターンで得られた気づきについてまとめたので、
少しでも学生の方の参考になれば幸いです。

目次

実務で使用した技術

[開発]

• 言語：TypeScript
• フレームワーク：React / ビルドツール：Vite
• バージョン管理：Git / GitHub
• コンテナ：Docker
• インフラ：AWS（ECS）
• CI / CD：GitHub Actions（Lint / テスト / ビルド / デプロイ などを自動化）

[分析ツール]

• Microsoft Clarity
• Google Analytics
• Treasure Data

[チーム開発・ドキュメント]

• Confluence / Jira
• Google Docs / Slides / Sheets

主な業務

私は主に、ニフティ温泉の施設詳細ページの実装を担当しました。
業務の流れは次のとおりです。

1. デザイナーの方・企画部の方からの修正依頼を確認
2. 修正内容を具体化した資料を作成（この時点でテストも考えておく）
3. メンターの方に承認をもらう
4. 実装（困った時にすぐ聞ける環境でした）
5. テスト項目書・リリース手順書・実装内容の説明資料を作成
6. コードレビューや資料レビュー・企画部の方の受け入れテストを受ける
7. リリース

自分から提案した改善：写真ギャラリー画像プレビュー画面

写真ギャラリー改善を提案からリリースまで
施設詳細ページには以下のような写真ギャラリーを見られる場所があります。

1枚1枚の写真をクリックした時の “プレビュー画面” のUI/UXを担当しました！

ユーザーがページのどこをよくクリックしているかを分析できるツール「Microsoft Clarity」で確認したところ、ページの顔である写真ギャラリーの、プレビュー画面のクリック数が少ないことに気づきました。
原因を探るため、実際にプレビュー画面を操作してみると、次の点が見づらい・使いづらいと感じました。

• ボタンを押せる範囲がわかりにくい
• 今見ている画像が何枚目かわからない
• 左右キーを長押しすると、画像が無限にループしてしまう
• 画像が拡大されすぎて、画質が少し粗く見える

そこで、これらがクリック数の少なさにつながっている原因ではないかと仮説を立て、次のような改善案をメンターの方に提案し、
実装・リリースまで行いました。

• ボタンを押せる範囲を広げ、ホバー時に色が変わるようにした
• 「3 / 12」のように、今何枚目かを表示した
• 最初と最後の画像ではループせず止まるようにした
• 画像を元のサイズより大きく表示しないようにした

期間内に効果の検証まではできませんでしたが、改善は作って終わりではなく、
効果を測って次につなげるところまでが大事だと実感しました。

スケジュールについて

時刻	やること	備考
09:30 ~	出勤 & 1on1開始	お二人のメンターと ・昨日やったこと ・今日やること ・困っていること を相談する時間
10:00 ~	協力会社の方を含めた部署内朝会	ニフティ温泉に関する 進捗ややること、 疑問点などの洗い出し相談
10:15 ~	弊社内メンバーのみで行う部署内朝会	同様に進捗ややること、 疑問点などの洗い出し・相談
10:30 ~	資料作成・設計・実装	リリースする日はリリース準備
12:00 ~	昼食	オフィス周辺は落ち着いており、 お昼ご飯が食べられます！
13:00 ~	資料作成・設計・実装	リリースする日はリリース開始
14:00 ~	1on1	09:30 の1on1と内容自体は同じ
15:30 ~	輪読会	エンジニアとして知っておきたい 設計・実装・コードレビューの 観点などを学ぶ時間 週3（月・水・金で実施）
16:00 ~	資料作成・設計・実装	1日の作業を振り返り、 やり残しがないか確認
18:00 ~	日報や学校のインターンシップレポート記入	1日のまとめを文書化し、 日報として残すことで、 後から見返せるようにする
18:30	退勤

こうして見ると、1日の中で「相談する時間」がたくさんあります。
最初は、こんなに頻繁に相談していいのかと遠慮していました。
しかし、早めに共有して方向性を確認することで手戻りが減り、結果的に作業がスムーズに進むことに気づきました。

また、週3回の輪読会では、設計や実装、コードレビューの観点など、普段の業務だけでは触れにくい知識を学ぶことができました。

毎日の終わりに日報を書いて振り返ることで、自分が何をできるようになったのか、
何が課題なのかを整理する習慣も身につきました。

学んだこと

テスト観点をいつ整理するべきか

インターン期間中、私は2回のリリースを経験しました。

1回目のリリースでは、デザイナーの方や企画部の方からいただいた修正依頼をもとに実装を進めました。
実装自体に意識が向いていた私は、UI/UXを確認するためのテスト項目書を「実装が終わってから作るもの」だと思っていました。

しかし、ある程度実装が進んでから書き始めると、「この修正では何を確認すべきだったか」「どの画面でどの条件を見ればよいのか」を思い出すのに時間がかかり、レビューでも手戻りが多くなってしまいました。
その経験を踏まえて、2回目のリリースでは、設計や実装と並行してテスト項目書を作成するようにしました。

すると、確認すべき観点が整理された状態で実装を進められ、手戻りや不具合を未然に防ぎやすくなることを学べました。

開発者の言葉ではなく、相手に伝わる言葉で話す

また、企画部の方の前で発表する機会も2回ほどありました。

最初は、実装した内容やこれから対応する内容をそのまま説明しようとして、「ロゴのwidthを調整しました」「余分なSpacerを削除しました」といった開発者目線の言葉を使ってしまいそうになりました。

しかし、聞き手にとって大切なのは実装上の名前や細かいプロパティではなく、「画面上で何がどう変わり、どのように使いやすくなるのか」です。
そこで、「ロゴが大きすぎたため、見やすいサイズに調整しました」「余分な空白をなくし、情報が見やすくなるようにしました」のように、相手に伝わる言葉で結論から説明することを意識しました。

専門用語をそのまま使うのではなく、相手の立場に合わせて伝える難しさと大切さを学びました。

資料は自分のためではなく読み手のため

資料作成についても、大きな学びがありました。

それまでの私は、資料は自分の考えを整理するためのものだと思っていました。
そのため、頭に浮かんだ順番のまま文章を書いてしまい、結論が後ろに回ったり、読み手が何を確認すればよいのか分かりにくくなったりすることがありました。

しかし、レビューを受ける中で、資料は自分のためだけではなく、相手の確認コストや迷う時間を減らすためのものでもあると気づきました。
自分の思考順ではなく、読み手が理解しやすい順番に並べ替え、結論を先に示し、必要な情報を整理して伝える。そうすることで、相手が短い時間で判断しやすくなります。

自分だけが分かっている状態では不十分で、常に相手やユーザーの視点に立って考えること。
これが、今回のインターンシップで得た一番大きな学びです。

さいごに

ここまで読んでくださりありがとうございます。

1ヶ月という短い期間でしたが、実際のサービスの開発から、提案、リリースまで経験させていただきました。
毎日の1on1で相談にのってくださったメンターのお二方をはじめ、皆さまに心から感謝しています。

楽しかったです。本当にありがとうございました。

---

ニフティライフスタイルからのおしらせ

ニフティライフスタイルでは、新卒エンジニアの採用をスタートいたします！

記事にあったような日々の1on1や輪読会などの学習機会はもちろん、実際のプロダクト開発に深く関わり、成長できる環境を整えています。
「早い段階から実務やユーザーファーストな開発に挑戦したい」「チームで協力しながら技術を磨きたい」という学生の皆さまのエントリーをお待ちしています！

まずは気軽に話を聞いてみたいという方も大歓迎です。ぜひ採用ページをチェックしてみてください！
https://herp.careers/v1/nlscareers/jniBsGhkNpii