株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2021』の21日目の記事になります。
はじめに
ユーザー体験を構成するUXデザイン5段階モデルは、抽象化されたものを具象化するための工程を表しています。
プロダクトデザインとかも好きなので、この工程はよく知っているのですが、抽象されたものを具象化してきくプロセスとしてすごくわかりやすいと思ってます。自分はシステム設計が好きです。 抽象化された概念をシステムにするときにも使えるのではないと考えました。
システム設計入門のプロセスだと、、ユースケース図ならべて、システム境界を決めますとか書いてあるのでしょうか
システム境界を決めれないから困ってるんだ！
こういう人は少なくないのではないでしょうか？
一昔のモノリシックなシステムをつくるのではあれば、、、どのユースケースをシステム化するのかという関心事で終わっていたと思います。
マイクロサービスでシステムをつくる事が多くなってきた、、この時代。本当のシステムデザインのスキルが求められるようになってきたと思うのです。 ビジネス戦略とシステムデザインもつながる必要ありそうです。
UXデザインの5段階モデル
階層はUXデザインの5段階モデルをベースにするので、この記事で扱う構造は5段階モデルのそのままです。
ビジネス戦略とユーザニーズが紐づき、戦略設計からUI設計するまでを5段階のプロセスにわけた概念の事です。
このプロセスでUX定義を進めると、ユーザニーズとデザインのトレーサビリティが繋がり、コンセプトが具体的にプロダクトに反映する事ができるようになります。
本記事は、UXデザイン5段階モデルとシステムデザインの連携を意識してかいているため、ユーザ体験ファーストになるように書いています。
戦略（Strategy）
そもそも、戦略とはどういうものでしょうか？
「戦略とは、一般的に特定の目的を達成するために長期的視野と複合思考で力や資源を総合的に運用する技術、科学である」
長期的である必要と、複合的である思考が必要。
このフェーズは、UXデザインと同じでいいのではないかと思います。
ユーザのニーズ・サービスの目的が整理するフェーズになると思います。
システムデザインする上で重要な情報としては、過去と未来の情報は重要視してもいいかもしれません。
3年後、5年後のビジネス戦略の情報や、業界の情報、世界のトレンドはプロダクトにどういう影響を与えるのか整理しておく必要があります。少なくともアーキテクトというポジションだったり、技術責任者の方はここをポイントに、設計責任者と話すといいと思います。
ビジネス的な成果もでてない状況で、未来の予測も難しい。しかし、システム設計はこれも考慮して拡張性を設計する事が求められるのです。
ここを見誤ると技術的負債が発生や、将来の開発スピードの低下、システムの寿命が短くなる事になります。
デザイナーの成果物
- プロダクトの目的
- SWOT分析・ビジネス価値
- ビジネス・営業戦略
- 業界の長期的なトレンド（経済白書）
- 技術の長期的なトレンド
- 会社・部署の技術戦略
- ユーザーインタビュー
- ペルソナ設定
エンジニアの成果物
- ビジョンドキュメント
- プロダクト開発戦略
- 大雑把なポンチ絵
- アクター（ペルソナ）
要件（Scope）
このフェーズではユーザ体験から、機能をイメージでできるところまで整理をします。プロダクトに必要な機能仕様や要件などを設計します。
所謂業務分析フェーズも含まれます。 AsIs,toBeや、ロバストネス分析などしてもいいでしょう。ドメインモデルを作り初めてもいいと思います。 ユーザの振る舞いを可視化し、システム化するスコープを決めます。 まずはどのようなデータがどういうユーザ体験に使われるのかというものを把握するといいでしょう。 データをカテゴリ化します、どのイベントに使われるか整理して概念データモデルを作ります。 データのカテゴリ化が終わると、コンテキストマップをつくり、コアコンテキストを見極めます。（ここが難しい）
ここまで整理されるとどこをスコープにするのか可視化できると思います。 また、ユーザ体感を提供するためのシステム化の優先順位もつけれるぐらいには可視化できてる状態になれると思います。
ここまでで、システムの役割定義は終わっていたい。マイクロサービスだと、どの単位でマイクロサービス化するなどの方針はこのフェーズで決めていたい。戦略や未来の情報も踏まえて、アーキテクチャをどのように選択していくかはここのフェーズできめちゃいます。ユースケース駆動でつくるのか、ドメイン駆動でつくるのかなど方式が定義されている状態を作ります。
デザイナーの成果物
- カスタマージャーニーマップ
- サービスブループリント
- 業務フロー
- データ・帳票
エンジニアの成果物
- 概念機能モデル図
- 概念データモデル図
- 制約条件・ビジネスルール
- コンテキストマップ
- アーキテクチャ方式設計
- 概念的な状態遷移図
構造（Structure）
情報設計を主に行うフェーズです。 UXデザイン上だと、画面に見えている視点でUIモデリングをしたりします。
どの画面にどんなコンテンツがあるのかが分かりやすいのか、コンテンツ同士の関連性をどのように見せるのかといった設計をします。
システムデザイン視点でいうとシステム全体が、いくつかのアプリケーションサーバで成り立っていてるのか可視化します。
どこで、どのデータがどのように使われて、どういうデータがつくられるのか可視化できている状態をつくるフェーズになります。
まず、概念データモデル、システムモデルを精緻化していきます。
LATCHをベースにリソースとイベントを整理してこれをベースにデータモデル図をつくったりするといいかもしれません。
データモデリングの手法はいくつかあるのですが、最終的にはERDが作られいるといいでしょう。
また、要件、戦略などのフェーズからデータ量も予測して設計する事もあっていいかなっと思います。データテーブル設計を論理設計と物理設計をわけて設計れる会社なら、ここでは論理設計でOKかと思います。シャーディングを意識したりする場合もあると思います。
ドメイン駆動とかを意識しているプロジェクトならば次の骨格フェーズでERDをブラッシュアップしていくのはいいと思います。
デザイナーの成果物
- UIモデリング図
エンジニアの成果物
- 機能設計書
- 論理データモデル図
- データフロー図
- システム設計書
- ドメインモデル図
- システム概要図
骨格（Skeleton）
骨格では、情報設計された構造にレイアウトを当ててプロダクトの完成イメージをつくります。UIレイアウトがあたったプロトタイプをつくりユーザ体験の完成度を高めます。
システムデザイン視点だと、1つアプリケーションの外部設計フェーズという所でしょうか。プロダクトのUIが明確になっていくるフェーズなので、それをベースにシステムがどう振る舞うか定義するフェーズになります。画面設計、画面遷移は、デザイナさんのアウトプットとかぶるかもしれません。
未来情報や、要件段階で決めた内容から、レイヤードアーキテクチャや、オニオンアーキテクチャなどアプリケーションアーキテクチャ設計を行いアプリケーションをどうつくるか決めます。データ量とか、コード量、複雑性、保守性を意識しなければいけません。
ドメイン駆動設計など、ドメインモデル図を作って進める方針の場合は、ここでプロトタイプしながら、ドメインモデルとデータモデルを言ったり来たりしてつくるのもいいでしょう。
この段階で重要なことは、プロダクトのUIのイメージが固まり、情報設計、データ定義が固まり始めます。 システムデザインとは情報がどのように制御されるのかを定義するとするなら、この段階で確実にやらないといけないものがあります。状態遷移の作成です。UMLのステートマシン図などを使うのがいいでしょう。 プロトタイプベースにデータがどのように変更されて、状態がどうかわっていくか確認しながら精査していくといいと思います。 ここでいう状態とはビジネス的な意味の状態(契約・解約など)もありますが、もう少しシステム設計視点の状態定義(契約申請中、解約処理待ち)もあっていいです。
デザイナーの成果物
- プロトタイピング
- ユーザビリティテスト
エンジニアの成果物
- 画面遷移図
- 画面設計
- 言語
- フレームワーク
- ERD
- ミドルウェア設計
- アプリケーションアーキテクチャ設計
- ビジネスルール
- バリエーション表
- 状態遷移図
- ドメインモデル図
- プロトタイピング
表層（Surface）
ユーザ体験の感性的な要素などを設計する段階になります。嬉しい、楽しいとか、楽ちんとかそういう気持ちよさを表現する事になります。
システムデザイン上の感性は主に、パフォーマンスは非機能要件に表されてくると思います。
APIをどのように作っていくかは、大きく感性に表現に影響すると思っています。
もちろん、フロントエンジニアが表層フェーズで求められるものを実現するかという事も決める必要があります。コンポーネント設計方針やCSSのパッケージ管理方法などがあると思います。（フロント苦手なので、、すいません、、）
デザイナーの成果物
- デザインシステム・デザインガイド
- ビジュアルアイデンティティ
エンジニアの成果物
- API設計・ガイドライン
- CSSパッケージ定義
- コンポーネント設計方針
- パフォーマンス設計
- シーケンス図
おまけ
運用設計系は今回いれてないですが、、それも追加していくとよりプロダクトをつくるときのシステムデザインのプロセスがわかりやすくなると思います。
読んでいただきありがとうございます。
明日は、@k_kamonさんの「成功できる組織にする為、考えた5つの取り組み(チームビルディング)」です。
ぜひ、読んでみてください。