STOP✋とりあえず「とりあえずデザイン作ってきますね！」
こんにちは！freeeでデジタルなプロダクトのデザイナー（以下PD）をやっているryotakeです。最近は英語の勉強を始めたはずが気づけばEnglishのVTuber沼に片足をつっこんでいます。
さて、私は新卒から4年ほどUXデザイナーという職種でしたが、去年freeeに入社するタイミングでPDに変わりました。
新しい職種になってまだ1年ですが、1年ながらもPDとしての振る舞いや考え方に結構変化があったな〜というところを振り返りつつ書きます。
ちなみにこの記事は freee Designers Advent Calendar の11日目です。
職種を変えたきっかけ
前職ではクライアントワークのUXデザイナーをやっていました。具体的には新規プロジェクトの立ち上げ系が多く、リサーチからコンセプトを作り体験設計をして、時には概念モデルやワイヤーフレームまで作るという感じでした。
その工程にやりがいや楽しさは感じていましたが、そこまでやるならやっぱりデザインデータを作り開発チームとして世に出すまでちゃんとやりたいなという気持ちがありました。
とはいえ、やはり経験的にパッとUIデザイナー的な職種になることは難しく、自分としてもこれまでの経験を180度変えるよりは軸足を少しずらしつつ広げていくような形で変えていきたいなと考えていました。
なので、freeeも元々はawaさんとのカジュアル面談がきっかけでリサーチャー的な入り口で選考を受け始めたのですが、1回目の選考担当だったmagiさんから「プロダクトデザイナーやっちゃいなよ（意訳）」ということで今に至ります。
おかげさまで今のところは理想としていたUXデザイナーの経験領域も引き続きやりつつ、デザインシステムの力を借りながらデザインデータを作り・・・ということができています。
また、これまではtoC寄りの経験がほとんどだったのでtoBのデザインも割と新しい挑戦でした。
そんな経歴の人間が書いていることを前提として読み進めてもらえればと思います。
PD幼年期「とりあえずFigmaで作ってきますね！」
freeeに入社してPDになりたての頃は、とにかくデザイン（データ）作るぞ😤と意気込んでいました。
そもそもFigmaを実務の中で触った経験も少なかったので、まずは最低限デザインデータを作れるようにならないと！と焦りもありました。
最初に入ったのがFigma上でデザインがある程度進んでいるプロジェクトで、そこにデザイナー交代で入ったこともあります。
引き継ぎのアウトプットとしてとりあえず「とりあえず作ってきますね！」とひたすらFigmaを使ってデザインを作り、チームに展開してまた作り、ということをひたすらやっていました。
自分がUXデザイナー時代に一緒に働いた、かっこいいデザインをドンッ！と出してくるかっこいいUIデザイナー達への憧れもあり、当時はこれが正解だと思っていました。
しかし、改めて振り返るとUXデザイナー時に考え続けていた「価値はどこにある？」ということはもちろん頭の片隅にはあったものの、デザインデータを作ることでいっぱいいっぱいになってしまっていました。
また、これまでは自分で担当することが多かった「なぜ作るのか？（why）」の部分をPdMから受け取りつつ作っていくことや、toBかつ人事労務という経験や知識が少ないドメイン領域でのデザインが初めてだったことなど、不慣れすぎて空回りをしていました。
もちろんユーザーストーリーマッピングやOOUIに基づいた設計なども行い、ただ漠然と作っていたわけではありませんがそれでも作ることに囚われていた記憶があります。
そんな状態で作ったデザインデータはやはりなかなか芯を食わず、開発チームを混乱させたこともあったと思います。
最終的にはなんとかリリースに漕ぎ着いたものの、リリースまでの期間（＝世に何もバリューを発揮していない期間）が長くなってしまったりと反省点は尽きません。
ですが、逆にこの経験があったからこそ不安だったUIそしてデザインデータを作る力はある程度つき、もっと良い方法があるんじゃないか？という考えをめぐらせていく事になります。
また、この頃にもっとレビューをもらってレベルアップしたいなーという想いもあって始めたUI眺める会は今も続いています。
PD成長期「めっちゃ雑に作ってみます」
ほろ苦初リリースを終えた後は、いかに最短距離でデザインを作っていくか？という思考のもと、今作ったり合意しないといけない要素をなるべく雑ミニマムな形で作るということを意識し始めました。
そのために手書きやmiro上でのテキストやシェイプ、既存画面のスクショなどを使った雑ワイヤーフレームでデザインを構築する機会を増やしました。
結果、1人で抱えて作る時間は減り、チームで議論しながらその場で形作っていく時間が増え、Figmaで作り込むのは「どう作っていくか？（how）」がある程度決まってきた終盤に集中するようになってきました。
また、この頃からデザインの要素を分解して考え構築していくこともより強く意識するようになりました。
雑に作るのは決して手抜きではなく、作って進めていく際に余計な検討要素を増やさないためでもあります。
これはクライアントワーク時にも強く感じていたことですが、「それっぽく見えてしまうもの」を作ってしまうと、見えているわかりやすいところに注目が集まってしまい議論が逸れがちです。
そうなると、例えば今はナビゲーションの話をしたいのに各画面の要素や配置に関する意見が出てきてしまったり、骨格の話をしたいのに表層であるスタイルに話題が集中しまったりと、こちらが意図した部分の議論や提案が霞んでしまう事になります。
そういった経緯もあり、提案したい部分の最小限を保った雑なものを量産しながら進めていっていたのがこの時期でした。
雑なものは修正や捨てることも容易なので、サンクコスト的な意思決定の阻害もありません。
チーム内での共有の方法もデザインを作り込んでからではなく全体像は認識を合わせた上でブラッシュアップした部分を随時共有していく形に変わったため、「○○のデザインまだですか？そろそろデザインが無いとエンジニアの手が空いてしまいます」という所謂デザイン待ち状態も減ってきて開発効率も上がってきました。
さらに、「デザインの要素を分解して考え構築していくこと」に慣れてくると、リサーチの解像度も高まってきました。
インタビューやユーザビリティテストをしている中で、今検証したい項目はなんだっけ？という問いや仮説をより細かく考えられるようになったので、そのために必要なプロトタイプの範囲もシャープに判断できるようになりました。これはPDになってから得られた感覚です。
PD成熟期「まず何を作るか認識揃えさせてください」
ここからは今も試行錯誤中な部分ですが、とりあえず考えなしに「とりあえず作ってきますね！」ということもほぼ無くなりました。デザインデータを作る工程もかなり圧縮されてきています。
その代わり、前述の雑なワイヤーフレームなどを作るさらに前に「このリリースで売りたいものは何か？＝何を作るのか？（what）」をチームで揃える工程を挟むようになりました。
whatの認識合わせが甘いことが品質やスピードを低下させていることに気づいたからです。
ユーザーストーリーなどを用いてwhatの認識合わせに努めてはいましたが、今取り組んでいるtoBの複雑なドメインになるとそれだけではユーザーがどういった「仕事（成果とその成果のための活動）」を達成できるべきなのかまでの粒度が若干見えずらい状態でした。
そのためwhatの部分は若干不明瞭なまま、howの工程と一緒くたに進めてしまっていたのです。
howの工程でwhatも認識を進めようとしてどれだけ雑にワイヤーフレームを作っても、そこにはUIという形=デザイン観点のhowが色濃く出ます。
それを見ると開発チーム的にはやはり「これをどう実装するか？」＝実装観点のhowで考えてしまいがちな状況になりがちです。
そうなると、そもそもMVPとして満たすべきwhatはどこまでだったんだっけ？があやふやになり後半に実装工数＝howでリリース単位を区切ることになり、削った部分はいつあるかわからない「2ndリリース」に持ち越され・・・となってしまうよねということになりがちです。
また、whatを揃えないままにデザインのhowで包括して進めてしまうことが、それぞれの専門的なhow＝チームのクリエイティビティを半減させているのでは？とも思うようになりました。
whatの認識が揃っていれば、各職能が「そもそもそれって〜」と批評的に考え新しい提案をすることもできますが、専門領域ではないhowだけを持ってこられるとそれも考えにくくなります、
そういった課題感から、PdMやデザイナー、エンジニアがそれぞれ考えるhowではなく、共通の認識としてwhatを管理することの大切さが見えてきました。
なので今は、同じ粒度で議論できるユースケースモデルやドメインモデルなどモデリングをチームでワークショップ的に行い、そのモデル自体やそこから書き起こした要求をwhatの拠り所として管理する形を取り始めています。
そうすることで、デザインや実装方法のような個別のhowだけに囚われず、チーム全体で「これは作りたいものを満たしているか？」を批評的に見やすくなり、why・how・whatの3つの観点を行ったり来たりしながら品質とスピードを上げれるのでは？と考えています。（ここは今実践中の部分）
また、ユースケースやドメインのモデルで認識が揃っていると、そのままそれらをオブジェクトや操作としてデザインの設計にもスムーズに移れる（かつ認識はすでに合っている）ようになり、少なくともデザイン工程に関しては効率アップを感じています。
幸いfreeeには同じ課題感を持っていたりこういった進め方に強いデザイナーもいるので、実践と学びのサイクルを回しつつ日々試行錯誤できています。
まとめ
気づけば、自分がPDになって1年間の振り返りをただただ書き連ねた私的な文になってしまいました。
初期はPDになったしfigmaを使ってかっこいいデザイン（データ）を作るぞ〜という1人での意気込みがメインでしたが、とりあえずでデザインを作ってみてもあまりうまくいかずより良い方法を模索する1年でした。
もちろん状況によっては不確実性が高くてもとりあえず、ではなく意図的に「とりあえずデザイン作ってきますね！」と先陣を切りバンッ！とデザインを作ってプロジェクトを前進させていくことは必要ですし、それはデザイナーならではの大きな武器だと思います。
作るものの性質や開発チームの成熟度によってはそれでガンガン進めるパターンも当然存在します。
ですが、少なくとも私がこの1年間やってきた状況ではその効用よりリスク（デザインが出てくることで実現方法に意識が引っ張られる）面での失敗が多く、それ以外の方法を模索してきました。
最近はPDという立場から、より良い開発チーム・プロセス・クリエイティビティに貢献して良いものをバンバン生み出すぞ〜！と別の意気込みもすくすく育ってきています。
そんなこんなで、PDになってからの1年はとっても充実していました。来年はもっと良いモノを作れるようになるよ。ね、ハム太郎！
今週の freee Designers Advent Calendar は木曜日まで人事労務チームのデザイナーが続きます！
明日はチームNo.1のガッツとアウトプット力を誇るhinachanが担当です。お楽しみに！
この記事が気に入ったらサポートをしてみませんか？