プロダクトマネージャーとデザイナーが密に連携する組織とは
――まずは自己紹介を兼ねて、お二人のChatworkでのお立場や働き方などについて教えてください。
石田隼氏（以下、石田）：プロダクト開発を統括するプロダクト本部のもと、私は7名のプロダクトマネージャーが所属するプロダクトマネジメント部のマネージャーをしています。プロダクト戦略策定や方針決定、メンバーのサポートなどを行いながら、自身もプロダクトマネージャーとしていくつかの開発プロジェクトを担当しています。
仁科智子氏（以下、仁科）：石田と同様、私もプロダクト本部に所属し、クラウド型ビジネスチャットツール「Chatwork」のUI/UXを担当するデザインチーム「プロダクトデザイン部」のマネージャーをしています。マネージャーとしてチーム目標の設定、アサイン計画、5名のメンバーの目標管理などを行いつつ、デザイナーとしての仕事も並行しています。
――どのような体制でプロダクト開発を進めていらっしゃるのですか。
石田：基本的にはプロダクトマネージャーとデザイナーが2人1組で連携しプロジェクトにあたっています。
まず、2か月以上の大きな規模の開発（ロードマッププロジェクト）の場合は、プロジェクトごとにプロダクトとデザイナーがアサインされ、2週間～1か月ほどで要件を決めてから実作業を開始します。いわば「プロジェクト型チーム」ですね。一方、ユーザー要望や社内からのフィードバックから生まれた「小さなカイゼン」の場合は、職能横断の固定チームで継続的に取り組み、1～2週間で要件を決めたらすぐに開発していきます。
将来的には、プロダクト開発組織全体を職能横断型の固定チームにして、ロードマッププロジェクトも開発したいと考えています。
組織改編によるオーナーシップ醸成で、デザイナーの仕事が変わった
――「プロダクトマネージャーとデザイナーが連携している」というと、デザイナーはどの段階から関わるのでしょうか。また、どんなメリットがあるのでしょうか。
仁科：かなり初期の段階から関わっています。以前は、プロダクトマネージャーが改善点を決め、エンジニアと相談して実現性を見極めたところで計画を立て、デザイナーが参加する流れでした。そのため「どうやって解決するか」が先行し、あれもこれもと機能を追加して画面デザインが錯綜することが多かったんです。
そこで、現在ではデザイナーが計画の初期から参加し「どうやって解決するか」の前の「何を解決するか」をプロダクトマネージャーと議論し、改善ポイントを決定してから開発・実装に入ることで、より的確に作業を進められるようになりました。
石田：初期からデザイナーに参加してもらうことで、プロダクトマネージャーだけでは思いつかないような体験のオプションを早期に検討できて助かっています。デザイナーも、決まった企画のデザインを社内受託的に受けるより「何を解決するか」を理解して取り組む方がオーナーシップが上がるでしょう。実際、品質も上がったように感じます。
仁科：他のスタートアップ企業でも多いと思うのですが、かつてデザインチームは1チームで、プロダクトもコーポレートサイトも、パンフレットやノベルティに至るまで、あらゆる案件を「受託状態」で受けていたため、常にオーバーフロー気味でした。
そこで、約2年前にブランドのコミュニケーションデザインを担うチームと、プロダクトの体験向上を高めるチーム（仁科氏が所属するプロダクトデザイン部）の2つに分割したんです。それだけでも、かなりメンバーが自分自身の役割やミッションを強く意識するようになり、実際にデザインに落とし込む前に「何を理解し、考えるべきか」を自分ごととして捉えられるようになったと思います。
石田：組織改編による意識改革は大きかったかもしれませんね。プロダクトマネージャーとしても、デザイナーの役割が明確になったことで上流から巻き込みやすくなりました。かつてはプロダクトマネージャーメインでユーザーインタビューを行っていましたが、今はデザイナーメインでプロダクトマネージャーは同席する形です。プロダクトマネージャーはビジネスとユーザーの両方を見る必要がありますが、インタビューによってユーザー側に引っ張られがちだったんです。そこをデザイナーが担うことになったことでプロダクトマネージャーの立ち位置も変わり、全体のバランスが良くなったように思います。
片手間になっていた「ユーザー体験の向上」に集中できるように
――組織改編で上流から関わるようになったり、ユーザーインタビューを主導したりと、プロダクトマネジメント的な動きをすることに、デザインチームのメンバーのとまどいはなかったのでしょうか。
仁科：むしろ、デザイナー側も、ユーザー体験のために「こうしたい」と思いながらできていなかったことを、優先度を上げて実践しやすくなりました。
例えば、以前は「ユーザーフィードバック」について、主体的な取り組みができていませんでした。全社員用のチャットに「ユーザーの声」が流れてくる仕組みがあったのですが、いっとき議論になっても開発されないままになってしまうことも多かったんです。現在はチャット上で議論する場は残しつつ、プロダクトマネージャーとデザイナーで構築したデータベースに登録しておき、大きな改定の時に一緒に対応できないか検討できるようにしました。
なお、ユーザーフィードバックのデータベースには、従来バラバラに管理されていたブラウザ版、モバイル版のユーザーの声および、セールスチームがヒアリングしてきた要望、チャットでの検討内容なども統合され、機能やカテゴリなどによって検索や絞り込みができるようになっています。
――優先順位の意思決定はどのように行っているのでしょうか。ユーザーフィードバックの反映にあたって難しいことの一つかと思います。
石田：最終的には人間が決めるということで、議論はがっつりしますね。でも、大量の要望が並列している中から議論を始めるのは大変なので、参考情報として「事業インパクト」や「要望数」などのスコアリングがあって、スコアの高いものから順に本当に必要か検討します。まずはロードマッププロジェクトにするか、小さなカイゼンプロジェクトにするか大きく2つに分けて、さらにチームごとに優先度をつけていく感じでしょうか。
それとはまた別に、セールスなどビジネス側からの要望としてプロダクト本部からも改善要求が来るので、それもマージして実行していきます。どうしても事業価値を意識した施策と、ユーザー体験を改善する施策は、同じ天秤で量れない。例えば、ユーザー体験を変える「リアクション機能の追加」と、事業価値をもたらす「決済方法の追加」は同じ粒度で量ることは難しいと思っています。そこで、あらかじめロードマップの中に両方のための余白をとっておくというイメージです。
