TechTrainテックブログPublicationへの投稿
🚄

TechBowlのインターンでデザインから実装までの業務を担当してきた！

tomato
に公開
デザイン
UI
frontend
インターン
長期インターン
idea

こんにちは、現在 TechBowl でエンジニアインターンとして働かせてもらっているトマト 🍅(@tomatog29)です！
今回は、インターンで初めてデザインから実装を通したタスクを担当したので、経験を共有したいと思います！！

担当したタスク

今回私は以下の 2 つのタスクを担当しました！

  • Railway をクリアするために必要なスキルを表示する機能のデザイン＋実装
  • クリア条件の UI 改善＋実装

この二つのタスクに分けて話していきたいと思います！

そもそもRailwayとは

そもそも Railway とは、TechTrain 上で提供されている学習用の問題集です！
あらかじめ用意された課題に取り組みながら、Frontend、Backend、Nativeなどの様々な技術を扱います！

Railway の問題には、それぞれクリア条件が設定されています。
例えば、
「タグを使い分けて見た目を作ろう」という問題では、次のような条件が指示されています。

  • HTML タグが正しく使われていること
  • img タグに src 属性が設定されていること
  • タイトルは p タグと span タグを使い、id や class を使わないこと
  • サブタイトルは p タグを使い、id や class を使わないこと

のように、様々な条件が決められていて、その条件を満たす実装を行う形式になっています！

タスク ① Railway をクリアするために必要なスキルを表示する機能

タスク概要

既存の Railway ページでは進行自体はできるものの、ユーザーから見るとクリアに必要なスキルがどこにもまとまっておらず「結局何を学べばこの Railway をクリアできるのかわからない」という疑問が残る状態でした...
なのでRailway の進行と学習のつながりをわからりやすくするために、各Railwayの習得までに必要なスキル一覧を入れ込むデザインを作成しなければいけませんでした。

Railwayには下記の情報を入れる必要があります。

  • 学習項目名
  • 学習レベル(入門/初級/基礎/応用)
  • 習得済みかどうか(user_abilities テーブルを参照して判定)
  • 対応する学習ページへのリンク(新しいタブで開く)

デザインの方針

デザインを考える上で最も意識したのは、もともとの学習ページにあるスキル一覧の階層構造との一貫性です！ユーザーが既に慣れ親しんだ階層と同じにすることで、迷うことなく UI を操作できると考えました！

しかし、このまま表示すると学習項目が多い Railway ではコンテンツが縦に長くなりすぎてしまいページ全体のバランスが悪くなってしまうという問題がありました。

この問題を解決するためにアコーディオン式のUIを採用しました。必要な情報はすべて含みつつもコンパクトにし、ページを圧迫しないような構造を実現することができました。これによって、ユーザーは必要なスキルを見たい時に見ることができ、次に何を学習すればいいのか迷わずに進められることができるRailwayページになりました！！

実装での工夫

データ構造の修正

API から取得した必要なスキルのデータは、カテゴリ情報を持たない必要なスキルだけの配列として渡されていました。なので、これを作成したデザインの「カテゴリ → ランク → 学習項目」へ変換することでよりわかりやすくデータを扱うことができるので変換しました！！

例えば、API からは以下のような配列が返されていました :

// 変換前: フラットな配列構造
[
  {
    id: 1,
    name: "HTMLの基本構造",
    ability_rank: 1,  // 1=入門
    ability_category: { name: "HTML" },
    acquired: true
  },
  {
    id: 2,
    name: "セマンティックHTML",
    ability_rank: 2,  // 2=初級
    ability_category: { name: "HTML" },
    acquired: false
  },
  {
    id: 3,
    name: "CSSセレクタ",
    ability_rank: 1,
    ability_category: { name: "CSS" },
    acquired: true
  }
]

これを以下のような階層構造に変換しました :

// 変換後: カテゴリ → ランク → 学習項目の階層構造
{
  "HTML": {
    description: "情報構造を定義するためのマークアップ言語",
    ranks: {
      "入門": [
        { id: 1, name: "HTMLの基本構造を理解している", ... }
      ],
      "初級": [
        { id: 2, name: "セマンティックタグを使える", ... }
      ]
    }
  },
  "CSS": {
    description: "見た目を定義するための言語",
    ranks: {
      "入門": [
        { id: 3, name: "CSSセレクタの基本的な使い方ができる", ... }
      ]
    }
  }
}

UIコンポーネントの責務分離

データ構造の修正を行うときにUI コンポーネント内で変換処理を書いてしまうと責務が混雑します。なのでgroupAbilitiesByCategory という配列を変換する関数を用意して、以下のデータ変換を行うことによって、UI は「整形したデータを受け取って描画するだけ」というシンプルな責務になるようにしました！

useMemoの使用

学習項目のデータは頻繁に変わらないので、再レンダリングをするたびに同じ変換処理を行うと、余分な計算や UI ロジックの再実行が発生してしまうので今回はuseMemoを使用しました！
それによって、UI は変換済みのデータを受け取って描画するだけになりシンプルな構造にすることができました！

このように データの正規化・責務分離・状態管理の最適化 を中心に設計することで、単なる UI 追加ではなく、今後も拡張しやすい堅牢な実装基盤を構築することができました。

タスク ② クリア条件表示部分のデザイン修正・実装

改善前の課題

Railway ページには元々クリア条件が表示されています。
クリア条件は重要な情報なのにも関わらずページを訪れた際に「この Railway をクリアするには何が必要なのか」が一目でわからない状態になっていました。

また、同じエリアに面接判定など他の情報も混ざっていて、情報の優先度がわかりづらくなっていました。クリア条件は Railway を見るときにとても重要な情報ですが、その重要性が UI に十分反映されていませんでした。

初回改善:視認性の向上を目指して

課題から2点をテーマにデザインを作成しました！

  • ユーザーがページを開いた瞬間に自然と視界に入ること
  • 情報としての優先度が直感的に理解できること

修正前はエリアが小さく目立ってなかったのでわかりやすくスペースをとって表示するようにしました！また、同じエリアに置かれていた面接判定の情報と役割が違うので、役割を分ける意味合いとしてカード UI に分離し見やすさと理解しやすさを高くしました。

大きく目立つように設計し直すことで、クリア条件がより明確に、そしてストレスなく読み取れるUIへ改善することができました。ユーザーが「まず何を見ればいいのか」「何をすればいいのか」を簡単に理解できるようになり、Railway を進めるうえで迷いが生まれにくい体験になったと感じていました...ですが

レビューで見えた新たな課題

実際にプレビューしてレビューをいただいたところ、新たな問題が出てきました...

場所を大きくとったのは確かに見やすくはなりましたが、「トップの場所を取りすぎていて本文までの距離が長くなってる」というフィードバックを受けました。
見やすく、わかりやすく表示するのは重要なのですが、そこに集中しすぎて全体の構成まで目を向けることができていませんでした。

フィードバックを受けて

試行錯誤を重ねる中で、
「クリア条件をわざわざカードとして別枠で表示する必要はないのでは？
本文の中に自然に組み込んでしまえば、もっと分かりやすくなるのでは？」
と思いました！

そこで、クリア条件と面接判定に関する情報を、独立したカードとして表示するのではなく、本文の一部として統合したデザインを作成してみました。

その変更によって、今までの

  • 情報の重要度が低く見えてしまう問題
  • 全体の構成が分断され、読解の流れが崩れる問題
  • ユーザーが本文に辿り着くまでに時間がかかる問題

を解決することができました！

クリア条件はRailwayの目的の部分であり、重要度は本文と同じぐらいあるはずなので切り離されているべきではありません。
本文内に統合することで、ユーザーは自然にゴールを理解できるようになりました！！

実装での工夫

このタスクでは、デザイン変更に伴う実装において、単に UI を調整するだけでなく、既存コードの構造的な問題点を改善する機会として捉えました。

不要なコードの削除

クリア条件の常時表示化に合わせて、開く閉じるのボタンがなくなったり個別のUIがなくなったので不要な箇所を積極的に削除しました！単に動作を維持するだけでなく、「必要最小限のコード」を意識して、将来のメンテナンス時にコードを読む負担を軽減できたと思います！

得られた学び

既存 UI を守りつつデザインを作る

TechTrain ではデザインシステムがしっかり整備されているので、サービス全体で統一感のあるデザインを作ることができます。ですが、決められたデザインシステムをできる限り守りながら新しいUIを作成することは、思った以上に難しいと感じました。

どこまで既存のルールを使い、どこから新しくデザインを作るべきかの判断に悩む場面がとてもありました。システムを尊重するのは重要ですが、遵守しすぎることでその場面に適した UI が作れなくなってしまう可能性もあります。
なので、デザインシステムを理解した上で基本は守りつつ、必要な場面では柔軟に判断することが重要だと学びました！

短いサイクルで改善を回すことの有効性

タスク ② のデザイン修正では、初回の提案がレビューで「場所を取りすぎている」という指摘がありました。もし最初からレビューを出さずに時間をかけていたら、この問題に気づくのが遅くなっていたと思います。早めにレビューをもらい、小さく修正を重ねるアプローチによって、認識のズレを少なく抑えることができました。「とりあえず動くものを見せる」ことで、言葉だけでは伝わりにくい問題点が可視化されスムーズにできました！！

情報設計にでの「表示順と密度」の重要性

クリア条件の UI 改善では、「目立たせること」と「圧迫感を与えないこと」のバランスが非常に難しいことがわかりました。情報は単に表示するだけではダメで、どの順番で、どれくらいのスペースで見せるかによって、ユーザーの理解のしやすさが大きく変わると思いました。特に Railway ページのような学習コンテンツでは、ユーザーが「次に何をすべきか」を迷わず理解できる情報設計が重要だと学ぶことができました！！

実装における設計の重要性

実装面でも多くの学びがありました。特に、コンポーネントの責務分離やデータ構造の正規化といった設計の工夫が、将来的なメンテナンス性に影響することを実感できました。「今動けばいい」ではなく、「後から変更しやすいか」を意識した実装の大切さを学びました！

おわりに

今回のインターンを通して、実務の中でデザインと向き合う楽しさと難しさの両方を感じることができました。個人開発ではなかなか経験できない「既にあるものをより良くする」という視点で考える時間は、とても新鮮で刺激的でした。

また、レビューやフィードバックを通して、チームでプロダクトを作ることの面白さも強く感じました。自分一人では思いつかない考え方や判断基準に触れられたことは、今後の開発やデザインにもきっと活きてくると思います。

このような貴重な経験の場をいただけて、本当にありがたいです！

ここまで読んでいただき、ありがとうございました！
少しでも参考になれば嬉しいです！！

TechTrainテックブログ
TechTrainテックブログPublication

TechTrainのテックブログです！ 試したことや実際の開発について書いていきます！

Discussion