2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
南里勇気氏(以下、南里):では、最後のトピックに入りたいと思います。今回、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.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには