UIデザイン×PdMで広がるデザインの可能性
こんにちは！dely株式会社でクラシルプロダクトのUIデザイナー兼プロダクトマネージャーをしている小林和央 (@kazkobay) です。最近はUIデザインとプロダクトマネジメント両方やる形で仕事をしています。
今回は自分がUIデザイナー出身がPdMに挑戦していてメリットに感じていることを実際の仕事の経験からまとめてみようと思います。
今回は各章ごとにPointを設けてますので、ざっと読みたい方はそちらだけ読むのをお勧めします。
この記事はdely Advent Calendar 2019の10日目の投稿です。https://qiita.com/advent-calendar/2019/dely
昨日はフロントエンドエンジニアの alluser（本名岡本）さんが「思わずへ〜ってなったTypeScriptのトリビア10選」という記事をアップしてくれました。自分が読んでも正直わかりませんでしたが、とりあえず悔しかったので「へ〜」とは言っておきました！興味のある方は読んでみてください！
目次
・はじめに、PdMとは
・PdM×デザインの利点「プロダクト面」
・PdM×デザインの利点「プロジェクト面」
・お互いの言っている事は、ほぼ伝わっていない
・部署の枠を超えていいプロダクトをつくるために
・デザイナーがPdMをやる上で一番大事なこと
はじめに、PdMとは
PdMとは何かについて簡単に書いておくと、施策を考えたり、関係者の調整をしたり、実装する上で優先順位をロードマップを決めたり、プロダクトに関する事の意思決定+実現に必要な事をなんでもやる「マネージャー」という名前を冠した実行者というのが実態かなと思っています。
これに関しては手前味噌ですが弊社VPoP奥原の記事がよくまとまっているので、詳しく知りたいという方はぜひ参考にしてみてください。
PdM×デザインの利点 「プロダクト面」
では、表題にもある、UIデザイナーがPdMをやるに当たって、業務の中で具体的に活かせる事といえばどんな点でしょうか？
まず僕が考える１つ大きな点は、デザイナーとして自分が目に見える部分を作れるという事だと思っています。例えばこれはプロダクト面では以下のようなメリットがあると思っています。
UIデザイン×PdMの1番のメリットは、もっとより良くするための設計や表現を自分自身が作る事によって、プロダクトの印象と体験面を自分のボールとして扱える事だと思う。形にしてみるとやっぱり違うって事もあるし、何度も違うアプローチで試せるのは自分が作る大きい利点。
— 小林 和央 / dely (@kazkobay) December 5, 2019
つまり、特定の機能を作ろうとする時に、通常のPdMであればデザイナーに簡単なワイヤーモックや手書きメモなどを渡して、UIイメージを伝えたり、ドキュメントで施策意図を伝えて検討してもらうというのが通常のフローだと思うのですが、UIデザイナーがPdMを兼務すると基本的に自分が手を動かして作る事ができるので、印象表現や別の導線や設計の方がいいかも？と作りながら、自分で思考できるのが利点です。
しかも、自分で機能で達成したい目的が完全に把握できているので、機能とUIデザインが一貫してブレない形を実現しやすいメリットもあります。
その結果達成したい目的に対して、意思決定者の意図が見えなく、そもそもUIを変える事が正しいのか？とデザイナーがモヤモヤしたり、逆にPdM側が自分の想像しているデザインと違うものが出来上がってくる、といった事態を避ける事ができます。
delyでは↑の様にslackにシェアしながら作っていくことがあるのですが、こういった方法でUIを作っていると、その施策に関わっている他の人アイディアやアドバイスが他の方から貰えたり、
「もっとよくするにはそもそもこうなんじゃないか？」自分の中でも思いつきやすかったりするので、おすすめです。
基本的に自分の作ったものは自分のバイアスが入っているので、
できる限り早い段階で思考を形にして、誰かに壁打ちした方が結果的に良いものに繋がる事が多いなと常日頃から思っています。
◆ Point
・プロダクトの印象と体験面をコントロールできる。
・意思決定者と制作者の摩擦が無くなる
・目的を第一優先にして、施策そのものを変更させたり、より効果的な設計を作りやすくなる
・UIをすぐ形にして関係者に共有できる
PdM×デザインの利点「プロジェクト面」
また、UIデザイナーがPdMをやる上でのメリットはプロジェクトマネジメント観点でもあり、具体的にはデザインの制作スキルをステークホルダー感との合意形成や、開発ゴールの認識すり合わせにも活かすとことができます。
プロダクト開発において合意形成を様々な部署と取らなければいけないPdMは様々な職種のステークホルダーたちと合意形成を取りながら進めていかなければなりません。そのためここでもデザイナーのビジュアル化して伝えるという事が役立ったりします。
例えば今プロジェクトを進める中でステークホルダーとの合意形成はfigmaのロードマップを用いて行なっています。
モザイクだらけでわかりにくいですが、このロードマップの良いところは、
◆ Point
・スクショ一枚ですぐに優先順位が伝わる
・開発スケジュールの進行に応じて柔軟に変更できる
・figmaで作る事で、URLを渡しておけば誰でも確認できる
・見やすさ重視なので、どんな職種の人がみても伝わる
などなど、スピードを持って開発を行い、優先順位が変わる事もあるスタートアップに対して、関係者間の確認を随時取りやすい手段なのかなと思っています。
このロードマップは弊社CXO坪田さんの開発全体のロードマップを参考にして制作しているので、ぜひ読んでみてください。
基本的にお互いの言っている事は、ほぼ伝わっていない
先述したようにプロダクト開発において状況は都度変化します。
自分は今マーケティング部の部署と向き合いで仕事する事が多いですが、かなりの頻度で、開発状況のシェアやプロダクトに対する違和感の擦り合わせを行うようにしています。これは対面でもslack上でも、できる限りわかりやすく伝える事を心がけていて、基本的にお互いの言っている事は伝わっていないという前提の元でコミュニケーションしています。
その中で有効だったなと思った点は以下です。
◆ Point
・意識的に人と話す機会を増やし続ける
・重要な事は何度も繰り返し伝える
・オープンスラックで議論のサマリをすぐに残す
・図やビジュアルを使って説明する（印象に残りやすい）
・UIのロードマップで今後どういう開発をしていくのかを示す
ちなみに前職では、東京/名古屋/大阪という遠隔チームでの開発だったので、仕様書やUI制作の意図をできる限りビジュアル化して伝えたりしていましたが、こちらも意図を伝えやすくするには有用でした。
↑遠隔開発の時の事例
部署の枠を超えてチーム一丸でいいプロダクトを目指す
多部署とのやりとりを行う立場の人に取って、ネックになるのは、多部署との認識の違いや、仕様の違いによって起こりうる問題です。
実際に出来上がったものが認識として違った、思ったような形になっていなかった、などステークホルダーが増えれば増えるほど、こういった問題は起こりやすいです。
その中で有効だった点は、当たり前のような事かもしれないですが
特に以下の点でした。
◆ Point
・プロダクトに関する結果やデータは部署を超えて全部共有する
・プロトタイプや開発β版など触れるもので共有する
・β版が出来上がったらすぐに共有して気になった点を出し合う
・プロダクトの譲れない点と収益ポイントの認識をきちんと話し合う
↑開発中のデバッグ版シェア例
↑分析数値のシェア例
こうする事で数値を追う部署、開発を担当する部署、それぞれ責任のなすりつけ合いを部署間で行わず、チーム一丸としていいプロダクトを目指す雰囲気をお互いが作っていく事が非常に重要だと思っています。
初期は全員同じ方向共有出来ているけど、人数が増えると徐々に難しくなる。そこで認識を合わせられる方法が必要で、そういった意味で見える形に落とすデザイナーは中〜大組織において、各職種を繋ぐ接着剤やファシリテーター的な役割を担いやすいポジションになる。これが１つのデザインの役割でもある
— 小林 和央 / dely (@kazkobay) December 1, 2019
プロダクト開発とマーケティングは切っても切り離せないものなのに、他社の話を聞くと意見がすれ違う事が多い気がしている。原因は同じ情報を共有して目線合わせをしている頻度と具体的に見える形にデザインしていない問題なのかと思ってたりする。
— 小林 和央 / dely (@kazkobay) December 1, 2019
デザイナーがPdMをやる上で一番大事なこと
ここまでいろいろとデザイナー出身の人がやるメリットを書いてきましたが、大前提としてデザイン出身のPdMは実装やデータ分析部分に関しては弱いです。これはソフトウェアプロダクトを作る上で重要な要素なので、そこはどうしても他のエンジニアさんの助けを借りる事が必要になります。
当たり前ですが、いいプロダクトを作るにはどうやっても、1人の力ではうまくはいきません。
したがって、わからない部分は素直にわからないと聞けたり、力を借りられる関係や、信頼される事ができないとデザイナーでPdMは務まらないと思っています。そのためには自分自身でまず勉強して体験してみることも大事ですが、何よりもまず、誠実でこの人はフラットに会社とプロダクトの事を考えている。ときちんと思ってもらえることが非常に大事だと思います。この点はエンジニア出身のPdMよりもより大事にしなければならない事なのかなと個人的には思っています。
◆ Point
・ デザイナー出身のPdMは基本的に実装部分の知識は弱い
・ある程度話せるレベルでの実装知識や、見積もり精度、データ分析の知見などは高める努力をする
・わからない部分は素直にエンジニアさんに頼る
・困った事を聞ける関係や、信頼される関係性ができないと、そもそもデザイナーでPdMはできない
・そのためにまず何よりも誠実でフラットで信頼される事が大事
一緒にプロダクト作りをしてくれる仲間を募集しています
もっと会社のことを詳しく知りたいという方はぜひこちらの会社紹介資料やインタビュー記事をどうぞ。さらにもっと詳しく聞きたい方はTwitterなどで直接連絡頂いても構いません！
以上 UIデザイン×PdMで広がるデザインの可能性でした！
明日はiosエンジニアのナンシーさんが
「Combine と RxSwift を比較してみた」というタイトルの記事を発表します！お楽しみに！