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