イベントメモ「戦略から関わるプロダクトづくり」

February 2, 2022

先日参加したセミナーの学習メモと、感想です。

採用支援サービスの要件定義・デザイン時のエピソードを、パネルトーク形式でお話しいただきました。

チームでプロダクト設計の共通認識をつくるには

メンバー共通のリテラシーを持ってあたった。グッドパッチでいうとUXの5段階モデル。この案件では、5段階モデルでいうと構造部分を重視した。ここが欠落すると、見た目などのビジュアル表現に寄り過ぎてしまい、デザインとして脆くなってしまう。

プロセスとしては、概念モデルを使った設計と、ユースケースモデルを使った設計を行った。

UMLクラス図を使って概念を整理する。プロダクトオーナーとデザイナー2人で、毎日3時間くらい詰めて話し合っていた。UIで表すかどうか別として、システム外の周辺ドメインも含めてすべて洗い出した。

クラス図を作るメリット

まず、クライアントが仮設シナリオ（ユーザーストーリー）を検討。デザイナーはそれを抽象化し、ユースケースとして [誰]が[何]を[どうする] 構文で詳細を記述していく。ユースケースはユーザーの「用途」。ユースケース単位で要件を記述していき、詳細設計を行った。

要件定義という段階では、機能一覧を作って、UIをつくって、というのが一般的。しかし、はじめに機能一覧を作ってしまうと、その機能を使わない可能性を取りこぼしてしまう。

ユースケースモデルを使う意図としては、リサーチ結果をUIに反映させたいというところがある。UXとUIをどう接続するのかはいまだに確立されていない部分だが、この案件のようにシナリオから構造化していく流れは一つのやり方としてうまく行ったと思っている。

膨大なデザインドキュメントで思想を共有する。デザインドキュメントによる共通認識のメリットは、エンジニアからの代替提案ができること。エンジニアの立場からすると、デザインを受け取っても実装できない場合がある。思想がわかっていれば、これなら実装できるという提案ができる。

デジタルプロダクトには終わりがなく、改善し続ける必要がある。重要になってくるのは改善のスピード。拡張性を担保するために、共通認識が役に立つ。

デザインの設計思想を語るところから始まる。抽象的なインターフェースの概念から、この案件ではこういう方向性が大事だからこうしましょうという流れまで。実務的なところで行くと、コンポーネントのルールや組み合わせ方。また、アクセシビリティのための実装方法など。ありとあらゆる種類のドキュメントを残した。

利用シナリオとしては、プロジェクトのオンボーディング時に読む。どんなコンセプトで作られているのかの把握に使う。

UIクラスの洗い出しからユースケースを書いて要件定義していく方法、社内のプロダクト開発でちょうど要件定義するところだし、早速試してみたいです。

興味深かったのは、デザインドキュメントがプロジェクトチームでの共通認識を作るのに役立っているという点。具体的にどんなアウトラインなのかなど、もっと詳しく知りたく思いました。

また、実際のUI作成時の思想（タイトル編集ポップアップ）のセクションがリアルでおもしろかったです。自分もあの画面だったら閉じるボタンはつけたくないなと思うなど。