こんにちは。アシアル広報チームです。
今回はアシアルのデザインチームについて、紹介させていただきます。

デザインチームのメンバー構成

エンジニア集団であるアシアルでは、大半の社員がエンジニアですが、その中で5名の少数精鋭なデザインチームが存在します。各メンバーがこれまでに多くの案件に携わり、経験豊富ですが、それぞれの得意範囲が異なります。

A氏：ベテランの職人肌のデザイナー。細部まで綿密に考え抜かれたデザインはお客様だけでなく、社員も感嘆します。また、UXデザインにおいても、ヒアリングの名人であり、インタビューなどを通して、クライアントの抱える潜在的な課題を見つけ、解決に導きます。

B氏：デザイナー？なデザイナー。デザイン領域を超え、営業やプロジェクトマネジメント、軽めのフロントエンド実装もこなす越境的な役割を得意とします。上がってきたデザインをHTML/CSSコードに落とし込むスピードには自信があります。

C氏：イラストレーションも手掛けるデザイナー。様々なタッチのイラストの中でも、柔らかなイラストに定評があります。イラストに限らず、他社事例の研究やデザインシステムの構築などもこなします。

D氏：何でもこなすオールラウンダーなデザイナー。美大出身の審美眼とセンスを活かし、様々なアイデアをもたらします。1ピクセルの見え方にもこだわりつつ、全体的な統一感も忘れません。他のデザイナーが見過ごしがちなところに違和感を持って望める稀有な才能の持ち主です。

E氏：理想を具現化するデザイナー。クライアントの理想とするイメージをデザインに上手く落とし込むのを得意とします。そのために、ヒアリングや徹底的な事例調査を行い、裏打ちされた客観的事実から持たされるデザインには誰もが納得します。実はエンジニアリングもこなせる理論的デザイナーです。

デザイン領域を超えたチームのカバー範囲

上述のように様々なタイプのデザイナーが在籍し、プロジェクトの要件定義段階からデザイナーが関わるため、様々な視点から先を見通したプロジェクト運用が可能です。デザイナーの本領域である画面設計やプロトタイプ作成、ビジュアルデザインのスコープを超えて、デザイナーの知見が活かせるため、実装段階での手戻りが少ないプロジェクト運用となります。

また、デザイナーの本分であるデザイン領域に関して、近年の潮流ではレスポンシブデザインへの配慮・実装はほぼすべてのプロジェクトで行われており、さらにダークモード対応であったり、マテリアルデザインに即したカラースキーム対応なども手掛けることが多くなってきており、デザイナーの担当領域が広く深くなってきていると感じています。

クライアント理解もデザイナーの役割

プロジェクトの要件定義時に、プロジェクトマネージャーと共に、仕様やクライアントの業務フローを理解してUIやデザインに落とし込むのは、アシアルのデザイナーの重要な役割のひとつです。画面を作成する以前に、課題の抽出から参画し、まだ見えていない要件を含めて、プロダクトに組み込んでいく事をデザイナーの使命として捉えています。デザイナーの主要作業として、一般的に考えられている(ビジュアル)デザインは、アシアルのデザイナーにとっては、課題解消の一つの側面でしかないと考えています。

最近の事例として、サントリーグローバルイノベーションセンター株式会社様と開発を行った「腸note」というアプリがあります。腸の音を測定し、ユーザーの今の腸の状態を瞬時に解析し、見える化するというアプリです。とてもシンプルなアプリですが、今までになかったアプリを作り上げるために、クライアントと３名のデザイナーがアイデアを出しあいながら、最適なUIを作成できたと考えています。

受託プロジェクトを多く手掛けることの恩恵

アシアルでは様々な業種のWebシステムやアプリを規模の大小を問わず、受託開発しています。上述の通り、そのなかでクライアント理解、業務フロー理解を行うため、様々な業種の知見が貯まることで、それを異なる業種の課題解決に役立てることが可能です。これはデザイナーに限ったことではありませんが、エンジニアよりもデザイナーのほうがこの恩恵に預かり、応用が効くものであると考えています。

近年の掲載事例だけを見ても、メーカー/飲料・教育/大学・証券/金融・病院/医療・銀行/金融・SIer/IT・メーカー/機器・放送/メディアなど、様々な受託開発を行っており、掲載できていない事例も多々あることを踏まえると、特定の界隈に偏らず、多くの業界・業種からお声がけいただいております。

また、プロジェクトの進め方も千差万別であり、ウォーターフォールを始め、アジャイル、スクラム、長期保守、伴奏型、研究プロジェクトなど、その特性に合わせた動き方にも精通しているため、プロジェクト運用上のウィークポイントを考えたデザイナーとしての立ち振舞いを行う事ができます。

実装時に起こりうる問題への対処

Webシステムやアプリ構築におけるコーディング・実装は、システムやアプリそのものであり、アシアルの中でもエンジニアが多数を占めているため、プロジェクトの根幹と思われるかもしれません。しかしながら、実際のところ、実装フェーズはプロジェクトの最終盤であり、その前のフェーズで決められた仕様に基づいてプログラムされていくだけとも言えます。

ただやはり、実装時に発覚する仕様上の問題というのも多くあります。アシアルでは実装前段階から、デザイナーとエンジニアが密にコミュニケーションを取りながら、実装時に問題となりそうなことを予め潰していきます。そのため、実装時に問題が出てくる割合が比較的少なく、問題が出てきたときにも、すぐにデザイナーを含め、対応を取ることができる環境にあります。

リリース以降、保守・メンテナンスを行っていく際に、デザイナーのアサインを行わずとも継続的に改修を可能にする手段として、デザインガイドラインやUIコンポーネントを初期開発時に用意しておくということも近年のプロジェクトでは増えています。改修時に、すでに存在するデザインやコンポーネントを使い回すことで、開発が楽になるだけでなく、統一されたデザイン感を崩すことがないため、とてもメリットがあります。

デザインチームとしての対応

プロジェクトにデザイナーをアサインする際、近年はできるだけ単独でのアサインを行うのではなく、複数人をアサインするように取り組んでいます。これには単独アサインの場合に、そのアサインされたデザイナーに何かがあった場合のバックアップ要因を確保しておくというリスク低減の意味もありますが、デザイナーが一人で考えられることに限界があることもよくわかっているため、常に相談しながら進められる環境にしておきたいという意味合いが強いです。

どんな優秀なデザイナーでも、一つのことを考え続けていると何が正しいのかよくわからなくなることが多々あります。その際に、別の視点からの意見を求められるのは大変心強いのです。
もし、単独アサインをせざるを得ない場合でも、デザインチームで定例MTGを設けているので、その際に他のデザイナーの意見を求められる機会が用意されています。

以上が、アシアルのデザインチームの特徴であり、強みとして考えている点です。

最後に番外になりますが、アシアルはエンジニアに限らず、デザイナーもみな人柄がよく、和気あいあいとチームMTGをしています。今回のこの記事もチームMTGで開催したブレストをまとめた記事となりました。ここまでお読みいただき、ありがとうございました。