Xデザイン学校#7のリフレクション

はじめに

2022年11月12日。7回目は構造化シナリオ法。4回目までのリサーチフェーズを学んでいた頃は、毎回アハ体験をしている感覚だったが、5回目で実装フェーズに入ってからは、実装フェーズの知識・経験のなさゆえか、アハ体験をしている感覚がなかった。（もちろん毎回学びは多いのだが。）ただ今回でやっと、実装フェーズに入って初めてのアハ体験をしたように感じる。

構造化シナリオ法

盛大に間違えているかもしれないが、構造化シナリオを以下のように理解した。

構造化シナリオのイメージ

Xデザイン学校で学んだ様々なデザイン活動には、「情報を整理して新たな意味を生み出す活動」と「前段の意味を生み出す活動を後段の意味を生み出す活動へと繋げる活動」の2種類があるように思う。これに照らし合わせて考えると、バリューシナリオとインタラクションシナリオは前後の世界を繋げる活動で、アクティビティシナリオは新たな意味を生み出す活動にしてUXの世界のキモとなる活動のように感じた。

BDDとアクティビティシナリオ

アジャイル開発を実践するためのプラクティスの1つにテストファーストプログラミングがあり、具体的な手法としてテスト駆動開発（Test Driven Development、以下「TDD」）や振る舞い駆動開発（Behavior Driven Development、以下「BDD」）がある。アクティビティシナリオの話を聞いて、パッと思い浮かんだのはBDDだった。BDDはあまり詳しくないので記事を読んでみたところ、以下のように書いてあった。

BDDはTDDの一流派ともいえますが、TDDに対し以下の実現のための原則や工夫が加えられています。
・テストを「振る舞い」（機能的な外部仕様）の記述に特化させる
・ユーザーの要求やアーキテクチャの設計仕様といった、
　より上位のインプットとTDDのテストにつながりを持たせる
（中略）
　BDDでは、テストの記述において
「Tests as Documentation」（ドキュメントとしてのテスト）
「Specification by Example」（例示による仕様）
という2つの考え方が重視されます。

テスト駆動開発／振る舞い駆動開発を始めるための基礎知識より一部改変

プロダクトコードの構造や仕組みに依存せず期待する振る舞いでテストを記述することでBDDのコード自体の保守性を高めようとする工夫や、要求と実装につながりを持たせる点、例示によって仕様を記すという手法には、アクティビティシナリオとの類似性を感じる。
具体的には、アクティビティシナリオの操作に依存せず活動を記述することでアクティビティシナリオの保守性を高めようとする工夫、ビジネスの世界とUIの世界に繋がりを持たせる点、シーンおけるペルソナの活動によって仕様を記す手法が、上述のBDDの特徴と似ている。
要は本質的な上位のレイヤーと移り変わりの激しい下位のレイヤーに抽象化のレイヤーを設けているのだ。
この抽象化レイヤーを挟むことは、VUCAと呼ばれるこの時代に果たしてどれだけ意味があるのだろう？と、ふと思ったが、先生がアクティビティシナリオを使って、デスクトップアプリをガラケーアプリ、スマホアプリに作り替えた事例があるというお話をされていて、そのレベルの変化に耐えられるなら問題なさそうだと思った。本当にゲームチェンジが起きる時はプロダクトの価値自体がなくなるだろうから、UXの世界でどうこうという話ではないのだろう。

デザインとは形と中身の関係だ（#0ぶり2回目）

今日は講座を受けながら、5月のプレ講座「UXデザインの基礎」で山﨑先生に紹介いただいた以下の言葉を何度も思い出していた。

Design is relationships. Design is a relationship between form and content.（デザインとは関係である。形と中身の関係だ。）

ポール・ランド

リサーチフェーズで作り込んできた価値（中身）を、ちゃんと繋がり（関係）を持たせてUIデザイン（形）に落とし込む。自分たちは今まさにその活動をしているように感じた。

大切なのはペルソナではなくペルソナづくり

計画することがすべてだ。立てた計画はどうでもいい。

陸軍元帥　ヘルムート・グラフ・フォン・モルトケ

これは「アジャイルな見積りと計画づくり」という書籍で紹介されている印象的な言葉。UXの世界では「隠れたあるある」を捉えることが大事という話や、アクティビティシナリオ、インタラクションシナリオはペルソナを自分に憑依させて作成することが大事という話を聞いて、この言葉と同じように、大切なのはペルソナではなくペルソナづくりだと感じた。
Xデザイン学校に入る前は、ペルソナを作るのは関係者で共通理解を育むためだと捉えていたが、この捉え方は上手くペルソナを捉えられていなかったようだ。いまビジネスの世界からUIの世界に繋げるために、あるあるを紡いだペルソナづくりをすること、そのペルソナとシーンを組み合わせて魅力的な世界観を描くことこそが、UXの世界では大切なのだと思う。

ビジネスモデルが悪いサービスのUIは良くならない

自分なりに構造化シナリオやUXの世界について理解しつつあった講義の終盤、先生が「ビジネスモデルが悪いサービスのUIは良くならない」とおっしゃっていて、その瞬間「うわ、俺のUXに関する理解は全面的に間違ってるわ」とショックを受けた。なぜなら自分の理解が正しければ、ビジネスモデルが悪くても、UXの世界で頑張れば、儲からないけど使いやすいサービスが理論的には作れるからだ。
だが続けて先生が「なぜか？そこまでのめり込まないから」とおっしゃっていて、ぐうの音も出ないほどに深く納得した。この言葉は実践をし続けてきた人でないと出てこない言葉だ。理論的には儲からないけど使いやすいサービスができるけど、実際はそうならない。サービスを作っているのは意思を持った人間だから。改めてリサーチフェーズの重要さを痛感。（毎回思い知らされる）
社内システムや社内クラウドのUIが使いにくいという話をどこに行っても聞くが、それも納得だ。UIデザインの段階で、勝負は決まっている。自社サービスを普段から社員が使うことで改善をするドッグフーディングという考え方がある。これまで、なぜこの考え方が社内システムや社内クラウドに適用されて、改善がなされないのだろうと疑問だったが、これも先生の話を聞いて合点がいった。社外に販売して儲けることを真剣に考えずに社内システムや社内クラウドを作り始めてしまっているから、後から改善しようにも、戻るポイントがないのだ。そういう意味では、ドッグフーディングできるのは、そもそも初めからビジネスモデルを決めて、UXの世界、UIの世界を通してきたサービスだけなのだろう。

おわりに

冒頭書いた通り、今回は実装フェーズに入って初めて、知識がつながる感覚を感じられてよかった。来週の京都での校外学習前に、UXの世界について自分なりに理解を持てたのは大きいと思うので、京都でいろいろなことを体験して、UXの世界に関する理解をさらに深めたい。