役割分担の重要性
こんにちは、microCMS FMです。
この番組は、microCMSの中の人が、 いろんなトピックについて雑談する番組です。
最初に自己紹介ですけど、 僕がプロダクトマネージャーの平松です。
はい、自分はmicroCMSシートを やってます大西です。よろしくお願いします。
お願いします。
今日のテーマですけど、テーマは、 デザイナーとプロダクトマネージャーの役割分担
っていうので、しゃべってみたいと思ってます。
おお、なかなか壮大なテーマです、今日は。
結構抽象的なね。ゴールドではないですけど。
まず、あえて自分、全くその領域じゃない 自分の方からしゃべり始めますと、
なんかそういうのがあるんですか? デザイナーさんとPMの領域が
被ってたりとかっていうのがかなり、 一般的にもそういう話題があるんですか?
そうだね。結構本とかノートとか、 ウェブサービスのノートとかでも、
たまに議論になってるかなというポイントですね。
おお、なるほどね。
実際、やってることは割と近かったりもするんですよね。 デザイナーとプロダクトマネージャーって。
ユーザーにヒアリングしたりとか、 仕様を決めたりとか、
あと画面設計考えたりとか。
割とどこをどう澄み分けたらいいんやっていうのは、 自分がプロダクトマネージャーになったときも
あんまりわからなかった。
ああ、なるほど。
ちょっとあれですかね、しゃべり始める前に、
平松さん、プロダクトマネージャー いつからやり始めたとか、
その辺を一回視聴者向けに自己紹介してもらっていいですか。
今、3年やってないか。
2年ぐらいやってます、プロダクトマネージャー。
この前はエンジニア10年ぐらいやってた。
組織による違い
ものづくりはずっとやってるけど、
いろんな職種と絡みながらものづくりする みたいなのはここ数年って感じですね。
会社の状況的に言うと、
マイクロCMSの共同創業者にデザイナーの人いるので、
結構デザインは力入れてるというか、
プロダクトのコアにもなってるみたいな感じですかね。
使いやすいサービスを作ろうみたいなのは 意識してやってるところっていう感じですね。
ありがとうございます。
じゃあどこからいきますかね。
さっきの領域重なる部分が多いみたいな。
領域はかぶりますよね。
平田くんとPMとは、デザイナーとは みたいな話になるんですかね。
そうだね。
プロダクトマネージャーのコミュニティとかもあるんで、
話聞いたりするけど、会社によってだいぶ違うっていう印象で。
PMの仕事に関してもってことですね。
役割分担かな。
役割分担が全然違う。
ここまでは、例えばUIのラフとかを 書いたりすると思うけど画面。
ラフを書くのをプロダクトマネージャーがやるか、
それはデザイナーの仕事だからプロダクトマネージャーが 立ち入るところではないみたいな。
結構バラつきがありますね。
確かに。
でかい組織、前職年は我々Yahooだったんですけど、
Yahooとかだとデザイン戦略じゃないですけど、
デザインのトップの人みたいな人もいたりして。
色はこういうのを全社的に使いますとかね。
ブランドでいきますとか。
そういうのもあれば。
そこまでやってないような会社もあったりしてますけど。
確かに。
結構チームの規模、組織サイズにもよる。
いろんな変数だよね。
我々で言うと大体全社員20人ぐらいですか。
エンジニア半分、ビジネスサイドといいますか、
バックオフィスとかも含めてあと半分ぐらいっていう感じですね。
プロダクト開発に関わってる、
インフラだけやってるとかそういうのは省いて、
見た目作ったりとか新規の作るような人たちで言うと、
7、8人とかですか。
実際行って動かしてっていう感じ。
広く見積もって。
10人ぐらいかな。
コミュニケーションとコラボレーション
10人ぐらいがそういうことをやってるという感じの規模感ではあるというのを伝えていきますか。
結構状況と違うけど、
自分なりにたどり着いた結論。
結論から。
プロダクトマネージャーとデザインどう役割を分けるか。
チームによる。
意味ないんですけど。
っていう結論で。
ただ、それだけだとあまりにもなので。
デザイナーって結構広いと思います。
UXリサーチャーみたいな人もおれば、
UI作りの人もおれば結構フロントエンドエンジニアと近いような人もいるし。
確かに。
でも、その領域の専門家ということなのかなと思うんですよね。
はい。
プロダクトマネージャーはジェネラリストなんで、
どれをやるというよりは全体的にバランスよく見て判断したり決定するという仕事が多い。
構成したりとかね。
ここの隅分けを意識しつつ、
得意な人いればパスしたらいいし、
誰もやる人いなかったらプロダクトマネージャーがやるっていう。
空いてるボールを、落ちてるボールを拾うみたいな動きをプロダクトマネージャーしたらいいのかな。
ところが自分もたどり着いたところですね。
なるほどですね。
フォーカス領域ね。
そうそうそう。
デザイナーさんのフォーカス領域って、
それは結局、UXリサーチまでやるのがデザイナーの仕事なんですっていう派閥もいれば、
UI作るのがメインな業務だよねっていう人もいれば。
今マイクを示すとだいたいどういう隅分けなんですか?
そうだね。
最初、機能をどういうのを作るか考えるみたいなところは、
自分がプロダクトマネージャーがやってる。
その後、どういう画面とか体験として提供するかみたいなところはデザイナーと相談しながらやってる。
相談ね。
ある程度そこで定まったらUIに落とすところはお願いして、
フィグマ作ってもらって、それ見ながら抜け漏れないか一緒に確認するみたいなことですね。
そこが出てきたらエンジニアに渡して、
エンジニアに渡してというかエンジニアに入ってもらって、
作りながらこういう風な設計の方が作りやすいとか、
技術的な制約とかも検討しながらさらに詰めていくみたいな。
大体そういう流れですね。
はい。
結構、聞いてる限りはすごい、
それに落ち着いたなら結構良さそうやなという気は。
叩きをPM作って、叩きというか最初の部分をPMの人が作って、
デザイナーさんと相談しつつ、
仕様を詰めて、
デザイナーさんだけが、
というかPMが絶対できないなというUIのデザインのところ。
そこの領域に踏み込んできたら全部お願いするっていう。
そういう一つありですよね。
自分はもうここのスキルは全然ないというとこまでは一緒にやるけど、
それ以降になってくると全てお願いして終わり。
だからデザインについて一緒に考えるみたいなのはそんなにしないって感じですか?
もうデザイナーにお任せやな。
特にね。
ラフを書いてた時期もあるんですよ。
手書きでこういう画面みたいな、iPadで書いて、
時期もあったけど最近あんまりやってなくて。
なんでかなと考えますと、
割とデザイナーとの連携が上手くなってきたからだと思う。
なんでラフを書いたかというと、
こういうイメージですって伝えるためやったのかなと思って。
実質でラフ無視してUI組まれたりとかもあるんやけど、
それ全然いいんやけど。
なんかこういう風にしたいですよとか、
こういう配置がいいと思ってますよみたいな、
コミュニケーションのツールとしてラフを書いてた。
みたいな感じで書いてたんやけど、
もうそれなくても冒頭で割とイメージ伝えるように今なってたんで。
役割分担の重要性
お互いのね、お互いの理解やと思うけど。
そうなるといきなりフィグマ作って、
よく喋ってもできるのかなっていうところで。
やっぱプロジェクトマネジャーが全部考えない方がいいなと思ったのは、
他の画面だとボタンってこういう風になっててとか、
コンポーネントの設計的にこういうモーダルを使う方がいいとしててみたいな、
一貫性保てるためのルールみたいなのがあるよね。
それって1画面だけ見てるとあんま分からなくて、
全体の体験設計みたいなのを、
うちだとデザイナーが見てるから、
そこは任せた方がクオリティ高いのできるなみたいな感じですかね。
うん、確かにそうです。
結論はチームによると。
今マイクロソフトではいい感じにコミュニケーション取ってきて、
一旦いい感じに落ち着いてるってことなんですかね。
落ち着いてます。
いいですね。
ちょっと人数増えてきたりね。
プロダクトマネージャーも複数になってきたりしたらまた変わると思うんやけど、
コミュニケーションと信頼関係
基本的にはプロダクトマネージャーはジェネラリストで、
デザイナーは領域のスペシャリストみたいな、
ベースがありつつお互い会話みたいな。
平松さんはエンジニア経験あるPMですけど、
エンジニアの領域にめちゃ踏み込んでっていう感じは別にしないですもんね。
エンジニアはエンジニアの得意な領域があるから、
そこはエンジニアにお任せすると。
俺がデータベース設計とかしだすとおかしくなるよね。
そう言われると確かに。
デザインもUIデザインみたいなのに関しては、
皆育ってデザイナーさんに任せるよねっていう感じに落ち着きますか。
データベース設計とかって技術全く知らない人って何も言えないと思うけど、
UIとかって割と言えちゃうやん、色とかボタンとか。
確かに。
全員に開かれてるというか。
見た目のことなんでね。
ボタン右上の方がいいんじゃないとか簡単に言えますもんね。
ノーションだとこうなってるよとかね。
材料として言う分にはいいんやけど、イメージ伝えるために言う分にはいいんやけど、
最後は一貫性とかね。
より見えない部分でめっちゃ支えてるものがあるからデザインって。
そこはプロにお任せかなという。
それも結構デザイナーさんの信頼関係というか。
このデザイナーさんだったら絶対大丈夫みたいな。
本当に多分中には絶対に右上のようにボタンを置いた方がいいのに、
左下にボタンを置くデザイナーさんとか多分いるかもしれないですよ。
でも今はそうじゃなくて、めっちゃちゃんと信頼できるというか、
めっちゃクオリティ高いデザインを毎回作ってくれるっていうので、
だんだんそこまで言わなくてもいいかみたいな感じになってきたとか。
そういう積み重ねみたいなのもありますよね。
いきなりはうまくいかないから、ちょっとずつ擦り合わせてみたいな感じだよね。
左下にボタンを置く方がいいと思うのを、なんでなのって聞くっていう。
でも仕様の詰めるところになったときに、
デザイナーさんと一回話してみたいなとか、
そういうすごい良いですよね。
考えたんでデザインお願いしますじゃなくて、そこは滑らかに繋いでいくというか。
それは大事そうですね。
めっちゃ簡単なやつやったら考えるけどね。
考えてデザインお願いしますっていう時もあるけど。
複雑で5パターンぐらい解決方法あるやつとかは。
自分が考えちゃうと手戻りあるっていうイメージですね。
そこはエンジニアの技術的なところもそうですね。
仕様を考えたけど、結構ヘビーな仕様の時は技術的な相談というか、
こういうのをほんまに作れそうかみたいな。
ちょっと難しそうって考えちゃったら仕様を変えたりとか、いつもしてますよね。
ほんまに一緒やね。
確かに。
いろんな人とのちょうど中間にいるPMならではの悩みと言いますか。
そうだね。
PMの仕事って言ってもちょっと話ずれちゃうかもしれないですけど、
PMの仕事自体もいろんな流派がありそうですね。
ちょっとこの話終わらんかもしれないけど。
あまり返しにやられちゃうからね。
でも元々機能を作る上でこういう問題を解決したいみたいなのがあると思うから、
デザイナーこうしたいっていうのでその問題が解決できてないみたいな時はやっぱダメ。
折れてはいけない時もあると。
確かに。
任せてるからといって出たものにすべてイエスというわけじゃない。
それはね、それも大事ですね。
ユーザーにとってちゃんと便利なものになってるかどうかの最終決定権はPMにあるというのは。
そうだね。
そりゃそうだと思いますね。そうじゃないとね、成り立たないと言いますか。
存在意義がね。
他の人がPM求めてることもそうだと思いますね。
はい、確かに。
見てる人がいるから好きかって言いやすいっていうのもいいことだと思うからな。
技術的には絶対こうした方がいいっすよとかって。
いろいろ言うつもりで言ったりもすると思うから。
そんな感じですかね。
何ですか。
チームによるけどフォーカス領域はあるということですね。
そうですね。ちょっとまた話しますかね。
いろんなPMとは何なのかみたいな。もっと話せるような気もする。
今日はこんなところですかね。
では、ありがとうございました。
