[アーティクル]
05/31/2016

May 2016

Volume 31 Number 5

Visual Studio - Lean UX プラクティスの育成

Karl Melder | May 2016

マイクロソフトは Visual Studio 2015 でデバッグと診断に新しい機能をいくつか提供しました。こうした機能の詳細については MSDN マガジン 2016 年 3 月号の記事「Visual Studio 2015 におけるデバッグの強化」(msdn.com/magazine/mt683794) で Andrew Hall が説明しています。UX への実質的な変更が伴う機能の場合、マイクロソフトは "Lean UX" アプローチを導入し、反復テストを利用して、ユーザーからのフィードバックを情報として直接設計に提供しました。

今回は、こうしたデバッグと診断の機能の 1 つ、パフォーマンスのヒント (PerfTips) を設計するために使用したプロセスを、その過程で得たベストプラクティス、ヒント、テクニックと共に紹介します。目標は着想のヒントを提供し、開発者や開発チームが開発プロセスにユーザーからのフィードバックを効果的かつ直接的に組み込めるようにすることです。

Lean UX

Lean UX は、IT 業界のトレンドになっているリーン開発の実践を補完します。Eric Ries は、著書『リーンスタートアップ』(日経BP社、2012年) で「ビジネス仮説ドリブンの実験 (business-hypothesis-driven experimentation)」アプローチを説明する中で、リーンの定義を、「構築、測定、および学習 (Build, Measure and Learn)」の実践としています。同じように定義すると、Lean UX とは開発のごく初期の段階でユーザーによる検証を継続的に行うことに重点を置く一連の原則とプロセスです。Lean UX では、対象ユーザーと製品についての設計上の仮説を極めて短いサイクルで検証する実験を行います。ユーザーが抱える実際の問題を解決することに重点を置いて、短いサイクルで繰り返し設計を見直します。Jeff Gothelf の著書『Lean UX』(オライリー・ジャパン、2014年) も優れた参考書で、チームの考えや実現目標を明確にできるガイダンスとワークシートが提供されています。

Visual Studio のデバッグエクスペリエンスを提供する当チームの場合、Lean UX とは、緊密なコラボレーションを求められるアプローチです。プログラムマネージャー、UX の研究者、開発者、UX のデザイナーなど、チーム全体がアイデアや仮説を生み出し、ユーザーからのフィードバックの解釈に関与します。

今回は、製品の開発プロセスでユーザーからのフィードバックを十分生かす方法について取り上げます。先を急ぐと失敗することを示します。特別な作業を必要としないで、開発者のアイデアについてのフィードバックを受け取る方法を説明します。デベロッパーツール部門でこうした手法を取り入れているチームは 1 つだけはでなく、リーン開発プロセスで機能の設計方法を根本的に変えているチームはたくさんあることを紹介します。

設計上の課題

マイクロソフトのテクノロジには、問題を診断するのに適した方法を開発者に提供するデータソースが豊富に含まれています。それなのに、UX ラボでは、ユーザーが手作業でコードを実行する状況に陥ることが何度もあります。プロファイラーなど、メリットを生み出すツールがあるにもかかわらずです。Visual Studio プロファイラーを使えば、パフォーマンスの問題を非常に効率的に検出できるとわかっているのに、インストルメンテーションデータを見ると、プロファイラーの使用率が低いことがわかります。ユーザーが 1 日に 8 時間以上作業に使っている Visual Studio のようなツールの場合、作業スタイルの変更をユーザーに求めるのは難しいのかもしれません。そこで、チームは、パフォーマンスの問題をデバッグするときにユーザーの自然な作業スタイルを活かして、デバッグ関連のエクスペリエンスを提供しようと考えました。

昔ながらのウォーターフォール手法を採用している場合、フォーカスグループを立ち上げ、フィードバックの早期収集、詳細仕様書の作成を行い、コーディング完成間近には、ユーザビリティ調査のスケジュールを設定します。ユーザーには、新機能を試し、実行時にバグが発生するといった問題を見つけて報告する作業が求められます。Visual Studio 2015 では、これとはまったく異なるアプローチを採用しました。

調査プロセス

ユーザビリティ調査のスケジュールを確保するのではなく、人手があるときは、ほとんどの製品サイクルで、2 人のユーザーのスケジュールを毎週金曜日、事前に確保しました。陰では、この日を「ドキドキ金曜日 (Quick Pulse Fridays)」と呼んでいました。ユーザーは、通常約 2 時間で、2 ～ 4 件の実験を行います。集中して実験する時間は、実験ごとに最適な時間が推測されています。実験には、どのようなユーザーがどのように操作するかをマイクロソフトが詳しく知りたいと考えるものや、マイクロソフトのアイデアを試してみるものがありました。設計上のアイデアを先に進めるには、最低でも 3 週間以上肯定的な評価が得られなければなりません。肯定的な評価とは、価値がある、発見の可能性が高まる、使いやすくなるとユーザーが強く感じるか、主要シナリオでの改善が実証されることです。

UX 調査の多くは定量的調査と定性的調査に分類されます。こうした調査では、インストルメンテーションや分析と、ユーザーからのフィードバックを組み合わせて、ビジネスや製品開発にガイダンスを提供します。早い段階での定性的調査では、フィードバックによってアイデアに対するユーザーの反応をみます。当チームでは、ユーザーの発言内容だけでなく、肉体的反応、表情の変化、声のトーンも考慮しました。ユーザーは、調査チームが見守る中、チームの助けなしでアプリケーションのパフォーマンスのバグを解決するような実作業も求められます (図 1 の写真を参照)。つまり、ユーザーには頭を使うことが求められます。チームは後からレビューするためにユーザーのようすをビデオ撮影し、見聞きしたことをメモします。ユーザーを見守ることで作業スタイルを理解し、明確にはなっていないニーズを見極めます。このようなニーズは、ユーザー自身さえ求めていることを意識していませんが、製品に劇的な改善をもたらす可能性があります。

図 1 ユーザーとの調査セッション

チームが成功するために重要なのは、アイデアを気に入るようユーザーに働きかけることではありません。ユーザーには、そのアイデアを使用したらどうなるだろうという点から、アイデアを示すだけです。その後、チームは一歩下がって、ユーザーの見解を理解できるように、ユーザーの声に耳を傾け、その行動を見守り、質問するだけです。チームが成功する鍵は、ユーザーが強く感じた部分をアイデアから切り取る能力、または強く感じた部分を設計に盛り込める能力にあります。

新しい観点を安定して取り入れるため、毎週異なる参加者を呼びます。参加者は、社内チームとベンダーの両方から採用し、選抜して、スケジュールを確保します。診断に関して具体的な専門知識を備えたユーザーを探したわけではありません。、採用条件はもっと単純で、Visual Studio のアクティブユーザーであることだけでした。スキル、経験、作業コンテキストが異なるユーザーを毎週採用します。こうすることで、毎週新しいことを学ぶ機会があり、一貫性を見極めることができました。また、成功を幅広い対象ユーザーに広げるために、アイデアを進化させることもできます。

同様に、チームからユーザーへバランスよく働きかけることも重要です。問いかけ方によって結果に大きく影響したり、会話に偏りが出ることがあります。チームは、ユーザーが自由に話せるように問いかけることをいつも心がけていました。そうすれば、ユーザーの言動から的確な疑問点を引き出せます。たとえば、ユーザーが何か気に入らないことがあると話しているときは、「詳しく話してください」とだけ問いかけます。思い込みをなくし、あらゆる場面で前提や仮説を排除します。こうしたスキルは UX の分野では基本的なもので、チーム全員が習得していました。インタビューの細かいテクニックについては、Cindy Alvarez 著『リーン顧客開発』(オライリー・ジャパン、2015年) がお勧めです。

早期の「ドキドキ」セッションと確固たる作業スタイル

製品サイクルの早い段階では、まず、ユーザーが自身のコードのパフォーマンスを監視する場合の助けとなるアイデアを考えました。チームはモックアップを作成し、「ドキドキ金曜日」を担当するユーザーに提示しました。この設計変更から 3 週間経っても、耳にするのは相変わらず、目的がわからない、そして「おそらくこの機能は無効にするだろう」といったものでした。チームが望んでいた答えではありませんが、耳を傾ける必要がありました。

ですが、診断アプリケーションの問題についてユーザーを見守っていると、コードナビゲーションの操作性の一部にもっと直接的な UX が必要であることが明らかになりました。いくつかのデバッガーウィンドウに追加情報が表示されていても、ユーザーは一度に複数のウィンドウに注意を払うことは難しいようです。チームが観察したところでは、多くのユーザーがコードに意識を集中し、多くの場合は、頭の中で「コードを順番に」実行しています。本誌読者の開発者の方であればお分かりになると思いますが、もっと作業効率が上がる別のツールを利用できるとしても、開発者には作業スタイルを変えないこだわりがあります。

チームはアイデアを形にするために Photoshop を使い始めていました。Photoshop を使うと、非常に経験豊富なデザイナーでもフィードバックに使用するモックアップを作り出すのに 1 日以上かかります。Photoshop を使うと極めて忠実に UI を再現しようとしがちです。そこで、Microsoft PowerPoint とストーリーボードアドイン (aka.ms/jz35cp、英語) を使うことにしました。そうすれば、チームの誰もが使え、アイデアをある程度忠実に表現するものをすばやく作成できるようになります。このようなストーリーボードによってユーザーはどのように見えるかを感覚的に理解することができます。ただし、進行中の設計とその直接的効果がユーザーに伝わる程度のラフなものです。実験が失敗しても、実質的にはストーリーボードの作成に要した 30 分が無駄になるだけです。チームが提示するテスト対象のアイデアは実際にはまだ機能していませんが、ユーザーからのフィードバックは新しいアイデアを生み出す助けになります。

ユーザーの操作モデルについてのフィードバックを得るため、PowerPoint デッキの各スライドではユーザーのアクション、またはそのアクションに対するシステムの応答を表現します。ユーザー操作のドラフトを作成するときは、ユーザーがクリックする場所を示すカーソルアイコンのイメージを含めます。これは、アイデアを共有し、詳細を理解するのに役立ちます。しかし、このカーソルアイコンはユーザーに示す前に削除することになりました。これを示してしまうとユーザーに次の行動を示すことになり、検出できるかもしれない問題を特定する機会が少なくなります。システム応答の各スライドでは、ユーザーが進展を感じているかどうかも問いかけ、システムから適切なフィードバックを提供しているかどうかを把握します。このフィードバック手法は UX 調査では「認知的ウォークスルー法」と呼ばれ、対話操作を設計する際のごく初期の段階で問題点を特定するのに有効です。また、今後さらなる繰り返しや実験を行って解決すべき懸案事項を早期に認識できるようになります。

アイデアの潜在的効果の測定は、そのアイデアを日常の作業環境でどのように使うかや、実感したことが直接的なメリットなのかデメリットなのかをユーザーが明確に表現できるかどうかにかかっています。そのアイデアを追求する価値があることを確信するためには、チームが納得できる詳細な例をユーザーが提供しなければなりません。チームは、ユーザーが多くの注意を払うようになり、積極的になり、興奮を表現するかどうかも見守ります。ユーザーが興味を持ち、診断操作に極めて肯定的な効果をもたらす可能性のあるアイデアを探します。

「なんて、すばらしい機能だろう!」

当チームでは、コード内にパフォーマンス情報を表示する方法を必要としていました。コードの読みやすさを損なわず、関連するコード内でのデバッグエクスペリエンスを提供する方法です。コードレンズは Visual Studio の機能で、編集履歴、バグ、単体テスト、参照設定についての情報を確認できるようにし、可能な操作モデルやビジュアルデザインについてのヒントを提供します。チームでは、開発者がコードをステップ実行するときに表示する方法を、いくつかアイデアを盛り込んだモックアップを使って実験し、パフォーマンスの数値をミリ秒単位で表示することにしました (図 2 参照)。

図 2 デバッグセッションでパフォーマンスデータを表示する初期のモックアップ

チームがそのアイデアを進めていこうと考えた最初の兆候は、参加した開発マネージャーがその操作を行って大きな興奮を見せたときでした。このマネージャーは、背景情報は一切与えられずに、提示された操作に興奮を示したのです。マネージャーは目にしていることを理解するにつれて、細かい質問を繰り返すようになり、話し方も非常に活気づいてきました。マネージャーによれば、これは初級開発者が抱える問題の解決策になるといいます。初級開発者はコーディング時に十分な判断ができず、作成するアプリケーションのパフォーマンスは不十分になりがちだと話します。こうした開発者に対する現状のプロセスでは、人手をかけてコードレビューのプロセスを踏み、パフォーマンスの問題を解決します。しかし、これは開発者にとってもチームにとっても大きな負担になっています。マネージャーは、このアイデアによって、初級開発者はコーディングの当初からパフォーマンスの高いコードの作成方法を学習できると感じたといいます。このマネージャーが残したコメントは、「この [PerfTip] は [Visual Studio] のポリシーになるのではないか」というものです。別のユーザーはその価値を認めた後で、「1 行のコードに示されたこの機能が Visual Studio をすばらしいものに変えている」と記しています。

この早期フィードバックによって、この機能が診断ツールのエントリポイントとなる可能性があり、有効な機能を見つけてもらえないという問題が解決すると、チームは活気づきました。PerfTips はユーザーが豊富なツールセットを導入するきっかけになるだろうとチームは考えたのです。

細部の設計

ここまでの作業はすべてモックアップのみで行い、一切コーディングは行っていません。アイデアに手ごたえを感じたら、PowerPoint の「クリックスルー」で多くのレベルで細部を作成し、毎週の実験に代えて多くの設計作業を行います。ただし、モックアップでできることには限界があり、以下のような調査の問題がいくつか残ります。

共通ロジックの問題をデバッグしているときに PerfTips の設計に影響しないこと、ただし、パフォーマンスの問題を扱うときはツールの検出可能性の問題が残らないことの検証。
ユーザーがパフォーマンスの数値を正しく解釈できるようにすること (前回実行を停止したところからの時間を計測)。
ユーザーはパフォーマンスが不十分な場合のみ値を表示するよう求めているが、確信を持って既定のしきい値を提案できていない。
デバッガーのオーバーヘッドに対する懸念 (数ミリ秒余分にかかる可能性があり、ユーザーへの付加価値が減少する可能性がある)。

チームは、特定の条件下で機能する最小限の機能を備えたバージョンを実装しました。次に、ユーザーがパフォーマンスとロジックの問題を診断できるように、問題を含むアプリケーションを作成しました。ユーザーには、問題の具体的な原因を突き止めるよう依頼します。ユーザーが原因を突き止められない場合、見聞きしたユーザーの行動からその理由を判断します。その後、設計を見直し、翌週再度試します。この間、外部 CTP バージョンをリリースしました。このバージョンはインストルメント化され、PerfTip がプロパティウィンドウにリンクされるため、ユーザーは必要に応じてしきい値を簡単に変更できます。チームの結論は以下のとおりです。

ユーザーがロジックの問題を解決する際、PerfTips は妨げにならなかった。実際には、ユーザーがパフォーマンスの問題に取り組んでいるときに PerfTips に気付くように、簡単なアニメーションを用意することにしました。
簡単な語句をいくつか変更した。たとえば、ユーザーがタイミングデータの解釈を間違えないように、「経過 (elapsed)」という単語を追加しました。
しきい値がユーザーを混乱させるだけになってしまうことがあった。たとえば、しきい値が一貫して表示されない場合や、大半の環境で機能するシンプルな値を特定できないという場合などです。自分のコードが最善であると分かっているため、しきい値は妥当なパフォーマンス時間の判断に有効だと話すユーザーもいます。
デバッガーのオーバヘッドが原因で値が正確にならないことに気付いたユーザーがいた。ただし、そのユーザーは全体的な差異を見ているので問題にはならないと繰り返し話しました。

全体として、パフォーマンスの問題の原因を突き止めるようにユーザーに作業を依頼し、数週間作業を繰り返すと、必ず肯定的な結果が得られました。特に問いかけなくても、「すばらしい」とか「なんて、すばらしい機能だろう」といった熱意のこもったコメントを添えたフィードバックをくれたユーザーもいました。

メモをとる

メンバーが集まって発生した事象について話し合う時間があるときはメモをとりますが、そのセッションが終わるまでは結論を書かないようにすることを学びました。その場では起きたことをそのままメモにとり、ユーザーの発言と行動をすべてを 1 つ 1 つ書き留めるようにします。文法やスペルは気にしません。発生した事象についてメモを更新し、数週間観察したパターンから分かったことを書き留めると、そのメモはチームの参考資料になります。

Microsoft OneNote が非常に便利なツールになり、テスト計画の追跡、その場でのメモの書きとめ、簡単なまとめの下書きなどに効果を発揮しました。見聞きしたことを書き留める記録係を必ず指名します。それ以外のチームメンバーはユーザーを見守ることに完全に集中します。会議に出席できないメンバー用に、Skype を使用したライブセッションをチームで共有しました。チーム全員を招待し、見て学べるようにしました。ミーティングが重なり、後からの視聴を求めるチームメンバー向けにセッションを録画しました。ビデオに録画したことで、チームはさらに注意が必要な分野を復習することもできました。成果についてのチームディスカッションを毎週開催し、翌週の予定を伝えます。正式レポートの執筆は求めず、ゆとりを持って実施しました。

まとめ

毎週の実験で行ったことに比べれば、PerfTips の設計と開発の作業はわずかなものでした。ユーザーひとりあたり毎週 4 件の実験を行うことで、多くのアイデアを試しました。ブレークポイント設定の設計を見直したことは、こうした実験の成果の一例です。毎週実験を繰り返し、有用で便利なエクスペリエンスを追求し続けた成果です。Lean UX を採用することで、チームは実験中に見聞きしたことからヒントを得て、リスクを軽減することができました。機能を設計する際、こうした実験では推測を重要視しません。アイデアはさまざまなソースから得ることができ、開発者が普段業務に従事している方法を見守ることでヒントが得られます。

ユーザーがアイデアに価値を見いだせなくても、コストをかけずにモックアップを作成すれば、最初から簡単にやり直すことができます。失敗からも新しいアイデアが生まれます。今回示した Lean UX の例やヒントから試してみようという気持ちが生まれることを願っています。今回引用した「リーン」シリーズの書籍は、このアプローチを採用するためのガイダンスやフレームワークとして非常に役立ちます。

プログラムへの参加

マイクロソフトの UX 調査チームでは、直接フィードバックを提供し、継続中の実験に参加していただける、さまざまなバックボーンをお持ちの開発者を探しています。参加するには aka.ms/VSUxResearch (英語) でご登録ください。ここでは、いくつか技術バックグラウンドの記入と、最適な連絡方法を入力をお願いしています。

このプロジェクトにわずかでも関わっていただいたすべての開発者に心より感謝いたします。「ドキドキ金曜日」には、Visual Studio に追加しようと目的を持って考え抜かれことを、チームが見守り、学習して、追求していく過程が「詰め込まれ」ています。開発チームの先頭に立ち、技術的課題に冷静に対処した Dan Taylor に心より感謝いたします。Andrew Hall は、深い技術知識と実用的アプローチでチームの前進をサポートしてくれました。Frank Wu は常に設計のアイデアを思いつき、それを突き詰めて、シンプルにする卓越した能力を身につけています。

Karl Melder は、UX 調査、コンピューターサイエンス、UI、人的要因における自身の教養と経験を UX の設計に堅実に当てはめる、UX 調査の上級研究員です。これまで 15 年以上、多種多様なユーザー向けに Visual Studio の開発エクスペリエンスの強化に取り組んでいます。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Andrew Hall、Dan Taylor、および Frank Wu に心より感謝いたします。
Andrew Hall は、Visual Studio Debugger チームのシニアプログラムマネージャーです。大学卒業後、基幹業務アプリケーションの作成に携わった後、コンピューターサイエンスの修士過程に復学しました。修士号取得後、Visual Studio の診断ツールチームに参加しています。マイクロソフト社内での勤務中は、Visual Studio のデバッガー、プロファイラー、コード分析ツールを駆使しています。

Dan Taylor は Visual Studio Diagnostics チームのプログラムマネージャーで、ここ 2 年間はプロファイリングと診断のツールを担当しています。Visual Studio Diagnostics チームに参加する前は、.NET Framework チームのプログラムマネージャーで、.NET Framework と CLR のパフォーマンス向上に大きく貢献してきました。

Frank Wu is はユーザーエクスペリエンスのシニアデザイナーで、現在は、編集と診断の最高のエクスペリエンスを設計し、すべての開発者に提供することに重点を置いて取り組んでいます。彼は HCI の修士号を取得後、ここ 10 年以上、セキュリティソフトウェア、Windows Server 製品、およびデベロッパーツールを担当しています。

次の方法で共有