デザイナーからのテック相談 エピソード１：UIデザイナーが、要件定義・設計フェーズに関わるメリット

こんにちは、UIデザイナーの小高です。デザイン業務に邁進しながらも、技術情報に関する悩みを抱える日々を過ごしています。アシアルにはエンジニアが多く在籍していますが、デザイナーがエンジニアやプロジェクトマネージャー（PM）のスキルにもう少し近づくことで、プロジェクトにどのような相乗効果を生み出せるのかを普段からぼんやり考えていました。

でも、一体どこから手をつければ良いかわからない。そんなもやもやを解決すべく、デザイナーの視点から「テック相談」を持ちかけてみました。今回は、その第1回目です。

プロフィール

デザイナー 小：UIデザイナー。デザインの表層分野を得意としていますが、骨格・構造・UXリサーチなど広い範囲でのデザインを担えるよう、日々取り組んでいます。現在は主にデザインフェーズに注力していますが、設計や開発フェーズでも貢献できる方法を模索中です。

エンジニア S：エンジニアからPMのポジションにシフトしたPM。アシアルに入社して、3年目くらいに大きな案件のプロジェクトリーダー（PL）を経験した後に本格的にPMをすることになった。今も現場でPMを担当しつつ、会社課題への取り組みや課題チームのビルディングなどもしています。

プロマネ K：デザイナー出身のPM。アシアルに入社して、２年目くらいからPMや営業の仕事もするようになり、最近はほぼほぼPMとして動いていて、たまに自分のプロジェクトでデザインワークをすることもあります。デザインチームのリーダーっぽいこともしています。

デザイナー 小：このメンバーに何を相談するか考えたとき、最初は「フロントエンド開発にUIデザイナーが関わった場合の効果」をテーマにしようと考えていました。プロダクトの表層的なクオリティに関わることができる点が魅力ですし、その方法について相談したい気持ちもあります。ただ、効果のイメージはつかめたので、今回は少し視点を変えて、エンジニアが多いチームの中で「どうすればエンジニアやPMの作業スケールに溶け込み、化学反応を起こせるか」について深掘りしたいと思いました。

エンジニア S：僕の意見ですが、デザイナーがプログラムの具体的な言語やデータベースの詳細まで理解する必要はないと思っています。それって多分、デザイナーだって、僕らにデザインの専門知識を求めているわけではないと思うんですよ。細かい事は必要ないけど、お互いがイメージを共有できるくらいの基礎知識は必要だと思います。

例えば、最近はSPA（シングルページアプリケーション）でシステムを構築することが多いですが、こうした仕組みを意識したUI設計ができると、より良い成果につながるんじゃないかと思います。

デザイナー 小：構築されている仕組みを考慮することで、UIにどんな違いが出てくると思いますか？

プロマネ K：「何を重要視するか」かなと。システムの特性をある程度理解した上でデザインしないと、ユーザビリティが悪くなることがよくあります。例えば、モーダルを出すタイミングや、この画面を先行して表示するべきかどうか、そういった判断に影響しますね。

デザイナー 小：表示に時間がかかるパターンが出てきてユーザビリティが悪くなるケースがある。なるほどです。

エンジニア S：そうですね。システムへの理解度っていうのは、動き方や運用面も含めて、デザインに大きく影響します。完成したデザインを、ただ組み立てるだけではなく、デザイナーとエンジニアはそれぞれやってることは違うんですけど、一緒に同じ目線で話す事が大事だなと思っていて。

デザイナー 小：それは本当に必要ですね…。ちなみに、「SPA」みたいなキーワードをはじめ、エンジニアと同じ目線でコミュニケーションを取るために、情報をキャッチアップするにはどうすればいいんでしょう？正直、会議中に出てくる技術的な単語についていけないこともあって…。Kさんはどうしてますか？

プロマネ K：はてブとかエンジニア向けの情報サイトをよく見ています。プロジェクトに関連するキーワードを探して、知らない単語があれば、その都度調べる感じですね。

エンジニアS：技術的な概要を把握しているだけでも、デザインのプラスになるんじゃないかな。あと技術情報を純粋に楽しいと思えるか、興味を持てるかどうかも大事な事かも。

デザイナー 小：楽しく取り組むこと！そうですよね。これを機に、技術的な情報にももっと興味を持って学びたいと思えてきました。この気持ちを持続させなくちゃ、ですね。

デザイナー 小：もう一つ、聞いてみたい事があって。プロジェクトの規模によって任せられる守備範囲が違うと感じていて、どんなプロジェクトにアサインされても対応できるように、少しずつスキルを広げておきたいと思うのですが。

プロマネ K：アシアルの場合、小規模プロジェクトだと1人で進めることもあります。そうなると、本当に何でもやる感じですね。お客さんとの窓口対応から要件定義、設計、そして開発まで、すべて1人で担当するケースもあります。

デザイナー 小：大規模プロジェクトだと、それぞれのフェーズをチームで担当するイメージがありますが、プロジェクトの規模によってやることに変化はありますか？例えば、作業が増えたり、省略されたりすることってありますか？

エンジニアS：小規模プロジェクトでも、大規模プロジェクトと基本的には同じことをやっています。プロジェクトで必要なことは、規模にかかわらず共通して起きていると思いますよ。

デザイナー 小：なるほど！規模によるボリュームの違いはあっても、必要なこと自体は変わらないんですね。もう少し設計フェーズのところを詳しく聞きたいんですが、デザイナーは「調査・分析系」や「画面設計書」で関わることが多いですよね。それ以外に設計フェーズでは、どんなものが必要になるのでしょうか？

プロマネ K：「画面設計書」というのは、いわゆるワイヤーフレームのことですね。これを指針にしてデザインを進めるので、デザインフェーズより前に作成されます。

エンジニアS：それから、設計フェーズの前段階で「要件定義書」や「基本設計書」を作成します。これらはシステムの機能要件や非機能要件を説明した資料で、「このシステムは何を実現しなければならないか」を定義するものです。

少し話が戻りますが、設計フェーズからデザイナーが関わるべきだと感じる理由として、例えばプロジェクトが業務システムの場合、アプリ開発や一般的なWebデザインよりも複雑になります。個別の画面だけでなく、連続する画面全体のUXや階層の深さを考慮する事も必要です。それぞれのプロジェクトの設計フェーズでクライアントの課題や目標が明確になっていくので、その時点でデザイナーが関われば、システムへの理解を深めたり、新しい提案をしたりする際に同じ目線で進められるというメリットがあります。

デザイナー 小：このあたり、普段からどのような準備や勉強をしておけば良いのでしょうか？少しでも理解を深めたいと思っているのですが…。

プロマネ K：多分、みんな経験を積んでいったパターンですよね。人によって、作る資料に多少の違いはありますが、大体は共通しています。どの資料を作っておけば後々の作業が楽になるかが、経験を通じてわかってくる感じです。

エンジニアS：そうですね。あとは、デザインで特に意識してほしいのは、「コンポーネント」という視点です。個別のページごとに最適化して設計すると、それぞれのパーツのCSSが増えて、ページに依存した作りになりやすい。そうなると、変化に弱いものになってしまいます。再利用可能な「コンポーネント」を意識して設計することは、特に規模が大きなシステムでは重要なポイントだと思います。

デザイナー 小：確かに、コンポーネントは一貫したブランディングを提供できるという表層的なメリットだけでなく、柔軟で変化に強いシステムを作る上でも大切ですね。

エンジニアS：「コンポーネント」以外にも、例えば階層の深さを意識するとか、一画面一機能にこだわりすぎないとか、考慮すべきポイントはいろいろあります。

デザイナー 小：私なんか、共通化って便利だと思う反面、それぞれに適したデザインが作りにくいというジレンマや難しさも感じています。

プロマネ K：最初に必要な要素をどれだけ想像できて、コンポーネント側にその思想を反映させておく事ができるかがポイントだったりはしますね。

今回の相談を通じて、多くの学びを得ることができました。ある程度の技術への理解は、UIデザイナーにとって必要な要素の一つである事を感じ、情報取得にもっと興味を持ち、この気持ちを持続させながら学びを深めていきたいと思いました。
まだまだ聞いてみたい相談したい事は、たくさんあります。より良いプロダクトを作っていけるよう、これからもお互いに近い距離感で協力しながら、感じたことや学びを発信していきたいです！