🛠️

FixFlowを公開しました｜不具合報告・修繕対応フローを最小構成で整理するLaravelサンプル

に公開
Laravel
PHP
設計
ポートフォリオ
業務改善
idea

はじめに

こんにちは、ヱビスです。
早速ですが、FixFlow というデモサイトを公開しました。

FixFlow とは、店舗や施設で発生する設備不具合について、
報告 → 担当設定 → 進捗更新 → 完了確認 までを整理する Laravel 製のサンプルプロダクトです。

このプロダクトで私がやりたかったのは、機能をたくさん載せることではありませんでした。
現場で起きがちな「情報の分散」を、最小限の仕組みでどう整理できるかを形にすることに注力しました。

単なる CRUD や管理画面のサンプルではなく、
現場で起きそうな業務の詰まりを、どういう流れで整理するか を見せることを重視しています。

このプロダクトを作った理由

店舗や施設の運営では、設備不具合への対応そのものよりも、
報告・共有・進捗管理がバラけること で運用が崩れやすいと考えています。

たとえば、次のような流れは珍しくありません。

  • 現場スタッフが不具合を見つけます
  • 店長に口頭で伝えます
  • 店長が業者に電話します
  • 本部にはチャットで共有します
  • 修理完了も口頭やメッセージで流れていきます

これでも、その場しのぎでは回ります。
ただし、案件が増えたり拠点が複数あったりすると、急に追えなくなります。

  • いま未対応の案件はどれか
  • 緊急度が高いものはどれか
  • 誰が担当しているのか
  • どこまで進んでいるのか
  • 過去にどう対応したのか

こうした情報が一箇所にまとまっていないと、
修理そのものよりも「管理の分散」の方が問題になります。

FixFlow は、そこを整理するために作りました。

想定した現場

FixFlow は、次のような現場を想定しています。

  • 飲食チェーン
  • 小売店
  • 介護施設
  • 複数拠点を持つ施設運営

登場人物も、いわゆる情報システム部門だけではありません。

  • 現場スタッフ
  • 店長 / 現場責任者
  • 本部担当
  • 総務 / 設備担当
  • 修理業者

ここで重要なのは、
現場は記録のために働いているわけではない という点です。

営業や利用者対応が優先されるので、記録や整理は後回しになりやすいです。
だからこそ、最初から大きな仕組みを入れるより、
まずは「最低限ここだけ揃えば追える」という単位で整理する必要があると考えました。

システム化前に起きやすいこと

FixFlow で扱っているのは、何か特別な業務ではありません。
むしろ、よくある困り方です。

1. 未対応案件が一覧で見えません

不具合の報告が口頭・電話・チャットに分かれると、
「今なにが残っているのか」が見えません。

2. 緊急度の高いものが埋もれます

空調トラブル、冷蔵設備の不調、水漏れなど、
早く見ないとまずいものほど、連絡の流れの中で埋もれやすくなります。

3. 担当が曖昧になります

「たしか誰かが業者に連絡していたはず」
この状態になると、対応しているのか、していないのかが分からなくなります。

4. 履歴が再利用しにくくなります

過去の修繕履歴や症状、写真、コメントが残っていないと、
同じような不具合が起きたときに毎回ゼロから確認することになります。

FixFlow で整理した範囲

FixFlow は、現場全体をフルシステム化するプロダクトではありません。

やったことはかなり絞っています。

  • 不具合報告を登録します
  • 写真を添付します
  • 優先度を設定します
  • 対応担当者を設定します
  • 対応状況を更新します
  • コメント履歴を残します
  • 未対応案件を一覧で追えるようにします

要するに、
「どこで何が起きていて、誰が持っていて、どこまで進んでいるか」
を追えるようにするところまでです。

ここを先に揃えるだけでも、現場の混乱はかなり減らせると考えています。

このサンプルで重視したこと

機能の多さより、流れの自然さを重視しました

見せたいのは機能一覧ではなく、
報告から完了確認までの一連の流れ です。

そのため、画面単位で派手さを出すよりも、
状態がどう動くか、履歴がどう残るかを重視しました。

いきなり大きくしないことを重視しました

こういう題材は、やろうと思えばいくらでも広がります。

  • 通知
  • 権限管理
  • エスカレーション
  • SLA
  • 再発管理
  • 業者マスタ管理
  • 拠点別集計
  • ダッシュボード強化

しかし、最初から全部入れると、
何を整理したかったのかがぼやけます。

今回はあえて、
最小構成で業務フローの価値が伝わる範囲 に止めました。

「現場にありそう」を優先しました

SaaS 的な見栄えだけを作ると、
結局「それっぽい管理画面」で終わります。

FixFlow では、まず業務背景があり、
そのうえで「この現場なら、この整理の仕方が自然そうだ」という筋を優先しています。

状態を持てるようにした意味

FixFlow では、不具合対応をただのメモではなく、
状態を持つ業務 として扱っています。

たとえば、次のような流れです。

  • 報告済み
  • 確認中
  • 業者手配中
  • 対応完了

実際の運用では、もっと細かく分ける余地があります。
ただ、サンプルとして重要なのは、
「報告されたものが、その後どう動いたか」が追えることです。

これがないと、次のような状態になりやすいです。

  • 受け付けただけで止まっています
  • 誰が見ているのか分かりません
  • 完了したのに一覧から消えていません
  • 完了報告だけがチャットに流れて終わります

状態遷移を置いたのは、
見た目のためではなく、業務の責任の所在を追いやすくするため です。

あえて入れていないもの

この手のサンプルで気をつけたかったのは、
「作っていないものまで抱え込まないこと」です。

現時点で FixFlow に入れていないもの、あるいは深掘りしていないものもあります。

  • 細かい権限制御
  • 通知の自動化
  • 再オープンの厳密運用
  • 修理業者の高度な管理
  • 詳細な分析ダッシュボード
  • 複雑な承認フロー

これは手抜きではなく、意図的です。

ポートフォリオとしてまず見せたいのは、
現場の詰まりをどう切り出し、どこまでを最小システムの対象にしたか だからです。

全部を盛ると、説明の焦点がずれます。
FixFlow では、報告から完了確認までの流れに集中しました。

FlowBlueprints の中での位置づけ

FixFlow は、FlowBlueprints という業務フロー起点のポートフォリオ群の1本目です。

FlowBlueprints では、機能から作るのではなく、先に次を考えるようにしています。

  • どんな現場か
  • 誰が登場するか
  • 今どう回っているか
  • どこで詰まるか
  • それを最小限でどう整理するか

その結果として、必要な画面や機能を定義します。

FixFlow は、その考え方を一番分かりやすく出せる題材として作りました。
不具合対応は、現場で起きる頻度が高く、しかも管理が散りやすいからです。

作ってみて感じたこと

作りながら改めて思ったのは、
業務システムの価値は「高機能であること」だけでは出ないということです。

むしろ、重要なのは次の整理だと思っています。

  • どの業務を対象にするのか
  • どこを問題と捉えるのか
  • どこまでをシステムで持つのか
  • 何をあえて持たないのか

この整理の方が、ずっと重要です。

FixFlow は大規模なシステムではありません。
ただし、現場の混乱を減らすための最小構成 としては、十分に意味のある単位にできたと考えています。

デモ

FixFlow は、説明を読むだけでなく、実際に触って流れを確認できるようにしています。

不具合の登録から、担当設定、進捗更新、完了確認まで、
どのように情報が整理されるかを見てもらえればと思います。

おわりに

FixFlow は、
「店舗や施設で発生する不具合対応を、報告から完了確認まで整理する」
ためのサンプルとして作りました。

派手な機能を並べるのではなく、
口頭・電話・チャットに散っていた情報を、
最小限の仕組みで一つの流れとして扱えるようにすることを目指しています。

今後も FlowBlueprints プロジェクトでは、
業務フローを題材にしたサンプルを追加していく予定です。

単なる管理画面集ではなく、
現場の課題をどう整理し、どこまでを最小システムとして切り出すか が伝わるものを積み上げていきます。

Discussion