多様な環境で作り方をデザインする
こんにちは！freeeでプロダクトデザイナーをしているryotakeです。
この記事は、先日freee技術の日2024というイベントで登壇した内容をもとにした書き起こしです。日々様々な開発プロジェクトに関わる中で考えていた、自分なりのデザイナーの振る舞い方を話させていただきました。
当日の発表資料は以下です。書き起こすと結構な長さになったのでスライドをパラパラめくって見てもらえるだけでも嬉しいです。
また、YouTube配信もあったのでアーカイブ動画も残っています。
他にもエンジニアやPdM、QAなど様々な方の登壇があるのでもし良ければ見てください！
多様な環境で作り方をデザインするというテーマで発表させていただきます。よろしくお願いします。
今日お話ししたいことは、デザインをデザイナーで閉じない、ということです。
デザイナーあるあるとモヤモヤ
事業会社のデザイナーをやっていると、既存プロダクトの小さい改善から新規プロダクトの立ち上げ、顧客への提案活動など様々なプロジェクトに参加する機会があると思います。
そういった機会に日々ワクワクしながらやるぞ！とどんどん首を突っ込んでいくと、気づけばいろんなチームから「いつデザインできますか？」「・・・・逆にいつまでにできないとやばいですか？」みたいなスケジュール調整をしていて、いつの間にかいくつかのプロジェクトのボトルネックになりがち、みたいなことがあると思います。実際、自分は過去に掛け持ちしすぎてコミュニケーションが後手後手になり、リリース遅延しかけてしまった経験があります。
リリース遅延しかけたけど間に合ったね良かったね、で終われば良いですが、こういう時は往々にしてしんどくてもやもやしてしまいがちです。このようなもやもやはリリースできたとしても積み重なってしまうもので、だんだん組織やチームに対して「なんであの人分かってくれないんだ」とか「どうして周りはこうしてくれないんだ」とどんどん卑屈になってしまうことも時にはあります。
そして、ここまでデザイナー視点で話してきましたが、これは職種や組織規模に関わらず組織のどこにでも発生しがちだと思います。開発組織とビジネス組織の対立なども良く聞こえてくる話です。
コミュニケーションの不確実性の存在
なぜこういうことが起こってしまうのだろう？と考えていた時に、エンジニアリング組織論への招待という本に腑に落ちることが書いてあったので、引用させてもらいつつご紹介できればと思います。
原因はずばり、複数人で何かを行う場合、必ずそこにコミュニケーションの不確実性があるからです。この不確実性は、人は他人を完全には理解できない、意図が伝わるとは限らない、理解されても予想通りに行動するとは限らないという3つに分解されます。
今回も私の中で考えてることを発表という形で資料を作り話していますが、意図が完全に伝わるかは私にはわからないですし、例えそれが100%伝わってすごい共感いただいたとしても、その人が次にどういう風に行動を変えてくれるのか、あるいは変えないのかみたいところは分かりません。他人のことなんて分かんないよね、という当たり前の前提が人間にはどうしてもあるという話です。こういった不確実性があるので、
”エンジニアリングは、複数人のチームで何かを実現していく工程です。そのため、1人の人間ではなかなか起こらないはずの不合理な行動が、組織では発生してしまうのです”
とあるように、複数人で何かをすると自分の中では最適な行動が他の誰かから見た時に実はそれが不合理な行動になってしまっている、ということが起こってしまいます。
また、もう1つ紹介するのがハンロンの剃刀という警句です。
“無能で十分に説明のつくことを悪意のせいにするな”
情報伝達の努力や能力の不足だけが原因で生じた悪いことでも、相手に悪意があったからではないかと邪推してしまいがちなので気をつけましょうね、という言葉です。
我々人間は、そもそも他人のことはどうしても分かりきれず、さらに分からないと悪意を見出してしまう性質まであるのに、さらにエンジニアやデザイナーなど専門性が分かれている他人同士で、さらに複数のチームを掛け持ちしたりといった形で日々開発しているというジレンマを抱えているわけです。そうなれば各所で不満が出てしまうのはむしろ自然の流れでもあるわけです。なので、
“いかにしてコミュニケーションの不確実性を減らしていくのかというのが、エンジニアリングにとって重要な態度となります。”
とあるように、その流れに抗っていくことが求められます。
デザイナーとしてデザインの透明性を作る
では具体的に、コミュニケーションの不確実性を減らすためにキーとなるのが情報の透明性を作ることと書かれていました。これを意訳すると、
意思決定とそれに関わる情報が正しく整合性を持って伝達されるよう継続して努力すること、情報の公開が情報の透明性を作るわけではありません。
とあります。これを自分に置き換えてデザイナー視点で解釈してみて、デザインの透明性として自分の中で戒めとしたわけです。
デザインを進める中での情報が正しく整合を持って伝達されるよう継続して努力すること。デザインを渡してただ説明すればそれで透明性ができるわけではないぞ！！！
前振りが長くなりましたが、こういった背景で「デザインをデザイナーで閉じない」に繋がってきたわけです。これは、デザイナーである私自身がデザインというブラックボックスを透明化する努力をして、チームの不確実性を下げて成果を最大化するための努力をもっとしていかなかんなという風に思ったという話になります。
ここから具体的にやってきたことを大きく3つご紹介します。
透明化のための試行錯誤
デザインを含めた開発プロセスをチームで定義する
1つ目は「デザインを含めた開発プロセスをチームで定義する」です。大元の課題感は、PMが企画してEngが見積もりをしてそこからデザイナーに依頼とかアサインが入って、デザイナーがデザインプロセスを回して、できたデザインデータを納品して、またここで開発プロセスが走っていく、のような形でプロセスが分離してしまっていたことです。
この状況を避けるために、開発チームの中でデザイナーが〜とかエンジニアが〜とかではなくそもそもプロダクトを作るために我々が何をやっているのかを整理しましょうということを一緒にやりました。
工夫ポイントとしては、自分たちの仕事を理解してアウトプットではなく仕事の連鎖を描くということです。「仕事」というのは「ここでは何らかの成果とその成果を出すために行う活動のまとまり」を指しています。雑な例ですが、UI設計という活動はユーザーにとっての価値や行動みたいものを材料としてUI設計という活動をし、デザインデータという成果を出しています。
そして、このUI設計という活動で生み出した成果であるデザインデータが、次の仕事の実装という活動の材料になって、この実装によってプロダクトという成果が生み出されていく。何かを材料として何かの活動で次の成果を生み出し、その成果を材料にまた活動によって成果に変換して・・・という仕事の連鎖を日々我々はやっているわけです。
スライドの図も小さくて見づらいですが、最初の材料のビジネス要求から始めて、それを業務モデリングという活動によって業務要求とかスコープを成果として生み出しています。そして次はそれを材料にして次はざっくりデザインや仕様を生み出していき、という連鎖を描いています。
こういったプロセス設計ではアウトプットや成果物ベースで繋げていくことが多いと思います。ですがそれだけの定義だと、「PRDが書けたらデザインデータを作る流れになっているけど、PRDに何が書かれていたらいいんだろう？」がチームで認識が揃いません。そうなると結局PMの方が一生懸命PMの視点だけで考えたPRDができ、チームとしていまいち理解できないままデザインや実装がそれぞれの職種の目線で進んでしまい、ということになりがちです。
自分たちの仕事の連鎖に着目してチームで認識を揃えてみたという話でした。これによってデザインも含めたプロセスが1つになったので、デザインの透明化が1つできたかなと思います。
職種に関わらず馴染みがある成果物・プロセスを選ぶ
2つ目が「職種に関わらず馴染みがある成果物プロセスを選ぶ」ということをやっていました。先ほどのUI設計（雑）を例にすると、このUI設計という活動のためには材料の一つとして「価値」が必要になっています。そのため、UI設計の前に「価値」を成果とする活動が必要です。
少し極端な話ですが、以前UXデザイナーだったのもあってやはりパッと思い浮かぶのはKA法で価値マップ〜とか構造化シナリオで〜とかUXデザインのプロセスでしたが、最近はプレスリリースや提案資料のような職能に限らず分かりやすい形で作ろうとすることが増えました。
これは前述のプロセスの整理などによって、「価値」が成果としてできればそれが材料となって次UI設計に繋がってデザインデータができるよという認識がチームで揃っている状態ができれば、それを生み出す活動自体は別に何でもいいよねとなったからです。何でもいいならデザイナーしか分からない形ではなく、プレスリリースなど誰が見ても分かりやすい、あるいはフィードバックしやすい形を用いればいいよねとなりました。
プレスリリースを「いきなり作りましょう！」言ってもポカンとなると思いますが、プレスリリースによって次の工程であるUI設計のために「価値」を生み出したいんですと認識が揃っていれば、やる目的が揃うので一緒に取り組みやすくなりました。
また、その考え方に慣れてくると、他にも同じ発想でいけるじゃない？となってきました。今まで情報設計は自分の中で完結しちゃっていましたが、これが次のデータ設計っていう活動の材料になるということまでわかってるのであればそれはもう一緒にやっちゃった方が良くない？とか、あるいはエンジニアがやる形に合わせた方が良くない？と考え始めました。具体的には、エンジニアにとって馴染みがあるユースケースやドメインのモデリングで情報設計も一緒に進めたりなどです。これによって認識のずれが減ったり、別の活動を一緒に並行して進めるみたいなこともできるようになってきました。これも1つ、デザインの中身を透明化することでチームの成果あるいはスピードみたいなものを上げれたかなと思っています。
figmaは必要になるまで使わない
最後3つ目は「figmaは必要になるまで使わない」です。figmaは僕も好きなツールですがデザイナー属人化を進めるリスクもあると思っています。
プロダクトデザイナーになりたてのとあるプロジェクトで、意気込んで要求とかが柔らかい初期段階から「もう1回figmaで作ってきますね！！」と言って作りまくった時の話です。
作った結果フィードバックをたくさんもらえたのは良かったのですが、それを全部figmaのデザインデータに反映して管理し続けてしまいました。その結果、デザイナーである僕しか触れないfigmaが最新の仕様状態になってしまい「最新の仕様はどこですか？」「figma見てください」という状態になり、自分が動き続けないとプロジェクトが動かないみたいな状況になってしまいました。つまり、デザイナーの私が完全にボトルネックになってしまったのです。これは別名「無限デザイン編」と呼んで笑い話にしてますが、当時は結構すごいプレッシャーで苦しい状況でした。
もう1つ、figmaで作るリスクとしては細かい部分が気になってしまうところにあります。freeeはデザインシステムが整備されているのもあり、パッと見精緻なものがパッと出せちゃいます。そうなるとみんな細かい部分がどんどん気になってきてきます。細かい部分の議論を重ねた結果「あれ、そもそも今回って何をリリースするべきなんでしたっけ？」とそもそもの部分が気付けば迷子になってしまったという怖い状況も起こったりしました。
これを避けるために、最近はデザイナー以外も触りやすいmiroやfigjam上で手書きや簡単な図形などを用いて雑なワイヤーフレームを素早く作り、細部が気にならないレベルで進めるようにしています。やはりこれも仕事の連鎖を意識すると、実はfigmaのデザインデータとして全てが出来上がりきってる必要があるのはかなり後だったりします。なので例えばまずは扱う情報だけ、次はレイアウトだけ、のようにその時々で決めるべきことやイメージをすり合わせるべき部分に集中できる状態を作りそれを積み上げていく意識をしています。
もう（上の画像のような）すごく雑なレベルで結構な量を描き進めています。このような粒度でも認識が揃えられるのは、今取り組んでいるのがtoBの業務システムであることと、社内のデザインシステムがある程度成熟しているからです。最終的なUIだけでなく途中のプロセスでもデザインシステムの恩恵を受けています。
この取り組みでもまた、デザイナーしかわからない、触れない状態を減らすことでデザインの透明化ができたと思います。
やってみてどうだった？
ここまでデザインを透明にするための試行錯誤を３つ紹介しました。
やってみると、冒頭のあるあるのようなボトルネックになってしまうことは減ってきたと感じています。また、職種を跨いだチームの連携が深まり開発のスピードや品質が上がってきたと感じています。まだこれらは個人や一部チームでの肌感レベルなので、今後は実際どれくらい改善になってるの？というところを検証していきたいと思います。
以上、デザインをデザイナーで閉じないこと。でした。これは決して責任逃れではなく、責任は持ちながら、不確実性を減らすための努力をしようということでした。
発表は以上です。ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？