ステータスが1列に
16種類、混ざっていました。

何が困っていたのか

工事の進捗は工程管理のアプリに、引き渡し後の不具合対応は別のアプリに入っていました。 どちらも動いてはいます。ただ、「この現場は今どうなっているのか」を知るには、2つを開いて突き合わせる必要がありました。

さらに厄介だったのが、アフターサポート側のステータスです。 1つのドロップダウンに、16種類の値が混ざっていました。たとえばこういう並びです。

性質の違うものが1列に入っているため、「対応中で、かつ写真が足りない案件」を絞り込めません。 どちらか一方しか選べないからです。結果として、担当者が頭の中と個別のメモで管理していました。

どう整理したか — 2軸に分ける

ステータスを、性質ごとに2つの軸へ分けました。

• 軸①：進行状況（1案件に1つだけ）
  未対応 → 訪問日確定 → 対応中 → 解析待ち → 完了
• 軸②：原因タグ（複数付けられる）
  施工不備／請求待ち／写真不足／保険対応／整定値変更

分けただけです。新しい概念は足していません。それでも 「対応中だが写真不足で止まっている案件」が一覧で出せるようになりました。 メーカーの回答待ちについては、待ち日数を自動で数えるようにしています。放置に気づけるようにするためです。

画面の構成

工務部門が日常的に使う範囲を、1つのダッシュボードにまとめました。

• ダッシュボード— 未対応件数、遅延、メーカー待ちなどを最初の1画面で把握
• 工程表— ガントチャート。開くと本日の位置まで自動でスクロールする
• 問い合わせ管理— 上の2軸で管理するカンバン。この事例の中核
• スケジュール／写真・図面／日報／協力会社ポータル／請求原価

既存システムは置き換えなかった

工程管理も、メンテナンス管理も、すでに現場が毎日入力しているアプリがあります。 これを新しいものに置き換えると、現場の手順が全部変わります。そこで置き換えではなく、接続する形にしました。 入力先はこれまでどおり。見るところだけを新しくした、という作りです。

接続してみて分かったこともあります。たとえば工程の進捗を表す項目が、実は既存アプリに存在していませんでした。 代わりに現地調査日・着工日・連系日・完工日といった日付から進捗を導出しています。 「あるはずのデータがない」は、実際に繋いでみるまで分かりません。

この事例から言えること

• 現場の詰まりは、多くの場合技術ではなく分類の設計にあります。1列に混ぜているものを分けるだけで見え方が変わります。
• 既存システムは置き換えるより繋ぐほうが、現場の負担が小さいケースがあります。
• 実データに繋ぐまで、「あるはずの項目がない」は分かりません。設計は繋いでから確定させるほうが安全です。
• 複数のシステムをまたぐときは、「同じものを同じと判定する鍵」を先に1つ決めるほうが早く進みます。その具体例は最適PRMの事例で書いています。