使いやすいシステムのためのアーキテクチャ：こんな時にはこのITアーキテクチャ （5）

使いにくいシステムをわざわざ作ろうとする開発者はいないはずだが、世の中には使いにくいシステムが散見される。システムの使いやすさの本質は、ユーザーがやろうとすることを適切に行えることにあるので、まず、ユーザーが業務上やるべきことを正しく見極めることが重要だ。

[河野紀昭，日本IBM ICP-エクゼクティブI/Tアーキテクト]

　使いやすいシステムとはどんなシステムだろうか。すぐに思い浮かぶのは、ユーザー・フレンドリーで分かりやすい画面があって、誰でも簡単に操作できることだ。

　だが、一見使いやすそうな画面があっても、業務に必要な機能が不足していては役に立たない。また、逆に極めて多機能で業務の必要以上の機能を備えているが、使いたい機能にすぐにたどり着けないといったことでも困るだろう。真の使いやすいシステムとは次のことを満たすシステムといえる。

1. 業務で必要な機能が過不足なく実現されている
2. 想定される利用者に対して、適切なユーザー・インターフェイスが用意されている
3. 上記を満たすためのシステム的な仕組みが用意されている

　業務で必要な機能を過不足なく実現といっても、これを実現することはなかなか難しい。実際のシステム開発では、機能が足りないことを恐れて「あると便利かもしれない機能」を作ってしまいがちである。ここはITアーキテクトの原点に立ち返って考えたい。

　ITアーキテクチャはビジネス要求を満たすためにある。ビジネス要求と関係ない機能はいかに気の利いた機能でも不要と考え、作らないことにすればすっきりする。とはいっても、実際の開発ではシステムの要件定義の段階でビジネス上の必要性と関係ない機能が紛れ込んでしまうことが起きがちだ。

　そこで、システムの要件定義をすることに先立って、ビジネス上の要求定義を分離して行う手法が有効だ。最初のステップで、ビジネスのルール、手順、ビジネス上の改善点を規定し、ビジネス上の要求からシステム要求を導き出すようにする（図1）。

図1 ビジネス上の要求定義を分離する

　最初のステップを省いて、システム要件をいきなり定義すると、ビジネス上の必要性が吟味されないまま、いわば思い付きでシステム化が行われてしまう可能性がある。こうなると、システム化された機能と本当に業務遂行に必要な機能にギャップが生じてしまい、いくら良いユーザー・インターフェイスがあっても「使いやすさ」は達成されない。業務手順を含め、業務をどのように良くするのかあらかじめ吟味して必要な機能を把握し、これをシステム要件に反映させることが、使いやすさ実現への第一歩となる。

勘所：まずビジネス遂行に必要な機能を考えよう

　ビジネス上の要求が明確になり、必要な機能が明らかになったら、システムをユーザーが最も業務を遂行しやすいように設計すればよい。ここで大切なのはユーザーを適切に想定することである。

　金融のシステムを例に取ると、Webでオンライン・バンキングの場合、一般ユーザーは事前にトレーニングを受けているわけでなく、画面は初めての人でも分かりやすく使える必要がある。こういう場合には、GUIを多用し確認画面を多くするなど、多少操作時間がかかるデザインになっても仕方がないだろう。

　一方で、コールセンターでお客さまの電話を受けるオペレーターは、訓練を受けているから、「初めてのユーザーでも分かりやすい画面」は必要でない。電話を受けながら画面を操作して、最短の時間で必要な入力や検索を行えることが重要だ。このような場合には、マウスの操作なしで、キーボードで操作を高速に行えた方が便利だ。

　このように、対象ユーザーによって使いやすさの尺度は異なってくるので、まず対象ユーザーを具体的かつ適切に想定して、そのユーザーにとって使いやすいことをユーザーの立場に立って考えることが大切である。

勘所：ユーザーを具体的に想定して、そのユーザーが使いやすいシステムを考えよう

　ユーザーの身になって、便利な画面を実現しようとすると、画面のレイアウトやコーディングを工夫することになる。工夫することは大切なのであるが、大規模システム開発で多数の開発者が参加している場合では、開発者が個別に工夫すると、それぞれの画面ごとには工夫してあるが、全体として統一が取れず使いにくくなってしまう恐れがある。

　ユーザーを想定して、使いやすさを実現する方針を決めたら、これを画面標準として規定し、全開発者が同じルック・アンド・フィールの画面を作成できるようにするとよい。画面標準として盛り込むべき内容は例えば次のようなものが挙げられる。

• メニューの配置や展開方法
• ボタンのラベル／配置
• 画面遷移の仕方
• 入力エラー時の動作（エラー項目を赤字にして表示など）

　画面標準を吟味するためには、代表的な業務画面のモックアップを作るとよい。モックアップでは本当のビジネス・ロジックを実装する必要はなく、HTMLで画面イメージを作り、ボタンを押すと次の画面にリンクで進むといった仕掛けを作ってユーザーに操作してもらって、ルック・アンド・フィールが適切かどうか検証する。

勘所：ユーザー操作の統一性を考えて標準化を行おう

　標準ができたら、標準に従ったアプリケーションを作りやすいように、アプリケーション・フレームワークや画面表示部品のライブラリを整備するとよい。標準化されたスタイルシートやタグ・ライブラリを使い、フレームワークの作法に従ってアプリケーションを作ると、洗練された使い心地のアプリケーションが出来上がるように、事前に開発環境を整備できれば最高だ（図2）。

勘所：使いやすいシステムを作りやすい環境を整えよう

図2 アプリケーション・フレームワークや画面表示部品のライブラリの整備

「こんな時にはこのITアーキテクチャ」バックナンバー

• 変化に強いシステムのためのアーキテクチャ
• 使いやすいシステムのためのアーキテクチャ
• 24時間止められないシステムのためのアーキテクチャ
• 高可用性システムのためのアーキテクチャ
• 大量トランザクション処理に適したアーキテクチャ
• 良好なレスポンスを実現するアーキテクチャ