デザインリニューアルプロジェクトを頓挫させたPdMの話
はじめまして、りんちゃむと申します。
私は現在、amptalk株式会社でセールスイネーブルメントSaaSのプロダクトマネージャーをしています。
プロダクトの価値を最大化しお客様の課題を解決するべく奔走する日々を送っています。
このnoteでは、前職で任された一大プロジェクト「デザインリニューアルプロジェクト」を自分の至らぬところの多さから頓挫させてしまった話をしようと思います。
失敗には必ず学べるところがあると思うので、ぜひ反面教師にしていただけると嬉しいです。
プロジェクトが立ち上がった背景
前職で携わっていたプロダクトは、ユーザーが20万を突破するなど多くの方に利用されていたホリゾンタルSaaSでした。
ローンチ後4年程度経過していたこともあり、多くの機能が実装され、それにより以下の問題が顕在化していました。
・機能が増えすぎて、ユーザーが必要な機能を見つけられない
・情報構造が整理されておらず、予測も困難
・デザインに統一性がなく、学習コストが高い
新機能や既存機能の開発をする際に、部分最適で開発を行うことはよくあることで、うなずいてくださるPdM仲間も多いのではないでしょうか。
これはシンプルに視野が狭かったり、考える時間がなかったり、また全体最適を考えると開発工数が嵩んでしまったりといったことが要因です。
前職のプロダクトも例に漏れずそういう背景で、大きく体験を改善するには全体最適を考える必要がありました。
全体最適を行い体験をスムーズにすることが、PLG（Product Led Growth）のプロダクトにおいては非常に重要で、その文脈で私が起案し承認をもらいました。
プロジェクトの計画
起案当時どのように進める予定だったかの計画は以下です。
プロジェクトメンバー
私（プロジェクトマネージャー）、デザイナー1名、エンジニア1名の計3名
スコープ
情報設計を見直し、現状のデザインを最小限の変更で最適化
ステップ
プロダクトの機能を大きく3つに分け、ユーザーが体験する順番にステップを切り1つずつ開発する。
開発期間
ステップ1に6ヶ月、その後のステップ2・3は1の結果を鑑み決定
頓挫した要因
頓挫した要因を全て挙げるとキリがないのですが、主な要因は2つありました。
1. コミュニケーションに失敗した
主に私がコミュニケーションに失敗した相手は、デザイナー、エンジニア、プロダクトオーナーの3役職に対してでした。
まずデザイナーとのコミュニケーションでは、デザインのスコープ切りの際に納得させられるような材料を持ってくることができずに、スコープが当初よりもはるかに大きくなってしまいました。
デザイナーとしてプロダクトのデザインに責任を持つ必要があるため、彼らの立場から「より大きなスコープでデザインの変更を行いたい」という提案があることは至極当然かと思います。
私はスコープを広げないために、常に「工数がないので最小のデザイン変更で行きたいんですよね」と伝えていましたが、それは説得材料にはならず、スコープはどんどんと広がっていき、最終的にはデザインフルリニューアルプロジェクトと化してしまいました。
次にエンジニアとのコミュニケーションでは、マイクロマネジメントされていると思われたくなく、進捗の確認頻度を週2程度でしかとらなかった結果、開発がどんどんと遅れてしまいました。
報告のたびに言われる「予定から遅れています」。当時はこの言葉に対し、「そうなんですね、どの程度遅れそうですか？」と遅れる時間軸のみを聞いていました。
その結果遅れた日数が積み重なり、最終的に6ヶ月で完了予定のプロジェクトは1年を超える大規模プロジェクトになっていました。
「詳細を根掘り葉掘り聞くとマイクロマネジメントされている印象を与える」「マイクロマネジメントされるとエンジニアはスピードが上がるどころかやる気をなくす」という偏った思い込みによってエンジニアとのコミュニケーションを最低限にしてしまっていたことを反省しています。
プロダクトオーナーとのコミュニケーションに関しては、直接コミュニケーションをする機会を自ら作りに行かず、「伝わっているはず」という前提ですべてを進めていたことが失敗でした。
結果として、遅れが出ているのにもかかわらず開発リソースの追加や代替案の検討が行えないまま、プロジェクトが頓挫してしまいました。
関わってくださったデザイナー、エンジニアの2人に申し訳ない気持ちでいっぱいでした。
2. インパクトのみを考えユーザーの声を軽視していた
2つ目の要因はユーザーの声を軽視していたことです。
実を言うとプロダクトはユーザーから「直感的でとても使いやすい」「初心者でも簡単」と評判のプロダクトでした。
しかしその一方で、「細かな設定がどこにあるかわからない」というお声もいただいていました。
そのため起案当初の私の課題感としても、詳細設定の情報構造が最も大きな課題であり、それ以外の部分は必要があればという程度でした。
しかし途中で「よりインパクトを出したい」という欲が出てしまい、ユーザーに最も評価されている箇所のデザインをステップ1に置き、詳細設定の部分はステップ2に置いてしまいました。
結果、想像以上にスコープが広がりフルリニューアルすることになっている部分（ステップ1）が、最もユーザーに評価されていた部分でもあり、変更リスクの高い選択となってしまいました。
学べること
2つの要因が、「巨大スコープで1年以上の開発期間、リスク激高デザインフルリニューアルプロジェクト」というモンスターを生んでしまい、最終的に開始半年ほどのタイミングで打ち切りが決定されました。
振り返っても、あのタイミングで打ち切っていてよかったなと思っています。
この失敗を経て学んだことは2つあります。
スムーズに進めるためにコミュニケーションをうまく使え、手段を選ぶな
プロジェクトマネージャー / プロダクトマネージャー は自分の力だけではなにもできない仕事です。
その分コミュニケーションをあらゆる角度から行うことで物事をうまく進めていくしかないのです。
デザイナーに対しては、開発工数だけでなくユーザーの声やデータ、本などを利用しデザイナーに腹落ちできる内容で納得してもらう手段が取れたかなと感じています。
もっともっとデザイナーに寄り添いながら方向転換を促せる方法はあったはずです。
エンジニアに対しては、遅れた背景をより詳細に聞くことができれば、次回の工数見積もりに活かせたなと思っています。
あらかじめエンジニアと強い信頼関係を築き、遅れた詳細の聞き方も「私に力を貸してください！！！」と言ったスタンスで聞けば、不快な思いをさせることはないはずです。
エンジニアの癖やどういうスタイルが仕事がしやすいタイプかを把握するのもコミュニケーションで補える点だったなと思います。
プロジェクトを進めるにおいて最も重要な意思決定者プロダクトオーナーとは、人任せにせず直接コミュニケーションをとるべきです。
特に開発リソース配分に関してなど、上司もPdMという役割で自分のプロジェクトを持っている場合は、リソースの奪い合いになるため信用してはいけません。
自分で自分のコミュニケーションに責任を持つ、これが最も大事だと学びました。
最初の課題に何度も立ち返れ、ユーザーの言葉を思い出せ
あらためて最初の課題に立ち返り、ユーザーからの反応を思い出すと、ステップ1にするべきは最も課題が根深い詳細設定の箇所だったことは明らかです。
プロジェクトの進め方としてどう並べると綺麗かや、最もインパクトを出すには、という視点は無視していいわけではないですが、本質的ではありません。
最小工数でユーザーに最大の貢献をする、そのためには課題への立ち返りとユーザーの最も大きいペインの見極めが重要です。
大きなプロジェクトであればあるほど、途中での方向転換の意思決定がしづらく、また頓挫した時のダメージも大きいため、最初の課題への立ち返りと軌道修正は常に行う必要があります。
さいごに
当時はどん底にいるような気持ちでしたが、今振り返ると学び多き経験だったなと思います。
私ほどひどいしくじりをするPdMはいないかもしれないですが、きっとあるある〜と思って見てくださっている方もいるのではないでしょうか。
こんな時期を経て（多少）強くなった私は今amptalkという会社で働いています。
最近10億円を調達させていただき、同じような失敗はできないなと気が引き締まるばかりです。
もしこんな私と働くことに興味があるなという方がいらっしゃいましたら、ぜひ こちら までお声がけください！
いいなと思ったら応援しよう！
