こんにちは。SmartHR プロダクトデザイングループの@uknmrです。
前回まで業務アプリケーションにおけるインターフェースやその質を高めるための方法について紹介してきました。
「あなたのデザインはどこから? 私はオブジェクトから」ということで、今回はSmartHRのプロダクトデザイナーが新規事業開発にどのように関わり、何を考えながら「デザイン」に向き合っているのか、ふたつの実例をもとにお伝えします。
プロダクトデザインとは
所属グループ名でもある「プロダクトデザイン」はSmartHRというデジタルプロダクトにおけるデザイン行為を指しています。主に外観に重きを置いた意匠ではなく、情報の整理と再構成をし、最終的にブラウザで動作するアプリケーションの開発をチームの一員としてスクラムに入りこんで行っています。
そんな我々の任務は「お客さまの業務を理解し、それをウェブサービス上で表現し、お客さまの成功につなげること」です。デザインツールを使って完成見本をつくるばかりがデザインではありません。手段にこだわらず、最短距離でプロダクト開発に貢献し、プロダクトの先にいるお客さまの成功やさらにその先にあるよりよい社会の実現を目指しています。
では、新規事業開発において大切なことはなんでしょうか。私はリリース（機能公開）だと考えています。業務アプリケーションは公開して、利用者に買ってもらって、使ってもらって、はじめてスタート地点に立つことができます。公開しなければないも同然ですし、利用者の必要とする機能がなければ売れるプロダクトにはなりません。使い勝手が悪くても同じです。この「（機能が）うまい」「（使い）やすい」「（公開が）はやい」の平衡を保ちながら公開に導くことが新規事業開発チームの定めだと思っています。
そのためには特定のデザイン手法や特定の技能にこだわらず、社会や組織、プロジェクト、チームなどさまざまな視点から状態をよく観察し、自分の手持ちの駒（技能）や状態と相談しながら施策を考えていくことになります。
ここからは直近1年間で実際に関わったプロジェクトのデザイン過程を紹介するとともに、何を考え、何を行ってきたのかを紹介します。
プロジェクトA：参画3ヵ月でベータ公開
ひとつめのプロジェクトは、私が参画した時には市場調査や利用者の方へのヒアリング（顧客ヒアリング）、プロダクト要求仕様書（Product Requirements Documentのこと、以下PRD）がほぼ出来あがっていました。PMM（プロダクトマーケティングマネージャー：売上に責任を持つPM）によってほぼ売りかたも定まっており、あとはいつ公開できるのかという段階でした。
チーム構成はPMMが1名、開発と兼務しているPM1名、ともにサーバーサイドエンジニアに軸足をおく開発2名、デザイナー1名という4人構成です。
入社したばかりかつ「デザイナー」として初めて担当する仕事だったため、私はとにかく自身の早い立ち上がりを目指していました。
概念モデリング
参画してまず行ったのは認識の擦り合せでした。チームの他構成員へのヒアリングを通したデザイナーへの期待値調整やPRD（Product Requirements Document：製品要求仕様書）を介したプロダクト理解、ドメイン知識の吸収を行いながら概念モデリングを行いました。
概念モデリングとは、PRDから主要なオブジェクトや操作を抜き出しながらオブジェクトの関係性を図示する作業です。記述はクラス図の記法にのっとり、iOSの標準メモアプリで手書きしました。オブジェクトにはオブジェクト名とその所持属性や状態、主たる操作を書き、オブジェクトの関係は1対1なのか1対多なのかを意識して線でつないでいきます。
この作業はPRDと照らし合わせながらPMとの擦り合せを繰り返します。ここでの目的は図を作りこむことではなく、あくまで開発を進めるうえでの認識を揃えることです。副次的にデザインの根幹とも言える「言葉」がチームの中で共通認識とともに揃っていきます。
UIモデリング
頭の中にプロダクトの概念が浮かび、作れそうなイメージが湧いてきたところで、詳細度を高めたモデリングをしていきます。概念モデルで抽出した各オブジェクトの所持属性の型を、開発側で並行して走っているDB設計と照らしあわせながら追記していきます。
所持属性の型とは文字（string）や数値（number）、真偽値（boolean）、オブジェクト（object）、またそれらが単体なのか配列（array）なのかを指します。TypeScriptの型を想像してもらえるとわかりやすいでしょうか。0やnull、undefined などの特殊値についてはここで考慮せず、後述のワイヤーフレーム作成時に状態として考えます。
この作業では開発との認識を合わせ、後戻りを最小限に抑えることを期待しています。ただ見た目をつくるだけなら型は必要ありません。どんな値が入ってくるのかを予想し、すり合せておくことが現実的なUIの作成には必要です。そしてそれが変更や拡張に強いUIにつながるのではないかと考えています。
ワイヤーフレーム作成
UIモデリングとほぼ同時にワイヤーフレームを作っていきます。実際の画面を描かずにモデルとにらめっこしているだけでは詳細度は高まりません。画面の構成を考えながらオブジェクトの状態について考えていきます。
所持属性が空になり得るのか、ページングは必要か、利用者は目的を達成できるか（動線）、ほかのオブジェクトや画面とどう影響し合うのか、などがおもな関心ごとです。デザインツールは同時編集も可能なWhimsicalを利用し、ときにはZoomで音声を共有しながら開発優先度の高い画面から順に作っていきます。動線を考えるときに、概念モデルとは別に、オブジェクトの一覧と詳細といったオブジェクトの関係がどのように関連するかを図示することもあります。
このUIモデリングとワイヤーフレーム作成を繰り返し開発できる詳細度まで高めていきます。必要があれば概念モデリングに戻って認識をすり合せることもあります。
UI実装
開発のメンバーにはワイヤーフレームを正として、細かい見た目は気にせず、とにかく動く機能をがんがん作ってもらいます。それをローカル環境で簡易ユーザビリティテストを行いながら、気になったところを片っ端から実装し、つぶしていきます。
ここでいう実装は、コンポーネントの切り出しや実装の共通化、SmartHR UIへの置き換えといったリファクタリング、CSSによるスタイリング（正しくはstyled-components）、フロントエンドにおけるビルド周りや開発環境の最適化などを指しています。
挙動の過不足や画面間の整合性が取れないなど、考慮不足があればUIモデリングやワイヤーフレーム作成に戻って修正します。ここまでくると概念モデリングまで戻ることはほとんどありません。
プロジェクトAの振り返り
以上がプロジェクトAにおけるデザイナーの関わりかたでした。3ヵ月ほどでベータ公開、その後正式公開し現在も開発と運用を続けています。早い立ち上がりを目指したことが、早い公開を意識することにつながり、最短距離でベータリリースまでこぎつけられたのではないかと思います。全構成員が常に早い公開を意識し、目的に対する目線が揃っていたのでとてもスムーズに進んだプロジェクトでした。
また、ウェブ業界で“デザイン”と呼ばれるデザインツールを使ったカンプ作成はまったく行っていません。これはSmartHR UIというSmartHRの全プロダクトで利用しているコンポーネントライブラリの存在が大きいです。雑なワイヤーフレームであっても標準的なコンポーネントを配置すればSmartHR UIのコンポーネントを想起でき、開発に置き換えられるからです。この存在はコミュニケーション齟齬を大きく減らしています。
