Inspired日本語版

第19章 設計 vs. 実装
実装の前にユーザーエクスペリエンスを設計する

ソフトウェア開発の作業では、同時に進められることや同時に進めるべきことがたくさんある。たとえば、私は、長い間、機能要件とデザイン (ユーザーエクスペリエンスの設計) は、お互いに関連し合っているので、並行して進めるべきだと主張してきた。私は、プロダクトマネージャーが要件を定義してから、これをインタラクションデザイナーに渡して設計してもらうという、従来のウォーターフォールモデルは好きではない。今や、多くの製品開発チームの人たちは、このモデルは時代遅れだと思っている。

また、ソフトウェアの実装とテストを並行してやることの意義に気付いたソフトウェアエンジニアリングチームもあるが、私は、こうしたチームが大きな進歩をもたらしてくれたと思っている。エンジニアがソフトウェアを書いてからこれを品質保証担当者に渡すという従来のモデルだと、実際のところ、もっと時間がかかる上に、結果の信頼性も劣る。実装とテストを同時に協調して進めることの有用性は、XP (eXtreme Programming) のようなアジャイル開発手法によって実証されている。

それはそうとして、多くのチームが並行してやろうとしていることだが、実はそうするべきでない作業というのが、ユーザーエクスペリエンスの設計と実装である。

その理由はいくつかある。

第一に、ソフトウェアアチームの中にはある種の力が働いているもので、これはよく覚えておいた方がいい。いったん、エンジニアリングが始まると、根本的な変更をすることは段々と難しくなるのだけれど、ユーザーエクスペリエンスデザインのアイデアを実装させていくにつれて、変更が必要になっていくものである。これには、まず、技術的な理由がある。エンジニアリングチームは、実装を進めるためには、自分たちである程度想定した要件やユーザーエクスペリエンスデザインを基にして、早い段階でソフトウェアアーキテクチャを決めていかなければならない。この早い段階での決定は重大であって、後々大きな影響が出る。また、心理的な理由もある。いったん実装の態勢になってしまうと、それがしっかり根を下ろしてしまい、前に戻る気にならなくなるのだ。また更に別の理由としては、現実的な話として、時間がどんどん過ぎていく中で、設計し直したりかき回したりすることは、チームにかかるプレッシャーをどんどん強めていってしまう。そのため、たとえアジャイルのような途中での変更を容認するモデルであっても、進んでやったほうがいい変更かそうでない変更かを即座に見抜かなければならないのだ。

第二に、ユーザーエクスペリエンスの設計では、使いやすくて価値のある製品にするという難題に取り組まないといけないが、そういう製品にするためには、早いうちから、事あるごとに、いろいろなアイデアを試してみる必要がある。こう言うと、「ベータ版をリリースすればフィードバックをもらえるから」とか、アジャイル開発手法を使っているチームであれば、「スプリントの終わりでテストしてみよう」といった反応が返ってくることがよくある。でも、ここまで待つのでは、アイデアを試すには遅すぎる。ユーザーエクスペリエンスデザイナーが優秀であれば、数日という単位でたくさんのアイデアやアプローチを試してみたくなるものだ。2週間から 4週間もかかるスプリントを待つのでは、あまりにものろくて、考えただけでうんざりしてしまう。

第三の理由は、2番目の理由とも関連している。私は、アイデアを試すためには、それを再現できるプロトタイプが必要だと主張している。ベータ版がプロトタイプみたいなものだとか、スプリントの結果をプロトタイプと思えばいい、などと主張する人もいる。でも、それだと、テストできる状態のソフトができあがってくるまで長く待たされるし、そもそも、プロトタイプ用のソフトは、正式版のソフトとはまるで違うものだと思っておいたほうがいい。プロトタイプ用はまさに使い捨てのソフトである。また、何時間かかけるだけで、がらりと変えることができるものでなければならない。正式版の製品にとって必要なことは、プロトタイプがボートだとすれば、そのアンカー (錨) の周りをのろのろと動いているようなものであるということだ。また、プロトタイプを作りたい人と正式版の製品を作りたい人では、タイプが違うということも頭に入れておこう。

第四の理由は、リリースを予定しているソフトウェアのユーザーエクスペリエンスは、バラバラに分けて作れるものではないことが多いという点である。一方、実装については、いくつかのインタラクションに分けて進めることは、時として、大いに理に叶ったやり方である。こうすることで、リスクを小さくしたり、品質を改善したり、統合 (インテグレーション) を容易にすることができるからだ。でも、ユーザーエクスペリエンスについては、全体的に考えなければならない。ユーザーエクスペリエンスというのは、それぞれのリリースでユーザーから見て筋が通っているものでないといけない。まだリリースできないでいるソフトウェアから火が付いたところだけ消して取り除くのは簡単だが、ユーザーエクスペリエンスで同じことをやるのは難しい。

最後の理由として挙げたいのは、ユーザーエクスペリエンスデザインには、それほど時間はかからないということだ。ある程度の時間は必要だけれど、まあ、1週間か 2週間といったところか。(もちろん、どれだけ時間がかかるかは、エンジニアリングの場合と同じように、どういう手法を使うか、何か特殊な製品要求はあるか、特定のスキルや経験がある人にやってもらう必要があるものなのか、といったことにも左右される。)

ユーザーエクスペリエンスの設計と同時に実装も始めようとすると、まず間違いなく、次のような事態に陥るだろう。デザイナーは、ストレスを溜めながら、数週間かかるはずの仕事を数日で仕上げようとする。エンジニアは、デザイナーから何か上がってくるのを待ちながらやきもきしている。しばらくすると、デザイナーは、エンジニアが作業を始められるようにするため、仕方なく、適当に見当をつけたというレベルのものを披露する。そして、エンジニアの作業がどんどん先に行ってしまう前に、大急ぎで何とかまともなデザインに仕上げようとする。でも、デザイナーがそれらしいものを仕上げたときには、すでに時遅し、エンジニアからは、「それは次のリリースでやりましょう」と言われてしまう。ところが、当然のことながら、次のリリースには、そのリリース固有の優先課題がある。結局、デザイナーは、できあがって発売されたものには満足できないし、顧客にも気に入ってはもらえない。

こうして、最悪の場合には、デザイナーは、ユーザーエクスペリエンスを優先してくれる会社で働くしかない、という結論にたどり着いてしまうだろう。

幸いなことに、この問題を解決するのは難しいことではない。ポイントは、実装が始まる前に、ユーザーエクスペリエンスの設計をやればいいということだ。これは、まさに、大事なことは順番だ、という状況である。まず、製品要求の作成と設計を同時に進めて、次に、実装とテストをいっしょにやるのがいい。

アジャイルな手法を使うチームの場合は、プロダクトマネージャーとユーザーエクスペリエンスデザイナーは、 スプリントゼロ (スプリントを開始するための準備段階) というコンセプトを使って、ユーザーエクスペリエンスデザインがエンジニアリングの 1～2歩先にいるようにする。そうすれば、デザイナーはできるだけ小さいボリュームに区切りながら作業を進めることができる。このためには、バックログの中で定義する項目の内容を充実させる必要がある。でも、結果的には、チームのメンバーはずっと快適に作業できるし、製品にとってもその方がいい。

このルールの例外は、エンジニアがバックエンドインフラ関係の作業を山ほど抱えている場合である。この状況では、ユーザーエクスペリエンスデザイナーが作業を進めるのと並行して、エンジニアリングチームはバックエンドインフラの作業を進めていくこともあり得る。相互に依存するところはあるが、どうにかできるだろう。もしユーザーエクスペリエンスデザイナーがキレそうになったら、エンジニアには、 1つか 2つのリリースのためのインフラストラクチャの作業をしばらくやらせておけばよい。その間に、デザイナーはいい設計にするためのバックログを作ることができる。

エンジニアが実装を始める前に、製品要求とユーザーエクスペリエンスの設計をいっしょにやってしまうように強く勧めているが、この最初の段階からエンジニアリングチームのだれかに参加してもらう必要はある。というのは、こうした作業の途中で、エンジニアが実現可能性やコストの評価をすることが欠かせないからだ。これは、設計の途中でエンジニアからのフィードバックを伝えるのに必要なことである。目的は、もちろん、価値のある、使いやすい製品の定義を見つけ出すことである。

優れたデザインを実現することについて、あちらこちらで大きな混乱が起きている。これは、特に、多くのチームがアジャイル開発手法を試すようになっているためでもあるだろう。これは残念なことだと思う。というのは、ずっと従来のウォーターフォールモデルでソフトウェア開発をやってきたチームにとっては、ほんの少しだけ注意して、ほんの少しやり方を変えるだけで、アジャイル開発手法を取り入れることが大きな大きな一歩になり得るからだ。そもそもどうしてそういう混乱が起こるのか、どうすれば両方の手法のいいとこどりができるのか、第26章「アジャイル開発手法をうまく使う」で述べることとする。