ROI事件ファイル No.575『不具合は見えたが、使う人の体験を測っていなかった』
不具合は見えたが、使う人の体験を測っていなかった
第一章：連携が悪い、だがどこを直せばいいのか
「基幹システムの連携で、相談できる企業を探しているんです」
TechWave社の経理システム担当、快田満氏は、切羽詰まった様子で状況を語った。「勘定奉行とOBIC7の連携に課題があって。月次処理に一週間もかかる。二重チェックが発生して、リアルタイムの情報共有もできない。業務効率が、著しく落ちています」
「その連携を、どう直そうとしていますか」とClaudeが尋ねた。
「不具合を、片端から潰そうとしています」と快田氏が答えた。「どこでデータが噛み合わないか、エラーはどこか。技術的な不具合を追いかけて。でも、直しても直しても、使う現場の負担が減った実感がない」
「使う人が、どこで、どれだけ困っているか、測りましたか」と私が確認した。
「……測っていません」と快田氏が答えた。「不具合ばかり見ていました。使う人の満足、どの業務が負担か、どの機能が使われているか。体験を測ったことがない」
「不具合は見えても、使う人の体験を測らなければ、効く手は打てませんね」と私が応じた。「HEARTで分解しましょう」
第二章：HEARTが問う、使う人の体験を五つで測る
「この案件には、HEARTが必要です」
Claudeがホワイトボードに「満足・関与・適応・定着・タスク成功」と書いた。
「HEART——満足度・エンゲージメント・適応・定着・タスク成功率の五指標とは、使う人の体験を数字で測り、どこを直すかを見極めるフレームワークです」と私が説明した。「肝は、不具合だけを見ないこと。技術的なエラーを潰しても、使う人の負担がどこにあるかは分からない。満足、関与、適応、定着、タスクの成功率。五つで体験を測るから、効く一手が見える。体験を測ってから直す道具です」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。快田氏から提供されたデータを入力する。
「月間のコストが出ました」とGeminiが読み上げた。「月次処理一週間の連携・二重チェック工数が月平均百九十時間、時給三千七百円で月七十万三千円。リアルタイム共有の不能による情報の遅れが月平均四十万円。連携エラーの手戻りが月平均三十六万円。使う人の体験を測らない改善の空振りリスクが月平均三十四万円。属人化による処理の停滞が月平均三十二万円。合計で月二百十二万三千円。年間換算で約二千五百四十八万円」
快田氏が数字を見つめた。「連携の不具合だけ見ていました。体験を測らず改善が空振りするコストまで足すと、これほどとは」
「では、HEARTで設計します」と私が続けた。
[満足・関与——どこが負担かを測る]
「最初に、満足と関与です」とClaudeが言った。「社員の満足度を調べ、システムへの不満点を洗い出す。各部署のエンゲージメントを測り、どの業務プロセスが特に負担かを特定する。不具合でなく、体験の重さを測ります」
[適応・定着——使われている機能を測る]
「次に、適応と定着です」とGeminiが続けた。「現行システムの利用状況を分析し、どの機能が使われ、どれが使われていないかを評価する。変更への抵抗感を調べ、スムーズな移行が可能かを見る。実際の使われ方を測ります」
[タスク成功率——どこで詰まるかを測る]
「適応の次に、タスク成功率です」と私が続けた。「各タスクの成功率を測り、特に問題が起きている箇所を特定する。月次処理のどこで詰まるか、が数字で見える。体験の詰まりを、正確に測ります」
[判断——改修とリプレイスを費用対効果で選ぶ]
「最後に、判断です」とClaudeが続けた。「五指標で測った体験を基に、改修案とリプレイス案を比べる。今回はデータが示した。費用対効果では、改修での対応が最も効く。測ったから、迷わず選べます」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：体験調査・連携改修設計・リアルタイム連携・処理自動化・定着支援費用合計五百三十万円
- 月次費用：システム運用・保守継続費合算月二十三万円
- 月次削減効果：月次処理の効率化＝月五十二万円（七割削減想定）、リアルタイム共有による情報遅れ解消＝月三十六万円、連携エラーの手戻り削減＝月二十八万円、属人化の解消＝月二十八万円、合計月百四十四万円
- 月次純削減：百四十四万円－二十三万円＝月百二十一万円
- 投資回収期間：五百三十万円÷百二十一万円＝約四・四ヶ月
「四ヶ月強の回収です」とGeminiが整理した。「効くのは、不具合だけを潰さず、使う人の体験を測ってから直す点です。エラーを追っても、負担の在り処は分からない。五指標で測るから、改修かリプレイスかも費用対効果で選べる。投資が空振りしません」
快田氏が数字を確認しながら言った。「不具合を潰せば済むと思っていました。体験を測らないと、どこを直せば効くか分からない」
「HEARTは、使う人の体験を測ってから直す道具です」と私が応じた。
第三章：体験を測ってから直す導入計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一ヶ月——五指標での体験調査、満足度と負担プロセスの特定。第二ヶ月——利用状況の分析とタスク成功率の測定。第三ヶ月——改修案とリプレイス案の費用対効果比較と判断。第四・五ヶ月——連携改修とリアルタイム連携・処理自動化の実装。第六ヶ月——試験運用と効果検証。第七ヶ月以降——定着支援、体験指標の継続測定」
「不具合を先に潰した方が、早くないですか」と快田氏が確認した。
「そこが落とし穴です」とClaudeが応じた。「不具合を追っても、使う人の負担がどこにあるかは見えず、直しても実感が出ない。HEARTで体験を先に測れば、効く箇所が分かり、改修かリプレイスかも根拠を持って選べる。測ることが、無駄な改修を避ける近道です」
快田氏がメモを取りながら言った。「不具合を潰す前に、使う人の体験を測る。順序が見えました」
第四章：体験を測って、効く手が見えた日
十ヶ月後、快田氏から報告が届いた。
月次処理は、改修後、大きく縮んだ。「一週間かかっていた月次が、大幅に短くなった。二重チェックの手間が消えた」と快田氏は記していた。
情報共有も変わった。リアルタイム連携が、情報の遅れを解いた。「勘定奉行とOBIC7が噛み合って、リアルタイムで情報が共有できるようになった」と報告書にあった。
最も大きな変化は、改善の起点に表れた。不具合を潰す状態から、体験を測ってから直す状態に変わった。「エラーを片端から追っていた。使う人の体験を五つで測ったら、どこを直せば効くかが見えて、改修で済むと判断できた」と快田氏は記していた。
判断の根拠も明確だった。費用対効果の比較が、改修という選択を裏づけた。「リプレイスありき、で慌てずに済んだ。測った数字が、改修で十分だと示してくれた」と報告書にあった。
副次効果として、システムの見方が変わった。不具合でなく体験で測る発想が根づいた。「エラーを潰す、で終わらせるのをやめた。使う人が、どこで、どれだけ困っているか、で考えるようになった」と快田氏は記していた。
快田氏の報告書の最後にはこう書かれていた。「連携の悩みは、技術的な不具合だと思っていた。だが本当の問題は、不具合は見えても、使う人の体験を測っていなかったことだ。HEARTで五指標を測った瞬間に、効く手が見えた。不具合を潰す前に、体験を測ることが先だった」
不具合は見えたが使う人の体験を測っていなかった会社が、体験を測ってから直せる会社に変わった日、システム連携は不具合潰しから、使う人の体験を五つの指標で測ってから直す設計に変わっていた、と記されていた。
「システム連携の相談は、たいてい『不具合を直したい』という形で来る。だが不具合を潰す前に問うべきことがある。使う人の体験を、測っているか。HEARTが問うのは、満足・関与・適応・定着・タスク成功の五つだ。体験を測れば、効く箇所も、改修かリプレイスかも見える。不具合は見えても体験を測っていなかった会社が、五つで測れた日、変わったのは技術の精度ではなく、使う人の体験を測ってから直す視点そのものだった」
関連ファイル
使用ツール
- ROI Polygraph — 月次処理工数・情報遅れ・改善空振りリスクの可視化
- ROI Proposal Generator — 使う人の体験測定を起点にした基幹システム連携の投資回収シミュレーション
