タイの自動車部品メーカー向けGoogle Cloud共通データベース・KPIダッシュボードWebアプリ

課題の背景

顧客は、社内データを自社GCP上の単一データベースに統合し、複数分野のKPIを単一のWebサイトで確認できるようにすることを求めていました。着手前は、分野ごとのデータが複数のシステムから出力された別々のレポートファイルに分かれていました。

顧客は、従業員が現場データの入力とダッシュボードの閲覧を同じWebサイトで行えるようにすることを求めていました。そのため第一フェーズは内部損失と不良のKPIから始め、その後、他部門のデータを同じシステムに追加しました。

要件と制約

システムは顧客のGoogle Cloud Platform（GCP）上で稼働し、顧客の情報システム部門の要件を満たす必要がありました。主な要件と制約は次のとおりです。

• データは、顧客企業のGCP上に、同社のアカウントとポリシーのもとで保存します。
• サーバー管理の負担を最小限にするため、serverless（クラウド事業者がサーバーを管理する）のクラウドサービスを中心にシステムを構成します。
• ユーザーは従来のExcelレポートファイルを引き続き作成し、一部の現場データをWeb画面から入力します。
• クラウドに載せるシステムは顧客の情報システム部門のセキュリティチェックシートを通過する必要があり、導入のたびに事前承認を得る必要があります。
• 第一フェーズの開始時点では入出力ファイルの形式が固まっておらず、開発中に要件の変更がありました。

この統合データベースシステムの仕組み

このシステムは既存のレポートファイルを単一データベースに取り込み、KPIを計算して、Webブラウザ上にグラフと表で表示します。データの大半がすでに既存のレポートファイルにあったため、従来の形式のままファイルを受け付ける方式を選びました。そのためWebの入力画面は、レポートにまだない現場データに限って用意しています。

顧客はサーバー管理作業の削減も求めていたため、Cloud RunやCloud SQLなどGCPが管理するサービスを使用し、サーバー管理の作業を減らしています。システムの処理の流れは次のとおりです。

1. 1

   データの取り込み

   ユーザーはアップロード画面からExcelレポートファイルと是正計画ファイル（PDF）をアップロードします。Part No.（部品コード）ごとの不良数や時間別生産実績などの現場データは、Defect Record Sheet画面とProduction Today画面から入力します。

2. 2

   KPIの自動計算

   Overall Summary画面は、選択した期間（日次、週次、月次、年次）ごとにInternal Lossと不良率を計算します。Business KPI Internal Loss画面には、製品グループ別のグラフ、損失金額、KPI目標設定画面で設定した目標線を表示します。

3. 3

   優先して対処すべき不良の確認

   不良ダッシュボードは発生の多い不良を順位付けし、上位の項目について担当者が原因、対策、完了予定日を入力できます。ユーザーはグラフ上の点をクリックして、添付されたPDFファイルを開くことができます。

4. 4

   計画と生産実績の比較

   Performance Analysis画面は、マスターデータ（Master Data）画面で設定した生産サイクルタイムから生産計画を計算し、入力された生産実績とシフト別に比較します。時間ロスの原因となった問題も記録します。

5. 5

   顧客のチェックシートに沿ったセキュリティ管理

   クラウドセキュリティ対応の範囲は、WebアプリケーションファイアウォールのCloud Armor（WAF）、SSL暗号化、ウイルス対策ソフトのClamAV、パスワードルール、システム管理者の権限制限、アクセス・操作ログ、データベースのバックアップ、開発用と本番用のGCPの分離です。

納入物

当社は2023年に、第一フェーズのWebアプリを顧客のGCP上で納品し、操作マニュアルとシステム管理ドキュメントも提供しました。第一フェーズの主な画面は次のとおりです。

• 概要画面（Overall Summary）：期間別のInternal Lossと不良率
• Excelレポートファイルと是正計画ファイル（PDF）のアップロード画面
• KPI目標設定画面と、製品グループ別のBusiness KPI Internal Loss画面
• 不良記録の入力画面とダッシュボード（Defect Record Sheet）
• 時間別生産実績の入力画面（Production Today）と、シフト別の計画と生産実績の比較画面（Performance Analysis）
• マスターデータ画面（Master Data）とユーザーログイン画面

このシステムは第一フェーズからどのように複数モジュールへ拡張されたのか

当社は、各部門のモジュールを同じWebアプリとデータベースに段階的に追加することで、このシステムを拡張しました。各モジュールには個別の範囲と要件文書があります。セキュリティ対応では、新しいモジュールを本番環境に載せる前にテストできるよう、開発用と本番用のGCPの分離と導入前の承認手順を追加しました。作業の順序は次のとおりです。

1. 2023年 第一フェーズ：内部損失KPI、不良、生産実績、マスターデータ。納品し、検収署名を受領
2. 2023年 内部損失モジュールの改修：表へのPDFファイル添付、表画面からのファイルアップロード、アップロードデータと不良レポート・生産数レポートとの照合、アップロード画面での通知
3. 2023年 売上・利益モジュール：Sales Dashboard（計画、実績、差異）、Profit Dashboard、Forecast、およびテンプレートに沿ったアップロード画面とデータエクスポート
4. 2023年 顧客の情報システム部門のチェックシートに沿ったクラウドセキュリティ対応
5. 2023–2024年 品質モジュール：顧客からのクレームと苦情、市場クレーム、メール設定。2024年初めの時点で修正とデータ正確性確認のサイクルにありました

同じ顧客の経費モジュールは別の事例です。詳しくは部門別に実際の経費を目標と比較して追跡するWebアプリの事例をご覧ください。

検収書類で確認できた成果

本事例で確認できた成果は、第一フェーズが納品済みであり、顧客代表者が署名した検収書類があることです。後から追加したモジュールについては、当社のプロジェクト状況サマリーがあるのみです。各書類で確認できる内容は次のとおり異なります。

• 第一フェーズの検収チェックリスト（Exit Criteria Checklist）：顧客代表者、担当検査者、当社側の署名者が2023年7月に署名しました。
• 納品書：顧客代表者が2023年8月に第一フェーズのシステムの受領に署名しました。
• 第一フェーズの完了文書：操作マニュアル、システム管理ドキュメント、署名済みの検収チェックリストを納品物の一覧に記載しています。
• 当社の2023年末時点のプロジェクト状況サマリー：当社の内部文書であり、顧客の検収書類ではありません。追加開発モジュールの状況を示す唯一の情報源です。

第一フェーズの後に追加したモジュールには署名済みの検収書類がまだないため、当社はこれらのモジュールを検収済みとは呼んでいません。第一フェーズの検収後の追加修正項目には、別途再テストのサイクルがありました。本事例にはビジネス成果の測定値がないため、書類で裏付けられた成果のみを報告しています。

私たちが学んだこと

本案件から、レポートファイルのデータを受け取る統合データベース案件について次の原則が得られました。

• 開発前に元ファイルの形式を合意します。レポートファイルを読み取るシステムは、ファイル構造に従って値を読み取ります。本案件では入出力ファイルの形式が開始時点で固まっておらず、開発中に変更がありました。そのため次の案件では、システムの開発に着手する前に、実際のサンプルファイルを用意して、列、コード、KPIの計算式を数値の責任者と確定するべきです。
• ファイルアップロードを受け付けるシステムは、データを元レポートと照合する必要があります。本案件では、内部損失モジュール改修の範囲に、不良レポート・生産数レポートとのデータ照合とアップロード画面での通知が含まれていました。ダッシュボードは、数値が各部門の使用しているレポートと一致してはじめて意思決定に使えるからです。
• 情報システム部門のセキュリティ要件はクラウドシステムの一部であり、後から付け足す作業ではありません。組織のクラウドに載せるシステムは、チェックシートへの回答、ファイアウォールの設定、利用ログの保存、導入前の承認手順が必要です。そのため最初から作業範囲に含めるべきです。

この手法をお客様の業務に適用する方法

貴社に複数分野のKPIレポートが複数のExcelファイルとして存在し、自社のクラウドアカウントをすでにお持ちであれば、本事例と同じアプローチを利用できます。既存のレポートファイルを統合データベースに取り込み、KPIを計算して単一のWebサイトに表示する方法です。このアプローチは、各部門が自部門のファイルで数値を管理し、全体像を見るには誰かがレポートを集約するのを待たなければならない場合に適しています。調整が必要なのは、ファイル形式、KPIの計算式、貴社のセキュリティ要件です。

• すべてのセットについて実際のサンプルレポートファイルを用意し、ファイル形式をどのくらいの期間維持できるかを確認します
• 開発前に、各部門の数値責任者とKPIの計算式および緑/赤の基準を取り決めます
• 情報システム部門のセキュリティチェックシートを早い段階で入手し、作業範囲に含めます
• データが最も整っているモジュールから始め、各モジュールでユーザーのフィードバックに基づく修正サイクルの余裕を見込みます