2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
リンクをコピー
記事をブックマーク
南里勇気氏(以下、南里):では、最後のトピックに入りたいと思います。今回、PM×デザイナーのスキルセットを持つみなさんに参加していただいたと思いますが、質問をいろいろピックアップしていると、やはり個人としてそのスキルをどういうふうに身につけていくかの具体的な案を知りたいのかなと思います。
今後、PM×デザイナー人材の需要が増えていく中で、まずはデザイナーがPMになるにはどういうアプローチをしていけばいいのかと、逆にPMはデザイン的な思考をどう学ぶべきかを聞いていきたいと思います。まず坪田さん、どうでしょうか。
坪田朋氏(以下、坪田):これは事業会社とデザイン会社でスキルセットが変わってくると思います。僕は事業会社側の人間なので、その文脈で答えます。
(必要なのは)ユーザー体験を作るフェーズのデザインして、エンジニアリングして、ソフトウェアが作られて、そのソフトウェアがどういう影響を与えるかを認識して、結果を把握できる能力だと思います。
検索機能でもお気に入り機能でもFeed機能もなんでもそうですが、ソフトウェアだけではなく、コンテンツ次第でお客さんの行動が変化するので、その先の行動まで認識しないとデザインは難しいし、PMもできないと思うので、やはりユーザー価値に触れて考える能力が必要だと思います。
人によっては自分でスケールを描いて可視化する人もいれば、誰かに調べてもらって、その勘所を伝えてデータを持ってくる能力か、言語化能力かわかりませんが、そこまでイメージできればPMになれるというか。事業会社のデザイナーにおいてはわりと必然な能力になってきているかなとは思います。
南里:ちなみに坪田さんは、もともと気づいたらできていたのですか。それとも意識していく中でスキルとして積んでいったのですか。
坪田:僕らの時代は、そんなに分業されていなかったんですよ。
南里:何でもやる時代(笑)。
坪田:なので、意識するよりかは、普通にデザインして、自分でコーディングして、ちょっとしたデータベース作ってとするような時代だったので、自分でゼロイチでサービスを立ち上げる経験がたぶん多かったです。
気がついたら分業化してましたが、当時は自分が設計したほうが早いので、そうやってずっと作ってきた感じです。1回、自分でサービスを作ってみるのが、やはり一番勘所を掴みやすいと思います。
南里:なるほど。プロダクトを作るための全部のことを、自分でやればいいということですよね。
坪田:そうですね。弊社もそうですが、実際に事業会社のデザイナーがデザインしている時間は、たぶん10割のうち2割ぐらいです。8割がそれ以外のサービス開発に必要な時間に使っているので、そのあたりの配分の時間軸というか、使い方が変わってくるのを意識できると、近くなるという気はします。
南里:なるほど、ありがとうございます。では同じ事業会社というところで、鈴木さんに振った後に、最後に受託開発経験の長い野田さんに振りたいと思います。PM×デザイナーについて、鈴木さんはどうですか。
鈴木伸緒氏(以下、鈴木):そうですね。僕も坪田さんとほとんど年齢は同じなので、時代的には坪田さんのおっしゃるとおりです。
南里:全部やってきた。
鈴木:そうですね。なんでも。僕と坪田さんは違うバックグラウンドではありつつも、なんでもやる環境下で、その結果が今になっているところはだいたい同じかなと思っています。
僕は事業会社がけっこう長いので、単純にデザインだけしていても何もうまくいかないところにぶち当たった時に自然と他に染み出すふうになったというか、そのサービスをきちんと使ってもらいたいと思えば思うほど、デザインだけ、要はUIだけやっていても何にもなれないということです。
そこにいたいのか、それともサービスをもっと使ってもらいたいのか、そのためには何をしたらいいかというので、その周辺をやり始めたというだけかなと思っています。
だから、ある意味自分の中ではUIだけをデザインしているだけではなくて、その周りも含めてサービスを設計したり、デザインしたりというところにおもしろみを見つけた結果、PMに近づいたのかもしれないという感じです。
南里:鈴木さんの場合は、プロダクトをよりよくしたいという文脈の中で、デザイナーという職種を越えて染み出していったような感覚が近いということですね。
鈴木:そうですね。デザインする領域を広げていったという感覚が、デザイナーの僕には一番しっくりくる表現です。
南里:なるほど、ありがとうございます。では野田さん、どうでしょうか。
野田克樹氏(以下、野田):僕もクライアントワーク経験が長いとはいえ4年ぐらいですが、坪田さんが最後に言ったこととほぼ同じことを言おうとしていました。
僕はもともとはUXデザインという超抽象的なレイヤーのデザインから入って、デザイナーとずっと名乗っていることに、ずっとコンプレックスを抱えています。その周辺領域には、実装の領域やもっと前の企画領域、UIデザインの領域というところがあると思います。
ユーザーリサーチや体験の言語化、ビジョンを言語化するという抽象レイヤーの仕事をしていった時に、ユーザーエクスペリエンスをデザインする、環境を作るうえでは専門性としては絶対必要ですが、PMとなると言葉の定義がぜんぜん違います。
プロダクトをマネジメントしなければいけない、成功に導かなければいけないとなった時に、絶対必要なのは、企画から自分の描いているデザインを作って実装まで、1周のサイクルをやることです。自分で実装はやらなくてもいいと思っていますが、実装して顧客フィードバックをもらって、なおかつそこからピボットして方向性を変えて違うものにしていく経験を自分1人でやる。もしくは自分1人ではないにせよ、自分が一番のオーナーとなってやる経験が絶対に必要だと思っています。
坪田さんの発信をよく見ていて、実際に坪田さんがbosyuを作るプロセスなどを見ると、やはりデザイナーはあの動き方をすべきだと強く思っています。
実は今、会社とはまったく関係なく、自分のサービスを週末プロジェクト的に出そうとしています。でもそれをやってみると、企画して開発会社に発注しようとした時に、「自分はぜんぜん開発のことがわからないな」となります。「なるほど、AWSとVercelみたいなのがあるんや」みたいなレベルから理解しています。
「ああ、なるほど。APIにはこういうAPIとこういうAPIがあるんやな」みたいなのを、エンジニアに「教えて教えて」と言いながら知っていきます。なおかつ、自分がFigmaの画面をいじっていると、「あ、これがプロダクトマネジメントの全体像なんだ」ということが初めてわかります。クライアントワークをやっていて、マイクロサービスを1個作るだけでわかるということです。
結局それをしないと究極的にはPMにはなれないなぁということで、どんなに小さいサイクルでも1周を全部自分が責任持ってやるというところではないかと究極的には思います。
南里:なるほど。ありがとうございます。オーナーシップを持ってやるからこそいろいろなことが気になって、調べてとすることが結局身になっていくみたいな話なのかなと聞いていて思いました。
野田:本当にそうです。これはもう読書では絶対に得られないことかなというのと、どんどんそういう経験を増やしていきたいと個人的には思っています。
南里:なるほど、ありがとうございます。すごくおもしろいです。これは挙手制でいいのですが、デザイナーからPMの観点はあったと思いますが、PMがデザイナーの思考をどう学ぶべきかみたいな、逆の方向で「こうだ」みたいなのがあれば、誰か1人ぐらい共有してほしいです。
坪田:PMがデザイナーの思考をどう学ぶかという話ですか。
南里:そうです。今、デザイナーがPM(の思考をどう学ぶか)というところはみなさんからけっこう出ていたと思うのですが、逆が出ていないので。
坪田:デザインを作ったらいいと思います。
南里:同じように作れという話ですね。
坪田:たぶんどこの会社でも、いいデザイナーさんがいると、(その人は)デザインシステム的なものを作っています。
南里:よく見ます。
坪田:それを組み立てるだけだったら、パワーポイントの操作と同じレベルなので、たぶん3時間Figmaを勉強すればできます。なので、デザイナー思考を学ぶべきかと言えるかは、たぶん食わず嫌いなんですよ。3時間Figmaと格闘すれば、「自分がこういうUIを表現したら、こういう価値が作れるのではないか」みたいな思考性がつかめます。
僕はまずそれをやれと伝えます。デザイン業務の雰囲気はつかめると思います。もう1つ思考という意味だと、デザイナーはわりと俯瞰的な目線で考えるのが得意な人たちなので、ストーリーの体験設計とかをしやすいんですよね。
街を歩いていても、いろいろなところの看板やサインや、建物の構造でも想像できるので「なんかこれ、なんでこういうふうに作られてるんだろう」というのを想像しながら生きると、観察力と作る力の両方がついていきます。やはり手を動かして観察していくのは大事かなと思います。
南里:わかりました。ありがとうございます。今の話を聞くと、逆も共通のイメージです。野田さんの話の、「自分のプロダクトを持ってやってみると」というのは会社ではできないので結局どうやって学ぶのかという視点になりがちですが、根本となるところで、オーナーシップを持ってやれることをしっかり横断的にやることが大事ですね。
話を聞いていて思ったのは、自分の影響範囲というか、自分のオーナーシップで仕切れる範囲で「じゃあプロダクトを作ろう」となると、もうそれは自然に学ぶよねという感覚なのかなということです。
南里:次は質問にいきたいと思います。(スライドを示して)「そもそもエンジニアがPMになってデザインを学べばいいと思う派ですが、それと比べてデザイナーがエンジニアリングを学ぶメリデメについてご教示いただきたいです」という質問ですが、これは今の文脈でいうとどうですか。同じようなメリデメというよりは、作ってみようかという話になりますか。
坪田:エンジニアがPMになってデザインを学べばいいというのは、まさしくそうだなと思うのでいいと思います(笑)。
デザイナーがエンジニアリングを学ぶメリデメは、何を目的とするかにもよると思います。コードを書くのか、(あるいは)抽象的な物事を分解して構造化していくのもエンジニアリングスキルだと思うので、それはどっちかかなと思います。
一番ムカつくのは、多少コードを学んだ浅い知識で、「これ簡単にできますよね?」や「これは複雑ですよね」みたいなことを、専門外の人に言われることです。
デザイナーが多少エンジニアリング、コードを学んだが故に「お前わかった感じで決めつけてるんじゃねえよ」みたいなことになるのが最悪なケースです。それはたぶん学ぶという観点でも足りていないんですよね。
エンジニアリングは、データベースの構造やスケーラビリティを考えたり、ネットワーク知識を身につけたりとさまざまな専門スキルがあると思います。
その人たちと話せるような能力を持つことがエンジニアリングスキルというのであれば、特に自分の管理領域なら会話ができるので、知っておいたほうが、チームに円滑に進むのではないかという理解をしています。
南里:なるほど。ありがとうございます。あと2つくらい質問をピックしましょう。これもおもしろいかなと思います。「UI/UXというレベルならまだしも、『デザイン』はエンジニア・PdMが10年やそこら学んだところで身につくものではないと思っています。そのうえで、PdMが何をわかっているとデザイナーは仕事がやりやすいのでしょうか」というのは、鈴木さんはどうですか。
鈴木:何をわかってくれているといいかというのでいうと、野田さんがたぶん冒頭で言っていたと思うのですが。すごくきちんと用意しないとデザイナーはデザインをできないと思っている方がわりといますが、逆で。僕はいつもそれをやめてほしいなと思ってここまできました。
たぶん、エンジニアの方と同じ粒度で何かスペックを伝えようと丁寧にやってくれる方はいますが、そうするとやれることがすごく定まってしまうので、どちらかというともうちょっと手前のフンワリしたところから一緒にやれるといいなと思っています。
ある意味、PdMの人とデザイナーの仕事の範囲で、かぶっている部分があるんです。野田さんが言っていたリーンキャンバスみたいなところは、PdMでもデザイナーでもいい領域だったりしています。結局、不確実な部分からちょっとずつ角度の高い部分を特定していく作業は、いわゆるダブルダイヤモンドといわれるディスカバリーのところに当たります。
そこはデザイナーでもPdMでもいい領域なので、そこをPdMがやった後にデザイナーに渡してしまうと、もう何もやることがなくなってしまう感覚があるので、探索のところは一緒にやったほうが、デザイナーがすごく活きてくるのではないかなとは思います。
南里:なるほど。ありがとうございます。先ほどの余白の話にすごく似ていて、ついいろいろ言ってしまいがちだけど、そうではないという話がすごく勉強になります。では最後に質問ですが、おもしろいかなと思って。野田さんに、現在直面している課題またはチャレンジについて教えていただきたいです。
野田:これは本当に僕の悩み相談みたいになってしまいますが、僕は先ほども話しましたが抽象的なデザインから入った人間です。会社はTBSに入ったのですが、TBSにはデザイナーが22人ぐらいいます。
番組のセットを作っているデザイナーがメインの人材で、デジタルプロダクト専門のUIデザイナーはあまりいなかったりする状態で、僕はもともとクリエイティブディレクションする人間として入りました。
とはいえ、やはり自分で作れないとだめだと思って、これまでは8割ぐらいKeynoteで仕事をしていましたが、ここ1年はFigma10割ぐらいでずっと仕事をしています。そして、1週間ぐらいで全体のプロトタイプを作ってみたいなことをやっていたりします。
PMと抽象的なことしかやっていなかったUXみたいなとこでいくと、具体的なものを作る力の足りなさみたいなものは、個人のキャリアの課題感ですごく感じています。それを解決するためにがんばっています。
あと会社という点では、僕がTBSの会社の看板を背負うには、ちょっと会社の看板が大きすぎる。とはいえ、やはりコンテンツのパワーはすごくあるとは思いつつ、それをデジタルのチャネルでちゃんと落とし込めているかというと、まだまだだと思うところはあると思っています。
まだ入って1年経っていないのですが、もうちょっとがんばってTBSのデジタルプロダクトを「ちょっと一線を画してるな」と、ここにいるリテラシーの高いみなさんに思ってもらうのが、僕のチャレンジかなと思っています。TBSのアウトプットを見たら、「あ、何。この人要るかも」と思ってもらえたらいいなと思っています。
南里:ありがとうございます。Twitterでキラキラの野田さんでもこういうふうに悩みを抱えているので、鈴木さんも坪田さんも同じように悩みを抱えているかなと思います。今日のトピックに関しては以上です。ありがとうございます。
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.15
好きなことで起業、赤字を膨らませても引くに引けない理由 倒産リスクが一気に高まる、起業でありがちな失敗