ユーザー・インターフェースの混在
ユーザー・インターフェースが変更されるというのはどんな時でしょうか？
- エンド・ユーザーからより生産性の高い（使い勝手のよい）ツールが欲しいという要望が上がる
- システムのライフ・サイクルを見計らって、次期更改時にその要求（またはその一部）を検討に組み込む
- 検討時の技術トレンドや予算に応じてその時最適と思われる手法で実装する
- 4～5年はそれを保守しながら維持していく
といった流れが一般的ではないでしょうか。
企業の中には様々なシステムがあり、そのそれぞれ構築した時期も異なれば運用・管理・開発している部門・担当者も異なることが多々あります。そうしたシステムはライフ･サイクルを共有しておらず、必然的に頻繁に刷新されるもの、長い間変わっておらずこれからも投資の対象となる可能性の低いものとが混在する結果となります。
別の理由により異種のユーザー・インターフェースが混在することもあります。求められる操作性や連携先の違いが主な要因です。例えば、Webベースのシステムでは伝票入力に要求される非常に高速なキーボード操作への対応は得意ではありません。文書やプレゼンテーションの作成をWebベースで行うという人も少ないでしょう。これはWebブラウザの表現能力やネットワーク/サーバーへの依存性からくる応答速度の悪さが原因です。パソコンのファイルシステムや接続されたカードリーダーといったデバイスとの連携も苦手な分野と言えるでしょう。こうしたニーズ、実は少なくはなく、社内システムの基本路線はWebベースでも、特定業務は例外的に専用クライアントを使用する（購入する、開発する）という決断が往々にして下されます。
ユーザー・インターフェース混在そのものが問題ではない
それでは、混在そのものが問題なのでしょうか？ それぞれの使い分けがきちんとされていればよいのではないか？ と思われる方もいるかもしれません。しかし、ここには大きな改善の余地が潜んでいるのです。
第1回でも定義している通り、ユーザー・インターフェースとは人とシステムとの間に立つものです。パソコンで利用しているユーザー・インターフェース、つまりデスクトップ・アプリケーションが異なるシステムは 一般的に互いに独立しています。逆に、独立しているから別の形で実現されている とも言えます（図1）。
例えば、Webベースのシステムで顧客情報を検索した後に顧客IDをコピー＆ペーストしてクラサバ・アプリケーションに入力、注文を確定して発注をかける、という操作を行っているとします。これは本来連続しているべき業務の流れをコピー＆ペーストという手作業によってシステムではなくエンド・ユーザーが繋いでいることを意味します。1つの業務をこなすために同じ顧客ID・商品IDを何度も入力しないと完了しない、そんな経験のある方は多いのではないでしょうか？
こうした作業は非効率なだけでなく、人的ミスも発生しやすく、品質の低下そして顧客満足度の低下にもつながる可能性があります。つまり、ユーザー・インターフェースが統一されていないことではなく、「複数のシステムを使うためのデスクトップ・アプリケーションがそれぞれ独立して機能しているために業務効率・品質が向上しない」ということが課題なのです。この課題が見えると、あるWebシステムからの出力をもとに次のWebシステムを使うといった同じユーザー・インターフェース技術を採用しているシステム間でさえも同じ課題を抱えており、実は根が深いことがわかりますお分かりいただけると思います。
