システムが使われないのは設計が悪い

2004年2月12日

IT Proの記事「使われないシステムは"ただの箱"」ですが、な〜んかポイントを外しているように思えます。

これまで（各種業務での経験を含めて）見聞きした業務系システムのドキュメントを前提とする限りでは、ドキュメントを含めた教育体制に問題があるというのは、おそらくその通りでしょう。コンスーマー製品のマニュアルを見慣れた目から見ると、品質的に許容レベルに達しているとは到底思えないものがほとんどです。これは仕上がりの出来不出来の問題ではなく（もちろんデザイン処理にもかなり問題がありますが）、文章品質や情報構成の手法などの根本的な問題です。

もう少し具体的に説明すると、この種のドキュメントの文章はエンジニアによる仕様書レベルであることが多く、品質的には書き直しが必要なレベルと言えます。それよりも問題なのは、情報が機能単位で構成されていて、実際の業務単位で構成されていないことです（タスク志向で情報が構成されていない）。一般的な業務には（1つの機能では完結せずに）複数の機能を横断してはじめて完結するものも多いと思います。で、このような場合に情報が個々の機能単位で構成されていると、ドキュメントを読んだだけでは操作の流れの全体像を把握できないのです。

さて、この記事ではドキュメントや教育体制に問題を転嫁するばかりで、システムの設計に問題はなかったのか？という根源的な問題から目をそらしていることが気になります。ドキュメントの重要性を主張してくれるのは嬉しいんですけど（笑）

当該システム現物を見た訳ではないので断定は避けますが、「使われない」システムは実際の業務フローを無視した設計がなされている可能性が非常に高いのではないかと思われます。おそらく、それぞれの機能にすぐにアクセスできるかどうか（ボタンだらけのトップメニューが代表例）は考えても、業務フロー全体を通した使いやすさやわかりやすさを実現することで、業務効率向上を支援するという視点が完全に抜けているのではないでしょうか。そもそも「利用者が本当に知りたい内容を事前に調べ，そのことを重点的に教える」内容は、システム設計段階で対応すべきレベルの話でしょう。

設計主体が企業内部／外部であるに関わらず、UI設計とドキュメント制作に関しては、設計の早期段階から（コンサルじゃなくて）実務専門家を参加させるべきです。従業員にプロトタイプを触ってもらう簡易テストだけでは、使いやすさを確保するにも限界があります。ユーザビリティ検証なしのWebサイト構築があり得ないように、社内業務システムでも専門家によるチェックは必須のはずです。初期導入コストの上昇分は将来的な運用コスト削減を考えれば楽勝でペイできるでしょうし、何よりもシステムを使ってもらえないという莫大な無駄金が発生するよりは、はるかにマシだと思うんですが...。