プロジェクト管理Webアプリ（ポートフォリオ）
作成したアプリについて
このアプリは、プロジェクトとタスクを管理するための Web アプリです。
トップページからプロジェクト一覧へ遷移し、プロジェクトの 作成・編集・削除 を行えます。
各プロジェクトの詳細画面では、タスクの 追加・編集 に加えて、完了 / 未完了 の切り替えによる進捗管理ができます。また、タスクの完了状況から 進捗率 を自動算出し、一覧画面と詳細画面の両方で確認できるようにしています。
プロジェクト一覧では、
- プロジェクト名
- 概要
- ステータス
- 締切日
- 進捗率
をまとめて確認できるため、複数案件の状況を把握しやすい構成にしています。
さらに、
- 作成 / 更新後のフィードバック表示
- API エラー時の再読み込み導線
など、日常的に使いやすい UI を意識して実装しました。
機能について
プロジェクト作成フロー
画面の流れ
一覧 → 新規作成 → 保存 → 一覧へ戻る（追加確認）
ユーザーは、プロジェクト名・概要・締切日 を入力して新しいプロジェクトを作成できます。
保存後は一覧画面へ戻り、作成完了メッセージとあわせて追加結果を確認できます。
プロジェクト詳細でのタスク操作
画面の流れ
一覧 → 詳細 → タスク追加 / タスク編集 / 完了状態の切り替え
各プロジェクトの詳細画面では、タスクの 追加 と 編集 ができます。
また、各タスクは 完了 / 未完了 を切り替えられ、操作結果がタスクリストへ反映されます。
さらに、タスク完了数に応じて プロジェクト進捗率（%） を自動計算して表示することで、プロジェクト全体の進行状況を把握しやすくしています。
機能一覧
- プロジェクトの作成・編集・削除
- プロジェクト一覧表示
- プロジェクト詳細表示
- タスクの追加・編集
- タスクの完了 / 未完了切り替え
- タスク完了率に基づく進捗表示
- API エラー時の表示と再読み込み導線
- 作成 / 削除後のフラッシュメッセージ表示
使用技術
バックエンド
- PHP（
8.3.17） - Laravel（
10.31.0） - REST API
フロントエンド
- HTML / CSS / JavaScript
- React（
19.2.0） - Vite（
7.2.4） - React Router DOM（
7.13.0）
データベース
- MySQL（
8.0）
インフラ・開発環境
- Docker（
27.3.1） - Docker Compose（
2.29.7-desktop.1）
技術選定理由
React（フロントエンド）
プロジェクト一覧では、取得中 / エラー / 成功の状態ごとに UI を切り替えています。また、詳細画面ではタスク追加・編集・完了切り替えに応じて画面更新が発生します。
状態変化に応じて UI を柔軟に更新する場面が多いため、コンポーネント単位で状態管理しやすい React を採用しました。
Laravel（バックエンド）
プロジェクトとタスクのリレーション管理を行う中で、
- Eloquent ORM による関連データ管理
-
withCountを利用した集計 - N+1 問題を意識したデータ取得
を行いやすい点を重視しました。
また、ルーティングやバリデーション機能も揃っているため、REST API を効率よく実装しやすいと考え、Laravel を選択しました。
Docker（開発環境）
Docker を利用することで、PHP や MySQL の実行環境を統一し、環境差によるトラブルを減らせるようにしています。
また、実務でも利用されることが多いため、ポートフォリオ制作を通して Docker を使った開発フローに慣れる目的もあります。
ER 図
なぜこのアプリを作成したのか？
学習や個人開発を進める中で、
- 今どの作業を進めているのか
- どのタスクが未対応なのか
- プロジェクト全体がどこまで進んでいるのか
を把握しづらくなることがありました。
特に、単純な Todo 管理では「プロジェクト単位での進捗管理」が難しく、複数タスクを整理しながら管理できる仕組みが必要だと感じていました。
そこで、
- プロジェクト単位でタスク管理できること
- タスクごとに進捗ステータスを持てること
- 一覧から現在状況を把握しやすいこと
を目的として、このアプリを作成しました。
また、この制作では単に CRUD を実装するだけでなく、
- React と Laravel の責務分離
- REST API を利用したデータ連携
- 状態管理
- リレーション設計
- N+1 問題を意識したデータ取得
など、実際の Web アプリ開発を意識しながら実装を行いました。
苦労した点
フロントエンド
API 通信時の 状態管理 に苦労しました。
プロジェクト一覧取得時に、loading / error / data の状態ごとに UI を分岐し、ユーザーに現在状態が分かりやすく伝わるよう意識して実装しました。
また、通信失敗時にはエラーメッセージだけで終わらせず、再読み込み導線を設けることで、操作を継続しやすい UI を意識しました。
バックエンド
プロジェクト一覧取得時の データ集計処理 に苦労しました。
一覧画面では、
- タスク総数
- 完了済みタスク数
- ステータス判定
- 進捗率
を表示する必要がありました。
最初はフロント側で集計や判定を行っていましたが、処理が分散して管理しづらくなっていました。
そのため、withCount や scope を利用し、集計処理や status 判定を Model 側へ整理することで、責務を分離しながら改善しました。
工夫した点
status を DB に持たず動的に判定
プロジェクトの status はタスク状況によって変化するため、DB には保存せず、Model 側で動的に判定しています。
status を保存すると、タスク更新時に整合性が崩れる可能性があるため、タスク状態から算出する設計にしました。
withCount を利用した集計処理
タスク総数や完了済みタスク数は withCount を利用して取得しています。
最初は PHP 側で count 処理を行っていましたが、一覧表示時の処理量が増えやすかったため、SQL 側で集計する形へ改善しました。
N+1 問題を意識したデータ取得
関連データ取得時には、N+1 問題を避けることを意識しました。
withCount や loadCount を利用し、必要なデータをまとめて取得するようにしています。
フロントエンドとバックエンドの責務分離
最初は React 側で status 判定や集計処理を行っていました。
ただ、ロジックが複雑になってきたため、現在は Laravel 側で集計や status 判定を行い、React 側は取得したデータを表示する役割に寄せています。
今後の改善
Service クラスへのロジック分離
現在の規模では大きな問題はありませんが、今後機能追加によって処理が増えると、Controller や Model にロジックが集中し、責務が曖昧になると考えています。
そのため、今後は Service クラスへ処理を切り出し、役割ごとに責務を整理できる構成へ改善したいと考えています。
コンポーネントの細分化
現在はページコンポーネント内で、
- API 通信
- state 管理
- UI 表示
- モーダル管理
などをまとめて扱っているため、機能追加に伴ってコード量が増えやすい構成になっています。
今後は責務単位でコンポーネントを分割し、可読性・再利用性・保守性を高めていきたいと考えています。
作成時に意識していたこと
とにかく小さく、タスクをばらして言語化
手を動かす前に「何をしたいか」を言葉にし、メモへ分解して小さなタスクに落とし込み、その順番で実装を進めました。
デバッグ
エラーが出た際は、原因候補を一つずつ言語化して切り分け、順番に潰していくことを意識しました。
console.log や Network タブを使いながら、「どこで値が変わっているのか」「どこで想定とズレているのか」を確認しながら進めています。
実務を意識
実務に近い進め方として、
- 仕様整理
- 設計
- 実装
- 動作確認
- 修正
の流れを意識して進めました。
また、コードを書く際も、後から修正しやすい構成や、読みやすい命名を意識しています。
実装後は PR にまとめ、レビューでいただいた意見をもとに改善を進めました。
おわりに
最後まで読んでくださり、ありがとうございます。
ポートフォリオを一通り形にできたことは、自分にとって大きな一区切りでした。
この制作を通して、設計や実装だけでなく、開発の進め方についても多く学べたと感じています。
特に、
- コードを書く前にタスクを細かく分解すること
- エラー時に原因を整理して切り分けること
- 責務を意識してロジックを整理すること
の重要性を強く実感しました。
まだ改善できる点は多くありますが、今後も機能追加や設計改善を続けながら、より良いアプリへ育てていきたいと思います。