【支援事例】 AppSheet で紙の点検表をデジタル化、脱エクセルを実現

folder_open支援事例

弊社(アプリスイート)が支援した AppSheet (アップシート) 導入事例の紹介です。この事例では、従業員約200名のリサイクル事業会社A社において、ホールディングス傘下の3事業会社の設備点検業務を AppSheet で統合システム化しました。紙の点検表とExcel管理から、タブレットとAppSheetを使用したデジタル点検システムに移行することで、点検記録のリアルタイム共有と標準化を実現しました。

3ヶ月間の開発期間でシステムを構築し、現場に定着させました。開発過程では、技術的な理想と現場の使いやすさの間でトレードオフが発生しましたが、点検作業員からのフィードバックを重視し、継続利用される実用的なアプリを実現できました。

💡この事例のポイント💡

  1. ホールディングス傘下の設備点検業務をAppSheetで統合し、点検表のリアルタイム共有を実現
  2. 現場作業員の声を重視した設計変更により、継続利用される実用的なアプリに
  3. 技術的理想より現場の使いやすさを優先することで、3ヶ月で定着に成功

本ブログ記事及びサンプルデータの著作権は、当社に帰属します。AppSheetを学習する目的での個人使用を除き、無断での複製、転載、改変、翻案、公衆送信等の利用を禁止します。詳細は、ウェブサイト利用規約をご確認ください。

1. 事例概要

A社は廃棄物処理・リサイクル事業を営むサービス業で、ホールディングス傘下に3つのリサイクル事業会社を抱えています。各社では、クレーンやプレス機、ギロチンなどの大型設備について、定期的な点検作業を実施していました。

これまでは各社ごとに独自の点検表様式を使用し、現場で紙の点検表に記録後、事務所でExcelに転記する二重作業が発生していました。また、各社の点検記録をホールディングスで統合把握することも困難な状況でした。

事例概要

項目 内容
業種 サービス業(廃棄物処理、リサイクル)
社員数 約200名
アプリ種別 設備点検
背景 ホールディングス傘下のリサイクル事業会社が3社あり、それぞれ設備ごとに紙の点検表に記録しExcelに転記していたが、業務効率化のために点検表をデジタル化し、点検記録をホールディングスで一覧できるようにしたかった。
AppSheet でやりたいこと
  • 紙の点検表とExcelでの管理から、デジタル(タブレットとAppSheet)に移行したい
  • 事業会社間で点検表の仕様(点検項目、点検記録、不具合報告)を共通化したい
  • 点検表に表示する項目を日次点検と月次点検で分けたい
契約内容 開発委託プラン
開発期間 3ヶ月
開発範囲 狭 ★☆☆ 広
開発難易度 低 ★★★☆☆ 高
運用難易度 低 ★★☆☆☆ 高

2. AppSheet を選定した理由

2-1. 既存業務の課題

現在の業務フロー

各事業会社では、クレーン、プレス機、ギロチンなどの設備について、始業前の日次点検と週1回の週次点検を実施していました。iPadは既に導入済みでしたが、紙の点検表での記録後にExcelへの転記作業が必要で、iPadを活用したデータベース管理への移行を検討していました。

業務効率の問題

各事業会社で紙の点検表に記録後、事務所でExcelに転記する二重作業が発生していました。点検作業者は現場で手書き記録し、事務担当者が後からデータ入力するため、転記ミスのリスクや作業工数の増大が課題となっていました。

統合管理の困難

各事業会社で異なる点検表様式を使用しており、ホールディングスが傘下3社の点検状況を統合して把握することが困難でした。設備の種類や点検項目が統一されておらず、全社的な設備保全状況の可視化ができない状況でした。

2-2. AppSheet 選定の決め手

モバイル対応による現場での直接入力

現場作業者がタブレット端末で直接点検結果を記録できるため、転記作業を削減できます。

傘下3事業会社統合でのデータ共有

複数の事業会社のデータを一つのAppSheetアプリで管理し、ホールディングスからリアルタイムで全社の点検状況を把握できます。

段階的なデジタル化

既存の紙の点検表の項目や流れをそのままデジタル化することで、現場の混乱を最小限に抑えながらシステム移行できます。

3. AppSheet でやりたかったこと

3-1. 実現した機能

統合設備点検アプリ

傘下3事業会社共通の設備点検アプリを構築しました。各社の設備マスタ(クレーン、プレス機、ギロチン)を統合し、点検項目も設備種別ごとに標準化。点検表の入力画面では、設備選択により適切な点検項目タブを移動していく仕組みを実装しています。

「次へ」ボタンをクリックすると、設備に合わせて適切なタブへ移動していく(以下、ダミーデータ使用)。

 

日次・月次点検の分離表示

同一の点検項目でも、日次点検と月次点検で表示項目を分ける機能を開発しました。点検頻度に応じて必要な項目のみが画面に表示されるため、現場作業者の操作負荷を軽減できます。

日次と月次では異なる点検項目が表示される。

 

不具合報告・写真記録機能

点検中に発見した不具合について、その場で報告データを作成し、写真撮影・添付できる機能を実装。撮影した写真には線画でメモを追加でき、不具合箇所を明確に記録できます。不具合報告には処置状況(未済・済)のステータス管理機能も組み込んでいます。

設備に合わせて不具合箇所がリストから選択できる(画面左)。不具合箇所の写真を添付し、不具合箇所を線画でメモする(画面右)。

 

自社修理履歴管理

不具合報告に紐付けて、自社での修理作業履歴を記録できる機能を構築。修理日、担当者、作業内容を記録します。

不具合報告の詳細画面内で、不具合に紐付く修理履歴をインラインテーブルで表示する。

 

セキュリティフィルタによるデータ分離

AppSheet のセキュリティフィルタ機能を活用し、各事業会社の社員は自社のデータのみ閲覧・編集可能とし、ホールディングスの管理者は全社データを統合表示できる権限設定を構築しました。

3-2. 技術的な工夫点

点検項目の階層構造の統一

紙の点検表のデジタル化はAppSheetの得意分野ですが、設備の種類や数が多くなるほど設計が複雑になります。この事例では、設備ごとに点検項目の階層構造が大きく異なることが課題でした。

ギロチンは「設備名 > 点検項目」の2階層、クレーンやプレス機は「設備名 > 分類 > 点検項目」の3階層、ナゲットプラントは「設備名 > 機器名 > 点検箇所 > 点検項目」の4階層となっていました。さらに、点検記録の付け方も「〇×△」「良・否」「異常なし・経過観察・要修理・補修済」など統一されていませんでした。

これらを統一するため、すべての設備で3階層に標準化し、点検表入力フォームではタブを活用しました。

設備名(第1階層)を選ぶと、設備に対応するタブ(第2階層:点検項目の分類名)が表示されて、その中に点検する各部名称(第3階層)が表示される。

 

設備種別による動的項目表示

設備選択時に、AppSheetのShow_If式を活用して点検項目タブの表示制御を実装しました。クレーンを選択した場合は「巻上、横行、走行、その他、電気」のタブが表示され、プレス機の場合は「本体関係、給脂状況の確認、油圧装置、冷却装置、計装装置、その他」のタブ、ギロチンの場合は専用の点検項目タブが表示される仕組みです。これにより、設備に応じた適切な点検項目のみが表示され、操作ミスを防止できます。

巻上、横行はクレーンの点検項目なので、プレス機を選択したときはグレーアウトして選択できない(画面左)。「次へ」ボタンで移動していくと、プレス機の点検項目タブ(本体関係)がアクティブになり、点検記録できる(画面右)。

 

点検項目数の多さへの対応と設計変更

設備あたりの点検項目数は、少ない場合で10程度、多い場合は70以上の項目がありました。当初は開発効率とメンテナンス性を重視し、「点検表」テーブルと「点検リスト」テーブルを分離する設計にしていました。点検表作成時にAutomationで該当する点検リストを自動生成し、点検項目をマスタデータとして管理することでメンテナンス性を確保していました。

しかし、点検作業員から「点検表を作成したらダイレクトに点検に移りたい」「一画面スクロールで点検していきたい」という要望をいただきました。当初の設計では、Automationの実行を待つ必要があり、点検リストをインラインテーブルで個別に開く操作が必要でした。

この要望を受けて、点検項目をマスタデータではなく点検表テーブルの列として実装する設計に変更しました。これにより即座に点検作業を開始でき、一画面での操作が可能になりましたが、テーブルの列数が膨大になり、メンテナンス性が低下するというトレードオフが発生しました。

点検表内に点検リストがインライン表示される(画面左)。階層や詳細情報(点検要領など)を柔軟に表示でき、スライドアイコン(右向きの >)でリストを移動できるのだが、理解が得られなかった(画面右)。

 

現場目線での操作性重視

当初の設計では、開発者目線で「点検記録と不具合報告を紐付けて記録する」仕様を考えていました。この場合、点検記録画面でタブを右端まで移動してから不具合報告を追加する必要がありました。

しかし、点検作業員から「点検中に不具合を見つけたとき、すぐに不具合報告を作成したい。点検記録を中断できるようにできないか」というフィードバックをいただきました。この要望を受けて、点検記録と不具合報告の紐付け(AppSheetのRef機能によるテーブル間リレーションシップ)を解除する設計変更を行いました。

これにより、点検記録を途中でも保存でき、不具合報告を作成してから点検記録に戻って作業を再開できるようになりました。ただし、この変更により入力必須設定ができなくなったため、点検項目の入力漏れについては目視で確認していただく運用でお願いすることになりました。

点検途中で一旦保存できるのだが、Required(入力必須)が使えなくなったため、点検忘れは目視でやることにした。

 

4. 導入効果

4-1. アプリでできるようになったこと

転記作業の削減

従来の「現場で紙記録→事務所でExcel転記」という二重作業が解消され、現場でタブレット入力した内容がそのままデータベース(Googleスプレッドシート)に保存されるようになりました。これにより、転記ミスのリスクがなくなり、事務作業の工数も大幅に削減されました。

傘下3事業会社での統合管理

各事業会社の点検記録がリアルタイムでホールディングスに共有されるため、設備の不具合発生状況や修理進捗を即座に把握できるようになりました。紙ベースでは月次での報告だったものが、日々の状況把握が可能になっています。

点検様式の標準化

傘下3事業会社で異なっていた点検項目や記録方式が統一され、設備保全業務の品質向上と効率化が実現されました。

4-2. 事例から得られた学びと改善点

開発者目線と現場目線のバランス

この事例では、開発効率・メンテナンス性と現場の使いやすさの間でトレードオフが発生しました。点検項目のマスタ管理から列管理への変更、点検記録と不具合報告の紐付け解除など、開発者目線では理想的ではない設計を行いました。

振り返ると、ユーザーの要望をすべて受け入れるのではなく、Automationの数秒待ちやアプリの操作方法に慣れていただく提案もできたのではないかと考えています。アプリには紙とは異なる作法があり、その特性を活かした使い方を提案することも重要だと思います。

現場の声を活かした設計の価値

一方で、現場の声を重視した結果、実際に継続利用されるアプリになったことも事実です。技術的な完璧さより実用性を重視するという判断は、AppSheet開発において重要な視点です。現場の要望と技術的な理想の両立を図る設計やデータ構造の工夫ができれば、より良い解決策を提案できるのではないかと思います。

Share Me!

前の投稿
【支援事例】 AppSheet で営業日報アプリを1ヶ月で開発、全社展開成功
次の投稿
【支援事例】 AppSheet で製造業の業務管理システムを内製化

関連記事

メニュー