読み物一覧

UIデザイナーの「画面作成」以外の業務について 〜プロジェクトの推進に役立つかもしれない〜

#column#DX#UIデザイン
2021/10/28

片岡 彩子

はじめまして。UIデザイナーの片岡です。

この読み物に何を書こうか悩みましたが、

「このブログを読んでる方はどんな方だろう…?(DXに関する、システム開発プロジェクトを担当されている方だったりするのかな…?)」と想像してみました。

そこで今回は

「世の中、UIデザイナーじゃない人の方がほとんど。(つまり、UIデザインをする人が何を考えているか、知らない人の方が大半。)

では、非デザイナーの方に向けて、
UIデザイナーという立場から提供できる

『事前に知っておけば失敗を回避できたり、
実は将来的なコストを削減できることにつながる情報』は
なんだろうか?」

と色々考えてみた結果、

普段やっている業務について、特に「画面作成」以外の普段見えない業務についてをご紹介することにしてみました。

UIデザイナーって…何をする方なの?

UIデザイナーとは、とてもざっくり言うと
PCで操作するシステムや、スマホアプリなどの「画面を作り込んで形にする人」のことです。

デザイナーと聞くと「見た目を綺麗にしてくれる人」というイメージはありませんか?

私自身、デザイナーとして働く前は、漠然とそういう印象を持っていました。

ですが「見た目を綺麗にする」という表現でイメージされている業務は、実はデザイナーの仕事のごくごく一部でしかありません。

特に、UIデザインにおいては最後の最後にやることであり、
その前にやることのほうが実はとても多いです。

UIデザイナーの「見えない」業務について知ることは、プロジェクト推進の参考になるかもしれない

普段あまり知られることがない、舞台裏で行われているUIデザイナーの仕事をご紹介することで、「デザイナー」職に対するイメージと、現実のギャップが埋まるのではないでしょうか。

また、適切な職能の人材をアサインすることに繋がるかもしれません。

さらに、その中で「これはデザイナーではない自分でもできそうだな」と思えることについては、

デザイナー以外の方が、プロジェクトを成功させるために準備できることも多々ありそうです。

それでは、普段からシステム開発現場にいないとあまり目にする機会がないかもしれない、UIデザイナーの業務内容について説明したいと思います。

実は沢山ある、「画面を作る」以外のデザイナーの業務

もちろん、各開発現場によって仕事内容は異なると思いますので、
あくまで一例だと思っていただけたら幸いです。

その中から、今回は下記の4つについてご紹介します。

1)まずは「業務理解」と、そのための「業務フロー図の作成」

2)開発予定の各機能の相互作用関係図の作成

3)現場へのヒアリング・ユースケースの整理

4)想定漏れをとにかくなくしていくための仕様検討

1.まずは「業務理解」と、そのための「業務フロー図の作成」

「システムのUIを作る」と言うことは、
ある意味では「働き方をデザインする」ことでもあります。

特にtoBの「日々使う業務システム」のUIである場合、その責任は大きくなります。

なぜなら、もしも使いづらいシステムを作ってしまったとしたら
「毎日ストレスを与えてしまう」ことになりかねないからです。

「システムが使いづらくとも、そのシステムを使わない、という選択をすることができない業務」の場合、
「システムにあわせて働き方を変える必要が出てきてしまう」ことすらあり得ます。

逆に言うと、「使いやすくてストレスがないシステム」は、働く方の毎日を快適にすることに直結します。もしかしたら離職率の低減にもつながるかもしれません。

と、いうことで「働き方をデザイン」してしまいかねない「業務システムのUI」を作るにあたっては、絶対に深く業務を理解する必要があります。

そういった意味で「業務フロー図の作成」は、
自分自身のプロジェクトへの理解を深めるためにも、
チーム内の認識の齟齬をなくすための資料としても、
さらには途中からジョインする開発メンバーがキャッチアップする際の資料としても、役立ちます。


2.開発予定の各機能の相互作用関係を図にしたものの作成

これは必ず毎回作ると言うわけではありませんが、
複雑に各機能が絡み合う、業務システムの開発案件である場合、作成するととても便利です。

開発する機能を一覧化し、各機能の相互作用関係を図にしたものを作成することで、以下のようなことに役立ちます。

■「チーム内での開発スコープの明確化(認識齟齬の解消)や、各マイルストーンごとの開発予定についての共有」。
(※「開発スコープ」とは、「何を、いつまでに開発するか」という開発範囲のことです。)
(※「マイルストーン」とは、第一次開発ではここまで、第二次開発ではここまで、と、「小さなゴール」を開発に設けながら、機能を追加したり拡張したりしていく際の、「各小さな開発ゴール」のことです。)

■どこからどこまでの機能群を何という名称で呼ぶのか「呼称の統一」
(※これを行うことでコミュニケーションコストの低減や勘違いの発生の予防ができる)

■システム全体の「情報の構造についてのイメージ共有」

上記の各機能の相互作用関係図の作成については
「デザイナーがやるべき」とは思っていませんが、
自分の中で頭の整理のために「図」の形で欲しくて、作ることがあります。
(このことに関してのみではありませんが、誰がやるかについてはあまりこだわっていません。)


3.現場へのヒアリング・ユースケースの整理

PM(プロジェクトマネージャー)が一覧を作ってくれる時も多く、とてもありがたいです。もし現場へのヒアリングに直接デザイナーが行ける場合は、デザイナーがまとめる場合もあります。

ユースケースとは、

「どんな時に、どんな立場の、何を達成したい、誰が、どんなことに頭を使いながら、どんな場所で、どういう状況で、このシステムを使うのか」について整理したもののことです。

それらの情報が整理されていない状態では適切な情報を適切に画面上に配置していくのは困難です。
また、もしかしたら、画面上のUIではない形で「解決策」が浮かぶ可能性もあります。

エンジニアに都度相談しながら、問題解決の最適解を見つけるためにもユースケースの整理は必須になります。

4.「想定漏れ」をとにかくなくしていくための「仕様検討」

私が最近よく行っている業務の中に
【『仕様の考慮漏れ』を潰しながら、仕様を確定させていく】というものがあります。

システムを作るとき、PMやエンジニアから伝え聞いた概要や要件、ラフなイメージなどを元に、まずはワイヤーを描き起こしてみる工程があります。

(※ワイヤーとは、ラフよりは詳しく、画面に必要な情報を配置し、情報の設計についてを考える段階の設計図のようなもののことです。この段階ではいわゆる「綺麗」な見た目をつける「スタイリング業務」にはまだ着手していない状態になります。)

実際にシステムの仕様を画面に落とし込む作業をしていると、
細かく「どの情報がどの情報由来で算出されるのか」「データはどのタイミングで取ってくるのか(サーバーへ送るのか)」等々、検討しますので、その過程ではじめて「あ、これはまだ検討されていないぞ」と気づく項目もあります。

それをできるだけ早い段階で見つけて、どんどん仕様を確定させていきます。

楽しい開発ライフを!👋

と、いうことで…今回は、この記事を読んだデザイナーではない方が

「DX…システム…やっぱり難しそう…」

と不安に思うのではなく、

「なんだか、前より少し解像度が上がって理解できたかも…!
何を準備すればいいかちょっとわかった…!」

と、明るい気持ちでこのページを去っていくことができたならいいな、と思っています。

何か一つでもあなたのDXプロジェクトのお役に立てば幸いです。