このサンプルで優先したこと
フロー整理を最優先
報告 → 担当設定 → 進捗更新 → 完了確認 の流れを、最小構成で明確に見せることを重視しました。
現場の混乱を減らす
機能の多さではなく、口頭・電話・チャットに分散する情報を一元化し、記録漏れを防ぐことに焦点を当てました。
最小単位のデータ設計
複雑なマスタ管理や権限制御より、業務に必要な最小限のデータ構造で成立させることを優先しました。
拡張可能な基盤
MVPとして筋の通った範囲に止めつつ、Laravelの設計パターンで自然に拡張できる余地を残しています。
あえて作らなかったもの
これらは「未実装」ではなく、初期スコープから意図的に除外した機能です。
再オープン機能
完了後の状態変更より、初回対応の流れを明確にすることを優先
通知機能（メール・Slack）
業務フローの中核説明より周辺機能が前に出るため初期スコープから除外
詳細な権限制御
初期版では役割差よりフロー整理を優先。Policy で後から拡張可能
業者専用画面
店舗側の業務フローに絞り、関係者が増える複雑さを避けた
マスタ管理画面（拠点・ユーザー）
管理画面集に見えるのを避け、不具合対応フローに集中
分析ダッシュボード・SLA管理
データ分析機能は別フェーズとし、記録と対応の基本に絞った
複雑な検索条件保存
基本的な絞り込みで十分と判断し、過度な機能追加を避けた
なぜこの範囲に絞ったのか
✕ 広げすぎた場合
- •管理画面の多さが主役になり、業務フロー理解が二の次に
- •通知・権限・マスタなど周辺機能に実装が分散
- •「何を解決するサンプルか」が不明瞭に
- •見せ場が「機能数」になり設計意図が伝わらない
✓ 今回の最小構成
- •不具合対応フローの見える化に集中
- •報告から完了までの流れが明確に理解できる
- •MVPとして筋の通った範囲に止めている
- •「分かった上で削っている」ことを示せる
拡張ポイント
現在は作っていませんが、設計上どこに伸ばせるかを示します。
Policy を追加してロール別制御に拡張
Laravel の Policy を使えば、店舗スタッフ・管理者・業者ごとの操作権限を細かく制御できます。
Notification / Job で通知機能を追加
メール送信やSlack通知は、Laravel の Notification と Queue を使って後付けで実装可能です。
ステータス遷移ルールの拡張
現在のシンプルな状態遷移を、保留・再オープン・エスカレーションなどに拡張できます。
管理画面の追加（Stores / Users）
拠点管理やユーザー管理画面を追加すれば、運用向けの機能を強化できます。
ダッシュボードや検索条件保存
集計・分析機能や、よく使う検索条件の保存は、基本機能が固まった後に追加できます。
実装例
最小構成でどこまで業務フローを整理できるか、実際の画面をご覧ください。
不具合一覧画面
サマリーと一覧で進捗を可視化
詳細・対応管理画面
情報と履歴を一元管理
技術スタックと実装判断
主要技術
- Laravel を前提にした設計
- Eloquent でのシンプルなデータ操作
- Blade + Tailwind CSS での画面構築
- シンプルな認証・認可機構
実装の考え方
- 過度なSPA化より業務の流れ優先
- 最小単位のデータ設計で成立
- 画面数ではなく業務整理が見せ場
- Laravel らしい拡張性を確保
FixFlow 全体の位置づけ
FixFlow は、FlowBlueprints 配下の1本目のサンプルプロジェクトです。現場にありそうな業務の詰まりを、最小システムで整理する考え方を見せています。
将来的に、他の業務フローサンプルへ展開できる設計思想を持っており、「機能の羅列」ではなく「業務理解と整理」を重視したポートフォリオを目指しています。