業務システムはなぜ使いづらくなるのか

業務システムが使いづらくなる要因は何か。それは業務プロセスの変化だと考えています。日々、業務プロセスを見直し、健全に改善を重ねる組織が扱う業務システムほど、業務システムの使い勝手は低下していきます。
業務プロセスの改善には「人」と「システム」の２つがあると考えています。「人」は、業務プロセスの改善内容に合わせて柔軟に行動を変えていくことができますが、「システム」は基本的には組まれているプログラムの通りにしか動くことができません。
これによって、人とシステムの間に業務プロセスの変化に対する変化量に差が出てきます。そして、この差が大きくなると業務システムは「使いづらい」と言われるようになります。

そして、この使いづらさは業務プロセスとの乖離の量と比例するので、新しくこの業務にアサインされた従業員の業務に対する習熟コストが増えていきます。
長く運用されている業務システムをレガシーシステムと呼んだりしますが、レガシーシステムの定義のひとつとして、「業務プロセスと業務システムの間に乖離が大きくなり、業務効率が低下している状態」があります。
そして、残念ながら、健全に業務プロセスの改善を続ける組織は、この乖離から逃れることはできません。
考えるべきは、改善されていく、変化していく業務プロセスに対して柔軟に変化していける業務システムの構築、そして最も重要なのは、業務システムの改善に対して常時リソースを確保しておくことです。
業務システムは一度作ったら終わり。現場から強い要望があったときに隙間時間に追加対応する。というのが、よくあるパターンだと思いますが、環境(社会、事業、目標、手法)が変化するという前提に立って、継続的に改善する体制を組織として整える必要があります。
業務システムは、顧客に価値を提供するために存在しています。
その価値の源泉となる業務システムに継続的に投資をしないと、業務は属人的になり、組織のナレッジマネジメントは停滞します。業務習熟度の高い従業員のノウハウを汎化してシステムに組み込む、失敗パターンをデータとして蓄積して今後の改善に活かす。
業務システムは、業務の効率化と継続的な業務改善のために存在するのです。

信頼性の高いデザインシステムを採用する

業務システムを改善しやすくするためのポイントはいくつかあります。
ひとつは「信頼性の高いデザインシステムを採用すること」です。
GoogleのMaterial Designなどがこれに該当します。デザインシステムを採用するときに大切なのは、フロントエンドのフレームワークが整っていることです。
自社でフロントエンドまで含めた独自のデザインシステムを構築するのはとてもコストがかかります。きちんとやろうとすると、デザインシステムを運用するための専用チームが必要になるほどです。
Material Designは様々なプラットフォームに対応した汎用性の高いデザインシステムで、Googleが設計思想、コンポーネントの使い方まで運用しているのに加えて、Material Designに対応したフロントエンドのフレームワークが様々な言語で提供されています。特別な事情が無い限りは、Material Designのような既存のデザインシステムを採用すると構築、運用コストを大きく削減することができます。

消せるUIを設計する

業務プロセスの変化に対して、業務システムが変化することができれば業務プロセスと業務システムの乖離幅を小さく抑えることができます。そのためには、柔軟性の高いUI設計が重要です。ここで言う、柔軟性の高いUI設計とは「消せるUI」です。
業務プロセスが変化したときに、不要になった情報や機能が残ったままだと、業務プロセスとの乖離幅が大きくなります。この乖離幅を小さくするために不要になった情報を消せるUIを作っておけると良いでしょう。消せるUIを作るポイントは、いくつかあります。

・オブジェクトベースなUIを構築する
・ダッシュボードにしか存在しない情報、機能を無くす
・ 汎用型UIと特化型UIの両方を作る

オブジェクトベースなUIを構築する

タスクベースなUIを構築すると、機能を消そうとしたときにその先にある情報もすべて削除対象になります。そのタスクベースな流れの中にあった情報が消すべきではない情報だった場合、不要になった機能自体が消せなくなってしまいます。
オブジェクトベースなUIで構築されていれば、削除したい機能ボタンを消したり、奥に引っ込めたりすることで対応が可能になるので、改善コストも小さく抑えることができます。

ダッシュボードにしか存在しない情報、機能を無くす

前述の「オブジェクトベースなUIを構築する」と似ていますが、ダッシュボードでしか閲覧できない情報や機能があると、ダッシュボードからその情報を削除することができなくなってしまい、ダッシュボードが機能しなくなってしまいます。ダッシュボードは業務プロセスのKPIを俯瞰する場所です。そこに不要な情報が紛れていると重要な情報が何かわからなくなってしまいます。
ダッシュボードに表示されている情報は、ダッシュボード以外のページで閲覧可能な情報を抽象化して俯瞰できるページとして設計しておくとよいでしょう。
ダッシュボードは、そこでタスクを簡潔させる便利な場所ではありません。

汎用型UIと特化型UIの両方を作る

業務プロセスを利用するユースケースは数多く存在します。
よくあるパターンとして、ひとつのユースケースをひとつのUIで満たそうとすることが多くあります。しかし、ユースケースとUIを1対1の関係で考えると、そのUIは消しづらくなります。消せるUIを実現するためには、ひとつのユースケースに対して、UIを複数要しておくことが重要です。UIを複数用意しておくことで、UIの一部を消したり、書き換えたりすることができます。そのための方法として考えられるのが、汎用型UIと特化型UIです。
ある特定オブジェクトのマスタページと言えるようなUIをひとつ用意し、そのオブジェクトに対するあらゆるユースケースを想定したUIにします。ここでは特定のユースケースに対しての利便性はそこまで重要ではありません。特定オブジェクトに対して、すべてのデータにアクセスでき、すべての機能が実行できることが重要です。
このような汎用型UIをひとつ作っておくことで、特化型UIを業務プロセスに合わせた形で提供することができます。
特定のユースケースに特化すると業務プロセスが変わったときに負債化しそうですが、汎用型UIを作っておくことで、不要になった特化型UIを消すことができるようになります。
そして、新しい業務プロセスに最適なUIをまた作り直すことができるようになります。

さいごに

業務システムは、社内で使うからコストをかけなくてよい、使えればいい。という声を聞くことが多いです。
しかし、顧客に提供する価値というのは組織から生まれるものです。その価値の源泉とも言える業務システムにもっと投資されることを願っています。