システム都合のプロセスの介在 — ユーザーはAとZだけでいい

現場のおっさんは「探して、出す」がしたいだけ

業務システムを導入するたびに、同じ光景を何度も見てきました。

PCの前でおっさんが固まっている。隣の若手を呼び出す。「これどうなってるんだ？」。若手も一緒に画面を見つめる。二人とも動けない。結局、もう一人詳しい人を探す。その人の仕事も止まる。感染が広がっていく。

原因はいつも同じです。おっさんがやりたいことはシンプルなのに、そこに辿り着くまでのプロセスが多すぎる。

社員を探したいだけなのに、検索画面の操作手順を覚えさせられる
図面を見たいだけなのに、ビューアーの設定をいじらされる
データを探したいだけなのに、フィルターの概念を理解させられる
連絡先を知りたいだけなのに、何階層ものフォルダを彷徨わされる

ユーザーの欲求は常に A → Z です。「これが欲しい」から「はい、どうぞ」まで、一直線であるべきです。

なのに、現実のシステムは A → B → C → D → … → Y → Z になっている。BからYまでは全部、システムの内部事情をユーザーに押し付けているだけです。

これを「システム都合のプロセスの介在」と呼んでいます。

どこにでもある、同じ構造の地獄

業界もシステムも関係ありません。この構造はどこにでも現れます。

ある大企業では、社員検索システムが神でした。名前を入れるか、組織ツリーから辿るか。入口が二つあるだけで、誰でも一撃で目的の人に辿り着けた。

ところがシステム刷新で別のプラットフォームに寄せた途端、同じことをするのに5分かかるようになりました。5分 × 全社員 × 毎日。恐ろしい損失ですが、プロジェクトの報告書には「新プラットフォームへの統合完了」と書かれています。成功扱いです。

CADの世界でも同じでした。現場の人間は図面が見たいだけです。紙でもPDFでも何でもいい。なのに「ビューアーを起動して、ファイル形式を確認して、プラグインを更新して、レイヤー設定を変えて……」。おっさんの心の声は一つ。「紙でくれ」。

業務システムで「検索フォーム」がなく、代わりに「ビューを作成してフィルターを設定してください」と言われるケースも典型です。リレーショナルデータベースの構造を理解していないと使えないフィルターUIを、業務ユーザーに渡している。データモデルの知識をUIに漏らすなという設計の基本が、守られていません。この構造がDataverseでどう現れるかは、Dataverseの検索が微妙すぎる件で詳しく書きました。

全部、同じ構造です。ユーザーがやりたいことと結果の間に、システムが知っていてほしい手続きが大量に挟まっている。

なぜこうなるのか

システムを作る側と、使う側の関心が違うからです。

作る側は機能を作ります。検索機能、フィルター機能、ビュー機能、エクスポート機能。機能が多いほど「高機能」と評価される。提案書に並べる弾が増えます。

ですが使う側は機能が欲しいのではありません。結果が欲しいのです。「この人の連絡先」「この条件のデータ一覧」「この図面の印刷物」。結果までの道のりに何個の機能が介在するかは、少なければ少ないほどいい。理想はゼロです。

さらに厄介なのは、この問題が数字に出にくいことです。おっさんが画面の前で5分迷っていることは、KPIのどこにも反映されません。若手が呼び出されて仕事が中断したことも記録されない。プロジェクトのKPIが「導入完了」である限り、導入後に現場で何が起きているかはフィードバックされません。

提案する側も、導入する側も、現場に残りません。だから現場で起きている地獄を見ない。見ないから、次のプロジェクトでも同じ構造を繰り返します。

現場を止めない、という設計原則

では、どうすればいいのか。

答えはシンプルです。ユーザーに見せていいのはAとZだけ。間のプロセスは全部、システム側が吸収する。

ユーザーが条件を入れてボタンを押す → 裏でどんな複雑なクエリが走っていようが、結果だけ返す
ユーザーが「印刷」を押す → 裏でどんなデータ変換が起きていようが、紙かExcelが出る
ユーザーが名前を入力する → 裏で何テーブルJOINしていようが、連絡先が表示される

BからYまでのプロセスを消すのではありません。エンジニアの側に引き取るのです。

これは「ダサいUIでいい」という話ではありません。ユーザーの認知負荷を最小化する、という設計原則の話です。結果的にUIがシンプルになるだけで、裏側は必要なだけ複雑であっていい。むしろ裏側が複雑さを引き受けるからこそ、表側をシンプルにできます。

そしてもう一つ。「現場を止めない」をKPIにすることです。

システム導入のKPIは通常、稼働日・コスト削減率・ペーパーレス化率などが並びます。ですが現場にとって唯一の関心事は「自分の仕事が止まるかどうか」です。教育期間で生産性が落ちるのも、操作がわからず問い合わせが殺到するのも、全部「現場が止まっている」状態です。

逆に、システムが変わったことにユーザーが気づかないなら、それは最高のUXです。裏側が近代化されていても、表側が今まで通りなら、現場は1秒も止まらない。導入初日から通常稼働。教育コストゼロ。定着率100%。

「Fit to Standard」の裏側で

「Fit to Standard」という言葉があります。パッケージの標準機能に業務を合わせましょう、という考え方です。

理念としては正しい。カスタマイズを最小限に抑え、アップデートへの追従を容易にし、導入コストを下げる。教科書的には完璧です。

ですが、その「Standard」がユーザーの業務に合っていなかったらどうなるか。

20年間「条件を入れてボタンを押す」で検索してきた現場に、「ビューをフィルターしてください」と言う。10年間紙で図面を確認してきた現場に、「ビューアーのレイヤー設定を覚えてください」と言う。

これは「業務を標準に合わせる」のではありません。「ユーザーにシステムの都合を学習させる」です。そしてその学習コストを払うのは、提案したコンサルタントでもベンダーでもなく、現場のおっさんです。

本当にフィットすべきは、Standardではなく現場の現実ではないでしょうか。

現場の人間は新しいことを覚えるのが仕事ではありません。本業を回すのが仕事です。システムはその本業を止めないことが最優先であり、そのためにシステム側が現場に合わせるのが筋です。

ユーザーが本当に欲しいもの

長年、様々な現場を見てきて確信していることがあります。

ユーザーが最終的に欲しいものは、驚くほどシンプルです。探して、出す。それだけです。条件を入れて検索して、結果を紙かExcelで受け取る。この体験が損なわれなければ、裏側がどんなモダンなアーキテクチャになっていても構いません。

システム刷新の成功とは、ユーザーの体験を壊さずに、裏側だけを近代化することです。アーキテクチャはモダンに、UXはユーザーが慣れ親しんだものに。この組み合わせが、最もコストが低く、最も定着率が高く、最も現場を止めないアプローチだと、現場を見てきた人間として断言します。

だっせぇUIでいい。合理的に業務が進めばそれでいい。

大事なのは、AとZの間にある「システム都合のプロセス」を、ユーザーの目から消すことです。消せないなら、せめて最小にすること。それがシステムを作る側の、現場に対する誠意だと思っています。

「刷新したのに現場の手数が増えた」「検索と出力のたびに画面を行き来している」といった状況の見直しもよくやっています。どこに「システム都合のプロセス」が挟まっているかの棚卸しから始めたい方は、無料の診断でお手伝いできますので、お気軽にどうぞ。