MTS#7「プロダクトマネジメントとデザイン」 イベントレポート
MIDAS TECH STUDYの運営チームから、以下の問題提起がありました。
・『どう作るか？』も大事だが『何を作るか？』の重要性が増してきている感覚がある
・プロダクトマネージャ、デザイナーの視点を取り入れることが有効ではないか
そこで、3月11日にデザインxプロダクトに強みを持たれるdely 坪田さん(@tsubotax)、ソウゾウ 鈴木さん(@nobgraphica)、TBSテレビ 野田さん(@ktknd)といった錚々たるメンバーにお集まり頂き、MIDAS TECH STUDY #7 「プロダクトマネジメントとデザイン」を開催しました。
本レポートでは、そこで行われたパネルディスカッションでパネラーの方々からお話いただいた内容をお伝えします。
PMとデザイナーの役割の違い
「PMとデザイナーの役割の違い」というテーマで、各自のバックグラウンドや現在の状況を踏まえて語っていただきました。
ここでは、坪田さんのお話をピックアップします。坪田さんはクラシルで、プロダクトビジョンとプロダクトに関する各スクワッドのKPIとを見立て、結合する役割を担われています。連続的な機能開発でいくべきか、非連続なものとすべきかの判断は経営方針も含めて検討されています。その経験内容を聞いた他パネラーや視聴者の方は、「ユーザー中心」への忠実さを理想論としては理解しつつも、それを実現する難度の高さに驚きを持っていたのが印象的でした。
坪田さん
『クラシルではPdMを「役職ではなく役割」と位置づけており、専任のBizDev担当者は置いていない。
その代わりに例えば、ユーザー志向に探索を行う場合はデザイナーが、グロースフェーズで色々な機能を試す場合はエンジニアが、といった具合にスクワッドミッション*1に合わせて適任のメンバーが担当する。
とにかく「ユーザーへの価値をアジャイルに実現しよう」という本質からズレないように、抽象的なロードマップや中期計画は作らない。もちろん各自でのプロジェクトマネジメントは行うが、どうせ2週間もすれば変わってしまうのでスケジュールは引かない。』
*1 クラシルでは、エンジニア数が10人を越えたあたりからQごとに特定のミッションを背負ったスクワッド（小規模チーム。MIDAS TECH STUDY #1「ユニコーン企業のひみつ」 でも取り上げています）形式で開発の運営を行っている。対話量を重要なチームKPIと位置づけて、朝会の人数は6人をMAXと決めている
運営所感
アジャイルやスクラム開発の本質は「職能横断的に動けるチームであること」ですが、実際にそのような体制で動けるチームは少ないと感じています。
クラシルの話は、「デザイナーやエンジニアがより得意な価値追求に集中できるようにするため」に経営陣がコミットしている非常に良い例でした。
デザイン的観点から考える「良いプロダクト」
「良いプロダクト」自体を定義することは難しいという出発点から、各自の「良いプロダクト」にたどり着くための具体的なアプローチをお話しいただきました。
野田さん
『100周くらいして「結局Lean Canvas*2が最強ではないか」という結論に至っている。役員や投資家といったステークホルダーが多い環境や、会議参加者が非常に多い大企業において、コンセプトを大切にしつつ、そこから経済性を加味してサステナブルな事業にしていくための抽象的な道筋の合意形成には前述のフレームワークを使うことが効率的だという実感がある』
鈴木さん
『インハウスでも、クライアントワークのスキルは当然大いに活かせる場面もある。しかし、代表や役員と直接話せる小さな環境だと合意形成の仕方を工夫するより、実物で見せに行くほうが早いこともある。経営としてのロードマップとは別に「言葉/文章以外での対話のための叩き台」として状態・体験軸での未来像をビジュアルで作るようにしている』
坪田さん
『確実性の高低は意識するようにしている。特に自分が取り扱うtoCやUGCといった分野は不確実性が高く、デザインとコンテンツの両軸でプロダクトを育てていく面がある。めちゃくちゃ優秀なデザイナーに、将来たどり着くだろうデザインを作ってもらうという手もあるが、今はめちゃくちゃ早く価値検証ができるデザインをどんな形式でもいい*3から作ってしまうようにしている』
*2 https://goodpatch.com/blog/lean-canvas
*3 Repro、KARTE、Firebaseなどを組み合わせたものから、手書きで紙に書いたものまで。「どのくらい作り込むか？」という質問に対して「自分がユーザーでないほど、早く検証を回せるようにするためには雑な方がよい」と回答されていた
運営所感
事業のフェーズやステークホルダーによって効率的なコミュニケーション方法は変わってくるという事例でした。画一的なフレームワークにあてはめるのではなく、自分たちの組織に合ったコミュニケーション方法を選ぶことの重要性が伝わってきました。
エンジニアやデザイナーなどチームの巻き込み方の工夫
MIDAS TECH STUDYはTECHイベントです。そのため、普段は協働の仕方をエンジニア目線で話を聞く機会が多いです。しかし、今回はPMやデザイナー目線から見る協働のお話を伺いました。
鈴木さん
『メンバーがコメントしやすい叩き台をいち早く作ることを意識しており、試してよかったことをプロダクト開発の標準的なプロセスに組み込むようにしている。ここ4年ほどフィードバックをもらう手段を試行錯誤してきたが、作るもののイメージがつけばエンジニアは勝手に選択肢を考えた上で作ってくれる。変に作り方の制約を設けないようにしている』
野田さん
『デザイナーは「コレを作って」と指示されてしまうとモチベーションが上がらないケースが多い。デザイナーと協働する際は、あえて自分一人で考え切らずに相手の意見を求める「余白のあるコミュニケーション」を取ることで「意思決定を演出する」ということを意識していた』
坪田さん
『人間は一気に情報を伝えられると、すべてを受け入れられないという習性があるため、意思決定のステップの随所で巻き込むようにしている。また、やらないといけないことは無限に湧き出てくるものなので「上位2つしかやらない」など強い意志を持つことでフォーカスすべきものはぶらさないようにしている。エンジニアと協働する上でも、技術自体のことは理解する必要はないと考えているが、人間力と思考は必要』
PM x デザイナーのキャリア
最後に「デザイン」分野にも強みを持つパネラーに、これまでのご自身の経験、これからのご自身の展望をもとにキャリア構築のお話を伺いました。
坪田さん
『事業会社のPMにしろ、デザイナーにしろ「ユーザー体験をデザインして、エンジニアリングして作られたソフトウェアがユーザーにどんな影響を与えるかを認識し、結果を予測して最適を決められる能力」が求められる。自分の場合は、まだ職種分業が成熟していなかったこともあり、事業を上手く作り上げるためにデザインも、コーディングも、インフラ構築も取り組んできた。その結果、勘所をおさえることにつながっている』
鈴木さん
『年齢的にも坪田さんと近く、同様に何でもやるという環境で育ってきた。デザインだけしていても上手くいかないので、他の領域にも拡げていくということをしてきた。「そのままでいいのか」それとも「もっと事業を上手く展開させたいのか」ということで腹決めしたことが現在につながっている』
野田さん
『企画や実装といった具体的に何かを「つくる」業務もあるなかで「UXデザイン」という抽象的なレイヤーに専門性を持つことに多少のコンプレックスを抱えていた。改めて現在、週末プロジェクトという形で周囲の助けを得ながら、オーナーとして「ものをつくる」サイクルを回してみる経験をして「これがPMだ」ということを実感している』
運営所感
「どうやったらxxになれますか？」という問いには、「実践するしかない」という見解はお三方ともに共通していました。
「プロダクト開発で届けたい価値に真剣に向き合うからこそ、自分ができないことに挑戦する。そして、その結果としてできるようになるのであり、その逆ではない」という考え方が展開され、非常に示唆に富むディスカッションでした。
まとめ
パネラーの皆さんは、デザイナーxPMキャリアを歩まれていることもあり、チームの作り方や仕事の進め方において「ビジュアルにすることを意識的に行う」「俯瞰的に物事を捉える」ことを意識されていました。
また、デザイナーxPMとして「インハウスとクライアントワーク」「大規模組織と小規模組織」でどのようにサービスづくりに携わるのかというお話が短い時間の中でお聞きできたことは、多様な経歴を持つパネラーの方々ならではだったのではないかと思います。
最後に、キャリア形成においてはどなたも「オーナーシップ」「実際に自身で体験してみる」ことの大切さをどなたも話されていたことは、エンジニアのキャリアパス論でも同様によく取り上げられる話題のため、どのような分野においても重要なことだと再認識できました。
お忙しい中ご登壇・ご聴講頂いた皆さま、ありがとうございました。