どの現場にも設備台帳はあります。たいていは監査や契約引き継ぎを機に気合いを入れて作られた表計算で、半年ほどは正確、その後は忙しさの中で静かに放置される——この失敗はあまりに普遍的なので、原因を正面から言葉にする価値があります。台帳の多くは「読む人」のために設計され、「生かし続ける人」のために設計されていないのです。
元が取れる項目だけを持つ
- 識別情報:種別・メーカー・型式・製造番号。製造番号は絶対条件——保証、フロン点検記録、履歴はすべてここに紐づきます。
- 設置場所:拠点・フロアやゾーン・設置場所の写真。「屋上東側」の一枚が、訪問のたびの捜索時間を消します。
- 日付:設置日と保証期限。保証内の機器の修理費を払い続ける現場は驚くほど多い——すぐ確認できる場所に期限がないからです。
- コンプライアンス属性:冷媒を持つ機器なら冷媒種と充填量(点検頻度がここから決まります)。証明・点検が要るものは書類と期限。
- 状態と履歴:「状態:良」という静的な欄ではなく、作業・報告書・測定値・写真の実際の積み重ね。状態は履歴から導かれるもので、一度書き込む感想ではありません。
このリストを超える項目には説明責任を求めてください。項目をひとつ足すたびに、入力する人に小さな税金がかかります。その税金の積み重ねが、台帳の放置という形で満期を迎えます。
台帳の質は「記録する瞬間」で決まる
生きた台帳と死んだ台帳を分ける設計判断はひとつ:誰が、いつ更新するのか。答えが「事務所の誰かが、あとで、メモから」なら、台帳はすでに死につつあります。持続するのは現場での記録だけです——機器の前に立つ人が、その場で。技術者が銘板を撮影し、店舗担当者が新設機器を撮り、作業報告書が仕事のついでに台帳を更新する。つまりスマホ第一の入力、転記ではなく撮影、自由記述ではなく導かれた項目、そして電波の死ぬ機械室でも動くオフライン対応です。
全拠点調査ではなく、一拠点から
全拠点の設備調査を発注して一気に載せたくなりますが、こらえてください。まず一拠点——一番手のかかる拠点——を載せ、一か月まじめに回す。不具合は機器に紐づけ、作業は履歴を育て、書類は期限つきで添付する。生きた運用の4週間は、どんな調査仕様書よりも自社のデータモデルを教えてくれます。FaciliTaskerはこのループを前提に作られています:一括インポートで始め、スマホ入力で生かし続け、機器ごとに履歴・書類・フロン情報を持つ台帳を——保守会社が誰であれ——自社のものとして。デモの予約時に一拠点分の表計算をお持ちください。それが何に変わるかをお見せします。
