今ではWebサービスやアプリ開発に携わる人なら誰もが知る単語になりつつある、UI/UXという言葉。

主にBtoCサービスの開発で重要視されることが多かったが、最近ではエンタープライズ領域でもUI/UXを重視する動きが活発化してきた。

大手SIerなどでUI/UX向上に向けた専門部署を設ける企業が増えており、これらの動きは、業務システムのタブレット対応のような前例のない取り組みや、既存システムのテコ入れなどで、ユーザー体験を重視していくという業界全体の“兆し”といえる。

そんな中、実は2000年代前半から各種コンピュータ製品やエンタープライズシステムのUI/UXを研究する専門チームを要していた企業がある。IT業界の大手、日本IBMである。

同社では2008年から「UCD（ユーザーセンタードデザイン）」を冠する専門部署も設立しており、今回はこの部署で活躍する渡辺啓子さんに、エンタープライズシステムのユーザビリティを向上させる際に意識すべきポイントを聞いた。

エンタープライズシステムのゆえの難しさは「時間」と「規模」

「エンタープライズシステムのUCDには独自の難しさがあります」

渡辺さんいわく、エンタープライズシステムのUCD設計が難しいのは、Web系システムの開発と比較して大きく2つの違いがあるからだという。

1つ目は、開発期間の長さである。

「例えばスマホアプリ開発などのシステム開発は1～2カ月で終わることが多いと思いますが、エンタープライズシステムの開発は短くても半年程度、長ければ数年単位になります。開発にかける時間が長くなればなるほど、ビジネス環境の変化などにより、開発当初のプランどおりにUI/UXを構築しにくくなるのです」

2つ目は、プロジェクトで必要となる人員の規模である。

「Web系開発なら多くの場合、少人数で構想からリリースまで一貫して同じ人が開発にかかわることができます。スマホアプリなら個人で作ることもあるでしょう。しかし、エンタープライズシステムは開発体制が大規模になりやすく、フェーズによってかかわる人が入れ替わることも多々あります。UCDチームは上流フェーズで離脱することもあるため、将来的に参加する人員の数が増えれば、プロジェクトによってはUCDの意図をわたしから直接話せなくなる可能性もあります」

そんな状況下で、渡辺さんはどのようにしてエンタープライズシステムのUCD設計を行っているのだろうか。

プロジェクトの各フェーズで求められる4つのポイント

まず、一般的なWebサービスのUX設計のフローを説明すると、（1）想定ユーザーのゴールとニーズを設定し、（2）ペルソナを作成しながらそのユーザーがゴールに至るまでの導線を設計する。次に、（3）プロトタイピングを用いてユーザーインタビューを重ね、そこで得た情報から（4）実装・リリースに進んでいくケースが多い。

このフローと何が異なるのかを、渡辺さんの言葉を借りながら、エンタープライズシステム開発のフローを大きく次の4つに分けて見てみよう。

【1】構想・計画：開発プロセスにUCDプロセスを溶け込ませる

エンタープライズシステムの開発で新しい取り組みを行うには、計画段階が肝心だ。

「提案段階を含めて初期に作成するプロジェクト計画では、適切な開発メソッドの選定と、それに合った作業プロセスとアウトプットを明確にすることが大事です。規定のウォーターフォール型の開発メソッドや、お客さまの開発標準もあります」

また、プロジェクトマネジャーや各チームリーダーと、作業やアウトプットに重複や不整合がないか調整を行うことも大切なことなのだという。

「基本的に、後工程につながらないアウトプットは意味がありません。お客さまや開発チームはUCDの取り組みに慣れていないこともありますので、プロジェクトマネジャーの視点で、役割や価値を説明するようにしています」

【2】要件定義：必要最低限の情報を持ったペルソナ作成

一般的なWebサービスのUI/UX設計と同様、渡辺さんがこのフェーズで行うのはペルソナ設計とプロトタイピングだ。

しかし、そのペルソナの設定をどこまで細かくするかという点において、エンタープライズシステムならではの工夫があるという。

「Webサービスとエンタープライズシステムの違いは、ユーザーの要求にあります。複雑な要求を持つWebサービスのユーザーの場合は、いろんな属性を持たせた方がサービスの改善点や追加すべき機能が見えてきます。が、エンタープライズシステムにおいてのユーザーの要求は、業務を完了させること。業務に関係ないであろう情報、例えば、兄弟が何人いるかなどの情報は、持たせるべきではありません」

エンタープライズシステムに求められるものは何なのか、プロトタイピングの目的を「業務をスムーズに完了させるUI（ユーザー・インターフェース）コンセプトの確認」と明確に定めることで、ペルソナに不要な情報を省くことができる。

【3】設計：各作業にクローズアップしたUCDチームのアウトプット

設計フェーズで渡辺さんが注力するのは、ガイドラインとサンプル画面の設計である。

前述のように大規模な人月になりがちなエンタープライズシステム開発では、渡辺さんが後続フェーズの作業者と接しない可能性があるため、直接対話をしなくてもデザイン意図が伝わるようなガイドラインを作成する必要がある。

「途中から開発に加わった人にプロジェクトのコンセプトを見せたところで、自分が作っている機能がその中でどのように働くのか、イメージがつきにくく、情報量が多いとかえって混乱させてしまう可能性があります。また、それを伝えるための時間というコストも生じます。そのため、ここで作るUIデザインガイドラインは、プロジェクトの全体像や思想ではなく、プロセスとアウトプットに合うような具体的な表現のものを作ります。場合によってはガイドラインよりも、正しいサンプル画面を示した方が品質を確保することができます」

プロジェクト全体の大まかな流れと、その中で作業者の置かれている状況や要求されている作業を考慮して、UCDチームからアウトプットを提供する。すると、作業者が責任感を持ち、さらに何をやれば良いものが作れるのか、1つ上のポジションの視点で開発してくれるようになるのだと渡辺さんは言う。

【4】実装・テスト：仕様変更に対応できるようにガイドラインを伝える

開発期間が長期にわたることから、実装・テストのフェーズになると仕様変更せざるを得ない状況は往々にしてある。法が変わり対応が必要になった場合や、ビジネス環境の変化、クライアントの要求があった場合などだ。

このような場合に渡辺さんはどのように対応するのだろうか。

「仕様変更が必要かどうかはプロジェクト全体で変更管理を行って判断するものですが、UIについてはある判断軸で考えています。ユーザーのゴール達成のために必要かどうかです。開発期間が圧縮されているプロジェクトの途中変更は、進ちょく、コスト、品質への影響が大きく、本来すべきではありません」

どうしても対応せざるを得ない場合はどうするのだろうか。

「そのような場合は、負担の軽い代替案、変更した場合のリスクと対応策など、開発チームと連携して仕様調整を行います。3年前に取得した『HCD（人間中心設計専門家）認定資格』でも改めて認識しましたが、知識だけではなく、課題に対して最善策を提案する能力が必要です」

渡辺さんはプロジェクト管理表もこのロジックで作成するのだという。「ユーザーのゴールを達成するシステムを開発する」という目的から考えて、プロジェクト全体で作業やアウトプットが補完されていれば、チームのプロジェクト管理表に不要な作業を入れない。

「プロジェクトの目的と判断軸さえ明確にされていれば、プロジェクトの後半で仕様変更の可能性があったとしても、その変更が本当に必要なのかどうかが判断できます」

また、ガイドラインを作業者に伝える際の工夫でも、対処できるのだという。

「ガイドラインの目的と対象を定義し、前提や理由、レギュレーションを記述します。『最低限これをやれば、これができる』というように、やるべきことを明確に決めて伝えます。状況の変化に耐え得るレギュレーションさえ決めておけば、仕様変更が起きた場合でも柔軟な対応ができます」

ちなみに、IBMがUCD専門の部署を立ち上げ、ユーザインターフェース設計に注力しているのは、他社との差別化のためもあったという。ユーザー企業の要求レベルが日に日に高まっているからだ。

そんな状況下だからこそ、SEでもプログラマーでも職種を問わず、より専門的な知識でUI/UXをとらえ、システムの価値を高めていく必要があるのかもしれない。

取材／伊藤健吾　文・撮影／佐藤健太　（ともに編集部）