「デザイナー」というカルマ

これは30代を目前に控えたあるデザイナーが個人的経験から編み出したデザイナーの動き方のアップデートをするために綴った独白の手記です。

プロローグ

私は暇でした。とにかく暇だったのです。

2023年が始まって2,3ヶ月。自分がUI設計を担当していたプロダクトの大方の設計を既に終えてしまっていたのです。
それは私が過去の地獄のような鍛錬からあまりに強大な力をつけてしまったのか、もしくは設計するUIの規模がチュートリアルのごとくありふれたToDoアプリほど小さかったのか、はたまたそれは周りの力であって、全ては私が見た幻想だったのかは分かりませんが、とにかく暇という事実には変わりはありませんでした。それはまだ寒さが残る3月のことでした。

一方、私の周りの環境は会社の規模の拡大とともに目まぐるしく変わっていました。
中でも私の所属するUI/UXデザイングループは長年続けていたスクラムチームへのコミットからの脱却への動きも見せ、複数プロダクトや他プロジェクトへの貢献を果たすメンバーも少なくありませんでした。

私は焦っていました。とにかく焦っていたのです。

以前複数プロダクトへのコミットも短い期間やっていましたがどうも駄目だったのです。私には圧倒的に向いていませんでした。
どうしても私の性格上、一つのことに思いを巡らせることでしか成果物の質をあげることしかできないのです。

私は無い知恵を絞り、この問題に対する解決策を考え、ある一つの答えにたどり着きました。

いっそデザインを辞めて違うことをすればいい、と。
その極端かつ一見無鉄砲にみえる決定には私が長年薄々感じていた謎が関係していました。

モノローグ: 謎

私が友愛株式会社に入社しておよそ丸3年。今まで3つの機能の開発を担当してきましたがどこか開発チームの中でデザイナーとして疎外感を感じていました。
プロジェクト初期にはPMとの協業でユースケースやユーザーストーリーの理解、選定を行いそこから高速で妥当なワイヤーフレームやプロトタイプを設計をします。
そこではまさに不確実な物を具体に落とし込むデザイナーの力量が試されます。ですがその段階を過ぎると自分が設計したUIの青図は手元を離れエンジニアによって具現化され、QAによって品質が担保され世に出ていきます。その段階では既にデザイナーの関与する範囲は比較的に小さくなっていき、やがて私の中で疎外感が生まれていきます。特に、デスクや障害発生時などデザイナーとして疎外感を感じるタイミングが多くありました。

複数プロジェクトへの貢献ができる方にとっては、その段階は疎外感ではなく他のプロジェクトへの関与を始める機会の現れなのかもしれません。ですが複数プロジェクトが得意ではない私にとってはどうしても歯痒いタイミングなのです。なぜなら私が主に設計した物なのに、設計以後関わりを減らすというのは色々なものにたいして不誠実であると感じるからです。そして何より私が寂しい、面白くない。

ですがこれは果たして本当に、私が”デザイナー”という職能だからこそ感じる疎外感なのでしょうか。いえ、そんなことはないはずです。 今までを振り返ると私はUIの設計にこだわりを持っていると自負していました。ですがその執着心が故に他の物を蔑ろにして、もはや自分を正当化していたのではないだろうか？デザイナーであることが他の職種に関与しないという免罪符だったのではないか？いやそれは普通に言い過ぎだし、自分に厳しすぎるので撤回します。

詰まる所、この疎外感というのは私自身が生んでいて、勝手にデザイナーとしての職能に限界を設けていたのだと気づきました。

そしてこれは言うなれば、私が歩んできたデザイナー像がもたらしたカルマである。

私は拳を強く握りしめて涙を拭い、心に近く誓った。デザイナーを辞めて、”開発者”になる、と。

これは私がデザインを辞めて、開発者になることを目指す中で重ねた悪（「デザイナー」というカルマ）との戦いと苦悩の記録である。

1. バックエンドとの戦い

バックエンドとの戦いで火蓋は切って落とされた。

友愛株式会社に入社してからというもの、デザインとのエンジニアリングとの接合を目指しコーディングをするようになった。業務外ではネイティブアプリケーションを開発したり、暇さえあればMDN等のドキュメントや書籍、他の人のコードを読み漁ったりした。業務内でも他メンバーからの援助もあって少しずつコードが書けるようになってきた。（もちろんレベルはたかが知れている）

最初はフロントエンド開発からスタートした。UIを設計する者にとって、目に見えて操作できるところに重点を置くのは自然だ。だがコードを書けば書くほど自分がWEBアプリケーション開発においてフロントエンドとバックエンドを切り離して考えているということに気づいた。そうなった経緯や歴史については全くの門外漢なので、不用意な言及はしないが、ネイティブアプリケーションではそもそもWEBアプリケーションほどフロントエンドとバックエンドという切り分け方をすることはないので違和感があったし、バックエンドの知識、経験が無ければフロントエンドのコーディングも思うようにできなかった。よりよくUIを設計するためにはバックエンドの経験が必要不可欠だった。

またバックエンドのコーディングを経験したことで、素材としてのデータにより注目してUIを設計できるようになった。昨今のUI設計にはオブジェクトを起点とするOOUIというフレームワークが主流になってきているが、OOUIはあくまでプロダクトの中で起点となるオブジェクトを炙り出すためのフレームワークであり、本当に細部までUIを設計するために必要なのは、データベースのモデル図だ。では簡略化せずにモデル図を用いてUIを設計すればいいのではないだろうか？またモデルの設計にもデザイナーが参加すればいいのではないだろうか？

今回は幸いにも同じチームに所属しているバックエンドエンジニアの協力もあり、ほんの少しはモデルの設計にも協力できた。またデザインツールにもER図がチーム全員に見える形で置いてあり、UIの議論をする際にも概念モデル図ではなく、ER図を用いて議論をする。

この戦いを通して、デザインとエンジニアリングの接合についてより深く理解できた。私はまだずっと線を引いていたのだ。

こうして私がバックエンドのコーディングをしてみることでバックエンドの戦いは一旦幕を閉じた。だが今後もこの戦いは果てしなく続くのだろう。

2. デスクとの戦い

次に訪れたのはヘルプデスク、通称デスクとの戦いだった。これを見た読者の中には、他のものと比べるとデスクなんて些細なものだと思った人もいるかもしれないが、デスクがデザイナーに与えてくる示唆というのは考えている以上に大きい。

恥ずかしながら、今までデスクにおいて回答を求められたら答えてきたが、能動的に1次回答者にはなってこなかった。そして顧客からくる要望や質問は多種多様なものだった。ユースケースや今後のロードマップ、イレギュラーな質問もあった。特にプロダクトの仕様についての質問は多い。

デスクをやっていると顧客が何を求めているのかがより深い解像度で理解できるようになる。しかし、“ただデスクをやる”ということがもたらしたのはそれだけではなかった。前述の通り、バックエンドの理解、知識を蓄えることで仕様についてもPdEの回答を待たず、ある程度は答えられるようになる。そして顧客のニーズと仕様に何らかのズレがある場合はデザイナーの視点で問題点を見つけ、それをチームにフィードバックすることができる。これは今後続ければ良いループになるかもしれない。ただデスクをやるだけはなく、”デザイナー”が”プロダクトの仕様を深い粒度”で把握しつつデスクをやるということは思った以上にメリットがありそうだ。

3. QAとの戦い

最後に待っていたのがQAだった。QA（Quality Assurance = 品質保証）とは実装後にバグを見つけたりプロダクトとしての価値を出せているかを確かめる工程を意味する。これは完全に未知との遭遇だ。デザイナーとして見た目や振る舞いを実装後に局所的に確認することはよくあることだが、複雑なアプリケーションにおいてエッジケースを含めた本格的なQAをやったのは初めてだった。

先に結論を言っておくと、まだこの戦いは始まったばかりでQAにおいて何も理解したことはない。それでもQAをやることで見えてくることは多い。

テストケースの作成は専任のQAの方にお任せした。私は現在目下マニュアルテストをひたすらやっている最中だ。マニュアルテストをやることでの学びもあるが、他人にテストケースを作ってもらったというのが大きい。もし自分がテストケースを設計するのであれば、自分がUIを設計したためどうしても恣意的な目線になってしまうという恐れがある。だが他人の目線で設けられた基準で見れば、公平かつ網羅的に考えることができる。そうすると案の定バグだけではなくUI上で考慮できていないところが出てきた。

そしてやはり誰かに教えてもらうより自分で発見する方が圧倒的に学びが多い。そして仕様にも詳しくなれる。ここまでくるとデザイナーがQAをしないという選択肢はあるのだろうか？とまで思えてくる。自分が設計したものを自分が触り倒すと考えると自然な行為だ。

QAをやることで新しいインタラクションやデザインプロセスについての大局的なアイデアも出てきた。例えばデザイン → 実装 → QAという一般的な流れをやめて、デザイン ↔ QA → 実装という流れにしてみてはどうだろうか？デザインと実装間での手戻りを極力をなくすために、ある任意のフォーマットを用いてデザイン作業とQA作業をしてしまえば、高効率で高品質なUIが設計できるワークフローになるのではないだろうか？もちろん実現可能性等は考慮していないが、アイデアはあったほうがいい。

結論、専門的なQAの知識を身につけるのは時間と場数が必要であまり現実的はないが、QA作業を手伝うだけでもデザイナーとして見えてくることは総じて大きいのでおすすめしたい。

番外編:　フロントエンドとの戦い

前述の通り、デザインとエンジニアリングの接合を目指す中でまずはフロントエンド開発から始めたのだが、どうも上手くいかない。別に期待するUIの振る舞いを1人で実装できないわけではない。それより拡張性と負債を軽減できるコードが書けないのだ。デザイナーとしてプロのエンジニア達の土俵に入るならそれなりに保守運用可能なコードを書くための努力はしないといけないと常々感じていたが、一朝一夕で獲得できるスキルではない。そしてわざわざ時間をかけたのにも関わらず、PR上でエンジニアから怒涛のコメントと修正依頼がくると他人の時間を使ってしまってるという事実に気が滅入ってしまう。

とはいえ、UIの品質も上げたい。そんな悶々とした日々が続いているのだがある日、ハッと我に戻って気づいた。私は別に自分が書いたコードをマージしたいわけではないのだ。あくまでデザイナーとしての責務の「可視化」を達成したいのであって、自分がコードを書くというのはそれの延長線にあるのだ。

なので改めてデザイナーとしての立場に戻ってみると、やることは明確に見えた。なるべく速く雑に実装して早い段階でPdEに共有する。もしUIの妥当性で問題ないのであれば、拡張性と負債が比較的無い実装方法を模索していくという方法だ。別にプロダクトのロードマップを変えてまで実装という行為をしたいわけじゃない。あくまでチームにUIの方向性を提示するためなのでこれでいいのだ。

とはいえ、私自身も今後”綺麗なコード”を書く意識を持ち努力を続けていかなければならない。

インターフェースとしてのデザイン？

こういった活動を続けていくと、UIがシステムとユーザーの界面に機能するだけじゃなく、チームにおける他職種同士を結ぶコミュニケーション上の界面であることに改めて気づく。これについてはSmartHRのProduct Design WikiのUIにも記述がある。

また、SmartHRプロダクトデザイングループではUIを開発時のコミュニケーションにおける重要な界面として捉えている。そのことについてはソフトウェア開発チームにおける界面としてのUIを参照されたい。

UIを設計するためのアイデアや改善の糸口は開発の至る所に隠されているのだ。

「デザインはデザイナーだけに任せるには重要すぎる」というフレーズは前からよく聞いていたが、これについては真実だと思う。このフレーズが意味する通り他の専門家の協力も仰ぎつつデザインをしていくことが重要だ。しかし、今までは職種の間にまだどこか壁があってそれを超えるように努力をしていた気がする。今回の活動を通し、壁を作っていたのは自分自身であり、そもそも壁を作らないことが重要なのだと気づいた。

そしてそれを突き詰めるとたどり着くのはUIを中心にした構造だけではなく、各職種が融けあうような構造なのだろう。

奇しくも「越境」という表現が、それを言う人がまだ近代から「抜けていない」ことの証明になってしまってる。境を作っているのは誰か。それは本人に他ならない。できる人は境を超えたのではなく、はじめからそれを引いていない。上妻世海氏が言うように「カテゴリーを横断するのではなく縦に貫け」だ。

— Manabu Ueno (@manabuueno) December 15, 2018

デザイン行為の執着を捨てる

最後に。冒頭で述べた通り私はUIが好きだし、人並みならぬ情熱をもっていたつもりだ。これまでもずっとUI設計の専門家として振る舞ってきたし、今後もUIを起点にプロダクトの体験を考えていくだろう。だが今期の後半から意図せずデザインに深く関わらないという選択をすることになった。はじめは品質の低下を心配していたがそれは杞憂で、その選択はデザインと他職種の壁を融かし、周りがデザインに関わる余裕を作ったのだ。

デザインプロセスにおいて発散と収束を繰り返すダブルダイアモンドモデルという図がある。自分の状態をあてはめてみると今は発散なのかもしれない。今まで収束するなかで培ってきたデザインに対する執着を捨て、新しい経験や知識を吸収している段階だろうか。もしかしたらいつかのタイミングでまた自分のデザインに対する見え方が変わり集中して造詣を深めるような気もする。だが次はわざわざ「越境」しなくていいように壁がない仕組みを作りたい。

エピローグ

月日は光のような速さで流れ3ヶ月が経ち、私は憂いていました。デザイナーとしてのカルマとの戦いには終わりがないことに。

もう今期が終わってしまいます。私は来期どうなっているのでしょうか。それは誰にも分かりませんし、デザイナーとしてなりたい姿がない私にすら分かりません。ですが、1つ分かるのは今までの私が作り上げてきたデザイナー像がもたらしたカルマを乗り越え、開発者としてチームに融けこみ引き続きプロダクトを作っていくということです。

私はただ強くなりたいのです。雨にも負けず、風にも負けず、複雑に絡みあったドメインや組織の急な方向転換にも負けない強い人間になりたいのです。そして私は幸せになりたいのです。

終

あとがき

この記事はフィクションでしたが、実際にこれを読まれている皆さんはどうですか？正直この物語で書かれている考えをはるか昔から持っている方には稚拙な内容に見えるかもしれませんし、主人公の考えに同意しない方、このような思想だけがつらつらと記述されている文章を嫌う方にとっては、チラシの裏に書くような内容かもしれません。ですが同じような苦悩を持っている方がどこかのタイミングでこのページを見つけ、その方の助けになれば幸いです。

元々この物語を書くきっかけは今期の「スクラムチームへの貢献の仕方をアップデートする」というグループ目標でした。グループからは複数プロダクトへの貢献が期待されていたのですが、中々得意ではない上に、私は天邪鬼な性分なので周りの評価など気にせず逆に1つのチームに潜ってみようと思ったところからこの物語の執筆がスタートしました。実際物語を考える上で最初はどうなるか分かりませんでしたが、思いの外いい方向に転がったので少しはホッとしていますし、この物語の主人公も、きっと彼が属している組織の自由に動ける環境に感謝していることでしょう。

※この記事の内容はフィクションです。実在の人物や団体などとは関係ありません。

著者

Nao Enomoto