「システムが使われないのは、現場への説明が足りないからだ」。そう考えて操作説明会を繰り返していませんか？ 実は、根本的な原因は運用の段階ではなく、もっと手前の「要件定義」にあります。
多くのプロジェクトでは、曖昧な経営層の「やりたいこと」だけで仕様が決まります。多角的な視点でフィルタリングをかけるプロセス抜け落ちているため、現実とのギャップが生じ、現場が拒絶反応を起こすのです。
本記事では、このギャップを埋めるための「3つの基準によるフィルタリング技術」について解説します。
2. 問題の正体：リテラシーの壁を越えられない「多機能」
なぜ、高機能なシステムほど使われないのでしょうか。それは、機能が増えるほどUI（操作画面）が複雑になり、現場のITリテラシーの限界を超えてしまうからです。
会議ログにある知見によると、現場のリテラシーと求められる操作レベルに乖離がある場合、どんなに便利な機能でも「これ使えない」「分からない」と判断され、リプレイス（作り直し）に追い込まれます。 「機能があること」と「その人が使えること」は全く別問題です。 「誰が（Who）」使うのかを無視して、「何ができるか（What）」ばかりを詰め込むことが、使われないシステムの最大の原因です。
3. 実践手順：成功率を高める「3つのフィルタリング」
「使われない」を防ぐためには、開発に着手する前に、膨大な「やりたいことリスト（要求）」を厳しく選別（フィルタリング）する必要があります。以下の3つの基準で優先順位を決めてください。
ステップ1：リストを持ち寄り、3つの視点で点数をつける
発注者と開発パートナーが協力し、以下の3項目を掛け合わせて優先度（松竹梅）を決定します。
1. ビジネス価値：それをやることで売上が上がるか、コストが下がるか？（発注者が判断）
2. ユーザーに受け入れられるか：現場のスタッフ or 対象ユーザーがそのUIを使いこなせるか？（ここが最重要）
3. 技術的コスト：実装にどれくらい費用と時間がかかるか？（パートナーが判断）
ステップ2：「ユーザー」視点で機能を削ぎ落とす
特に「ユーザー」の視点が重要です。例えば、PC操作に不慣れなスタッフが多い現場で「詳細な分析機能」を入れても使われません。 「現場のリテラシーでは、この入力操作はハードルが高い」と判断したら、ビジネス的に重要でも、あえて機能を削るか、自動化して裏側に隠すという判断が必要です。 「多機能」ではなく「現場が使える形」に絞り込むことが、成功への鍵です。
ステップ3：プロトタイプで「リテラシーの壁」を検証する
机上の空論で「使えるはず」と判断するのは危険です。 必ず動くプロトタイプ（試作品）を作り、実際に現場のスタッフに触らせてください。 「文字が小さくて読めない」「ボタンの意味が分からない」といった反応があれば、それはリテラシーとの不一致です。この段階なら、仕様を簡略化するなどの修正が低コストで可能です。
4. 具体例：フィルタリングによる成功と失敗
失敗ケース（フィルタリング不足）
「あれもこれも」と要望を詰め込み、高機能な在庫管理システムを開発。しかし、現場は年配のパートスタッフが中心で、スマホの文字入力すら苦手だった。結果、「紙に書いて後で事務員が打つ」という二度手間が発生し、現場は疲弊した。
成功ケース（適切なフィルタリング）
ユーザーに受け入れられるかという視点でのフィルタリングを徹底。「文字入力は無理」と判断し、機能を「バーコードをスキャンするだけ」の1点に絞り込んだ。 詳細なデータ修正機能は現場アプリから削除し、管理画面（PC）のみに実装。 結果：現場スタッフは「これなら簡単」と初日から使いこなし、リアルタイムな在庫管理が実現した。
5. まとめ
• 教育で解決しようとしない：使われないのは説明不足ではなく、現場のリテラシーに合っていないから。
• 3つの基準で選別：ビジネス的価値、技術的コストに加え、ユーザーが使いこなせるかの視点で機能をフィルタリングする。
• 動くもので検証：プロトタイプを現場に触らせ、リテラシーのギャップがないか開発前に確認する。
• 捨てる勇気：現場が使えない機能は、どんなに高尚な目的があっても「ゴミ」になる。勇気を持って削ぎ落とす。
システムは「作って終わり」ではなく、現場に使われて初めて価値が生まれます。まずは「やりたいことリスト」を、現場の目線でフィルタリングすることから始めましょう。