https://codezine.jp/article/detail/13762
シェアしました。
プロダクトマネジメントにおいて重要な「ユーザー理解」。ユーザーの課題を理解し、それをどう解決できるか、といった観点でプロダクトに向き合うことは、プロダクトの体験向上、ひいては事業成長のために不可欠だ。しかし、実際に現場で取り組むにはさまざまな壁があるだろう。プロダクトマネージャー1人が課題を理解していても、他部署の理解、改善のためのリソースや体制なくしては実践することはできない。そんな中、ビジネスチャットツールを開発するChatworkでは、プロダクトマネージャーとデザイナーが連携し、デザイナーもユーザーインタビューを行うなど、ユーザー中心の開発を推進しているという。柔軟な組織編成によって醸成された本質的な「ユーザーファースト」文化とは。またそれを実現する秘訣とは。プロダクトマネージャーの石田隼氏、UI/UXデザイナー兼UXリサーチャーの仁科智子氏の両名にお話を伺った。
| 目次 |
|---|
プロダクトマネージャーとデザイナーが密に連携する組織とは
――まずは自己紹介を兼ねて、お二人のChatworkでのお立場や働き方などについて教えてください。
石田隼氏（以下、石田）：プロダクト開発を統括するプロダクト本部のもと、私は7名のプロダクトマネージャーが所属するプロダクトマネジメント部のマネージャーをしています。プロダクト戦略策定や方針決定、メンバーのサポートなどを行いながら、自身もプロダクトマネージャーとしていくつかの開発プロジェクトを担当しています。
仁科智子氏（以下、仁科）：石田と同様、私もプロダクト本部に所属し、クラウド型ビジネスチャットツール「Chatwork」のUI/UXを担当するデザインチーム「プロダクトデザイン部」のマネージャーをしています。マネージャーとしてチーム目標の設定、アサイン計画、5名のメンバーの目標管理などを行いつつ、デザイナーとしての仕事も並行しています。
――どのような体制でプロダクト開発を進めていらっしゃるのですか。
石田：基本的にはプロダクトマネージャーとデザイナーが2人1組で連携しプロジェクトにあたっています。
まず、2か月以上の大きな規模の開発（ロードマッププロジェクト）の場合は、プロジェクトごとにプロダクトとデザイナーがアサインされ、2週間～1か月ほどで要件を決めてから実作業を開始します。いわば「プロジェクト型チーム」ですね。一方、ユーザー要望や社内からのフィードバックから生まれた「小さなカイゼン」の場合は、職能横断の固定チームで継続的に取り組み、1～2週間で要件を決めたらすぐに開発していきます。
将来的には、プロダクト開発組織全体を職能横断型の固定チームにして、ロードマッププロジェクトも開発したいと考えています。
組織改編によるオーナーシップ醸成で、デザイナーの仕事が変わった
――「プロダクトマネージャーとデザイナーが連携している」というと、デザイナーはどの段階から関わるのでしょうか。また、どんなメリットがあるのでしょうか。
仁科：かなり初期の段階から関わっています。以前は、プロダクトマネージャーが改善点を決め、エンジニアと相談して実現性を見極めたところで計画を立て、デザイナーが参加する流れでした。そのため「どうやって解決するか」が先行し、あれもこれもと機能を追加して画面デザインが錯綜することが多かったんです。
そこで、現在ではデザイナーが計画の初期から参加し「どうやって解決するか」の前の「何を解決するか」をプロダクトマネージャーと議論し、改善ポイントを決定してから開発・実装に入ることで、より的確に作業を進められるようになりました。
石田：初期からデザイナーに参加してもらうことで、プロダクトマネージャーだけでは思いつかないような体験のオプションを早期に検討できて助かっています。デザイナーも、決まった企画のデザインを社内受託的に受けるより「何を解決するか」を理解して取り組む方がオーナーシップが上がるでしょう。実際、品質も上がったように感じます。
仁科：他のスタートアップ企業でも多いと思うのですが、かつてデザインチームは1チームで、プロダクトもコーポレートサイトも、パンフレットやノベルティに至るまで、あらゆる案件を「受託状態」で受けていたため、常にオーバーフロー気味でした。
そこで、約2年前にブランドのコミュニケーションデザインを担うチームと、プロダクトの体験向上を高めるチーム（仁科氏が所属するプロダクトデザイン部）の2つに分割したんです。それだけでも、かなりメンバーが自分自身の役割やミッションを強く意識するようになり、実際にデザインに落とし込む前に「何を理解し、考えるべきか」を自分ごととして捉えられるようになったと思います。
石田：組織改編による意識改革は大きかったかもしれませんね。プロダクトマネージャーとしても、デザイナーの役割が明確になったことで上流から巻き込みやすくなりました。かつてはプロダクトマネージャーメインでユーザーインタビューを行っていましたが、今はデザイナーメインでプロダクトマネージャーは同席する形です。プロダクトマネージャーはビジネスとユーザーの両方を見る必要がありますが、インタビューによってユーザー側に引っ張られがちだったんです。そこをデザイナーが担うことになったことでプロダクトマネージャーの立ち位置も変わり、全体のバランスが良くなったように思います。
片手間になっていた「ユーザー体験の向上」に集中できるように
――組織改編で上流から関わるようになったり、ユーザーインタビューを主導したりと、プロダクトマネジメント的な動きをすることに、デザインチームのメンバーのとまどいはなかったのでしょうか。
仁科：むしろ、デザイナー側も、ユーザー体験のために「こうしたい」と思いながらできていなかったことを、優先度を上げて実践しやすくなりました。
例えば、以前は「ユーザーフィードバック」について、主体的な取り組みができていませんでした。全社員用のチャットに「ユーザーの声」が流れてくる仕組みがあったのですが、いっとき議論になっても開発されないままになってしまうことも多かったんです。現在はチャット上で議論する場は残しつつ、プロダクトマネージャーとデザイナーで構築したデータベースに登録しておき、大きな改定の時に一緒に対応できないか検討できるようにしました。
なお、ユーザーフィードバックのデータベースには、従来バラバラに管理されていたブラウザ版、モバイル版のユーザーの声および、セールスチームがヒアリングしてきた要望、チャットでの検討内容なども統合され、機能やカテゴリなどによって検索や絞り込みができるようになっています。
――優先順位の意思決定はどのように行っているのでしょうか。ユーザーフィードバックの反映にあたって難しいことの一つかと思います。
石田：最終的には人間が決めるということで、議論はがっつりしますね。でも、大量の要望が並列している中から議論を始めるのは大変なので、参考情報として「事業インパクト」や「要望数」などのスコアリングがあって、スコアの高いものから順に本当に必要か検討します。まずはロードマッププロジェクトにするか、小さなカイゼンプロジェクトにするか大きく2つに分けて、さらにチームごとに優先度をつけていく感じでしょうか。
それとはまた別に、セールスなどビジネス側からの要望としてプロダクト本部からも改善要求が来るので、それもマージして実行していきます。どうしても事業価値を意識した施策と、ユーザー体験を改善する施策は、同じ天秤で量れない。例えば、ユーザー体験を変える「リアクション機能の追加」と、事業価値をもたらす「決済方法の追加」は同じ粒度で量ることは難しいと思っています。そこで、あらかじめロードマップの中に両方のための余白をとっておくというイメージです。
| 目次 |
|---|
ユーザー理解で事業価値を高める文化、鍵はユーザーインタビュー
――「何を開発するか」はプロダクトマネージャーとデザイナーが中心となって検討しているとのことでしたが、その他のメンバーと納得感を共有するために、意識していることはありますか。
石田：特にロードマッププロジェクトの案件は、全員の納得感を得るのは非常に難しいです。どうしても各々が自分に見えているユーザーと比較して捉えてしまうので。とはいえ、頭では理解してもらえるよう、プロダクトマネージャーとしては事業ビジョンや戦略とひもづけて説明することが必要だと思っています。特にビジネスインパクトのための開発とユーザー体験のための開発の配分については、経営層と「今重視すること」を握って説明を行ったり、時には役員から直接話してもらう機会を設けたりしています。
基本的に、Chatworkは全社的に「ユーザーフォーカス」の考えが根付いてます。社内のあらゆる関係部署でユーザー視点を共有しようという意識があり、例えば、以前は朝礼でセールスチームから「今月の事例」として新規ユーザーの動向を紹介していました。そのほかにも、デザインチームからユーザーフィードバックとして既存ユーザーの声を共有する機会などがあることで、エンジニアも何か改善依頼があった時に「ああ、あの事例の件か」と背景を理解しやすいわけです。
仁科：やはりユーザーインタビューのインパクトは大きいですよ。案件に取り組む前に課題の確認や仮説の検証などを行い、絞った仮説からアイデアの効果について見るユーザーテストも行っています。平均して月5人くらいに実施しています。改めて、ユーザーフィードバックをデータベースにまとめるだけだと、なぜそれが必要というのかわからないんですよね。同じ機能を求めていても、理由や背景が全く違うこともあります。そこを推し量るためにもユーザーインタビューは有用だと思います。
ただ、インタビューもデザインも行うデザイナーの負荷は高まっているので、ユーザーインタビューなどの知見を持つ人とUIデザインにしっかり落とし込める人、とそれぞれのスキルを高めながら分業していくことも考えています。
石田：かつてプロダクトマネージャーがユーザーインタビューを行って、モックを作ってテストもして……と1人で行っていたところを、デザイナーが上流まで上がってきてくれて分業し、さらにそれが複数名体制になっていくという、そんな流れになっています。事業や組織が大きくなるにつれて、うまく分業や権限委譲をしていく必要が生じてきたので、まさにその過渡期といえるでしょうね。
自分の領域をかたくなに決めず、状況に応じて役割を変えられる文化
――Chatworkさんは組織がスケールするにつれて権限委譲や協業をうまく行っている印象があります。秘訣は何でしょうか。
石田：「これは自分の領域だ！」と守りたがる文化、人を作らないことでしょうか。Chatworkには他の人の知見から学ぶ、新しい人にどんどん任せるといった文化が、現場だけでなく経営層にもあると思います。そして、新しい人に権限委譲することで、これまでその領域をやっていたメンバーがより自分の強みにフォーカスしてパフォーマンスを出せるようになると考えています。
仁科：スタートアップということもあって、組織の変化に応じて「役割を変えるのが当たり前」という認識があるからかもしれません。最近も、プロダクト本部の中にDevHRチームというのができて、そこはプロダクト本部の人事や採用などを担当しているのですが、例えば仕事上の問題が生じた時に自分の上長に相談する前にそこに相談することができるんです。そんなふうに、課題があれば新しい部署も作ればいい、役割を変えればいいという、変幻自在さは強みかもしれません。
石田：横のつながりも大きいですね。プロジェクト以外でも隣のチームと頻繁にコミュニケーションができるようになっていて「改めてお願いに行く」「社内受託する」のではなく、気軽に相談したり、議論したりできる。仁科さんともめっちゃ話してますよね。
仁科：本当に！ もしかするとチームメンバー以上かもしれませんね。互いのチームの課題感が共有できて、その課題に対して解決策をお互いのリソースも含めて考えられるというのは心強いです。
――そうした連携をとりながらも、お二人はプロダクトマネージャーとデザイナーという立場でそれぞれ職能領域やミッション、評価は異なると思うのですが、どのように分かれているのですか。
石田：プロダクトマネージャーの主軸は「ユーザーの課題解決を通じて事業成長につなげること」にあり、基本的には事業に向き合っていることが必要だと思っています。しかし、その手前に「ユーザーの課題解決」という目標があり、そのファーストゴールのクリアのためにデザイナーの力が必要という認識ですね。業務領域はプロダクトの”ゆりかごから墓場まで”で、そのためには不足していることは何でもするスタンスですが、中でも最も重要なのは適切な「課題の抽出」と「ソリューションの見極め」だと思っています。その意味でもデザイナーとの連携・協働は最重要視しています。
なお評価は、能力目標と実績目標に基づいて行われます。能力目標の方は評価基準を作成して客観的に評価し、次の目標を設定します。実績目標については、人によって異なり、グロース領域を担当する人なら事業KPIにひもづくKPIを目標に定めて達成度合いを見ます。ロードマッププロジェクトの担当も遂行した上で数値的なKPIで評価できれば理想的ですが、現在はそこまで至っておらず、最終的なリリースを実績として評価しています。
仁科：プロダクトデザイン部としては、ユーザーに向き合うことが第一ですね。その意味では、事業成長まではミッションと捉えていません。職務領域としては、ユーザーの課題発見と仮説の絞り込みのため、判断材料を提供しながらファシリテートすることが一つ。そしてもう一つは固定概念にとらわれず、広い視野で課題解決策を見いだし、実現可能性を見定めながら提案することと認識しています。評価についても、やや定性的にはなりますが、この2点においてDevHRチームに相談しながら行っています。またプロダクトマネジャー部と同様、実績と能力の2つの軸で評価しています。
これからもユーザーファーストな開発環境を実現するために、歩みを止めない
――今後、ますます組織をスケールさせていくにあたり、どのような方ならChatworkで活躍すると思われますか。
仁科：現在UIに強いメンバーの方が多いので、今後はUXに強いデザイナーに来てもらえると、お互い補完しながら強みを発揮できるのではないかと期待しています。そして、やはりChatworkの「働くをもっと楽しく、創造的に」というミッションに共感があり、「それはどういうことだろう」と考えながら、共にプロダクトでそれを実現したいと考える方に来ていただきたいですね。
また、スキルとしてはデザイン決定においてオーナーシップを持ってファシリテートできる方が望ましいですね。そのためには、主観ではなく、ユーザーの課題を吸い上げて判断し、周囲を納得させながら進行する力が必要です。自社でもクライアントワークでもいいのですが、そうした経験のある方、意欲のある方であれば、面白い仕事ができると思います。
とはいえ、初めは私たちが一緒に伴走して、進め方を理解してもらうとともに、社内コミュニケーションがとりやすいように環境整備を行います。スキルが足りない方もティーチングとコーチングを駆使しながら、オンボーディングで育成する感じですね。また今年から新たに、全社的にUXディレクションをするポジションを新設しています。今まで以上に、UXの経験や知見のある人に相談しながら、デザインに取り組める環境になってきていると感じます。ゆくゆくは、UXデザイナーとUIデザイナーがお互いの強みを持ち合いながら協力して取り組めるようになるといいなと思っています。
石田：プロダクトマネージャーもChatworkのミッション・ビジョンへの共感が一番重要だと思っています。今後、事業は拡大し、組織編成も繰り返され、チャレンジングな環境が続くと思うので、そうしたカオスな状態が楽しめることも重要でしょうね。その中で、プロダクトマネージャーとしても役割分化が進み、例えば、技術領域に強い、ビジネス領域に強いといったように、プロダクトマネージャーとして自分の色や特徴を発揮できる方が活躍できると思います。
――最後に、ユーザーファーストのプロダクト開発がなかなか自社で進まないと悩まれている方にアドバイスがあればお願いできますか。
石田：一番効果的なのは、プロダクトマネージャーも含めてデザイナーやエンジニアなど、開発側が「一次情報」に触れられる仕組み、役割設定を行うことだと思います。いきなり仕組みを作るのが難しければ、営業担当者に同行させてもらうところから始めてはいかがでしょうか。プロダクトの弱み、強みもわかりますし、プロダクトをよく知る側だからこそできるセールストークもあります。
仁科：基本的には私も石田さんと同意見なのですが、ユーザーファーストが独りよがりになってしまうと、なかなか組織内で理解が得にくいのもまた事実です。ユーザーの言うままに従うことではなく、ユーザー価値を高め、それが事業価値となると説明できなければ、ユーザーファーストな開発環境の実現は難しいでしょう。ユーザーにとって価値があることでも、エンジニアリングで実現できなくては意味がないですし、「市場価値」や「ユーザー価値」「実現可能性」といった3軸で説明できるよう、仲間を見つけるのが大切だと思います。
石田：このあたりは、私たちもまだ試行錯誤中ですよね。5月に開催予定の弊社初主催のテックイベントで、この辺りの「ユーザーファーストな開発」を行うための日々の試行錯誤について、話しますので、ぜひご参加いただければと思います。
Chatwork Dev Day 2021
開催日時：2021年5月26日（水） 13:00～18:00
――ありがとうございました。
0 コメント:
コメントを投稿