バックエンドエンジニアがフロントエンドに挑戦して得た学び

株式会社CastingONEの清水です。
自分は元々バックエンドとしてやっていたのですが、去年の12月頃からフロントエンドをやり始めてからもうすぐ1年が経ちます。
バックエンドエンジニアがフロントエンドを1年弱やっていく過程で起こったこと、役立ったことをまとめてみました。

各時期における経験と学び

1. React・TypeScriptについて何もわからない時期

この時期の特徴

• できること
  • フロントは何もない
• 課題
  • React・TypeScriptについて何もわからない

効果的だった取り組み

• 一般的なReact・TypeScriptの入門記事などを読んで基本的な理解をすること
• 簡単なWebアプリケーションを作ってみる(ToDoアプリやHit&Blowなど)
  • すごく簡単なToDoアプリ以外にも要件が複雑なアプリも1つ作ってみると理解度が増すのでやっておくことをお勧めします

やったけど自分には合わなかったこと

• Reactの公式ドキュメントのLearn配下を一通り読む: https://ja.react.dev/learn
  • この時期に読んだのですが、あまり腹落ちせず大部分忘れました
  • ただこの辺を理解することは大切なので、もう少し理解が深くなってからやればもっと効果もあったんだろうなという感じはします

2. 軽微な修正でも苦戦する時期

この時期の特徴

• できること
  • React・TypeScriptについて基本的なことは理解できるようになった
• 課題
  • 実務のコードを読んでもどこにどんな実装がされているのかわからない
  • 各ディレクトリがどんな役割なのかがわからない
  • 不明な文法が多すぎてコードを読むのに苦戦する
  • 実務コードがわからなすぎて蕁麻疹が出る

効果的だった取り組み

• ディレクトリごとの役割をまとめてみる
  • 詳細
    • 大抵のプロジェクトでは各ディレクトリごとに役割が定められているので、その特徴をまとめていきます
  • メリット
    • ディレクトリごとの役割がわかるだけでもかなり読みやすくなります
• わからなかったことリストを作成して、わからない関数や概念などが出た場合は記載していく
  • メリット
    • 言語化することで理解度が上がります
    • 概念が少し複雑なものはメモしておくことで後でもう一度見返せます

3. 理解に苦しむライブラリと悪戦苦闘する時期

この時期の特徴

• できること
  • 軽微な修正や複雑な処理でなければ修正できる
• 課題
  • 簡単な修正タスクはこなせるようになってきたなと感じることが多いが、コードを読むと何もわからないコードがちょいちょいある
  • 何もわからないコードの元凶は理解しにくいライブラリを用いて実装されているケースが多い
    • 理解が難しいライブラリとしては、React-Hook-Form、Yup、dnd kit、TanStack Query、Reduxなどがある

効果的だった取り組み

• 対象のライブラリを用いて何かしら作ってみる
  • 個人的にはこういう理解が難しいライブラリは手を動かさないと理解できないので、理解力に自信がある人以外は実際に作ってみることをお勧めします

4. 設計入門時期

この時期の特徴

• できること
  • コードを読む上で最低限の知識はついており、複雑なコードもある程度理解できるようになる
• 課題
  • 複雑な仕様を設計・開発を適切に行えるか不安が残る
  • PdMと開発陣が集まり仕様の意見交換と設計を行うリファインメントにおいて自分なりの意見を言っていきたい

ちなみに自分はこの時期に位置しており、一部できていたりできていなかったりします。

効果的だった取り組み

• 自分なりのコードリーディング手法の確立
  • 他の記事でも書かれているようなモジュール単位で読みましょうやツールを使いこなしましょうなどは前提やった上で、自分が一番理解しやすい方法を確立
  • 私がやったコードリーディングの具体的なやり方は以下に記載
• 自分用の設計テンプレートを作成
  • これのおかげでタスク設計や工数の見積もりが実装前から行えるようになった
  • 言語化したことにより設計ができるだけでなく提案なども行えるようになった

利用していたテンプレート
コードリーディングテンプレート

• 利用していた設計テンプレート

テンプレート

なぜこのEpicをやるのか？(自分なりの言葉で再解釈)

• aaa
• bbb
• ccc

[概要]どのように実現するのか？(自分なりの言葉で再解釈)

• aaa
• bbb
• ccc

[詳細]どのように実現するのか？(自分なりの言葉で再解釈)

• 〇〇画面
  • A機能
    • 仕様1
    • 仕様2
    • 仕様3
  • B機能
    • 仕様1
    • 仕様2
    • 仕様3
• △△画面
  • A機能
    • 仕様1
    • 仕様2
    • 仕様3
  • B機能
    • 仕様1
    • 仕様2
    • 仕様3

課題感のあるユースケース(ユーザーの業務フロー)

ユースケース1

• 現状の問題点1
• 現状の問題点2
• 現状の問題点3

ユースケース2

• 現状の問題点1
• 現状の問題点2
• 現状の問題点3

修正後のユースケース(ユーザーの業務フロー)

ユースケース1

• メリット1
• メリット2
• メリット3

ユースケース2

• メリット1
• メリット2
• メリット3

ロジックの詳細設計(実装が複雑な場合のみにメモとして残します)

• 〇〇ロジック
  • ロジック1
  • ロジック2
  • ロジック3

切るべきStoryとTaskは？(✅は今回のVersionに必ず含めなくてはいけないもの、❌は別の人のタスクによるブロッキング)

• 〇〇画面
  • ✅❌Story1
    • TaskA
    • TaskB
  • Story2
    • TaskA
    • TaskB
• △△画面
  • Story1
    • TaskA
    • TaskB
  • ✅Story2
    • TaskA
    • TaskB

実装するつもりでコードリーディングをして気づいたことは？

• 詳細は以下のコードリーディングの項目を参考にしてください

コンポーネント・Props・hooks設計(実装が複雑な場合のみにメモとして残します)

• aaa
• bbb
• ccc

テスト設計(どんなテストが必要になるか書いていきます)

• aaa
• bbb
• ccc

開発フロー(大規模の改修が必要な場合など開発フローが複雑化しそうなものはここで整理します)

• aaa
• bbb
• ccc

その他感じたこと(整理していく中で気になることが色々と出てくるのでここに一旦メモしていきます)

• aaa
• bbb
• ccc

• 設計テンプレートを実際に使ってみた例

テンプレートの利用例

例題: ユーザーのタスク管理機能の追加

なぜこのEpicをやるのか？(自分なりの言葉で再解釈)

• ユーザー体験向上：ユーザーが自身のタスクを管理できることで、作業効率が向上し、プラットフォームの利用頻度も増えることが期待される
• 競合との差別化：他社サービスに類似のタスク管理機能があり、ユーザーにとって有益な機能として求められている
• エンゲージメント向上：タスク管理を導入することで、ユーザーがサービスにより長く関わりを持つことができる

---

[概要]どのように実現するのか？(自分なりの言葉で再解釈)

• ユーザーが簡単にタスクを作成、更新、完了、削除できるインターフェースを提供する
• タスクの進捗や締め切り日を設定し、視覚的に進行状況を確認できるダッシュボードを追加する
• リマインダー通知機能を実装し、期限が近いタスクをメールやアプリ内で通知する

---

[詳細]どのように実現するのか？(自分なりの言葉で再解釈)

• ダッシュボード画面

  • タスクリスト表示機能
    • 仕様1: 全タスクがリスト形式で表示される
    • 仕様2: タスクを日付順、進捗順で並び替え可能
    • 仕様3: フィルタ機能でステータス別に絞り込み表示
  • タスク進捗バー
    • 仕様1: 各タスクの進捗率が表示される
    • 仕様2: 進捗バーの色で進捗度合いを視覚的に区別
    • 仕様3: 完了済みタスクは別のカラーで表示

• タスク作成画面

  • 新規タスク作成フォーム
    • 仕様1: タイトル、説明、締め切り日、優先度を設定可能
    • 仕様2: 進捗の初期値は「未着手」に設定
    • 仕様3: 作成ボタンを押すとダッシュボードに反映
  • リマインダー設定機能
    • 仕様1: リマインダー時間を設定し、通知を受け取れる
    • 仕様2: デフォルトで24時間前に通知
    • 仕様3: リマインダー方法をメールかプッシュ通知から選択可能

---

課題感のあるユースケース(ユーザーの業務フロー)

ユースケース1: タスク管理ができないために、ユーザーが別ツールを併用している

• 現状の問題点1: 既存の機能では進捗や締め切りを可視化できず、管理が難しい
• 現状の問題点2: 外部のツールと連携して管理する必要がある
• 現状の問題点3: タスクを漏らしたり遅延するリスクがある

ユースケース2: タスク漏れや締め切り遅れが発生しやすい

• 現状の問題点1: 期限が近づいているタスクに気づかないケースがある
• 現状の問題点2: 適切なタイミングでの通知がなく、見逃しがち
• 現状の問題点3: 効率的にタスクをこなすためのサポートが不足している

---

修正後のユースケース(ユーザーの業務フロー)

ユースケース1: 一つのプラットフォームでタスク管理が可能になる

• メリット1: タスクリスト機能により、タスクの進捗状況が可視化される
• メリット2: 進捗と締め切りが一目で確認でき、他のツールを使用しなくても管理が可能
• メリット3: タスク漏れや遅延が減り、管理効率が上がる

ユースケース2: 締め切り遅れを防げるリマインダー機能の導入

• メリット1: 期限が近いタスクについて通知を受けられる
• メリット2: 定期的にリマインダーが送られ、見逃しを減少させる
• メリット3: ユーザーが計画的にタスクを進めるサポートが充実する

---

ロジックの詳細設計(実装が複雑な場合のみにメモとして残します)

• リマインダー通知ロジック
  • ロジック1: 通知予定時刻をタスクの締め切り日から計算
  • ロジック2: 通知が実行されたかのステータスを保持し、重複を防ぐ
  • ロジック3: 通知の履歴管理、再通知のスケジュール管理を実装

---

切るべきStoryとTaskは？(✅は今回のVersionに必ず含めなくてはいけないもの、❌は別の人のタスクによるブロッキング)

• ダッシュボード画面

  • ✅❌Story1: タスクリストの表示 → タスク一覧取得APIが必要
    • TaskA: タスク情報の取得と表示
    • TaskB: 並び替えとフィルタリング機能の実装
  • Story2: 進捗バーの追加
    • TaskA: 進捗計算ロジックの実装
    • TaskB: 視覚的に進捗状況を表すUIの実装

• タスク作成画面

  • ✅Story1: タスク作成フォーム
    • TaskA: 入力フォームの構築
    • TaskB: フォームからのデータ送信処理の実装
  • ❌Story2: リマインダー設定機能 → リマインダー設定APIが必要
    • TaskA: 通知のタイミング計算ロジック
    • TaskB: 通知の選択肢を実装

---

実装するつもりでコードリーディングをして気づいたことは？

• データ取得時に非同期処理が多用されているので、タスクリスト表示時のロード時間を短縮する工夫が必要
• フロントエンド側のUIをよりパフォーマンス重視に設計する必要がありそう

---

コンポーネント・Props・hooks設計(実装が複雑な場合のみにメモとして残します)

• タスクリストコンポーネント
• タスク作成フォームコンポーネント
• リマインダー設定コンポーネント

---

テスト設計(どんなテストが必要になるか書いていきます)

• タスク作成フォームのバリデーションテスト
• リマインダー通知の送信テスト
• タスクリスト表示のソート・フィルタリング機能のテスト
• タスク進捗バーの表示ロジックテスト

---

開発フロー(大規模の改修が必要な場合など開発フローが複雑化しそうなものはここで整理します)

• フロントエンドとバックエンドの同時開発が必要なため、APIの仕様を先に定義しておく
• フロントエンドのUI設計とコンポーネント設計を同時進行で行い、バックエンドのAPI実装と連携を取る
• テストコードの実装も同時進行で行い、統合テストを実施してからリリースする

---

その他感じたこと(整理していく中で気になることが色々と出てくるのでここに一旦メモしていきます)

• ユーザーからのタスク通知設定のカスタマイズ要望が多い場合、追加の設定オプションが必要かもしれない

設計テンプレート

• 利用していたコードリーディングテンプレート

コードリーディングテンプレート

• 〇〇画面
  • A機能
    [ ] 仕様1
    - メモ1
    - メモ2
    - メモ3
    [ ] 仕様2
    [ ] 仕様3
  • B機能
    [ ] 仕様1
    [ ] 仕様2
    [ ] 仕様3
• △△画面
  • A機能
    [ ] 仕様1
    [ ] 仕様2
    [ ] 仕様3
  • B機能
    [ ] 仕様1
    [ ] 仕様2
    [ ] 仕様3

• コードリーディングテンプレートを実際に使ってみた例

コードリーディング実例

実例：タスク管理アプリケーション

• タスク詳細画面

  • タスクの締め切り管理機能

    • 締め切り日時のカウントダウン表示はどのように実装されている？
      • メモ1：締め切り日時と現在の日時の差分をリアルタイムで計算し、カウントダウン表示を更新している。
      • メモ2：setIntervalを使用して1秒ごとに表示を更新し、残り時間がゼロになった時点で「期限切れ」と表示されるようにしている。
    • 締め切りを過ぎたタスクに自動的に「遅延」のタグを追加する仕組みはどこにある？
    • タスクの締め切りを更新した場合、通知が再設定されるのはどのようなロジック？

  • コメント機能

    • コメントの投稿が完了したとき、他ユーザーにリアルタイムで通知されるのはどの仕組み？
    • コメントに「いいね」をつけた際、即時反映されるのはどのタイミング？
    • ユーザーが削除したコメントをどこまで保存している？

• ダッシュボード画面

  • プロジェクトの進捗表示機能

    • プロジェクト全体の進捗バーはどのようにして計算されている？
    • 各タスクの進捗ステータスをリアルタイムに反映する仕組みはどこにある？
    • チームごとの進捗率を表示する際のデータ取得方法はどうなっている？

  • フィルタ機能

    • フィルタを適用した状態をローカルストレージに保存しているのはどの機能？
    • フィルタ条件が更新されたとき、どのように画面に即時反映している？
    • 過去に使用したフィルタ条件の履歴をどこで管理している？

さいごに

現在は設計入門の時期と記載しましたが、今後は難易度の高い設計もできるようにしていこうと思います。
今やっていることは効果的なので続きていきつつ他に良い進め方があればアップデートしていきます。