Cutting Edge - UX にギャンブルは禁物 — ワイヤーフレームの使用

Dino Esposito | January 2016

Dino Esposito 不滅の科学者アルバートアインシュタインの言葉を恐れずに言い換えると、「ソフトウェアアーキテクチャにどのような未来が待ち受けているかはわからないが、変化があるとするならば、階層の設計には間違いなくトップダウン手法を取り入れることになるだろう」となります。UX 主導型設計 (UXDD) とは、ソフトウェアアーキテクチャの出発点に、主としてワイヤーフレームやストーリーボードを取り入れるアプローチです。UXDD でこのアプローチによって反応を引き出した結果は、無味乾燥で単調な要件のリストではなく、ユーザーが望む作業方法を明確に映し出す、活気あふれる生き生きとしたスケッチの集まりになります。当然ながら、ユーザーが望む作業方法は、実際のビジネスプロセスをシンプルなソフトウェア表現にしたものといえます。個人的見解ですが、ここ数十年はテクノロジがソフトウェアアーキテクチャの中心的な役割を担ってきましたが、今やその座を失いつつあります。現在は、特定のテクノロジ、レガシプラットフォーム、スキル、予算に対するこれまでの投資を考慮しながら、利用可能なテクノロジと製品を組み合わせて特定の目標を実現できる設計者の能力が重要視されるようになっています。

別に目新しくもないと思われたでしょうか。おそらく、その通りでしょう。ソフトウェアについてのこうした考え方は真新しいものではありません。しかし、これまで決して主流になることはなかった考え方です。

ワイヤーフレームの定義

ここでは「ワイヤーフレーム」という言葉を使っていますが、同じ意味で「スケッチ」が使われることもあります。今回は、UXDD の観点から「ワイヤーフレーム」と「モックアップ」の違いを明確にします。まず、UXDD で使われる言葉をいくつか以下に示します。

「スケッチ」とは、主に、思い付いたアイデアを手早く書き留めた手書きのメモです。スケッチを書き留めるのに理想的なのは、カフェテリアにあるペーパーナプキンなどの紙です。スケッチがアーキテクチャの大まかな骨組みを表すこともありますが、たいていは、ユーザーとシステムの間でどのように対話するかというアイデアを示すものです。
「ワイヤーフレーム」はスケッチよりももう少し厳密で正確なもので、レイアウト、ナビゲーションロジック、コンテンツ編成の詳細などの情報を追加したものです。ただし、色、グラフィック、影、フォントなどの UI の詳細は含みません。
ワイヤーフレームを拡張し、グラフィカルなスキンを組み込むと「モックアップ」になります。

モックアップとワイヤーフレームには、心理学的に重要な違いがあります。ユーザーにアプリケーションのモックアップを見せると、背景の画像、色、スタイルなどのグラフィカルな側面にユーザーの意識が集中します。情報の編成、同じ情報のナビゲート方法やレイアウトに注目することはほとんどありません。ワイヤーフレームはモックアップの一種ですが、グラフィカルなコンテンツを一切含まない簡潔なものです。ワイヤーフレームは手描きすることも、PowerPoint、Visio、Balsamiq などの汎用の描画ツールを使って描くこともできます。ただし、最近は専門的なツールも登場し、複数のワイヤーフレームをリンクしてストーリーボードを形成し、最終的なエクスペリエンスの具体的な考え方をユーザーに提示できるようになっているものもあります。

ワイヤーフレームのコスト効率が高い理由

バックエンドを計画する前でも、ワイヤーフレームを使ってプレゼンテーション層の考え方を形にできれば大きなメリットがあることには、多くの開発者が賛同します。長年の間、この業界の人々は、ソフトウェアの設計と建造物の設計はほぼ同じだと考えてきました。その後、アジャイルという概念が登場し、コードを作成する前に、設計を完成しておかなければならないという考え方に闘いを挑みました。アジャイルでは、実際に設計や分析を行わないわけではありません (実は正反対です)。しかし、アジャイルではソフトウェア開発の根本的な問題に対処できない可能性があります。ソフトウェアの最終目標とは何でしょう。ソフトウェアを作成する目的は、データを格納して処理することだけでしょうか。そうではありません。ソフトウェアを作成する主な目的は、ユーザーが業務上の仕事を効率よく迅速に遂行できるようにすることです。効率よく迅速に仕事を進めることを考えた場合、つながりが広がっている現代では、プレゼンテーション層が最も重要になってきます。このような場合、繰り返しの作業や共同作業を行う際にユーザーが受け入れられるワイヤーフレームやストーリーボードを定義することがアジリティにつながります。決して、優れた永続化モデルを作成できるようにたくさんの情報を定義することがアジリティにつながるわけではありません。

しかし、ワイヤーフレームに割く時間を、製品の完成や直接的な収益にはつながらない無駄なコストだと考えるソフトウェアマネージャーも少なくありません。そのため、実際のソフトウェアアーティファクトに専念するチームを持つことを避けがちです。長年ソフトウェアエンジニアリングと土木エンジニアリングには似たところがあると考えられていることから、次のように考えてみてはどうでしょう。車庫 (もっと高度な建物でもかまいません) を建てるときには、どのような車庫にしたいか説明するでしょう。レンガ職人にレンガを積み上げることだけを指示し、出来上がったものが望みどおりではないとか、頼んだものではないとは言わないでしょう。

ワイヤーフレームの作成と検証は、管理や追加コストが必要な別のタスクです。ただし、表示画面を書き留めたワイヤーフレームファイルを微調整するのと、数千行のコードから成る多層システムを微調整するのでは、まったく手間が違います。ワイヤーフレームと UXDD を採用すると、当然、1 行のコードを作成するまでの時間が長くなりますが、最初のスプリントを提示した後は多くの時間が節約されます。システムが完成半ばまでくれば、多くの時間が節約された効果やメリットをより実感し、評価することができます。UXDD により、プロジェクトを短時間で提供するという夢にさらに一歩近づくことができます。後のスプリントや作り直しに費やす時間の節約は、事前にワイヤーフレームを作成するためにかかる時間を補って余りあります。

ワイヤーフレームの作成方法

UXDD とワイヤーフレームの根底には、ビジネス領域をモデル化するようにソフトウェアを作成すべきではないという考え方があります。どちらかと言えば、ビジネス領域を正確に映し出すようにソフトウェアを作成すべきだという考えです。このように見方を変えると、システムを考案する際に使用するパターンに関連副産物が生まれます。具体的には、強力なタスク指向の焦点を事前に分析できるようにし、モデル化の関連性を不鮮明にします。大半のマネージャーにとっては、このような側面はここ数十年だれも行わなかった奇妙なことのように思え、恐怖を感じます。顧客と面談して導き出すのは、昔から、あらゆるものを包含したデータモデルを作成するための情報でした。このような情報があれば、システムの状態を読み取り、更新できます。しかし、ビジネス領域やアプリケーションの複雑性が増すにつれて、こうしたアプローチの効率と管理の容易さはどんどん低下しています。

昔ながらの個人インタビューやグループインタビューはまだまだ有効です。ただし、システムで処理する関連イベントの把握や、そのイベントを引き起こすタスクや環境の把握を目的にすれば、もっと効果が上がります。イベントストーミングは新しい手法で、ワイヤーフレームを取り込み、プレゼンテーション層を迅速かつ効果的にレイアウトするために行います。専門家や熟練の技術者が執筆した、イベントストーミングを実践するための簡単な入門書については、bit.ly/1N25MJl (英語) をご覧ください。簡単に言えば、イベントストーミングとは、迅速かつストレートに要点を突く手法で、複雑なビジネス領域を探る手段です。この手法は強力なタスク指向の趣があり、実装する領域 (特にタスク) を学習できるようにします。さらに、ユーザーが本当に実行すべきことや、ソフトウェアを利用して正確に映し出す必要がある操作、トリガー、イベントの実際のフローを聞き取ることができるようになります。

ワイヤーフレームの検証方法

これは重要なポイントです。ワイヤーフレームの作成について顧客から明確な承認や承諾を得られなければ、すべての作業が無駄になり、理想的な UX の最終形は保証されません。UXDD では、ワイヤーフレームの承認を得てから、コードの作成に着手しなければなりません。

ですが、ワイヤーフレームを顧客に見せるのは、最初の手順にすぎません。ワイヤーフレームの効果的な検証には、通常、多くの作業が必要です。タスクを実行する意味や、特定のタスクを完了するための手順と画面のシーケンスを、ユーザーに示さなければなりません。ストーリーボードとは、1 つのビジネスタスクを組み立てるために、複数のワイヤーフレームをつなぎ合わせるものです。ワイヤーフレームのコンテンツが十分正確であれば、ストーリーボードの再生は、ソフトウェア製のプロトタイプのテストとほぼ同じです。ただし、ストーリーボードのコストはソフトウェアプロトタイプのコストに比べるとほんのわずかで、ストーリーボードはほぼ瞬時に修正が可能です。高度なシナリオでは、フィルムが使えれば、ストーリーボードの再生にフィルムを使用する方がおそらく合理的です。フィルムによる再生は、各操作かかる平均時間だけでなく、多くのことを明らかにします。正確な検証プロセスには、Test-Operate-Test-Exit (TOTE) などの認知分析要素を含めることができます。TOTE とは、基本的に、ユーザー満足度や共通目標の達成度を段階的に向上していくことを目的として試行錯誤を繰り返すセッションです (図 1 参照)。

図 1 UX 分析に適用される認知分析の TOTE フローチャート

TOTE には特別なテクニックはありません。考え方は単純かつ常識的ですが、予想したとおり効果的に機能します。認知分析の適用や事前準備に時間をかけただけ、後工程での時間短縮が大きくなります。結果、差引は大きくにプラスに働きます。全体的に見れば、想定したモデルに基づいてコーディングを始め、後で間違ったアーティファクトをリリースしたことに気付くよりも、間違いなく優れています。

典型的な例

ここからは、実際の話です。果てしなく続いたミーティングを終え、チームも顧客も、ビルドする Web サイトのすべての側面について、十分議論し、分析できたと確信しました。システムの 1 つ 1 つの側面がすべて明確になり、確定したと考えられ、問題点も挙がりませんでした。このような蜜月はほんの数日しか続かず、開発者がログインページに取り組んだとたん、最初の疑問が生じました。ログインするのはメンバーだけですか。ソーシャル認証は必要ありませんか。「必要ありません。お客様はそのことには触れていません」というのが答えでした。ログインは、Facebook 認証や Twitter 認証を用意しないで提供されました。実は、ソーシャルログインはその顧客の必須要件でした。あまりにも当然かつ明白だったので、言わなくてもわかるはずだと顧客は考えたのです。ソーシャルログインには別途作業が必要です。事前に把握していれば、このメンバーシップシステムの実装を異なる方向に導くことができたはずです。同時に、ソーシャルボタンを用意していないログインページのスケッチを顧客に見せていたら指摘や報告を得られたはずだと、チームのだれもが思いました (図 2 参照)。

図 2 だれも作成しなかったソーシャルログインのワイヤーフレーム

ワイヤーフレームからプロトタイプへの変換

要件を導き出すプロセスで認知分析を使用する考え方に関心が高まるくほど、ワイヤーフレームやストーリーボードの作成に役立つ専用ツールを求めたくなります。ワイヤーフレームは比較的簡単かつ迅速に作成できますが、ストーリーボードはそれほど簡単ではありません。特定のユーザーや特定のビジネスシナリオでは、数枚のワイヤーフレームを単純につなぎ合わせるだけでは不十分な場合があります。場合によっては、なんらかのコードを記述して概念を実証する必要があります。ここでは、状況が明確になるようにいくつか用語を解説します。「概念実証」とは、一般に、仮定の検証や、特定のコンテキストでの新しいテクノロジの試行といった簡単なテストです。個人的には、ドメイン固有の "hello world" と呼んでいます。「プロトタイプ」とは模造システムです。プロトタイプでは、システム全体のシミュレーションを試みたり、システムの実現可能性や利便性をテストします。プロトタイプは、ストーリーボードだけでは不十分だと判明した場合に用意します。最後に、厳密な定義があるにもかかわらず同じ意味で用いられているのが「パイロット」です。「パイロット」とは、一般的な利用対象者やデータセットのサブセットに限定してテストされる完全な運用システムです。

まとめ

ワイヤーフレームとは、関係者どうしがやり取りする通貨のようなもので、ドメイン駆動設計のユビキタス言語とは抽象化のレベルがまったく異なります。ユビキタス言語もワイヤーフレームも、会話を簡潔にし、情報や説明不足によって生じる誤解、データの誤った表現、間違った想定のリスクを減らすことが目標です。

ユビキタス言語とワイヤーフレームは、アイデアを実行コードに自動変換する手法ではありません。控えめに言うと、両者に共通する重要な点は、想定する予算や期日に合わせてソフトウェアを作成するコストを削減できる具体的な手順のシーケンスを見つけることです。

次回は、今回の内容を掘り下げて、ワイヤーフレームを使用する場合のアーキテクチャ上の (深い) 意味について説明します。

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 に心より感謝いたします。