Evomo × Prochiz · 2022年 · B2B SaaS
ProchizがExcelを手放せなかった、2つのギャップを閉じる。
損失の可視化と問題追跡を、Evomoの既存画面の中に設計する。
役割
UI/UXデザイナー
期間
2スプリント · 2022年3〜6月
クライアント
チーズ製造 · B2B SaaS
フォーカス機能
損失計算 & 問題追跡
概要
Evomoは、工場の機械をセンサーで見守るIoTプラットフォーム。クライアントのProchizは、チーズ製品を専門とするインドネシアの大手食品メーカーで、どの機械がいつ止まったかはEvomoがすべて記録していた。
ところが、Prochizの月次報告書を読むと、Evomoが埋められない列が2つあった。損失の数値は毎月手計算。問題の対応記録は毎週Excelで手作り。監視プラットフォームにお金を払いながら、ProchizはまだExcelで回っていた。
このケーススタディは、そのギャップを閉じた2つの機能の話。新しいページは1枚も増やしていない。
00 / いまのEvomo
機械にセンサー、管理者にダッシュボード。
Prochiz — チーズ製品を専門とするインドネシアの大手食品メーカー。複数の生産ラインが毎日稼働しており、機械が1時間止まるだけで数千個単位の製品損失につながる。
OEE（Overall Equipment Effectiveness） — 工場の設備がどれだけ効率よく動いているかを0〜100%で表す通信簿のようなもの。100%は「止まらず・不良品もなく・フルスピード」の状態。このページでは以後、シンプルに「稼働スコア」と呼ぶ。
Evomoの仕組み — 3ステップ
センサーが自動で記録
各機械のセンサーが、止まった時刻と動き出した時刻を自動で記録する。誰も手入力しない。
ダッシュボードが損失を表示
機械が止まった原因が、損失の大きい順にリアルタイムで並ぶ。
管理者が優先順位を決める
Plant Managerはこのデータで「どの問題から直すか」を決め、毎週取締役会に報告する。今回の設計ギャップが見つかったのはこのステップ。
機械を見守ること
停止・再稼働はセンサーが自動記録。ダッシュボードは常に最新。
停止原因のランキング
どの原因で何分止まったかが、影響の大きい順に並ぶ。
その停止で何個失われたか
どこにも表示されない。毎月手計算していた。
誰が直すか・直ったか
割り当ても記録も存在しない。Excelで管理していた。
評価まとめ
Evomoは「機械を見守ること」は本当によくできている。足りないのは意思決定のレイヤー — その停止で何個失われ、誰が動くのか。
01 / ペインポイント
それでも毎月、2つの数字は手作業で作られていた。
最初に「何が欲しいですか」とは聞かなかった。人は「こう仕事しているつもり」を語るが、書類には「実際にしている仕事」が残っているからだ。だからProchizにまず頼んだのは書類 — 月次報告書・ダウンタイムログ・生産スプレッドシート。浮かび上がったギャップは5つ。そしてPlant ManagerとEngineerに話を聞くと、何度も出てくるのは同じ2つ — 損失への影響が最も大きい2つだった。それがこのプロジェクトになった。
Prochizの週次ダウンタイム報告書 — Line 2の実物から再現
.xlsx日次のOEE・損失ブロック — Speed × Output（個）、損失（分）、OEE%
✎ すべてExcelの数式。毎週、人の手でメンテナンスされている。
| 停止原因 | 分 | 回数 | % | B問題の詳細（Finding Problem） | B是正処置（Corrective Action / CAPA） |
|---|---|---|---|---|---|
| Mesin PFM mati/stop | 190 | 6 | 2.2% | ✎ シフト1でPFMのチェーンが破断。交換後も包装の外れ・破れが頻発 | ✎ EGDチームが稼働中にホーム軸を手動設定 — WO:00500 |
| Trouble heater upper/lower crimper | 80 | 3 | 0.9% | ✎ 上部クリンパーのアラーム。設定温度に達しない — サーモカップルの不良を示唆 | ✎ サーモカップル交換（WO:00498）、翌日に温度コントローラーも交換 |
| Force majeure (gempa) | 30 | 1 | 0.3% | ✎ 16時00分に地震が発生 | ✎ 従業員を避難 |
この報告書はProchizに以前から存在し、毎週BODとマネージャーの会議で議論されている。停止原因・分数・回数はEvomoがすでに自動で提供し、Prochizが分析している。橋が無かったのは色付きの部分：損失の計算（A）と、ダウンタイムにどう対処し再発を防いだかの記録 — CAPA（B）。
損失が計算されない
「月次報告書には停止ごとの生産損失の記載が必須。Evomoは計算してくれないので、毎月誰かがExcelで手計算している。」
Plant Managerへのインタビューで裏付け
→ Feature 03 — Expected Losses で解決
担当者・追跡・記録がない
「ダウンタイムが起きても、是正・予防処置（CAPA）を記録する仕組みがない。誰が直し、何をしたのかが残らず、週次レポートは毎週手作りしている。」
Engineerへのインタビューで裏付け
→ Feature 04 — Problem Tracker で解決
他にも見つかったが、今回は見送り
稼働スコアの目標値を設定できない
— 実在する課題だが、損失への影響は小さい
レポートのExcel書き出しが手作業
— 問題Bが解決すれば大部分が不要になる
歩留まりデータの手入力
— 別のワークフローで、影響も小さい
02 / デザイン
2つの問題に、1つの判断：すでにある記録に仕事をさせる。
並べてみると、2つのギャップは1つの問題だった。Evomoの中で「停止」はただの受け身なログで、何個分の損失かを語らず、誰のものでもない。だから別々のツールを2つ作るのではなく、この1つの記録に2つの仕事を与えることにした — 工場が体験する順番どおりに：まず損失を見せ、次に誰かを動かす。
問題 A
損失が計算されない
停止が「何分」でしか語られず、何個分の損失か誰も分からない。
問題 B
担当者・記録がない
誰が直すのか、直ったのかが残らず、レポートは毎週手作り。
1つの解決策
停止記録そのものを再設計し、すべてを持たせる。
予測損失（個数）を自動計算して表示
担当者を割り当て、対応内容を記録
月次・週次レポートはその記録から自動で組み上がる
問題 A — 損失が計算されない
期待損失（Expected Losses）
すべての停止に「何個分の損失か」の予測値を付ける — 管理者がすでに毎日見ている一覧の中に。
解決するギャップ — 毎月の手計算
月次報告書には停止ごとの生産損失の記載が必須。Evomoは計算してくれないので、毎月誰かがExcelで手計算していた。この列で予測は完全に自動になり、SuperadminとManagerは「何個失われるか」を常に意識できる。
ちょっと計算：このラインは通常1分あたり8〜9個を生産する。機械が40分止まったら、作られない製品は何個？
タップして答え合わせ
追加された損失列。管理者が毎朝すでに見ている画面にそのまま表示されるため、新しい操作を覚える必要がない。
1列だけ。新しいページは作らない
必要な数値 — 停止時間・通常の生産スピード — はすべてシステム内にすでにあった。新しいレポートページを作れば毎回1クリック増える。既存の一覧に列を足せば、答えは「そこにある」。
数値は金額ではなく「個数」で表示する — Prochizの報告書がもともと個数ベースで書かれているからだ。既存の報告フォーマットに合わせた、小さいが意図的な判断。
03が「何個分の損失か」に答え、04が「誰が直すか・直ったか」に答える。同じ停止記録、同じ画面、1つの流れ。
問題 B — 担当者・記録がない
問題トラッカー（Problem Tracker）
すべての停止を「誰かが持つタスク」に変える。担当者が決まり、対応が記録され、週次レポートはその記録から自動で組み上がる。
解決するギャップ — 毎週のExcelレポート
毎週、誰かがBOD会議用のレポートをExcelで手作りしていた。この機能は新しい仕事を増やさない — 是正・予防処置（CAPA）を記録した瞬間、その記録がそのままレポートになる。
問題発生からレポートまで — 2つの機能が1つの流れに
01
問題発生
機械が停止、ダウンタイムは自動で記録
02
損失を数値化（Feature 03）
予測損失（個数）が自動算出
03
担当者に即通知（Feature 04）
タスク起票 → 担当者へ通知
04
週次レポート
解決済みの問題がライン別に自動集計
画面ではなく、流れを設計した
Evomoには「機械が止まった」と「誰かが直して、記録が残った」をつなぐものがなかった。だからUIを描く前に、責任の連鎖 — 誰が報告し、誰が割り当て、誰が直し、何が残るか — を先に設計し、それから各ステップに画面を与えた。
1つの停止を、最初から最後まで
流れを実感するために、ある朝の1件を追ってみる。9時14分、ライン101の機械B-2が止まった。
Operasional — 報告する
機械B-2が停止。センサーはすでに記録済みで、現場スタッフがやることは理由の入力だけ。
1停止はダッシュボードに自動で現れる
%20-%20dashboard-DHkPxRFE.png)
2理由を選んで送信するだけ
%20-%20input%20reason-b0OAXNjX.png)
開始・終了時刻はセンサーから自動入力。例外的な状況のみ手入力も可能。
Superadmin (supervisor)
Superadminが停止に気づく — この時点で損失はすでに約150個。Issueとして登録し、担当者を割り当てる。
1各停止の損失を確認
2Issueとして登録
3担当者を決め、指示を書く
Operasional — 直す
通知を受けた担当者が機械を直し、対応内容を記録してClose。週次レポートに必要な情報は、この時点ですべて揃っている。
1通知を受け取る
%20-%20notifikasi-CDtv2TAo.png)
2タスクを開き、In Progressに
%20-%20issue%20list-BqEp_DsC.png)
3対応を記録してClose
%20-%20edit%20issue-BpFZyTUm.png)
プロトタイプ
このフローが機能する理由：すべてのステップが、ユーザーがすでに目にしているもの（タイムライン上の停止・通知・一覧の項目）から始まる。新しい手順を覚えなくても、トラッカーは常に最新に保たれる。
設計上の判断
問題の登録はダウンタイム原因の一覧画面から
予測損失が見える状態のまま登録できる。別ページへ飛ぶと文脈が途切れる。
Superadmin: まずOpenにしてから担当者を割り当てる
確認してから委任。Open = 承認済み・未割り当て の状態が現場の実態に合う。
Operasionalの起点は通知
現場スタッフはダッシュボードを常時見ていない。通知が唯一の合図。
ステータスは3つだけ
インタビューで全員がこの3状態だけを使っていた。「承認待ち」は存在しない。
セッション個人化フィールド
同じラインでも担当者によって文脈が違う。週次レポートで「誰のシフト中か」まで追跡できる。
クローズ済みの問題はTrends（傾向分析）にも反映
問題はクローズで終わらない。翌週の原因分析への入力になる。
細部だが意図的な点：問題の登録はFeature 03の損失列と同じ画面から始まる。「何個失われたか」が見えたまま「誰が直すか」を決められる — 2つの機能が1つの判断の流れになる。
03 / 変わったこと
Prochizで何が変わったか。
おさらい：毎月、誰かが損失を手で数え、毎週、誰かがExcelでレポートを作り直していた。同じ仕事が、こう変わった。
| ジョブ | 設計前 | 設計後 |
|---|---|---|
| 損失の算出 | 手動計算 | ダウンタイム一覧画面で自動算出 |
| 問題追跡・週次ライン報告 | 手書き台帳・Excelで週次手作業 | ダウンタイム→問題トラッカー → 担当者へ通知 → 週次集計レポート自動生成 |
Plant Manager — 週次 BoD プレゼンテーションへの活用
Plant Managerは毎週、取締役会に各ラインの稼働状況を報告する必要があった。損失計算と問題追跡を組み合わせることで、このプレゼンに必要なデータが一元化される。
損失計算
各ダウンタイムによる予測損失（個数）が一覧画面でそのまま確認できる。「今週はこのラインで合計XX個分の損失が発生した」と数値で示せる。
問題トラッカー
Problem Trackerの週次集計ビューで、「何の問題が・誰が対処し・どんな是正処置を取ったか」がライン別に揃う。BoDへの説明に必要な情報をExcelなしで提示できる。
04 / 成功の定義
もう一度出荷するなら、これを測る。
まず正直に：PRDには成功指標があったのに、ローンチ後に計測されることはなかった。このプロジェクトで一番の反省点だ。次に同じものを出すなら初日から計測する — が、その前に、あなたならどれを測る？
もしあなたがこれを出荷するなら、最初に何を測る？
優先する指標を2〜3個選んでください。
おわりに
このプロジェクトで一番学んだのは、「クライアントの意見より先に、クライアントの書類から始める」ということ。工場のことを何も知らない状態から始めたが、答えは最初からProchizのスプレッドシートの中にあった。ここまで読んでいただき、ありがとうございました。