---

November 2015

Volume 30 Number 12

Cutting Edge - UX 主導型設計によるアーキテクチャの改善

Dino Esposito | 年 11 月 2015

どのようなソフトウェア システムでも、その設計とエンジニアリングは、ユーザーの要件を集めるというおなじみの手順から始まります。そのためには、普通、ユーザーやその分野の専門家とのミーティングや面談を何回も行います。最後のミーティングを終えると、システムの詳細がすべて決まり、支障なく開発を始められるとプロジェクトに参加するほぼ全員が考えます。最終製品が、説明を受けて理解したものと別物になるとは誰一人として疑っていません。ユーザーは満足し、アーキテクトも自身が行うべきことを正確に把握したと思っています。

しかし、現実には、抽象的な要件に合意しても、それが正しく実装される保証はないことは経験上わかっています。ユーザーに実際のプロトタイプを見てもらうと、まったく気に入ってもらえないことがよくあります。ミーティングや議論を何度も重ねてきたにもかかわらず、ユーザーと開発者は最終製品についてまったく別の考え方を持っていたように思えます。開発者は受け取った要件を中心にソフトウェアを構築します。にもかかわらず、最終成果物がユーザーが求めるポインを外していることがよくあります。

多くの開発者は機能の完全性を目指す傾向があり、エンド ユーザーがシステムで実現しようとしているビジネス プロセスに十分な関心を向けていないのではないでしょうか。そのため、ビジネス プロセスの機能面は捉えていても、実装全体としては洗練さも滑らかさも期待どおりにならないのではないでしょうか。今回は、アーキテクトが初めから正しいシステムを構築する可能性を高める設計アプローチを提案します。ここでは、このアプローチを UX 主導型設計 (UXDD: UX-Driven Design) と呼ぶことにします。

リンゴが頭の上に落ちてきた

リンゴが頭の上に落ちてきたことから、万有引力の法則を思いついたという真偽が定かではないアイザック ニュートンの逸話を憶えていますか。最近、あるリンゴが私の頭にも落ちてきて、ユーザーの期待と実際のプロセスに細心の注意を払わなければ、構築するシステムは別物になるという法則に思いつきました。つまり、機能を分析するだけでは足りないのです。

ユーザーから、テニス トーナメントの対戦表をサポートする、(ユーザーが言うところの) 簡単で手軽な Web アプリケーションを構築するという依頼がありました。ユーザー ストーリーは 1 つだけです。オペレーターがドローに選手名とランクを指定すると、それがドローの現状に反映された XML フィードがシステムに公開されるというものです。開発者としての習慣で、まず、そのデータを保持するデータベース テーブルの構想を立てました。次に 2 つのテキスト ボックスを備えた簡単な HTML フォームを考えます。1 つのテキスト ボックスには選手名を、もう 1 つにはランクを指定します。興味深いごとに、打ち合わせが終わったとき、ユーザーは選手名とランクを入力すると、それに対応した XML が出力されるツールが完成すると確信していました。しかし、開発者が打ち合わせどおりと考えたものを引き渡し、ユーザーが実際のドローのシミュレーションでテストしたところ、ユーザーの思いどおりには機能しませんでした。ユーザーが実際に求めていたのはもっと複雑なものでした。図 1 を見ると、開発者とユーザーが考えていた全体像の差がわかります。背景画面がユーザーが希望する実際のプロセスを表現したものです。重ねて表示した黒い縁取の黄色い画面が、あまりにも簡易すぎる低コストのソリューションです。

図 1 要望と理解の差

結局のところ、UX とは単なるジェスチャとグラフィックスだけではありません。ユーザーがソフトウェアの操作で体験することすべてです。効果的な UX を設計するには、アーキテクトや開発者として、データ モデルとストレージよりも、タスクとビジネス プロセスに重点をおくべきです。タスクを理解するには、タスクの分野、ユーザー、そしてユーザーがその分野で取り組んでいることを学ぶ必要があります。これに対応するのが UXDD です。ただし、UXDD はワイヤーフレームやモックアップを使用するための単なる一般的アドバイスではありません。シンプルなシナリオにワイヤーフレームやモックアップを使用してもうまくいきません。ユーザー自身が頭の中で、必要なソフトウェアは非常にシンプルで、実際のプロセスを徹底的にエンジニアリングするほどのものではないと考えているためです。アーキテクトの立場としては、タスクの重要性についてユーザーから適切なメッセージを受け取っていないということです。望んでいたのは低コストのソリューションではなく、効率的なソリューションでした。最初に提案した低コストのソリューションは、実際の状況にはまったく役に立たないことは認めざるを得ません。開発者の失敗は、ユーザーの分析を全面的に盲信し、実際のビジネス プロセスを詳しく知ろうとしなかったことです。

UXDD とはアーキテクチャに関する一連の決まりごとを表します。UXDD に従うことで、タスクと UI に関連してビジネス上重要なポイントを外すリスクが最小限に抑えられます。興味深いのは、UXDD によって、現在の開発とソフトウェア エンジニアリングにおける確立された一部の慣習が変わるかもしれないことです。

トップダウン設計

機能の点では、設計作業をボトム (永続化モデルなど) から初めても、トップ (プレセンテーション層とビュー モデルなど) から初めても、動作するシステムを正しく構築できます。UX の点では、プレゼンテーション層とビュー モデルから設計を始め、その後バックエンド スタックも含めた他のすべてを構築する場合に限り、成功を収められます。

アーキテクトや開発者の多くが職業上学んできたことに、ユーザーの要件を基にエンティティとリレーションシップで構成された永続化モデルを構築すれば、非常に多くのことを成し遂げられるというものがあります。このモデルは、スタック全体を通して使用されるシステム全体のモデルになります。UI 固有のわずかなデータ転送オブジェクトと連携するのはほんの時折です。この状況では、システムの設計と構築はボトムアップ方式で行われ、必然的に、永続化を中心に据えたデータ モデルの構想がプレゼンテーション層に反映されることになります。このデータ モデルは、一般にデータの作成 (create)、読み取り (read)、更新 (update)、削除 (delete) の頭文字を取って (CRUD) と呼ばれます。どのようなシステムでも、突き詰めれば、ほんの少しだけ洗練されたビジネス ロジックを備えた CRUD になるのがほとんどです。その過程で、プレゼンテーション層に注意が払われることはほとんどありません。このデータ モデルと非常に密接に連携する UI がユーザーにとって適切な場合もありますが、そうでない場合もあります。適切でなければ、最初の作業プロトタイプを引き渡すと、追加交渉で火花が散ることになります。最初にボトムアップでシステムを考えると、ある時点で、さまざまなユーザー プロセスを反映するために最も外側の層を変更しなければなりません。これは四角い杭を丸い穴に合わせるようなものです。そのため、多くのソフトウェア プロジェクトにとってはこの点が最大の課題になると考えます。

このプロセスを改善するには何ができるでしょう。その答えが、トップダウン設計のアプローチに戻ることだと考えます。プレゼンテーション層から始めて、プレゼンテーションの要件を基に詳細を詰め、実装していきます。これを効率よく行うには、いわゆるスプリント 0 （ウォーターフォール モデルの予備手順) が必要になります。スプリント 0 では、UX を細部まで理解します。システムのバック エンドの構築に移行するのはその後です。

UX 主導型の方法論

要件については、ユーザーに問い掛けながら受動的に推測していくよりも、エビデンスを基にユーザーと議論し能動的に作り上げていく方がよいと UX の専門家から教わりました。要件をユーザーに問い掛けていくと、アーキテクトやアナリストは受け身になりすぎる傾向があり、ソフトウェアをできるだけ早く用意したいユーザーは、あらゆる機能の優先度を下げていきがちです。そして、最終的にシステムを引き渡すと、ほとんど使い物にならないという苦情が寄せられるのです。さらに、「ユーザーがそう望んでいるのだから」という言いわけしながらどんどん受け身になっていくと、構築予定の「対象」への理解が進みません。今日の開発者は、ユーザーの希望をモデル化するのではなく、実社会の要素を正確に映し出すソフトウェアを開発します。ビジネスの構造的な側面を見落とすことは致命的で、大きな間違いを犯すことになります。

想定する UI について、ワイヤーフレームを使用しながら合意を形成していくのが一般的な方法です。ワイヤーフレームをユーザーに繰り返し実行してもらい、フィードバックを求めても、ほんの一部の範囲しか効果がありません。ワイヤーフレームは優れていても、ストーリーボードがなければその価値は限られます。

1 つの画面を効率的に 1 枚のワイヤーフレームにまとめることはできても、その 1 画面ですべてが完了するタスクはほぼありません。画面のワイヤーフレームを見ているだけでは、プロセスを実行して起こるボトルネックを突き止めることはできません。そこで複数の画面を 1 つのストーリーボードに連結する方が、はるかに適切な考え方です。この点について最も大きな課題と考えられるのは、ストーリーボードを構築するツールを見つけることです。このツールの市場は急速に拡大しています。図 2 に、アプリケーションのプレゼンテーション層のプロトタイプを短時間で作成できるツールをいくつか一覧にします。これらのツールを使用することで、設計するプロセスの具体的なアイデアが顧客に伝わるようなプロトタイプを作成できるようになります。

図 2 迅速かつ効率的に UI プロトタイプを作成するツール

ツール	URL
Axure	http://axure.newson.co.jp/
Balsamiq	balsamiq.com (英語)
Indigo Studio	http://jp.infragistics.com/products/indigo-studio
JustInMind	http://www.xlsoft.com/jp/products/justinmind/
UXPin	uxpin.com (英語)

また、最新バージョンの Microsoft Visio と PowerPoint にもプロトタイプ機能があり、特に Visual Studio Ultimate と組み合わせると効果を発揮します。図 2 に一覧しているツールはすべてワイヤーフレームを作成するプラットフォームとしても充実しており、中にはクリックによるモックアップの作成や、ワイヤーフレームを機能別のプロトタイプへの変換に使用できるものもあります。

最先端のこのようなツールを使用することで、早い段階からフィードバックが得られます。さらに重要なのは、こうしたツールによって、設計プロセス前半のコーディング前からユーザーを巻き込めることです。バック エンドの開発が半分終わった時点でプレゼンテーション層に重要なポイントが抜けていることが判明した場合は、投げ出すか、調整するかのいずれかしかありません。

同時に、プレゼンテーション層を UX 専門家のチームに外部委託するだけでは不十分です。今日のプレゼンテーション層はシステムに不可欠な部分になったので、ソリューション アーキテクト、UX アーキテクト、ユーザーが連携して取り組まなければなりません。この連携を最初の手順とし、理想を言えば、プレゼンテーション層についてのユーザーの同意が得られるまで次の段階には進まないことです。方法論の点では、コーディングの前に多くの意見を受け入れてプレゼンテーション全体の設計を仕上げ、次にアジャイル性を強化して、スプリントの手順としてプレゼンテーション層の分析を追加します (図 3 参照)。

図 3 アーキテクチャ UX 主導型設計の 3 つの手順

UX 以外のソリューションの設計

ソリューション全体または現在のスプリントのプレゼンテーション層が確定したら、十分定義したデータ フロー (つまり、各フォームで入出力される明確な内容) を使用して、フォームなどの画面のコレクションを用意します。アーキテクチャとしては、各操作の入力モデルと、フォームへの記入や想定どおりの応答を作成するのに必要なビュー モデルを把握することを意味します。このプレゼンテーション層を、Martin Fowler が定義したサービス層パターン (bit.ly/1JnFk8i、英語) に概念上一致する中間サービス層や、ドメイン駆動設計の階層型アーキテクチャのアプリケーション層を経由してバック エンドに接続します。これはシステムの論理セグメントにあたり、ユース ケースと、ユース ケースに必要なタスクのオーケストレーションをすべてこのセグメントに実装します。アプリケーション層はバック エンドの最上位に位置し、プレゼンテーション層と直接対話します。アプリケーション層は、プレゼンテーション層からトリガーできる操作ごとの直接的なエンドポイントで構成されます。これらのエンドポイントは、ワイヤーフレームから得られる入力とビュー モデルのみを受け渡しします。

このアプローチは本当に効率的なのでしょうか。もちろんです。ワイヤーフレーム分析が徹底しており、正確であれば、ユーザーが望むプロセスのみを実装していることになり、初めからうまくいきます。初回リリースやデモを配置後の変更について再交渉する場面は大幅に減ります。結果として、時間も費用も節約されます。図 4 は、ユーザーがソフトウェアをどのように見ているかを示しています。UXDD を用いることで、このような方法でソフトウェアを設計できるようになります。

図 4 ユーザーから見たソフトウェアの本質

まとめ

データ モデルを出発点にする今日のソフトウェア設計方法に比べて、UXDD はデータ モデルよりもタスクとプレゼンテーションに重点をおきます。データ モデルや永続化が重要ではないといっているわけではありません。それらはタスクのために機能するもので、主役ではないといっています。好むと好まざるにかかわらず、実社会で求められるものはこの方向に近づいています。UXDD は、テクノロジーやパターンではなく、方法論です。UXDD はどのようなテクノロジもパターンも否定しないし、強制もしません。ただし、CQRS および Event Sourcing とは非常にうまく連携します。アプリケーションを構築する実際のプロセスに満足していなければ、水平思考の方法として UXDD アプローチを採用してはどうでしょう。

---

Dino Espositoは、『Microsoft .NET: Architecting Applications for the Enterprise』(Microsoft Press、2014 年) および『Programming ASP.NET MVC 5』(Microsoft Press、2014 年) の共著者です。JetBrains の Microsoft .NET Framework および Android プラットフォームのテクニカル エバンジェリストでもあります。世界各国で開催される業界のイベントで頻繁に講演しており、software2cents.wordpress.com (英語) や Twitter (@despos、英語) でソフトウェアに関するビジョンを紹介しています。

この記事のレビューに協力してくれた技術スタッフの Jon Arne Saeteras に心より感謝いたします。