タイの自動車部品製造会社向けに、工場内のサーバーで欠陥を記録するPチャートウェブアプリ

課題の背景

課題は、紙とExcelに分かれていた業務を単一のWebアプリに移すことでした。このWebアプリは、シフト、ライン、ワーク別に不良記録を受け付け、ラインレベルと組織レベルの両方の不良目標を保持する必要がありました。グラフ、異常と対策の記録、レポートは、この同じデータを使う必要がありました。

要件と制約

システムは工場のサーバー上で稼働し、組織の既存システムのデータを使う必要がありました。作業範囲、要件定義書、検収項目による主な要件は次のとおりです。

• 工場のサーバー上（On-Premise）にUbuntu Server上のDockerで1システムを設置し、データをPostgreSQLに保存します。
• ユーザーは組織の既存システムのAPI経由でログインします。
• 不良率の計算に使う生産数は既存システムからAPI経由で取得し、不良数は作業者が入力します。
• 不良種類（Defect Type）はシステムが定める固定リストとし、その種類の下にユーザーが不良項目（Defect Mode）を追加します。
• システムはすべての記録履歴を保持し、削除された項目は画面から非表示にする必要があります。
• ユーザーはラインレベルと組織レベルの両方で不良目標を設定できます。
• テストデータの不足は、作業範囲の中でリスク要因として明記されました。

このシステムはどのデータからP-Chartを計算しますか

システムは、シフトごとに作業者が入力した不良数と、工場の既存システムからAPI経由で取得した生産数からP-Chartを計算します。これら二つの値をもとに、要件定義書の計算式に従って日次不良率、平均線、上方管理限界線（UCL）を計算し、グラフで表示します。

グラフ、集計画面、PDFレポートは同じデータベースから読み込みます。そのためデータは、従来のように何段階も転記するのではなく、現場で一度だけ記録します。画面はNext.jsとAnt Design（Webアプリ開発ツール）で開発しているため、作業者はWebブラウザから利用します。

1. 1

   マスターデータの設定

   マスターデータ（Master Data）の設定画面で、ユーザーはシステムが定めた不良種類の下にラインとワークごとの不良項目を登録し、ラインレベルと組織レベルの不良目標も登録します。

2. 2

   日次の不良記録

   作業者は日付、シフト、ライン、ワークを選択し、不良数を表に入力します。システムはすべての記録履歴を保持し、検索、修正、削除ができます。削除した項目は画面から非表示になります。

3. 3

   P-Chartの自動計算

   システムは不良数を既存システムの生産数と比較し、日次不良率、平均線、上方管理限界線（UCL）を計算してグラフで表示します。

4. 4

   異常と対策の記録

   不良が基準を超えた場合、担当者はその日とワークに紐づくAbnormal Occurrence & Action Record（異常と対策の記録）の表に、問題、原因、対策を記録します。

5. 5

   集計とレポート出力

   集計画面には日次、月次、年次の不良とパレート図（不良項目を多い順に並べたグラフ）を表示し、P-ChartをPDFで、表をCSVファイル（Excelで開ける表形式のファイル）で出力できます。

納入物

当社は工場のサーバー上でP-Chart Control Webアプリ1システムを納品しました。画面はマスターデータからレポート出力まで、上記の手順をすべて備えています。Webアプリのほかに、納品物は次のとおりです。

• 工場のUbuntu Server上のDockerインストールパッケージとPostgreSQLデータベース
• ログインと生産数取得のための、組織の既存システムのAPI接続
• 開発文書
• 検収書
• 操作マニュアル

実施手順と変更要求

当社は2024年9月からP-Chart Control Webアプリを開発し、2025年4月に納品して、2025年半ばまで改善を続けました。開発中、お客様から変更要求（Change Requirement）が複数回提出され、いずれも回ごとに版を更新する変更要求書に記録されました。作業の流れは次のとおりです。

1. 2024年9月: 作業範囲と要件定義書に基づき設計と開発を開始
2. 2024年12月以降: 記録履歴、非表示による削除、組織レベルの目標など、変更要求に応じてシステムを調整
3. 2025年4月: システムが検収項目に合格。お客様は複数人が同じ不良項目を入力した場合の集計について追加の変更要求を提出し、納品・検収書に署名
4. 納品後から2025年半ばまで: マスターデータへの新しい不良項目の追加や、組織レベルの目標の入力方法の調整など、システムの改善を継続

検収により確認できた成果

この事例で確認できた成果は、検収と受領の署名です。P-Chart Control Webアプリは検収項目（Exit Criteria）に合格し、この自動車部品メーカーは2025年4月に納品・検収書に署名しました。検収項目には、開発中の変更要求から生じた記録履歴、非表示による削除、組織レベルの目標が含まれます。

納品後、お客様の依頼により当社はシステムの改善を続け、2025年に案件を完了しました。この事例には、レポート作成時間や不良数の減少といったビジネス効果を示す数値はありません。そのため、文書で確認できる成果のみを報告しています。

私たちが学んだこと

この案件から、日次の品質データ記録システムに関する次の原則が得られました。

• 見た目よりシステムの速度を優先します。チームが案件完了後にまとめた教訓は、見た目よりも先にシステムの処理速度を考慮することです。そのため、毎日記録するよう設計されたシステムの記録画面とグラフ画面は、見た目を調整する前に実データで速度をテストすべきです。
• バックエンドを作る前にデータのルールを取り決めます。記録履歴、削除方法、組織レベルの目標に関する変更要求は開発中に発生し、範囲の変更によりバックエンド（Backend）の修正が必要になると、作業時間が長くなりました。
• P-Chartの正しさは、計算に使う生産数の正しさを超えません。既存システムからAPI経由で生産数を取得することで、作業者は不良のみを入力し、生産数は組織が現在使用しているシステムから得られます。

この手法をお客様の工場に適用する方法

貴社の工場がまだ不良を紙とExcelに記録しており、P-Chartで不良率を追跡しているなら、この事例と同じ進め方を利用できます。不良を現場で一度だけ記録し、既存のシステムから生産数を取得して、グラフ、集計、レポートはシステムに計算させる方法です。調整が必要なのは、貴社工場の生産数の取得元、ログイン方法、レポート様式です。

• 生産数をどのシステムから取得するかを確認し、API接続の権限を早い段階で申請します。
• 不良項目、計算式、テスト用の実データサンプルを準備します。
• 工場のITチームと社内サーバーを事前に確保します。
• 変更要求の扱い方をプロジェクト開始時に取り決めます。