「多機能で高品質なシステムが使われないのは、現場への説明が足りないからだ」。そう考えて操作説明会を繰り返していませんか？ 原因は運用の段階ではなく、もっと手前の「要件定義」にあります。
多くのプロジェクトでは経営層の曖昧な「やりたいこと」だけで仕様が決まり、複数の視点で機能をふるいにかける工程が抜け落ちたまま開発に入るので、出来上がったものと現場の現実とのあいだにギャップが生まれ、そこで拒絶反応が起きます。多機能型システムに潜む罠と、それを避ける3ステップのフィルタリング術をまとめます。
ITリテラシーの壁を越えられない「多機能」
なぜ、高機能なシステムほど使われないのか。機能が増えるほどUI（操作画面）が複雑になり、現場のITリテラシーの限界を超えてしまうからです。
業務環境と求められる操作レベルに乖離があると、どんなに便利な機能でも「これは業務中に使えない」「手順が多すぎる」と判断され、作り直しに追い込まれます。「機能があること」と「業務の中で使えること」は全く別問題です。「誰が・どんな状況で（Who / When）」使うのかを無視して、「何ができるか（What）」ばかりを詰め込むことが、使われないシステムの最大の原因になります。
作るものを一緒に整理する 要望メモ、既存資料、口頭のアイデアだけでも構いません。何を最初に作るべきか、開発会社へどう伝えるかを整理します。成功率を高める「3ステップのフィルタリング」
「使われない」を防ぐには、開発に着手する前に、膨大な「やりたいことリスト（要求）」を厳しく選別（フィルタリング）する必要があります。以下の3ステップで優先順位を決めてください。
ステップ1：リストを持ち寄り、3つの視点で点数をつける
発注者と開発パートナーが協力し、次の3項目を掛け合わせて優先度を決めます。
- ビジネス価値：それをやることで売上が上がるか、コストが下がるか（発注者が判断）
- ユーザーに受け入れられるか：現場のスタッフや対象ユーザーがそのUIを使いこなせるか（発注者・開発側が判断）
- 技術的コスト：実装にどれくらい費用と時間がかかるか（開発側が判断）
FMは、書籍『システムを作らせる技術』（白川克 著）で紹介されている、要求を「作る」「後回し」「作らない」に白黒つけて合意形成する手法です。発注者と開発パートナーで一緒にマトリクスを埋めていきます。「作らない機能」もリストに残すのがポイントです。
| 機能 | ビジネス価値 | 現場で使えるか | 技術コスト | 判定 |
|---|---|---|---|---|
| バーコードで在庫を減らす | ★★★ | ★★★ | 低 | 作る |
| 月次の在庫分析レポート | ★★ | ★★★ | 低 | 作る |
| 在庫の自動発注アラート | ★★★ | ★★ | 高 | 後回し |
| 入荷予定の手動入力 | ★★ | ★ | 中 | 作らない |
| バーコード無し商品の写真認識 | ★ | ★ | 高 | 作らない |
FMの効果：「作らない機能」を明示的に残すことで、「なぜ作らないのか」の合意形成が視覚的にできます。後から「やっぱり欲しい」と言われた時も、なぜ最初に外したかが一目で分かり、スコープクリープを防げます。
出典：白川克『システムを作らせる技術 エンジニアではないあなたへ』（日経BP, 2021）
ステップ2：「ユーザー」視点で機能を削ぎ落とす
起点は現場です。機能の取捨選択は、開発側の都合ではなく「現場で使う人の立場」から逆算してください。たとえば営業SFAで、商談ごとに10項目の入力を求めたらどうなるでしょうか。移動中のスマホでは入力しきれず、「空欄で保存」が常態化します。
線を引く基準は「なくても業務が回るか」に置いてください。経営層にとって価値のある分析項目であっても、現場が入力しなければデータはゼロ。ゼロのデータから生まれる分析も、ゼロです。
多機能なSaaSより、現場が無理なく使い続けられるSaaS。この絞り込みが、定着するか棚上げされるかを分けます。
ステップ3：プロトタイプで「リテラシーの壁」を検証する
机上で「使えるはず」と判断するのは危険です。必ず動くプロトタイプ（試作品）を作り、実際に現場のスタッフに触らせてください。「文字が小さくて読めない」「ボタンの意味が分からない」といった反応が出たら、それは現場社員のITリテラシーとの不一致が起きているサインです。この段階なら、仕様の簡略化で低コストに直せます。
具体例：フィルタリングによる成功と失敗
失敗ケース（フィルタリング不足）
「あれもこれも」と要望を詰め込み、入力項目が10個以上ある高機能な営業SFAを導入しました。ところが営業担当には商談から商談へ移動するスキマ時間しか入力する余裕がなく、「とりあえず空欄で保存」「数日後に記憶を頼りにまとめて入力」が常態化します。データは信用されません。営業会議は結局「あの案件、いまどうなってる?」のヒアリングに逆戻りし、SFAは「報告のための二度手間ツール」になって現場が疲弊しました。
成功ケース（適切なフィルタリング）
ユーザーに受け入れられるかという視点でのフィルタリングを徹底しました。営業担当が現場で入力する項目は「次回アクション」「受注確度」の2つだけ。それ以外の情報（顧客名、商談日時、参加者など）はGoogleカレンダー連携やメールの自動取り込みで裏側から補完し、詳細な分析・編集機能は管理画面（PC）のみに実装しました。結果、営業担当は「2タップで完了するなら入力できる」と初日から使いこなし、以前より詳細なデータが自然と蓄積されるようになりました。
まとめ
押さえるのは4点です。
- 教育で解決しようとしない：使われない理由は説明不足でなく、現場のリテラシーに合っていないこと。
- リストを持ち寄り、3つの視点で選別：ビジネス価値と技術的コストに加え、ユーザーが使いこなせるかで機能をふるいにかける。
- 動くもので検証：プロトタイプを現場に触らせ、リテラシーのギャップがないか開発前に確認する。
- 捨てる：現場が使えない機能は、どれだけ大きな経営目的があっても使われない。削ぎ落とす。
システムは作った時点では価値を生みません。現場に使われて初めて成立します。まずは「やりたいことリスト」を、現場の目線でふるいにかけるところから始めてください。
よくある質問（FAQ）
Q1. 使われないシステムが生まれる最大の原因は何ですか？
A. 原因は2つです。現場のヒアリング不足と、ステークホルダー間の利害衝突を放置すること。現場が日々どんな作業をしているか、なぜ既存ツールでは不足なのかを確かめないまま経営層や情シスの想定だけで作ると、現場は新システムを使わずに従来手順へ戻ってしまいます。
Q2. ローンチ後に使われていないことに気づいたらどうすべきですか？
A. まず利用率（DAU/MAU、機能別利用率）を計測し、どの機能が・どの部署で・なぜ使われていないかを切り分けます。そのうえで、機能の問題なら改修、運用の問題なら業務プロセス変更や研修、噛み合っていないなら段階的な廃止を検討します。「使われていない事実」をオープンにすることが第一歩です。
Q3. PoC（概念実証）と本番システムでは何が違いますか？
A. 求められる品質の水準が違います。PoCは「アイデアが技術的に成立するか」「ユーザーが本当に使うか」の検証が目的なので、品質・セキュリティ・運用性は最低限で構いませんが、本番システムはこれに加えて安定運用・セキュリティ・性能・可用性がすべて必須要件になります。PoCのコードをそのまま本番化しようとして破綻するのは典型的な失敗です。
Q4. 要件を絞り込むと、ステークホルダーから「機能不足」と言われませんか？
A. スコープ管理（FM法）のように、3軸の客観評価で絞り込んだ根拠を示すと納得を得やすくなります。「ビジネス価値は高いが、現場で使う体制がないので今回は外す」と説明できれば、ステークホルダーも代替案（運用整備、研修）を検討するようになります。